Üzerinde çalıştığınız projenin kötü bir şekilde inşa edildiği ve gelecekte başarısız olacağı ve sürdürülecek bir kabus olacağı bir durumda olsaydınız ne yapardınız ... ama müşteriler tarafından yönetim tarafından bir "başarı" olarak kabul edilir. mutlu?
Umurumda değil mi? Müşterilerin bundan daha iyi bir uygulamaya sahip olabileceğini bile fark etmemeleri uygun mu?
Hangi noktada doğru inşa etmeyi umursamıyorum ve sadece akışla devam ediyorum?
Yanıtlar:
Müşteriler mutluysa, doğru bir şey yapıyorsunuz demektir. Birçok insan nasıl yapıldığını bilmeden sosisli sandviçin tadını çıkarır ...
Uygulama soruna iyi bir çözümse ancak vakfın hatalı olduğundan endişe ediyorsanız, işleri aşamalı olarak nasıl iyileştireceğinizi öğrenin ve ürünü güncellediğinizde bu geliştirmeleri uygulamak için bir plan hazırlayın. Artımlı anahtar: tüm bölümlerini yeniden yazmak için kaşınıyorsanız, yöneticiniz bunun mantıksız olduğunu söyleyecektir. Mükemmel, iyinin düşmanı olabilir. Look up Netscape onlar yeniden yazmak Navigator "zorundaydı" Çünkü IE kurşun atalım nasıl jwz hikayesini.
Uygulamanın kullanıcı arayüzü kendisi bir karmaşa ise, istemciler yine de mutlu olabilir çünkü "zor yolla" karşılaştırıyorlar ve hatta bir program bile bundan daha iyi olabilir. Arka planınız ve becerileriniz nedeniyle hayal edebileceğiniz bir ideal ile karşılaştırıyorsunuz. Yine, şeyleri artımlı yollarla nasıl geliştirebileceğinizi düşünün ve bunu planın bir parçası olarak sunun.
İlginizi kesmeyin: işinizin olabildiğince iyi olmasını istiyorsunuz. Ama aynı zamanda faturalarınızı ödeyen müşteri olduğunu unutmayın ve onlar için yazılım yazıyorsunuz, siz değil.
Bu onlar için bir kabus değil. Sizin için bir kabus olacak ve ne yaptığınızı bildiğinizi düşünüyorlar, bu yüzden düzeltilecek. Programlamayı anlamayan kişilerin uygulamanızın gerçekte olduğundan daha kötü olduğunu düşünmeyi tercih eder misiniz? Bu bir istisna değildir. Yapabiliyorken tadını çıkar. Daha iyi müşteri bu app outgrows umuyoruz. Bir iş olarak o kadar ileri gidebilirler ki, bu kesinlikle işe yaramaz. Düşündüğünüzden tamamen farklı nedenlerle yeniden yazıyor olabilirsiniz.
Üst yönetim durmuş gibi görünse bile hiç umursamamanız gerektiğini düşünmüyorum. Bence bu deneyimin dışına çıkmak önemli olan yanlış olduğunu düşündüğünüz şeyleri hatırlamak ve belgelemek. Gelecekte bu hatalardan kaçınmak eninde sonunda, şu anki yönetici grubu olmasa bile, belki de çalıştığınız bir sonraki yönetici grubunun farkına varılacaktır.
Kodun kalitesini artırmak için yeniden faktoring içeren geliştirme için bir sonraki adımlar için fikirler sunmaya başladım. Teknik detayların çok derinlerine inmekten uzak durun, ancak önerdiğiniz düzeltmelerin müşteri memnuniyetinin nasıl devam edeceği anlamına geldiğine dikkat edin . Yönetim her zaman yeni bir şey arayacağından temizliği yeni özelliklerle karıştırmaya hazır olun.
Genel olarak, müşteriler bir şeyler ters gidene kadar bakım ile ilgilenmezler. İdeal olarak, şirket itibarını önemsiyor ve kodu koruyarak korumak istiyor.
Bununla birlikte - bu ürün çok kısa vadeli olarak görülüyorsa, gerçekte doğru yapmak için bir katma değer olmayabilir. Bu durumda - ucuz düzeltmeleri arayın - geliştirici aklı için büyük bir değere sahip az çaba gerektiren şeyler.
Yapmazsın. Başarıyı, teknik olarak doğru ve bakımı kolay bir şekilde yeniden düzenlemeye başlamak için fon / izin / satın alma güvenliğini sağlamak için kullanırsınız. Ya da başarıyı "Eski kod tabanını koruyacağım" bölümünden terfi etmek için kullanırsınız.
Belki de önceliğiniz / bakış açınız yanlış.
Herhangi bir yazılım projesi ile ilgili en önemli şey, kullanıcıların gereksinimlerini karşılamasıdır.
Bu, C / S tasarım modalarına göre "doğru" olmanın bir milyar dolar daha önemli.
Evet, doğru tasarım desenlerini kullanmalı, teknolojiyi doğru kullanmalısınız vb. ancak yalnızca kullanıcı gereksinimlerinin sağlam ve sürdürülebilir bir şekilde uygulanmasını kolaylaştırdığı ölçüde.
Gerçekten bir iş ihtiyacını karşılayan gerçekten kötü yazılmış bir sistem, kimsenin istemediği veya kullanmak için herhangi bir nedeni olmayan harika yazılmış güzel belgelenmiş bir kod parçasından her zaman daha iyidir.
Mevcut kullanıcılarla iletişim kurmaya çalışın ve onlara hangi yönlerin iyileştirilmesi gerektiğini düşündüğünü sorun. Ardından, iyileştirme gerektiğini düşündüğünüz bazı yönleri geliştirebilir ve kullanıcıların önerdiği yönleri de geliştirebilirsiniz. Geliştirmelerinizi "kullanıcı tarafından önerilen iyileştirmeleri uygulamak için gerekli" olarak gerekçelendirebilirsiniz.
Örneğin: kullanıcılar arama işlevinin yavaş olduğunu düşünüyorsa. Açıkçası aramadan daha fazlasını sunan daha iyi bir Veri Katmanı oluşturarak bunu geliştirebilirsiniz, ancak daha sonra harcanan zamanı haklı çıkarabilirsiniz.