Teknik olmayan bir müşteriye, uygulama özelliklerinin basitleştirilmesi gerektiğine nasıl ikna edilir?


15

Çoğu zaman, 100'lerin gereksiz özellikleri olan bir uygulama ile yeni bir müşterinin bana geldiği durumla karşı karşıya kalıyorum ve projenin başarılı olma şansı elde etmek için işlerin büyük ölçüde basitleştirilmesi gerektiği açık. Müşteriyi daha Minimum bir Geçerli Ürün (MVP) yaklaşımı almaya ve basitleştirmeye nasıl ikna edersiniz?

Düzenle:

Dolayısıyla, mevcut en iyi yanıt, müşteriye büyük uygulama için bir zaman / maliyet tahmini sağlamaktır. Bu cevaba çok düşkün değilim çünkü bu durumla ilgili gerçek problemi çözmüyor. Ve bu - büyük bir uygulama belirtmek ve daha sonra uygulamayı en baştan kullanmaya çalışmak kötü bir uygulamadır. Başlangıçta küçük, basit bir MVP temeli kurmaktan çok daha rahat hissediyorum. Ve sonra bu temele tek tek küçük özellikler ekliyoruz. Peki müşteriyi bina yazılımına bu şekilde yaklaşmaya nasıl ikna edebilirim?


3
Şelale ve çevik / yinelemeli gelişim arasındaki farkı tanımladığınız anlaşılıyor. Bu iki yaklaşımın avantajlarını / dezavantajlarını google'da çevikliğin tüm faydalarını göreceksiniz ve bunları argümanınız olarak kullanabilirsiniz. Bir listem var, ama şu anda kullanışlı değil.
Bob Horn

Yanıtlar:


15

Bu yüzlerce özelliği yüksek kalitede yapmanın ne kadar para / zamana mal olacağını tahmin ederek. Çok, çok az müşteri paralarını ağzına koyacaktır.


10
ve daha gerçekçi hedeflerle projeyi alma şansınızı büyük ölçüde artıran bir alternatif sunacağım.
Paul Hiemstra

1
Mümkün olan yerlerde, tahminleri "çekirdek", "güzel şeyler var", "rüya görmelisiniz" olarak ayırın (bunu müşterinin önünde bu şekilde söylemeyin). Tüm İş Analizi işini ücretsiz olarak yaparken dikkatli olun.
mattnz

@PaulHiemstra - mükemmel nokta. Dahili müşterilerle çalışmaya alışkınım, ama tavsiyeler de orada duruyor.
Telastyn

@Telastyn post post edit
Ryan

Aslında tüm bu özellikler için tahminler koymanıza gerek yok. çevik olun, en iyi yirmi kişiyi seçin ve bunları sürüm 1.0'a x $ karşılığında koymaktan memnuniyet duyacağınızı söyleyin. 1.0'dan 1.8'e kadar olan sürümlerin fiyatını tahmin etmek için önceden zaman harcamak istemediğinizi belirtin.
MSalters

12

İki kelime: Kullanıcı Hikayeleri.

Ben en hızlı yolu, bir istemci A Clue® alın yardım etmek olduğunu öğrendik sahip olmaktır ettik onları her istedikleri özellik veya sayfa için bir kullanıcı hikaye benimle konuşmak. Aşağıdakiler de dahil olmak üzere birkaç şey olur:

  1. Sayfanın / özelliğin gerçekte ne yapması gerektiğini düşünmek zorundalar .
  2. Daha fazla ayrıntı istedikçe ("ve sonra? ... ve sonra? ...") Magic Space Monkeys ™ 'in uçup gitmesini sağlamayacaklarını anlamaya başlıyorlar. hafta sonu boyunca.
  3. Yaratılış sürecinde gerçek ortaklar olurlar. Bu da , halihazırda% 80 tamamlanmış bir şey hakkındaki düşüncelerinin neden değiştirilmesinin a) program gecikmesine ve b) maliyet artışına neden olacağını anlayacakları anlamına gelir .

Ciddi anlamda. Sahiplerin Kullanıcı Öyküleri , sürece en azından biraz akıl sağlığının getirdiği için bildiğim en iyi araçlardan biridir.


7

Maliyet ve üretim zamanı yönünü tartışırken, gerekli minimum özelliklerin (minimum sahip olunan ürün grubu) sürüm 1'de "olması gerekir", ardından gereksinimlerin geri kalanını ilk sürümden sonra sprint olarak gerçekleştirilebilecek biriktirme kümelerine koyun. Umarım gerekli olmayan "sahip olmak güzel" olanlar paketin arkasına gidecek ve bu sprintlere ulaştığınızda (ürünle ilgili gerçek deneyimlerden) daha önemli olan yeni ürünler zirveye çıkacaktır.

Müşteri, işinin maliyetini ve hızlı bir şekilde ürün almanın önemini düşündüğünüzü ve birikmiş iş yerine koyarak sahip oldukları "güzel olmalarını" doğrudan reddetmediğinizi takdir etmelidir.

OP düzenlemesine yanıt vermek için düzenleyin: Müşteriyi neden en erken uygulanabilir bir ürünü piyasaya sürmenin iyi bir fikir olduğuna ikna etmek için, ürün gerçek kullanıcılar tarafından kullanılana kadar (özellikle kullanılabilirlik açısından) başarılı olup olmadığını bilmenin zor olduğunu açıklayın. Müşteri, tüm kullanıcı tabanına erken bir ürün sunmaktan çekiniyorsa, yalnızca müşterilerinin hedeflenen bir alt kümesi için kullanılabilecek bir "sınırlı beta" yapmanızı öneririz. Onlara bu yaklaşımın arka tarafının, ürünün kullanılamaz olduğuna dair geç bir belirleme ile uzun, maliyetli bir geliştirme döngüsü olduğunu söyleyin. : 37 Sinyaller bu konuda iyi referanslar birkaç üretti Real, Alma ve Rework . Gerçek Olmak web'de ücretsiz olarak kullanılabilir.


Bu tam olarak güzel olanların kullanımıdır :) Listeden çıkarmadan insanlar mutlu kalırlar!
Geerten

MuSCoW yaklaşımına benzer.
Thinhbk

3

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:

  1. 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.
  2. 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,


Teşekkürler. Ancak, müşterinin proje başına ödeme yapmak istediğini ve tüm bu analiz çalışmalarının proje fiyatı kararlaştırılmadan önce (potansiyel olarak düzinelerce saat sürebilen) yapılması gerektiğini biliyorsanız, o zaman ilk analiz çalışması?
Ryan

@Ryan - Büyük bir proje için önceden ayrıntılı bir analiz çalışması yapmayı reddederim çünkü a) yanlış fikir verirdi ("Belirsizlik Konisi" - en.wikipedia.org/wiki/Cone_of_Uncertainty ) ve b ) aslında müşterinin projeyi gerçekleştirmek için başka bir yere götürebileceği değerli bir çalışma. Aslında tam olarak bu durumda en az bir kez bildiğim gibi sonuçlandıktan sonra, analiz çalışması için de ücret aldığımızdan eminim (müşteri projeyi kabul ederse iade edilebilir).
Joris Timmermans

1

Öncelikle, gereksinimlerinin gerçekçi olmadığını açıklamaya çalıştım ve onlara bir dizi karşı gereksinim sundum. Bunun sorunlarını daha basit ve daha hızlı çözeceğini ve böylece daha az maliyet ve riskle açıklanacağını açıklayın. Bunu teknik bir tartışma haline getirmeye çalışmayın, müşteri bunu umursamıyor. Müşteri, zamanında iyi bir ürün almayı ve iş vakasını çözmeyi umursuyor. Müşteri bütçe almazsa, ya sözleşmeyi kabul edip işi yapın ya da müşteriyi bu formda proje için neden sorumluluk alamadığınızı reddedip açıklayın.


1

Diğer insanların önerdiklerine benzer, ancak biraz farklı, müşterinin her şeyin geçerli olabileceğini, ancak ÖNCELİKLENDİRMELERİ gerektiğini öneririm. İlk olarak hangi öğenin yapılması gerekiyor. Hangi öğenin ikinci yapılması gerekiyor. En önemlisi, zamanınız tükenirse, hangi öğelere sahip olmamanız en az zarar verir. Her öğeyi 1'den 732'ye (veya her neyse) önceliklendirin ve bu sırayla tamamlayın.


1

Aşırı gereksinimler nedeniyle bütçe ve zamanlamanın gerisinde kalan bir uygulamanın tarihsel bir örneği, FBI'ın Sanal Vaka Dosyası'dır. Birkaç düzine mevcut uygulamanın yerini alması amaçlanmıştı ve hepsinin aynı anda tamamen geçiş yapması gerekiyordu. Proje sonunda iptal edildi. Başarılı olacak bir çerçeveyi tasarlamak ve bireysel uygulamaları yeni sisteme aşamalı olarak değiştirmekti. Bunun yerine, politika ve kavga her uygulama paydaşının, uygulamalarının en önemlisi olduğunu ve herkesin mevcut uygulamaya eklenmesini istedikleri tüm özelliklerden "olmazsa olmaz" özelliklerine sahip olduğunu iddia etmesine yol açtı. Sonunda, her gün yazılan değişiklik taleplerinin hacmi, her gün gerçekte yazılan kod miktarını aştı.

2 vakada "Her şeye sahibim" çalışmasını gördüm. Birinde, büyük finansal müşterinin (her şeyin şelalesini kullanarak), 40 farklı sistemi (şirketimiz 40'tan birini yaptı) değiştirildi ve bir kez düştüğünde faaliyete geçti. Entegrasyon testi ve iletişim büyük sorunlardı. Benim tahminim, konferans görüşmelerinde (görüşmelerdeki herkesin faturalandırma oranını saydığınızda) yaklaşık 100 bin dolar / gün yaktığıdır. Her iki durumda da, teslim edileceklerin listesini çıkarmak için güçlü müzakereciler aldı ve sonra herkesin ayaklarını yere çiviledi. Kale direkleri hareket etmedi, yeniden müzakere yoktu. Her iki iş de zamanında ve spesifikasyonda sona erdi. Biri bütçe üzerinden, diğeri bütçe üzerindeydi. Bunun için takımlarının neler sunabileceğini bilen çok iyi proje yöneticilerine ihtiyacınız var (Q özelliğinin 3 aldığını söyleyebilen tür).

Mükemmel PM'lere, müzakerecilere ve metriklere sahip olmayan müşteriyi artımlı teslimatlara itmeyi öneririm. Hala tüm altın tuğlayı bir kerede istiyorlarsa, başka bir danışmanlık bulmalarına yardımcı olarak daha iyi servis edilebilirler. Bazen en iyi cevap "size yardımcı olamayız".


0

Kısa Cevap: Müşterimi dinlerim ve onlarla orta yol yaklaşımını bulurdum.

Müşteriyi dinlemenizi ve bütçelerine ve zamanlamalarına bağlı olarak, projeyi aşamalara ayırın (sürüm, sürüm2, vb.).

Ardından, uygulamanın sunması gereken gerekli özelliklerin teslim edilebilirliği, bütçesi ve önceliklendirilmesinin her aşamasını tahmin etmeye devam edebilirsiniz.

Bu nedenle, iş kapsamını ve çıktıları tanımlamak için bir yol :)


0

Diğer cevapların belirttiği gibi, önceliklendirme çok önemlidir. Bunu yapmanın kullanışlı bir yolu MoSCoW yöntemidir . Ancak tüm listeyi bölmekle başlamak isteyebilirsiniz, aksi takdirde özellik listesinin kendisi size (veya müşterinize) anlama sorunlarını verecektir :)

Bunun yanında, soruna bir bütün olarak bakma probleminiz var. Bunu muhtemelen müşterinizle oturarak çözebilir ve aşağıdaki adımları uygulayabilirsiniz:

  • Özellikler boyunca dünya çapında ilerleyin ve kategorileri onlardan ayırın
  • Kategorilere öncelik verin (MoSCoW kullanarak) ve belki bir hiyerarşi tanımlayın (varsayılan özelliklere sahip bir temel kategori, ana konular için kategoriler, ana konuların belirli varyasyonları için kategoriler). Bu, önceki adımda tanımladığınız kategorileri değiştirebilir (yeni bilgiler sayesinde).
  • Her özelliği tek tek gözden geçirin ve bir kategoriye atayın
  • Top-x kategorilerindeki öğelere öncelik verin (MoSCoW kullanarak).

Bu, istenen özelliklerin güzel ve yoğun bir yukarıdan aşağıya görünümünü verecektir ve bir tabanla başlamak ve diğer özelliklerle genişletmek için farklı yinelemeleri tanımlamak için gidonlar verecektir.


Tamam. Ancak müşteri proje bazında çalışmak isterse, proje başına sözleşme kararlaştırılmadan önce tüm bu planlama işleri için size ödeme yapmaya nasıl ikna edebilirsiniz?
Ryan
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.