Durumdaki hayal kırıklığınızın temel nedeni, muhtemelen müşteri tarafından kullanılan algı ve yanıltıcı / yanlış terimlerden biridir. Müşteri genellikle size bir gereksinimler listesi ile gelmez , ancak düşünebilecekleri her şeyin istek listesi onlar için yararlı olabilir . Bunların hepsi şart değildir çünkü müşteri, her özelliğin gerçekten gerekli olup olmadığını gerçekten düşünmek için henüz zaman harcamamıştır .
Bu her zaman bir sorun olmak zorunda değildir
Müşterinizin tüm bu özellikler için parası varsa ve onunla ayrılmaya istekliyse ve müşterinin sahip olduğu gerçek, gerçek sorunları çözmeyi gerçekten umursamıyorsanız , bu çok kazançlı bir proje olabilir. Bu, çok, çok nadiren gerçekleşir ve çoğu geliştirici için ruh öldürücü bir iştir, çünkü projenin sonunda müşteri için başarılı olmayacağını hissedebilirsiniz (bir geliştirici olarak finansal olarak başarılı olsa bile). Aynı zamanda yüksek risklidir, çünkü büyük olasılıkla çok fazla belirsizliğe sahip sabit maliyetli bir projeyle sonuçlanabilirsiniz ve büyük projelerde riski yanlış değerlendirmek gerçekten önemlidir.
Ya bir problemse?
Diyelim ki bu nadir durumda değilsiniz. Bu durumda, istek listesinin iki ana eksikliğini aşağıda belirtildiği gibi ele almak isteyeceksiniz:
- Müşterinin böylesine geniş bir gereksinimler listesi geliştirmenin maliyetleri hakkında doğru bir fikre sahip olması olası değildir, bu yüzden gerçekten yapmanız gereken para miktarı için sözleşme almanız olası değildir.
- Bu istek listesinin, müşterinin sahip olduğu ve çözmek istediği gerçek sorunu doğru ve kısa bir şekilde tanımlaması pek olası değildir.
Deneyimlerime göre, düzeltmek için 2'yi ele almanız gerekiyor. Asıl soruna inmek , geliştiricinin, artık müşterinin hiç düşünmediği şekilde sorunu çözmede yaratıcı adımlar atmak için gerekli girdiye sahip olduğunuz anlamına gelir. Bu çözümlerin, tam istek listesinin uygulanmasından çok daha ucuz ve daha hızlı olması muhtemeldir.
Bunu nasıl düzeltirsiniz?
Matthew Flynn'in cevabında söylediği gibi - müşterinin gereksinimleri önceliklendirmesini sağlayın. Bu her zaman kolay değildir, ancak onları yapmaya zorlar. Gerekirse "Birisi kafanıza silah tutmuşsa, hangi tek koşulu muhafaza edersiniz?" İfadesini kullanın. Bu süreçte genellikle müşterinin bireysel gereksinimlerin ne anlama geldiğine dair çok net bir fikri olmadığını görürsünüz. Bu durumda Peter Rowell'in önerilerini yapın ve müşterinin Kullanıcı Hikayeleri üzerinden çalışmasını sağlayın. Siz ve müşteri sorunu ve gereksinimleri daha iyi anlamaya başlayacaksınız ve ardından önceliklendirmeye geri dönebilirsiniz. Müşterinin sorununu çözmek için yeterli bildiğinizden emin olana kadar bu adımları gerektiği kadar tekrarlayın .
Bu bir çözüm geliştirme sorununu nasıl cevaplıyor?
Öncelikli bir gereksinimler listesine sahip olduktan sonra, müşterinize aşamalı bir geliştirme süreci önermek için ihtiyacınız olan girdiye sahipsiniz. Bunu Agile olarak adlandırmak zorunda değilsiniz, ancak sözleşmeyi her gereksinim (veya bölünmez gereksinimler seti) için daha küçük parçalara ayırmayı ve bunları müşteri tarafından onaylanarak tek tek teslim etmeyi önerebilirsiniz. Veya müşteriyi Çevik geliştirme stillerinden birinde işbirliği yapmanın en iyi yararına olacağına ikna etmek için çevrimiçi ve çevrimdışı kullanılabilir birçok kaynağı kullanabilirsiniz. Her durumda, sözleşme / proje teklifinizi, bu yapı taşlarını öncelik sırasına göre, her birinin kendi maliyeti ve sonucu olan bir şekilde açıkça öneren bir formda sağlayabilirsiniz. O havucu müşterinin önünde tut,