Uygulanabilir olup olmadığından emin olmadığınız bir özellik sunmaya söz vermeli misiniz?

HN'nin bir makalesinde aşağıdaki tavsiyeye rastladım:

Emin değilseniz bile müşterinize / kullanıcınıza "evet" deyin. Zamanın% 90'ında bunu yapmanın bir yolunu bulacaksınız. Zamanın% 10'u geri döner ve özür dileriz. Büyük kişisel büyüme için ödenecek küçük fiyat

Ama ben her zaman bir müşteriye / kullanıcıya herhangi bir söz vermeden önce fizibilite analizi yapması gerektiğini düşündüm , böylece hiçbir noktada yanıltılmasınlar. Peki yukarıdaki şartlar hangi durumlarda geçerli olmalıdır?

Bu, kısa bir süre sonra bu makalenin tetiklediği ikinci sorudur.

• İyi programcı: Kodu optimize ediyorum. Daha iyi programcı: Verileri yapılandırıyorum. En iyi programcı: Fark nedir?
  Bunun başka bir adı daha var: erken optimizasyon.

• Asla erken çıkış kullanmayın.
  "Tek giriş noktası / tek çıkış noktası" kuralı budur. Bu gerçek sorun üzerinde bir yama, yani erken çıkmak bir karışıklık bırakabilir. Doğru kural "pisliğinizi temizleyin" dir. Daha da iyi bir kural, programcı kendi karmaşasını temizlemek konusunda endişelenmek zorunda kalmamak için kendileri temizleyen veri yapılarını kullanmaktır.

• Ve şimdi, emin olmasanız bile her zaman müşterinize / kullanıcınıza "evet" deyin. Zamanın% 90'ında bunu yapmanın bir yolunu bulacaksınız.
  Bu da inanılmaz derecede kötü bir tavsiye.

Bazen müşterinize hayır veya "bunu hangi binyılda istersiniz?" Mimarinizi yok edecek, müşterinin harcamaya istekli olduğundan çok daha pahalıya mal olacak ya da ona nasıl ulaşacağınıza dair bir ipucunuz olmayacağına dair söz vermeyin. Teknolojiyi biliyorsunuz, müşteriyi değil. Nasıl yapılacağını bilmiyorsanız, yapabileceğinizi söyleme. Emin değilseniz, bunun mümkün olup olmadığını araştırmak için zamana ihtiyacınız olduğunu varsayalım. Dürüst olmak daha iyidir ve sizi beladan uzak tutacaktır.

Sözlerinizi yerine getiremezseniz müşteriler hızlı bir şekilde eski müşteriler haline gelir. % 10'luk bir hata oranı kulağa küçük gelebilir, ancak müşterilerin% 10'una odaklanacaktır. Bazen söz verdiğiniz şeyi yerine getiremediğinizde dava açarlar. Bunu gerçekten istemiyorsun. Diğer zamanlarda, bir vaatte iyi yaptığınızdan emin olmak, iflas etmenize, delirmenize veya eşinizi kaybetmenize neden olabilir, çünkü 18 saat çalışıyorsunuz. Bunu da istemiyorsun.

Bunu şu şekilde düşünün: Tüm uçak inişlerinin% 90'ı başarılı olsaydı havayolu endüstrisine ne olacağını düşünüyorsunuz? Sizce geri dönüp, çökmekte olan% 10 için özür dilemek her şeyi düzeltir mi?

"Bunun yapılabileceğini düşünüyorum" demek daha iyi olur. veya "Kontrol edip size döneceğim". Hayır ya da karşı bir şey önerdiğim zamanlarım oldu. Müşteri "internete hiç bağlanmadan çalışan ve dokunsal geri bildirim kullanan bir tarayıcı tabanlı uygulama" istiyorsa, muhtemelen mümkündür. Ancak pahalıdır ve gerçek ihtiyaçların ne olduğunu tartışmak daha yararlı olacaktır.

Dürüst olmanız durumunda müşteri size saygı duyacaktır. Sorudaki tavsiyede, kişi zamanın% 10'unda yanlıştır. Eğer her on seferde bir rutin olarak yanlış olan biriyle çalışırsam, ona hiç güvenmeyeceğim. Bu korkunç bir geçmiş.

Ay'a söz vermek ve bir kaya teslim etmek, tolere edilmemesi gereken bir tür satış elemanı yaklaşımıdır. Mümkün olup olmadığını bilmiyorsanız, araştırın. Ya da onlara bakmak için ne kadar zaman ayıracağınıza dair bir teklif verin. Bu şekilde, teslim edemeyeceğiniz hiçbir şey vaat etmiyorsunuz, ancak size bakmanız gereken süre boyunca ödeme alıyorsunuz.

Bu soru resmi olarak incelenmiştir ve ortaklaşa üretilen IEEE Bilgisayar Topluluğu / ACM Etik Kuralları tarafından ele alınmaktadır .

2,01. Deneyimlerinde ve eğitimlerinde herhangi bir sınırlama konusunda dürüst ve açık sözlü olmak, yetkinlik alanlarında hizmet sunmak

3.04. Üzerinde çalıştıkları veya çalışmayı önerdikleri herhangi bir proje için uygun eğitim ve öğretim ve deneyim kombinasyonu ile kalifiye olduklarından emin olun.

3,09. Üzerinde çalıştıkları veya çalışmayı önerdikleri herhangi bir proje için maliyet, çizelgeleme, personel, kalite ve sonuçların gerçekçi nicel tahminlerini sağlamak ve bu tahminler hakkında belirsizlik değerlendirmesi sağlamak.

5.05. Üzerinde çalıştıkları veya çalışmayı önerdikleri herhangi bir proje için maliyet, çizelgeleme, personel, kalite ve sonuçların gerçekçi niceliksel tahminlerini sağlamak ve bu tahminler hakkında bir belirsizlik değerlendirmesi sağlamak.

Teslim edemeyeceğiniz bir şey vaat etmenin kesinlikle ticari ve yasal etkileri vardır. Genellikle bunlar, başka bir yere giden, ödemeyi reddeden veya şirketinize dava açan müşteriden gelir. Başkalarıyla ortaksanız, tarafınız teslim edilmezse tazminat davası açabilirler. Davalar rakiplerden bile gelebilir.

Süper bilgisayarların ilk günlerinden Seymour Cray ve Control Data Corporation'daki bir ekibin bir ürünü piyasaya sürmeye yakın olduğu bir hikaye var ve çok büyük bir bilgisayar şirketi müşterilerine de piyasaya sürülmeye yakın olduğunu söyledi. Yalan CDC'ye çok fazla iş maliyeti getirdi ve büyük şirketin iddiaları için güvenilir bir kanıt gösteremediği bir davaya dönüştü. Sonuç, o zamanlar 80 milyon dolar değerinde büyük bir çözümdü (2012'de enflasyona göre ayarlanmış yaklaşık 223 milyon dolar). Burada okuyabilirsiniz:

http://en.wikipedia.org/wiki/Control_Data_Corporation#CDC_6600:_defining_supercomputing

Yeterli zaman, kaynaklar ve başarının tanımlanması konusunda esneklik göz önüne alındığında her şey mümkündür. Beyaz x-kütle örneği, yalnızca% 50'den daha iyi doğruluk istiyorsanız ve kullanıcının coğrafi konumuna ve biraz istatistiksel verilere sahipseniz kolaydır.

Çoğu projedeki asıl ilk soru, bir şeyin mümkün olup olmadığı değil, belirli bir dizi koşul göz önüne alındığında makul olup olmadığıdır.

Özellik, girişimin masrafını garanti etmek için yeterli değer katıyor mu?

Fikir oldukça harika olsa bile, uzun bir geliştirme dönemi veya daha egzotik bir donanımın edinilmesi gerekiyorsa, müşterinin bunu önceden bilmesi ve çoğu durumda konuşmayı daha makul hedeflere yönlendirmesi daha iyi olacaktır.

Birisi size boş bir çek verecek ve son teslim tarihi olmayacak kadar çılgınsa, elbette onlara her şeyin mümkün olduğunu söyleyin, sadece yol boyunca hedefe ulaşmada yer alan teknolojilerin birkaçını icat etmeniz ve dağıtmanız gerektiğini bildirin.

Öte yandan, makul kaynaklarla makul müşterilerle uğraşırken, bazen müşteriye anlaştıktan sonra bazı özelliklerin kesilmesi gerektiğini söylemek daha kötü bir şey yoktur, çünkü zaten tükenmiş ve zaman / para / kaynakları teşvik etmiş veya bunu belgelemek ve% 10'u ilk etapta projeyi yeşillendiren şey olabilirdi. Bu durumlara kapılın ve bir müşteriyi yeni kaybettiniz ve muhtemelen tüm pazarda çok sözlü bir kötü referans kazandınız.

Şeytanın avukatı oynamak

Analitik bir zihniyete sahip olan teknik kişiler, performanslarının öncelikli olarak tamamlanmış taleplere karşı taahhütlü taleplerin puan kartına dayanarak değerlendirileceğini varsayabilirler, ancak pratikte, bu kadar kesilmiş ve kurutulmuş değildir.

Geliştirme başlamadan önce, müşteriler bir ekibin performansı konusunda güven ve taahhütte bulunma istekliliklerine göre görüşlerini oluşturmaya başlar.

Bunun bir nedeni, müşterilerin bir yüklenicinin taahhütte bulunma konusundaki tereddütünün, talebin büyük zorluklarından veya yüklenicinin yetenek eksikliğinden kaynaklanıp kaynaklanmadığını değerlendirmekte zorlanabilmesidir.

Bir talebin zorluğunu ölçmek için kesin bir kriter olmadığından, genellikle müşteri için daha önemli olan, yüklenicinin taleplerin% 90'ı veya% 100'ünün karşılanmasından ziyade% 100 çaba sarf ettiğine güvenmesidir.

Müşterinin iki senaryo arasında seçim yapması gerektiğini varsayalım:

Yüklenici A :

• Tüm talepleri yerine getirebileceklerinden emin
• Sonuç: Teslim edilen taleplerin% 90'ı
• Müşteri, yüklenicinin% 100 çaba göstermesinden memnun .
• Müşteri, tamamlanmamış taleplerin, muhtemelen yüklenicilerin kontrolü dışında olan öngörülemeyen sorunlardan kaynaklandığını algılar.

Yüklenici B :

• Taleplerin% 90'ını karşılamayı taahhüt eder. Kalan% 10'u teslim edebileceklerinden emin değilim
• Sonuç: Teslim edilen taleplerin% 90'ı
• Müşteri, yüklenicinin taleplerinin diğer% 10'unu tamamlamaya çalışmadığını hayal kırıklığına uğrattı
• Müşteri, taleplerin tamamlanmayan% 10'unun , yüklenicinin çaba veya yetenek eksikliğinden kaynaklandığını varsayar.

Her iki senaryoda da aynı sayıda istek iletildi; ancak, müşteri "aşırı yüklenici" Yüklenici A'nın% 100 çaba sarf ettiğini hissetti ve bunu Yüklenici A'nın kredisine kalan taleplerin gerçekten zor olduğunu doğrulamak için kullandı.

Diğer taraftan, müşteri, Yüklenici B'nin% 100 çaba göstermediğini ve tüm talepleri yerine getirememesinin, Yüklenici B'nin çaba veya yetenek eksikliğinden kaynaklandığını hissetti.

Feragatname: Bir stratejinin gereğinden fazla taahhüdünü savunmuyorum; bu sadece aşırı taahhüdün olumlu sonuçlar doğurabileceği olası bir gerçek dünya durumunun gözlemidir.

Onlara "başak çözümü" yaratmaları için zaman vermelerini söylemelisiniz .

Spike çözümü, kodlarken, bir projede belirsizlik yaratan bir şeyin nasıl yapılacağını veya hatta mümkün olup olmadığını anlamanıza izin veren küçük bir programdır.

Örneğin, programla hiç SMS göndermediğinizi, ancak bir şekilde bunun mümkün olduğunu bildiğinizi varsayalım. Spike çözümü, SMS gönderen küçük bir program yapmak olacaktır. Bu şekilde artık bir belirsizlik değildir ve fizibilite hakkında daha fazla tahmin yapabilirsiniz.

İşte eXtreme Programlama belgeleri üzerinde şöyle diyor:

Zor teknik veya tasarım sorunlarına cevap bulmak için ani çözümler oluşturun. Spike çözümü potansiyel çözümleri keşfetmek için çok basit bir programdır. Başlığı sadece incelenmekte olan sorunu ele alacak ve diğer tüm endişeleri göz ardı edecek şekilde oluşturun. Çoğu sivri tutmak için yeterince iyi değildir, bu yüzden atmayı bekleyin. Amaç, teknik bir sorun riskini azaltmak veya bir kullanıcı hikayesinin tahmininin güvenilirliğini arttırmaktır. Teknik bir güçlük sistemin gelişimini sürdürmekle tehdit ettiğinde, bir iki geliştiriciyi bir ya da iki hafta boyunca soruna sokun ve potansiyel riski azaltın.

Deneyimlerime göre, bir kullanıcı bir şey istediğinde, kullanıcının gerçekten ne istediğini veya neye ihtiyacı olduğunu ayrıntılı bir şekilde istemelisiniz. Çoğu zaman, talebi bir daha asla duymayacaksınız.