Zaman tahmini yanlış gittiğinde ne yapmalı?

Diyelim ki bir vakanın 3 günü olacağı tahmin edildi. İkinci gün, vakanın arttığını ve zaman tahmininin yapıldığı zaman sayılmayan yeni senaryoların ortaya çıktığını fark edersiniz. Yeni bulgu 2 gün ekstra (toplam 5 gün) yol açar. Bu, er ya da geç geliştirici olarak karşılaşacağınız tipik bir sorundur.

• Proje liderine yeni teslimat süresini bildirirken hangi strateji kullanılabilir?
• Sık sık neden soruyu anladınız? Yeni teslimat zamanını nasıl motive ediyorsunuz?

Gerçek şu ki, birçok proje SDLC sırasında analiz ve tasarıma fazla zaman harcamıyor.

EDIT: Çok karmaşık projelerde, Analiz ve Tasarım'a ne kadar zaman ayıracak olursanız olun, iş kuralları çok karmaşık olduğu için daima sürprizler vardır. Ancak bu gibi durumlarda, proje liderinin karmaşıklığın farkında olması ve beklenmeyen sürprizler ortaya çıktığında doğru tutum sergilemesi gerektiğine inanıyorum. Sorun, karmaşıklığı anlamayan proje liderleriyle nasıl başa çıkılacağıdır.

Kötü haberi vermek

Konuyu derhal derhal gündeme getirmeniz gerekir, ancak bunu makul bir zaman diliminde yapabilirseniz (bu birkaç saat, daha fazla değil) yapmadan önce bir etki değerlendirmesi yapmalısınız.

Tüm kötü haberlerde olduğu gibi, ayrıntılı bilgi vermek en iyisidir (sadece “geç olacak” lafını bırakmak yerine), bu nedenle:

1) Kayıp olan işler için revize edilmiş tahminler / zaman çizelgeleri.

2) Bazı şeylerin zaten bitmiş olduğunu bilmek ışığında, şimdi düşündüğünüz gelecekteki görevler için gözden geçirilmiş tahminler / zaman çizelgeleri daha uzun sürebilir.

3) Kaymanın meydana gelmesinin çok kısa nedenleri (dönmeyin, sadece gerçek değil, mazeret yapmış gibi görünmeyin). Bu durumda, "X ve Y kurallarına dayanarak tahmin ettik, ancak şimdi hiç belirtilmeyen Z'yi dahil ettiler" diyorsunuz. Bunu, müşterilere olan gecikmeyi açıklamakta ve ilk etapta tam olmanın önemi konusunda eğitmek için kullanabilir.

4) Mümkün olan şeyleri tekrar yoluna sokmak için alternatifler varsa (genellikle kapsamı azaltmak ancak başka seçenekler olabilir - projenin diğer kısımları vaktinden önce olabilir ve işleri dolaştırmak mümkün olabilir).

Kaymalarla birlikte psikolojik / güvenilirlik etkisinin kültürel olduğunu unutmayın. Biri ile kurtulmak mümkün olabilir, ancak ikincisi daha sert ve üçüncüsü hala zor olacak.

Bu nedenle, 2. nokta önemlidir - sadece kaymış olanı değil, şimdi beklenenden daha uzun süre alabileceğini düşündüğünüz gelecekteki görevleri de gözden geçirin. BT'lerde kayma olur, hatalarınızdan ders almamak daha büyük bir günahtır.

Kötü haberi vermek zorunda kalmamak

Burada iki senaryo var: birincisi, tahminleri kendiniz yapmadınız, bu durumda bir dahaki sefere tahminlerde yer almaktan başka bir şey yapamazsınız.

İkinci olarak, tahminleri kendiniz yaptınız, bu durumda daha iyi tahminlerin nasıl yapılacağına bakmanız gerekir. Benim için sorudaki anahtar kelime "iş kuralları çok karmaşık olduğu için her zaman sürprizler var" dır .

Saygılarımla, her zaman gerçekleşirse, sürpriz olmamalıdır . İş kurallarının yalnızca yarısını alırsanız, tahminlerinizde bunu varsaymanız ve özelliklerin sürünmesine izin vermeniz gerekir.

Bunu, sahip olduğunuz kurallara ilişkin tahminleri artırarak yapabilirsiniz (işe yarar ancak kimseyi gerçekte neler olduğu konusunda eğitmezsiniz), ancak tahminlerinizde belirtmek daha iyidir "Tarihsel olarak aldığımız kurallar basitleştirilmiş bir sürümdür. Gerçekten istedikleri şey. Belirttikleri kuralların uygulanması 3 gün sürecek, ancak bahsedilmeyen ancak geliştirme ve test sırasında keşfedilmesi muhtemel olan kurallar için 3 günlük bir beklenmedik duruma daha izin vermeliyiz. ”

Başbakan bunu sorgularsa, ona her zaman doğru olduğunu hatırlatmanız gerekir (örneklerle - örnekleri tartışmak zordur) ve ayrıca nazikçe sizin de olduğu gibi zamanında zamanında teslim etmenin kendi yararına olduğunu söyleyin. muhafazakar olmak daha iyi?

Ancak, sonuç şu: belirli bir faktörden dolayı her zaman hafife alıyorsanız (bu durumda sürünme özelliği) o zaman tahminlerinize dahil edin.

Zamana dayalı tahminler gelecekle ilgili tahminlerdir ve bu uzun vadede daima başarısız olur. Kazanamayacağın anlamsız bir savaş.

Tahmin etmeyi gün cinsinden durdurun ve bunun yerine göreceli tahmin kullanmaya başlayın . İşte basit bir örnek:

1. Her göreve bir numara atayın. En zor görev 10 ve en kolay görev 1 olabilir.
2. Görevlerinizi tamamlamak için programlamaya başlayın.
3. Bir hafta sonra çalışmanızı durdurun ve tamamlanmış tüm görevlerin numaralarını toplayın. Diyelim ki 14 ile bitiyorsun. Haftalık hızın bu.

Gelecek hafta, işlemi tekrarlayın. İddiaya girerim hızın değişecek, ama fazla değil. Bununla birkaç hafta geçtikten sonra, hızınız oldukça kararlı olmalı ve bu bizim hedeflediğimiz şey. Artık güvenle plan yapmaya başlayabilirsiniz. Hızınıza göre özetlenen görevleri seçin ve PM'iniz söz verildiği gibi tamamlanacağından emin olabilir. Proje liderlerinizi bu şekilde ele almalısınız.

Tahminin yanlış olduğunu görür görmez alarm zilini yükseltmeniz gerekir. Teslimatı gecikme hakkında bekleyenlere bildirin.

Mümkünse takım arkadaşlarından yardım isteyin. Hala mümkün olduğu kadar yüksek kaliteli yazılımı teslim ettiğinizden emin olun.

Bir kestirme yol sonunda büyük olasılıkla daha fazla zarar verecektir ve ilgili herkes bunu bilmeli. Ya da en azından onlara açıklamak mümkün olmalı.

Bu o kadar sık ​​gerçekleşir ki, hiçbir deneyimli proje sorumlusu, çok fazla bir şey yapmaz. Sadece dürüst ol ve iyimser yeni tahminler yapma; gördüğünüzde çok daha uzun süreceğini söyleyin. Günlük olarak "biraz daha zamana ihtiyacım var" deme.

Yöneticiye açıklamak zorunda kalacaksınız: Tahmini ilk etapta yanlış mıydı ya da olumsuz koşullar (bir gün bir böcek avına harcanan) gecikmenin nedeni miydi? İlk durumda, tahmin sürecinde bir sorun var, belki de çok iyimser ya da saf. İkinci durumda, umarız proje planına dahil edilmiş olan arabellek için bir durumdur.

Tahminlerinizin aşırı iyimser olması da dahil olmak üzere (özellikle!) İlerlemenizden daima ilgili paydaşları haberdar edin. Mutlu olmayacaklar, ancak projenin gerçekte nerede durduğunu ve buna göre plan yapabileceklerini bilecekler.

İdeal olarak, özellikler listeniz MoSCoWed olacak - Zorunlu, Olmalı, Olmaz, Olmaz.

Taşkınlığa doğru giderken Coulds'u, sonra Shoulds'ı kes. Zamanında yol alabilmeniz için özellikleri kesin: Projeniz genellikle yalıtımlı olarak yaşamaz ve çıkış tarihini geçtiğinizde, akış aşağı projeler artık programlarını da aşar.

İdeal olarak, sadece ~% 60 Musts olacaktır. Bunları kesmek zorunda kalırsanız, başınız çok derde giriyor (çok ciddi bir taşma), bu durumda köşeleri kesmeniz gerekir.

Köşeleri keserek oluşan pisliği temizlemek için serbest bırakıldıktan sonra kendinize yeterince zaman ayırdığınızdan emin olun!

Proje tahmini kumar, sade ve basittir. Risksiz ödül yok.

Yönetici bunu anlamıyorsa, açıklayacağım ilk şey budur.

Asıl soru, riski kim kapsıyor?

Sabit fiyatlı bir sözleşmeniz varsa, riski atarsınız.

Zaman ve malzeme ise, o zaman riskini koruyor.

Bu yüzden, tahmin ederken, tahmin ettiğinizi anlamak önemlidir ve tahminin ne kadar belirsiz olduğu ve riski kimin karşıladığı hakkında bir fikriniz olması gerekir.

En iyi stratejinin tahminlerinizi sürekli olarak iyileştirmesi olduğuna inanıyorum . Biliyorum, diyorum ki, sorunuz bir şekilde yanlış yerleştirilmiş.

Dan North tarafından Kasıtlı Keşif Tanıtımı Okuma Tahmin sürecinin başlangıç ​​aşamasına yerleştirilmesinin tam olarak sorunun ve alanın cehaletiniz maksimum düzeyde olduğunda bir tahmin yapmaya eşdeğer olduğu sonucuna vardım. Kabul et, neyin belirsiz olduğunu tahmin edemezsin, özellikle hala bilinmiyorsa .

Çevik metodolojiler bu sorunu, projenin ömrünü birkaç parçaya (Scrum'da sprint, parçalara ayırma) ve her hafta tahminde tekrarlama (boyutlandırma hikayeleri) olarak çözer. Her hafta, sorun hakkında bildikleriniz rafine edilir ve tahmin de öyledir.

Bana göre bir tahmin doğru veya yanlış olamaz. Sadece giderek daha fazla rafine edilebilir . Bir tahmin bir taahhüt değildir. Bu yüzden buna tahmin denir.

Geciktiğinizde (ve ayrıca “önceden teslim etme riskiniz” olduğunda) yapabileceğiniz en iyi şey, çünkü sorun aynıdır: Kötü tahmin etmişsinizdir) gerçeği en kısa zamanda yükseltmek ve gerçeğe sunmaktır. Buna risk yönetimi denir. Bir geri bildirim ne kadar erken verirseniz, karşı-kötüye o kadar etkili olacaktır. Genellikle bu, her şeyi sağlayamayacağınıza dair kanıtlarınız varsa, müşterinizle konuşmanız, ona taahhüdün yalnızca% 70'ini verebileceğinizi ve onun için neyin iş değeri daha yüksek olduğuna karar vermesine izin vermesi gerektiği anlamına gelir .

Buraya yazdım Yanlış tahmin, yardım! Geciktim! Özellikleri kesin ve şelaleyi durdurun!

Buna tahmin denir, çünkü bu eğitimli bir tahmindir. Bu, geleceğin yanılmaz bir açıklaması değildir ve yazılım tahminlerini bu şekilde tedavi edenlere çok az sabrım var. Sonuçta, birçok şey beklediğinizden daha uzun sürecektir, nadir durumlarda daha fazla zaman alabilirler. Bu dünyadaki en iyi programcılara bile olur. Bir yönetici bunun size gelmemesini nasıl bekleyebilir? Eğer menajerin bunu anlamıyorsa, fazla deneyimi olmaz. Program baskısı uygulamak için anlamıyormuş gibi yaparsa, mantıksız davranıyor.

En iyi yaklaşım en açık olanıdır. Bir özelliğin beklenenden daha uzun süreceği konusunda net bir fikriniz olduğunda, bunu yöneticinizle görüşün. Hem sorunlarınızı hem de yöneticinizin sorunlarını çözecek olan ilerlemenin çoğu yolu vardır. Yani, özelliğin işleri yavaşlatan kısmı göreceli olarak önemsiz olabilir veya daha hızlı ilerlemeyi mümkün kılacak şekilde değiştirilmesi kolay olabilir. Bununla birlikte, durum ne olursa olsun, ikinci bir iyimser tahminde bulunmayın.

Tüm ekibin bilmesini sağlayın ve bir çözüm bulmaya çalışın. Öncelikle yüksekten düşüğe öncelikli 3 çözüm öneririm:

a. Geçici bir düzeltme veya geçici bir çözüm bulmaya çalışın

b. Yapabileceğin iş, en iyisini yap. İşinizin mükemmel kısmını müşteriye gösterdikten sonra, yardımlarını isteyin: bunu yapabiliriz, ancak bazı sorunlar var ve işinizin verimliliğini yavaşlatabilir ... Belki de herhangi bir gereksiz istek olup olmadığını sorabilirsiniz. düşürülebilen veya kesilebilen bir özellik.

Sorunlarına alternatif bir yaklaşım önerebilir, belki de iyi bir fikir.

c. Fazla mesai-çalışma

Seçenekler:

• Kesme özellikleri
• Kesim kalitesi (daha sonraları için hata düzeltmeleri bırakın)
• Verimliliği artırmak
  • Engelleyicileri bul ve kaldır
  • Molası / dinlenme
  • Kişisel / uyku süresini kısaltın
  • Daha fazla iş gücü edinin
  • Daha iyi araçlar alın
  • Eğitim
  • Motivasyonu arttırın
    • Bedava yemek
    • [Söz] zam / promosyon / tatil / ikramiye / vb.
    • Tehditler
    • Çalışma koşullarını iyileştirin (daha iyi donanım, mobilya vb.)
    • Çevreyi değiştirin - bir kafeden çalışın ya da tüm ekibi serin bir yere taşıyın - bir dağ evi mi yoksa bir göl evi mi?

Bu yaygın bir sorundur :)

Daha basit yaklaşımlardan biri, öngörülemeyen problemler her zaman meydana geldiğinden, yaptığınız tahminde tampon eklemektir. Tamponun büyüklüğü ekibin büyüklüğüne, teknolojinin belirsizliğine ve sorunun kendisine bağlıdır.

Daha büyük ekipler hastalanabilecek daha fazla insana ve "her şeyi" bilen daha az insana sahiptir.

Yeni teknolojiler her zaman zaten bildiklerinizden daha risklidir.

Tahmini tarihte bitmeyeceğinizi görünce paydaşlarınızla erken iletişim kurun. Belki müşteri / paydaşla konuştuktan sonra işleri yeniden önceliklendirebilir veya belirli özellikleri geciktirebilirsiniz.