Berbat tahminlerle başa çıkmak

Üzerinde çalıştığım son bir projenin, mimar tarafından ciddi bir şekilde hafife alındığı kanıtlandı. Tahmin en az% 500 oranında gerçekleşti.

Maalesef müşteri ile yapılan tahminler imzalandıktan sonra projeye dahil oldum. Kıdemli dev olarak, hızlı ve işlevsel bir teknik özellik olduğunu fark ettim. bazı büyük boşluklar ve belirsizlikler içeriyordu.

Sonuç olarak, işletme ve teknik direktörlerle acil durum toplantısı yapma zorunluluğunu duyduğumu hissettim. Her şeyden önce bir geliştirici olarak, bunu çok stresli ve zor bir durum olarak buldum. "İşletme", BT'yi beceriksiz olmak ve haberci olmakla suçladı, birkaç mermi aldım.

Müşteri hesabını iptal etmekle tehdit etti, ancak şu ana kadar proje hala bitmedi ve artık doğrudan bununla ilgilenmiyorum.

Mimar sosyal olarak iyi bir adamdı, ancak bu bölüme dayanarak ya basit bir şekilde beceriksizdi ya da tahminde etkili olan büyük satış / iş baskıları vardı.

Peki, programcılar olarak, bu tür bir durumla ilgili deneyiminiz nedir ve bununla nasıl başa çıkmanızı tavsiye edersiniz?

Uzun cevap, ama hey, sonunda bir özetim var, bu yüzden her şeyi okumaktan rahatsız olmazsanız, özetini atlayın!

Bir geliştirici olarak durumla tam anlamıyla diğer tüm projelerle uğraşmak zorunda kaldım, ancak etkin bir şekilde nasıl başa çıkacağımı öğrendiğimden beri proje yönetimine girmedim. Benim için etkili bir şekilde uğraşmak iki şeyle ilgili: beklentileri yönetmek ve tahminin nasıl yürüdüğünü anlamak.

Bir tahmin yapmanın, bir tahminde bulunmanın veya tahmin doğruluğunu gösteren herhangi bir ilk belirtiyi ilk önce bir durum tespiti yapmadan yapmanın etik dışı olduğu iddiasıyla başlayın. Diğer insanlar, gereken miktarda çalışmayı tahmin etme konusundaki profesyonel yeteneğinize güveniyor, yanlış bir gösterge vermek, onlara ve işlerine zarar verecek.

Fakat bir şeyler vermek zorundasınız, gerçek hayatta doğaçlama bir toplantıya veya geç bir projeye sürüklüyorsunuz ve üstünüz büyük olasılıkla derhal bir rakam bulmanızı veya tahminlerini yorumlamanızı beklediklerini açıkça ortaya koyacaktır. Beklenti yönetimi devreye giriyor.

Sorunu anlamadan ve rakamları kendiniz çözmeden herhangi bir şekil veya gösterge vermenizin yanlış olacağını açıklayın. Onların rakamlarının oldukça doğru olabileceğini söyleyin, yalnızca tahminde bulunmadan önce kendiniz bilmezsiniz. Ve orada neyin gerekli olduğunun iyi bir resminiz olsa da, rakamları hesaplamak için hala biraz zamana ihtiyacınız olduğunu söyleyin. Sizden bekleyebilecekleri tek bir tahmin var: bir tahminde bulunabildiğiniz zaman. Elbette bu rakamı sağlayın.

Bir geliştirici olarak, başkalarını ilk önce gözden geçirmeden tahmin etmek için hiçbir zaman sorumluluk almaz (veya kabul edilebilecek şekilde yorumlanabilir). Bir proje yöneticisi olarak bu tamamen farklı bir meseledir, çünkü o zaman tahmin sürecini gerçekten de kontrol edersiniz: bir tahminin türetilme ve gözden geçirilme şekli ve gerçek işi yapmak için diğer insanlara güvenmek zorundasınız ve yapmanız gereken Tabii ki kararlılar.

Durum tespiti yapmadan tahminler hakkında asla yorum bile yapmayın. Bu etiktir. Bir avukat veya doktor, bir müşteri (veya hasta) kurallarına göre oynamadıkça ve önce bir değerlendirme prosedüründen geçmedikçe, hiçbir tavsiyede bulunamayacaklarını açıkça belirtir. Benzer şekilde, profesyonel görüş bildirmeden önce sorularınızı yerine getirme hakkınız vardır.

İkinci kısım, tahminin nasıl çalıştığı ile ilgilidir. Tahmin geliştirme ve yazılım geliştirme dışındaki endüstriler (imalat, finansal piyasalar, inşaat) dahil tahmin sürecinin nasıl çalıştığı hakkında çeşitli yaklaşımlar araştırmanızı öneririm. Bu size patronunuz veya müşteriniz tarafından sizden makul olarak ne beklenebileceği hakkında fikir verecektir ve garip bir şekilde, iş miktarı hakkında daha doğru tahminler yapmanıza yardımcı olacaktır. Tahminlerinizi savunma yeteneğinizi geliştirecek ve rakamları her zaman bir mimar veya satış elemanı tarafından sağlananlardan farklı olarak savunmanız gerekecektir.

Normalde, çalışma şekli, tahmininin önce tuhaf görünümlü veya nispeten büyük eşyalar için taranmasıdır. Bu nedenle “standart dışı” bir isim olan her şeyi savunmaya hazır olun. Ayrıca daha büyük görevleri ayırın, böylece tüm görevler aynı büyüklük sırasına sahip olacak, yani çoğu görev 2 gün sürerse ve tek bir görev 10 gün sürecekse hazırlanın.

Her göreve neyin dahil olduğu konusunda net olun, sadece dev olması ve birisinin de belgeler içerdiğini varsayması yerine dev ve birim sınamasını bölmek en iyisidir. Açıkçası bu şekilde oldukça iyi bir taneli tahminde bulunmanız gerekecek.

Sonra sondaj geliyor. Uzun bir çalışma dağılımını incelemek oldukça zor olduğu için, müşteriniz veya patronunuz farklı bir strateji benimseme olasılığı yüksektir: rastgele bir bit üzerinde yoğunlaşarak, tüm tahminleri geçersiz kılmayı başarabilene ya da tatmin edici bir hale gelinceye kadar, hakkında bir şeyler biliyor ve delinir cevapları. Tüm tahmininin güvenilirliği rastgele bir numuneye bağlı olabilir! Bu nedenle, bir kez daha dikkatlice hazırlamak için zamana ihtiyacınız var, yalnızca ilgili bitleri dahil edin, ekstraları hariç tutun veya onları “iyi bir hoş” bölümüne taşıyın ve rakamları nasıl savunacağınızı düşünün.

Açıkçası, yaklaşımınızda tutarlı olabilir, yani özelliklere, ekran sayısına vb. Göre tahmin etme veya bir yaklaşımların karışımına sahip olabilirsiniz, ancak herhangi bir durumda neden belirli bir tahmin yöntemi seçtiğinizi savunmaya hazır olun. Ayrıca, rakamlarınızın neden gerekli iş miktarını öngörme girişiminden farklı olduğunu açıklamaya hazır olun.

Zayıf tahminlerin açık belirtilerini öğrenin:

• Genel fabrika işleri ile doldurulmuş, şablondan kopyalanmış (iyi tahminler eldeki işe özeldir).

• Kaba taneli tahminler (yani birkaç günden uzun süren işler).

• Bir projenin erken safhasında veya ilgili gereksinimler veya işle ilgili gerçek bilgiye sahip olmayan biri tarafından yapılan tahminler.

• Gerçek kişiler dışındaki kişiler tarafından derlenen tahminler

• Belirsiz tahminler (neyin dahil edildiği ve eşit derecede önemli, neyin hariç olduğu net değil).

• Görev büyüklükleri sırasındaki büyük fark.

Gerçekleştirilmesi gereken uygulama bilgisi olmadan rakamları tahmin etme ve sondaj uygulamalarında pratik yapın. Bu, zor kanıtınız olmadığında başkasının tahminini onaylama isteği ile basıldığında, fazladan bir süre için talebinizi desteklemeye yardımcı olacaktır.

Özetle:

• Durum tespiti yapma fırsatını yakalamadan önce, bu konuda berbat bir tahmin yapmayın.

• Başlangıçta açıkça belirtin, kimsenin başka bir yol olduğunu varsaymasına izin vermeyin ve sessizliğinizi bir anlaşma işareti olarak yorumlayın.

• Çeşitli tahmin yöntemlerinin nasıl çalıştığını, pratik uygulamalarını ve bu dış yazılım geliştirme de dahil olmak üzere faydalarını bilin.

• Tahmininizi savunmaya hazır olun.

• Başkalarının tahminlerini nasıl değerlendirebileceğinizi öğrenin, böylece kendinizi çok yanlış rakamlara adamak zorunda kalmazsınız.

Geleceği tahmin etmek imkansız. Bir tahmin istemek ("tahmin") sadece sorun istiyor. Herkes yapar ve herkes yanlış yapar.

“% 500 oranında” ile ilgili kararınız muhtemelen mimarın tahmin ettiği kadar yanlış. Ne de olsa, "... proje henüz bitmedi ..." Burada gerçekler yok.

Kimse "doğru" cevabı bilmiyor. Ve bitene kadar kimse bilmeyecek.

Ve yapıldıktan sonra bile, "orijinal" tahmin (değişiklik kontrolü olan veya olmayan), gerçekten gerçekleştirilmiş herhangi bir şey ile ilişkili olmayabilir.

Tahmin etmek bir tuzaktır - teçhiz edilmiş bir oyundur. Kazanamazsın, hatta kıramazsın ve oyundan bile çıkamazsın.

Düzenle

Kötü tahminlerle uğraşmak; Yanlış görünen bir "eski" tahmin .

İşte burada. Başka birinin tahminleriyle aynı fikirde değilsin. Ya gerekli olduğunu düşündüğünüz bir şeyi atladılar; onlar sizden farklı bir iş kapsamına sahipti ya da farklı bir verimlilik oranına sahiplerdi. Ayrıca, tahmin sadece çabadan daha fazlasıysa, farklı bir maliyet temeline sahiptir. Hepsi tartışmalı. Bu yüzden tahmine kadar olan detayları tartış. Genel sayıya itiraz etme - bir özette gerçek bilgi yok . Tahminin temelini oluşturan münferit ayrıntıları tartışınız. Ne düşündüklerini öğren.

Varsayımlarınızın varsayımları kadar yanlış olması muhtemeldir. Eşit olasılıkla.

Tahmini Sorulduğunda .

1. Yanlış olacaksın.

   1. İşin kapsamı hakkında yalan söylüyorlar.

   2. Takımın verimliliğini bilmiyorsun.

   3. Hangi yeni teknolojiye dahil olursa olsun yanlış tanıtıldı.

2. Bu şeyleri rastgele örtmek için sadece dolgu malzemesi atamazsınız. Aslında bilmiyorsunuz ve "tahmin" için bir temeli yok. Sadece tahmin ediyorum. AŞ bunu.

Kural 1: Yalnızca tahmin ettiğinizden beri, küçük artışlarla tahmin edin.

Herhangi bir "tahmin" durumunda temel soru geleceği öngörmek değildir . Bunu bir veya iki haftadan daha uzun süreler boyunca hiçbir doğrulukla yapamazsınız. Tahminlerinizi, doğrudan ve anında ayrıntılı bir bilgi sahibi olduğunuz bir zaman ufkuyla sınırlandırın. Örneğin, bir sonraki sürüm.

Temel soru - genellikle - alıcılarınızın veya müşterilerinizin karar vermesidir. Soru “maliyet ne olacak?” Değil. - bu eksik. Sorun şu ki, "yatırım buna değecek mi?" Asıl soru, "maliyet / fayda oranı nedir" ve "daha fazla yatırım daha fazla getiri yaratmayacağı için harcamaları ne zaman durdurmalıyız?" Bunlar gerçek sorular.

Kural 2: Karar vericiyi gerçek bilgilerle destekleyin.

Çoğu insan en Çevik bir yaklaşımla servis edilir. İlk sürüm - bundan bir ay sonra - 5 kişi x 4 hafta sürecek ve 1 milyon dolar / gün kayıplarını düzelten X ve 200 bin dolar / hafta kayıp fırsatlarını düzelten Y özelliğini verecek. Ne yaptığınızla ilgili ayrıntılı bilginiz var, bu nedenle bu tahmin mantıklı geliyor. Bundan sonra bırakma biraz puslu.

Bundan bir yıl sonraki sürüm, gelecekte sadece rasgele bir sayıdaki herhangi bir tahminde bulunacak kadar ileride. Gelecekte 6 aydan fazla bir şeyin ayrıntılarını terlemeyin, yalnızca basit kurallara uyun.

TCO'nun ne olduğunu sordukları zaman dürüst olmalısınız. "Toplam maliyet, geliştirme için ödeme yapmayı bıraktığınızda gerçekleşir. Ödeme yapmayı bırakana kadar, her zaman maliyete tabi olursunuz."

Asıl soru, "Hangi sorunları çözmeye çalışıyorsunuz?" ya da "hangi yeni fırsatı takip ediyorsun?" ve "Bunun değeri nedir?"

Kural 3: Yazılımı, çözmesi gereken sorundan daha az maliyetli hale getirin.

Sorunu çok iyi bilmiyorsanız, tahmin algıya uyacak şekilde oynanacaktır. Bundan kaçınmaya çalışın.

Olasılık Üzerine . Hastalığı veya kazayı zayıflatması dışında, yazılım geliştirmenin hiçbir kısmı gerçek olasılıklarla yönetilmez. “Riskler” sadece kötü yönetimdir. Genel olarak "iş ihtiyacının karmaşıklığına A veya B teknolojisine ihtiyaç duymadık" şeklinde. "Sorun ya da teknoloji hakkında daha fazla şey öğrendiğimizde," kapsamın sürünmesi "olarak cezalandırılan programı değiştirdik.

Bir şeyler öğrenme ve kapsamı değiştirme olasılığı yoktur. Bu bir kesinlik.

Planlamada . "Planlama" var ve "tahmin" var. Neyin inşa edileceğini planlamak en iyisi bir kontrol listesi veya bağımlılık grafiği olarak temsil edilen bir şeydir. Gereken çabayı “tahmin etme”, bilinmeyen faktörlere dayanır.

"Planlama" sıradan iyi yönetimdir.

"Tahmini" bilinmeyen bir bilgi gerektirir. Eforu doğru bir şekilde “tahmin etmek” için, ürünle ilgili kaynak kodu düzeyine sahip olmanız ve bu kaynak kodunu hangi kişinin yazacağını ve bireyin hangi hataları yapacağını bilmeniz gerekir. Bunu bilemediğiniz için, herhangi bir tahminin yanlış olması gerekir. Ve genellikle yanlış yanıltıcı ve bu nedenle işe yaramazlık noktası.

Tahmin% 500 oranında yapıldıysa ve proje halen devam ediyorsa, bir tahminin değeri nedir?

Yok. Tek yaptığı insanları mutsuz etmek oldu. Ancak yine de proje ilerledi.

Kimse geleceği göremediğinden tahminde bulunmak doğru değildir. Yararlı olun, insanların karar vermelerine yardımcı olun.

Ufku kısa tutun. Değeri mümkün olduğunca çabuk verin. Müşterinin herhangi bir zamanda projeyi iptal etmesine ve yine de değeri olmasına izin veren bir plan oluşturun.

Planın, projedeki tek "kutsal gerçek" olmasına izin verme. Verilebilir işlevsellik kutsaldır. Teslim edilenler değiştikçe her şey değişmeli.

Planın yarattığı değerin ötesine geçmesine izin vermeyin.

Yeterli zaman yoksa, yeterli zaman yoktur. Zaten projeyi bitirmek için sihirli bir çözüm yoktur. Benim düşünceme göre, söyleyebileceğiniz şeyi yaptınız. Zor yoldan bulmak zorunda kaldılar. Genelde böyle gider. Umarım mimar ve yönetim hatalarından ders almışlardır ve bir daha yapmazlar. Yönetim, argümanlarınızı dinlemek ve uygun önlemleri almak için çok cahil olduğunda bu normal bir iştirse, başka projeler veya başka bir şirketi aramak iyi bir fikir olabilir.

"Geliştiriciler zanaatkarlar ve bir zanaatkarın yapabileceği en kötü şey, berbat bir ürün vermesini sağlamak." Bir yerden ünlü alıntı ama nereden hatırlayamıyorum.

Dürüstlük her zaman onurlandırılmalıdır. Bir "mimarın vizyonu" nu kabul ediyordum ve geliştirici bana, tüm çözümün işe yaramayacağına dair korkunç bir haberle geldiğinde, iş birimlerine gittik ve korkunç bir konuşma yaptık. Ardından geliştirici, işlevselliğin% 80'ini içeren yeni bir tahminle geldi, ancak zamanında ve bütçeyle teslim etti.

İş birimleri, geliştiricinin kendileriyle doğru bir şekilde konuştuğu, şirketlerinin kısa zamanda geldiğini kabul ettiği ve teslim etmek için bir köpek gibi çalıştığı için kazanıldı. Son 7 yıldır bu adam bizim için çalışıyor. Çünkü her zaman dürüsttü.

Tüm senaryo çok nadirdir - çoğu zaman iş birimleri teslim edemediğiniz için aptal olduğunuzu düşünür. Bu şekilde çalışmayan müşterileri aramanız gerekir, çünkü uzun vadede onlarla daha fazla kazanacaksınız, çünkü sadece size bir pislik gibi davranmak isteyen cretinsleri memnun etmeye çalışacaksınız.

Alanlarını bilmeyen mimarlar için, veba gibi onlardan uzak durun. Benimle sert bir şekilde takviye eden bir akıl hocam vardı - "Bu. Değil. Uygulama!" Hatalara ancak onları erken yaparsanız, düzeltmiş ve bir daha asla yapmadıysanız hoşgörülü davranırdı. Teknik olmayan, deneyimsiz kişilerin müşterileri ile birlikte konumlarına izin veren şirketler, “iletişim kurabildikleri” için işsiz kalmayı hak ediyorlar.

Bir zamanlar bu durumla karşılaştım. Bunun dışında bir proje bitti çünkü iş gereksinimi değiştirdi ve iletişim boşluğu vardı ve üst yönetim projenin zamanında projeyi istemesini sağladı. Daha da kötüsü için bu proje üzerinde çalışan bir adam daha öncelikli olan başka bir boşluğu doldurmak için çıkarıldı.

Ekibim projeyi bitirmek için geceler geçiriyordu. Bir gece geç saat sabah 3:00 civarında (19 saat boyunca çalışıyordum) yöneticilerime e-posta gönderdim.

Ertesi gün bir toplantı yaptık (Sadece dev adamlar). Tüm ekip bir hafta sonu geldi ve projeyi tamamlanmadan önce test etti. Çok az kişi ekibe hızlı düzeltmeler yaparken katıldı. Sonunda projeyi tüm ekibin çabasıyla teslim edebildik (Sadece proje ekibi değil). Aynı süreci diğer projeler için de takip ettik.

Tüm ekip (projeye dahil olmasalar bile) uygulamayı test etti ve hızlı hata düzeltmelerine yardımcı oldu.

Not: Ekibim, yine farklı projeler üzerinde çalışan alt ekipleri olan yaklaşık 25 kişiden oluşmaktadır.

Tek tavsiyem "Yöneticiyle konuş. Onlara projenin zamanında teslim edilemeyeceğini kesin olarak söyle. Ayrıca onlara alternatif ver. Yönetici, bebeğin ne olursa olsun zamanında teslim edilmesini bekler :)"

İşletmeler genellikle işlerin beklenenden daha uzun sürdüğü gerçeğini sevmiyor olsa da, daha az gergin olmayı tercih ediyorlar. Birine ne kadar zaman alacağını bir an önce bildirirseniz, herkes bu koşullar etrafında daha hızlı bir şekilde plan yapabilir. Bu başlangıçta zor bir zaman olsa da, uzun vadede daha kolay olacaktır. Sadece ikinci kez doğru olsun ve acil durum içine inşa.

Yönetiminizle ilgilenirken bir anahtar noktayı vurgulamama izin verin: yöneticiler çözümleri takdir eder.

Yönetiminize bir sorunla gitmeniz gerekiyorsa (örneğin, tahmin delice gerçekçi değildir), durumu nasıl çözeceğinize dair alternatifler eklemek için önceden çok çalışın. Örneğin, sistemin değerini anlamak için bir Pareto analizi (80/20 kuralı) yapabilir, maksimum işletme değeri olanlara konsantre olmak için özellikleri kesme (en azından ilk sürümden itibaren) için öncelikli bir durum oluşturabilir, sistemin özel parçaları için uygun alternatifleri (açık kaynaklı projeler vb.) arayabilirdiniz.

Beş kiloluk bir poşetin yirmi beş kiloluk kum tutamayacağına şüphe yok, ancak yönetiminizin nahoş mesajınızı emmesine yardımcı olmanın bir parçası sizin bir müttefik olduğunuza dair kanıt sunuyor.

Bu ilginizi çekebilir IEEE yazıda ben var blogged önce yaklaşık. İşte önemli noktalar.

• Projenin başarısızlığına neden olan en büyük itici güçlerden biri aşırı iyimser tahminlerdir.
• Tahminlerin çok düşük olmasının büyük bir nedeni, tepeden erken teslimat için çok fazla baskı yapmak.
• Diğeri, tahminler üzerinde tekrar ziyaret edilmeksizin uygulama sırasında kapsamın kaymasıdır.

Öncelikle, söz konusu mimarla gayri resmi olarak konuşur, tahmininin problemleri listesini okur ve problemlerin nerede olduğunu ve çözülmesi gereken zamandaki farkı ikna etmeye çalışırım.

Daha sonra bölüm müdürünüze / proje müdürünüze gidip onunla konuşacağım.

Günün sonunda, mimar ESTIMATES'i verdi, bu yüzden onlar değişime maruz kalıyorlar ve bazen büyük miktarlarda, bunun farkında olduğu sürece, bir ürünü piyasaya sürmek gibi alternatif planlar yapabiliyorlar. fazlar, işlevselliğini veya diğer araçları azaltır.

Günün sonunda, yukarıdakileri bir kez yaptıktan sonra, artık sizin sorumluluğunuzda değildir.

Kesinlikle doğrudan müşteriye ya da mimarların patronuna gitmemelisiniz, bu sadece kötü duyguları teşvik eder ve neredeyse hiç durmadan bazı suçları alırsınız.

Yapabileceğiniz en iyi şey sizden (kişisel olarak değil, bu durumda) kötü tahminlerden öğrenmektir. Öğrenilmesi gereken bir şey, fikirleri uygulayan kişiden başka birinin asla ne kadar süreceğini tahmin etmesine izin vermemektir. Programcıların hızları büyüklük sırasına göre değişebilir, bu nedenle başkası için tahmin yapmak imkansızdır.

Acını hissediyorum ... Tüm bu hayal kırıklığıyla nasıl başa çıkacağımı bilmiyorum :(

https://stackoverflow.com/questions/541873/developing-on-for-a-moving-target

Geçmişte, satış departmanının müşterinin ödeyeceğini düşündüğü bir rakamı karşılamak için tahminleri kesen Proje yöneticileriyle uğraşmak zorunda kaldım. Yönetici, affetmek için yalvarmanın izin almaktan daha iyi olduğunu düşünüyordu.

Bu nedenle geliştiriciler tahminlerini değiştirmeyi öğrendiler, çünkü yöneticileri tarafından kesileceklerini biliyorlar. Tahminleri iki katına çıkarır ve% 30 eklerseniz, makul bir programa sahip olma şansını yakalarsınız.

Müşteriler her zaman daha ucuz olmasını isterler ve makul bir tahminle onlara gelirseniz, buna balkırır ve maliyeti düşürmenizi veya yürürsünüz. Ancak, çok yükseğe çıkarsanız, tartışma olmadan yürürler ("Biz bunu düşünürüz ve size geri döneriz").

Bu, yönetilen beklentilerin bir oyundur.

Sorun, orijinal tahminlerin geçersiz olması değildi - yönetim size inanmadı.

Bir karar vermede yönetimi almanın en iyi yolu şudur:

1. Sorunu destekleyecek kanıtlarla özetleyin; ve
2. Aralarından seçim yapmaları için çoklu çözümler sunmak (en az tercih edilenden en çok tercih edilene kadar).

(1) Scrum'u uygulamak ve tehlikeli tahminlere karşı gerçekleri izlemek, taleplerinizi desteklemek için iyi çalışır.

(2) için seçeneklerimden biri "Müşteri ile Öncelikli Bir Özellik Listesi Geliştirin (aka Scrum terimlerinde Ürün İş Listesi)". Bu, sabit fiyatlı veya bürokratik örgütlenmelerde zor olabilir, ancak mümkün .

Umarım yardımcı olur!

Ben (kodlayan herkes hakkında emin olduğum gibi) empati kurarım. Son şirketim bu konuda oldukça berbattı - satışçılar girip bir proje satarlardı ve sonra gelirsiniz, tahminleri görürsünüz ve sadece gülersiniz.

Tomh'in dediği gibi - bir günde sadece çok zaman var. Uyumamış olsan bile.

Üç şey sanırım.

Çoğu zaman sadece müşterinin beklentilerini yönetmeniz ve şeffaf olmanız gerekir . Yapabilecekleriniz konusunda dürüst olun ve ne yaptığınızı gösterin - hepsini. Bu, özellikle kaba bir şekilde parçalanan (Totophil'in bahsettiği gibi) gereksinimleri karşılarsanız geçerlidir. Yapmanız gereken iş miktarını görebilirlerse, tahminin ne kadar kötü olduğunu görebilirler. Verimliliği ve ilerlemeyi görürlerse, bu benim deneyimimdeki her şeyden daha önemli.

Bence beklentileri yönetmenin ve iş yükünde şeffaf olmanın yanı sıra, diğer büyük şey de kapsam yönetimi . Nazi kapsamı olmada anal / saldırgan olmakla kendi kuyruğunu kapatmak arasında geniş bir alan var. Birisi bu ekstra özelliği veya işlevselliği istediğinde - kabul et! Sonra onlara projeye katacak ne kadar zaman nispeten doğru bir tahmin vermek bunlar başaşağı sadece değil (ya da sonraki sürümü.) Değil başka 80 saatlik çalışma haftası kendinizi tıkınma - sen de o tahmine bazı pedi olsun muhtemelen diğerine yetişmek.

İyi şanslar!

Asla görmeden veya anlamadan hiçbir şey yapmayın. Müşteri veya kendi hesabınız size bu kadar para vermeye istekli değilse, sizi başarılı olmaya hazırlamazlar.

Bu, ayrıntıları, verileri ve oluşturulan uygulama boyunca nasıl etkileşime girdiklerini anlamadaki bir başarısızlıktı. Soru sormak, cevap bulmak ve hepsini çivilemek yerine varsayımlar yapılır.

Müvekkillerime sık sık söylediğim bir şey, eğer beni asacaksanız, en azından birisinin değil, kendimi kendi ipimle asmama veya kendi silahım ve mermilerimle vurmama izin verin.

Bunu çözmeye çalışan döner bir kapıya sahip olmak, sonunda onlar için çok daha kötü olacaktır.

Gerçekçi olmayan, zayıf planlama ve öngörülemeyen öngörü, organizasyonun genelindeki bir sorunun sinyalleri olabilir; bu durumda buna alışmanız veya devam etmeniz daha iyi olur.

Öncelikle, projenin kapsamını fazla tahmin etme olasılığınızı düşünün. Satış görevlileri ve mimarlar çözümlerini abartma eğilimindedir. Bunları yüz değerinden almayın; Müşteriye söz verdikten sonra muhtemelen daha azını bulmanızı bekliyorlar.

Burada yapacağım şey, sahip olduğum zamanı almak ve elimden geldiğince akıllıca harcamak. Müşterinin önceliklerini belirleyin ve bunlara teslim edin. On kereden dokuzu, müşteri önceliklerini yerine getirdiği için mutlu olacak ve çalışmaların% 80'ini görmezden gelecek.

Yapmak istediğin son şey, acil durum toplantısı yapmak ve insanları kötü olmakla suçlamak. Diyorsun:

"gerçeği bilmelerine izin ver"

ama gerçeklik sadece bir fikir! İşini yap, dinlenin ve için önemli noktalar konusunda politik mesajlarına sermaye harcama size . Terfi, daha çok para, daha çok tatil gibi.

Patronunuz sizin için bir terfi ticaretinde gerçekten müşteri üzerinde çok çalışkan mantıklı. Bir müşteri adına haywire gidiyorsun.

Hatırlanması gereken bir şey, tahminlerin kapsam sünme ya da kaçınılmaz gecikmeler içermemesidir (ya da müşterinin size belirli bir formatta bir bilgi dosyası gibi söyleyeceği şeyleri size vermemesine dayanan sorunların olmamasıdır).

Bunlardan birinin gerçekleştiği her seferinde hem tahmini hem de son tarihi geri itmeyi öğrendik. Yeni bir özellik ekleyin, yeni bir tahmin ve yeni bir son tarih alın. Kabul edilen tarihte gerekli bilgiyi sağlayamamak, yeni bir son tarih almak. Bilgi verin ancak eksik veya yanlış veya söz verilenden başka bir şekilde, yeni bir tahmin ve son tarih gönderin, üzerinde anlaşılan özelliklerin gerekliliklerini değiştirin, yeni bir tahmin ve son tarih verin. Proje üzerinde çalışmayı bırakın, çünkü müşteri daha yüksek bir öncelikte çalışmanızı istedi, yeni bir son teslim tarihi gönderin (ve eğer proje uzun süre bekletilirse muhtemelen yeni tahmin süresi ortaya çıkacaktır).

Orjinal tahmin geliştirme grubunun dışından geldiyse ve ona danışılmadıysa, o zaman elde ettiğinizde, kendi tahmininizi hazırlayın (sahip olacağını düşündüğünüz tüm görevlerin detaylı bir düzeyinde - çok daha yüksek bir düzeyde size verilen tahminden daha ayrıntılı olarak) ve derhal zinciri sağlayın ve verilen tahminin yerine getirilmesi için ne kesmeniz gerektiğini sorun.

Cevabınız hiçbir şey değilse, müşteriye konuyu daha derinlemesine incelediğimiz için yeni tahminden haberdar olunmasında ısrar edin. Eğer yönetim tarzı müşteriye sadece X saat ödeyecek diye ısrar ederse, ondan sonraki geliştirme saatini kim ödeyeceğini sorun çünkü sizin için tanımlandığı şekilde iş sizin tahmininizden daha azını yapamaz. Şirketin isabet almaya ve saatlerce kendilerine ödeme yapmaya istekli olduğu ortaya çıkabilir.

Kârlarından çıkarmaya istekli olmazlarsa ve müşteriye daha fazla saate ihtiyaçları olduğunu söylemeyecekler ve şirket, geliştirme personelinin satış konusundaki ayrıntılı tahminlerini '' müşterinin ne kalacağını düşündüğünü '' geri almayacak projeyi kazanmak için "tahmin, bir ölüm yürüyüşü projesindesiniz ve en iyi seçeneğiniz en kısa sürede çıkmanız. Müşterinin, ödemeyi kabul ettikleri 50 saati harcadığınızda ve gerçekte ihtiyaç duyduğunuz 500 ile yapılmaya bile yakın olmayan projenin mümkün olan en kısa sürede alacağını bilerek daha mutlu olacağını belirtebilirsiniz. Onlara aşırı iyimser tahminlerin proje başarısızlığının en büyük tahmincilerinden biri olduğunu hatırlatın. Bu tür şirketlerle çalışmaz, ancak yeterince zamanlarsanız tekrar edersiniz.

Ayrıca, tahmin düzeltmesini de dikkate alacağım. "Şimdi gördüğüm gibi bu proje X çalışma saatini alacak" demek istiyorum. % 20-30 sonra tekrar tahmin edeceğim ve böyle devam edeceğim.

Ne de olsa bir dosya indiricisi tahminini nasıl yapıyor? Sürekli olarak arıtır.

Yeterli tahmin edicilerin "Tahmin etme, benden matematik yapmamı istiyor ve geleceği faydalı bir şekilde tahmin etmemi istiyorsun" ve "Yaptığımız taahhüt, yaptığımız matematikten tamamen ayrıdır" gerçeğine yeterince vurgu yapmıyor. aptalca iş yapmayı kabul edebiliriz, bitiremeyeceğimizi gördüğümüz şeyleri kabul edebiliriz ancak bunların hiçbiri çözümün matematiğini gerçekten değiştiremez "ve" Dev olmayan geliştirme metodolojileri yapabiliriz A özelliğinin toplamı, başarısızlığı çok daha az olası kılan B tarihine göre yapılacaktır "

Birçok tahminde müzakere dilinde konuşulur. Matematik dilinde konuşmaları ve matematiğin belirsizlikleri hakkında konuşmaları gerekir .

Tahmin edici, iş adamlarının onunla pazarlık etme isteklerine karşı gerçeği bükmek için hiçbir şey yapamaz. Onun tek işi denemeyi bırakmalarını sağlamak.