Programcı olarak bizlere sürekli olarak 'Ne kadar sürecek' soruluyor.
Ve biliyorsunuz, durum neredeyse her zaman böyle:
Bunların birçoğu basit ve çözülmesi kolay olmayan örgütsel veya kültürel konulardır, ancak sonuçta gerçek şu ki, bir tahmin isteniyor ve makul bir cevap vermenizi bekliyorlar. Bu işinizin bir parçası. Basitçe söyleyemezsin: Bilmiyorum.
Sonuç olarak, her zaman daha sonra yerine getiremeyeceğimi fark ettiğim tahminleri veririm. Birçok kez oldu ve her zaman tekrar olmayacağına söz veriyorum. Ama öyle.
Bir tahmine karar verme ve sunma konusundaki kişisel süreciniz nedir? Hangi teknikleri yararlı buldunuz?
Bir Tahmin İstendiğinde Söylenecekler
"Sana geri döneceğim" diyorsun.
İşlemi yavaşlatırsanız ve bu bölümde açıkladığımız adımlardan geçerek biraz zaman harcarsanız, neredeyse her zaman daha iyi sonuçlar alırsınız. Kahve makinesinde verilen tahminler (kahve gibi) size musallat olmak üzere geri gelecektir.
Bu bölümde yazarlar aşağıdaki işlemleri önermektedir:
Yazılım tahmini, yazılım mühendisliğindeki en zor tek görevdir - yakın bir saniye de ihtiyaçların ortaya çıkarılmasıdır.
Bunları oluşturmak için bir sürü taktik var, hepsi önce iyi gereksinimleri elde etmeye dayanıyor. Ama sırtınız duvara yaslandığında ve size daha iyi detaylar vermeyi reddettiklerinde, Sahte O:
Annem çocukken tehdit ediyormuş gibi "Çabuk ol ve biraz kıyafet seç, ya da I onları senin için seç!"
Doğru tahminler istemek konusunda çok kararlı bir adam için gelişim yaptım. Yerleştirdiğimiz, çok iyi çalışan şey şuydu:
Faturalandırmanın% 20-25'i çok gibi geliyor.
Ama benden yaklaşık 2 saat süreceğini düşünerek XYZ'de değişiklik yapmamı isterdi. 1 saatlik ayrıntılı tahminde 8,5 saat alacağını belirleyeceğim. Bu yüzden 8,5 saatlik ödemeye değip değmeyeceğine karar verecekti. Değilse, tahmin etmeden yapsaydım, ne kadara mal olacağından 7.5 saat tasarruf etti.
Ve eğer yaptı 8.5 saate yatırım yapmak istiyorsa, tahmin için yaptığım detay işi zaten yapmak zorunda olduğum işti.
Bu yöntemle, çoğu görevi çok fazla abartmak zorunda kalmadan zamanında veya hatta erken getirebildiğimi buldum. Zaman çok küçük bir şekilde parçalandığından, kayıp kaymadığımı erken söyleyebilirim. 3 saat sonra 8.5 saatlik görevimin 12 alacağını söyleyebilseydim, daha fazla zaman geçmeden onunla konuşabilirdim, böylece maliyet hakkında endişeliyse özelliği yeniden değerlendirebilir ve çekebilirdi. .
Nikel ve dimer miydi? Hayır, ona parasını en çok yarar gördüğü yere uygulamasına izin vererek baktım. Ve her zaman korkunç olduğum tahminlerde deneyim kazandığım için çok mutluyum.
Bize ne yapmak istediklerine dair çok geniş ve kesin fikirler verildiği toplantılarda sık sık bir "basketbol sahası tahmini" istenir. Ben her zaman diyorum ki, "bugün bir cevap istiyorsan bir yıl ve bir milyon dolar. Bana çok daha fazla ayrıntı vermek ve bunları gözden geçirmek için biraz zaman vermek istiyorsan, o rakamları senin için düzeltebilirim."
Neredeyse her zaman bunu anlıyorlar.
Bu tahminin ne olduğuna bağlıdır.
Bir iş vakası için ilk, yüksek düzeyli bir tahmin için, temel şeyler şunlardır:
Ben de aynı şeyi hisseden karşılaştırılabilir bir proje seçmek için en iyi tekniği buluyorum. "Hissedin" tamamen özneldir - ancak bu tür bir tahminle deneyimlerim bana objektif ölçümler bulamayacağınızı söylüyor. Sonra geniş bir aralık sağlayın. % -50 ila +% 100 aralığının iyi olduğunu söyleyen bazı kitaplar okudum ama birçok faktöre bağlı.
Ayrıntılı, düşük seviyeli bir tahmin için:
Karanlık yoldan zor yolu öğrenenlerden bazı tavsiyeler.
Gereksinimler belli değil. Kimse tüm çıkarımların derinlemesine bir analizini yapmamıştır.
Bu noktada bir tahmin yapmayın. Düşman sayıları hakkında hiçbir ipucu olmadan bir savaşı kazanmak için kaç askere ihtiyaç olduğu tahmin edilmez. Tahmin izcilikten sonra yapılır. Bu düşmanla savaşmadığınız sürece budur.
Yeni özellik muhtemelen kodunuzda yaptığınız bazı varsayımları kıracak ve yeniden düzenlemeniz gerekebilecek her şeyi hemen düşünmeye başlayacaksınız.
Başkalarının bu alanla ilgili uzmanlığa sahip olmasını beklemediğiniz sürece, bu faktör dikkate alma sorumluluğunuzdur.
Geçmiş ödevlerden yapacak başka şeyleriniz var ve bu diğer işi dikkate alan bir tahmin bulmanız gerekecek.
Yukarıdaki ile aynı, yanınızda bir slob takım arkadaşı tarafından yaratılan beklenmedik çalışmalar için bile, kodunuzun önceden tahmin edemeyeceğiniz şekilde hata vermesine neden olan neredeyse yok olan bir test prosedürüyle. Hava tahmini.
'Done' tanımı muhtemelen belirsizdir: Ne zaman yapılacak? Kodlamayı bitirmiş gibi 'Bitti' mi yoksa “kullanıcılar kullanıyor” da olduğu gibi 'bitti' mi?
Buradaki kullanıcı sonu gereksinimini anlayın, bir kullanıcı gibi düşünün. Eğer hiçbir kullanıcının muhtemelen tolere edemeyeceği bir barebone iş akışına sahip bazı temel işlevlerin "done" olduğunu düşündükleri şey olduğu için, akranlarınızın "yapılması gereken" bir şey olduğunu tahmin ederse yaptıklarını yapmayın. Bunu kullanıcı açısından düşünün, çünkü tahmin ettiğiniz tüm müşteri genellikle anlayacaktır. Barebone teknik gereksinimlerine değil, tam kullanıcı sonu gereksinimlerine yönelik tahmin. Ve tahminler isteyen müşterilerinizin, şeyleri nasıl ifade ettikleri ve söylediklerinizin teknik yönlerini anlamaları konusunda burada tamamen yanlış olacağını anlayın.
Tüm bu şeyler hakkında ne kadar bilinçli olursanız olun, bazen "programcısının gururu" sizi başlangıçta alabileceğinizden daha kısa süre verir/kabul eder. Özellikle son teslim tarihlerinin ve yönetim beklentilerinin baskısını hissettiğinizde.
Bunu yapma! Kendini motive eden ve muhtemelen zorla kolayca teslim olan bir işçi gibi konuşuyorsun.
Buradaki sorun şudur: Diyelim ki siz ve Joe aynı görev için zaman tahminleri yaptınız (ancak iki ayrı çalışan arasında, her iki tahminin de bir seferde farkında olmadığını). Cesurca tahmin edersiniz, "bir hafta". Haftada 100 saatten fazla çalışacaksınız, ücretsiz fazla mesai olduğunu düşünebilirsiniz. Şimdi üç gün geç kaldın.
Bu arada Joe 5 ay tahmin ediyor. Bunun gülünç olduğunu düşünüyorsun, bunu bir hafta içinde çekebileceğini düşünüyorsun. Joe ne kadar çalışıyor? Haftada 10 saat? ... tam olarak 5 ayda bitirmesi dışında.
Tahmin edin kim jackass olarak algılanıyor? Bu doğru, sen. Joe harika bir işçi gibi görünüyor, şimdi güvenilmez görünüyorsun. O kadar önemli değil ki Joe'nun aldığı sürenin ~% 7'sinde daha iyi bir sonuç elde etmiş olabilirsiniz. Önemli olan bir haftalık tahminden 3 gün izinli olmanız.
Asla daha sıkı tahminin yanında hata yapmayın. Daha gevşek tahmin tarafında Err. Şirketinizde inşa edeceğiniz bir itibar var ve tahminlerinizin uzunluğuna, tahminlerinizin doğruluğu kadar dayanmayacak. Çok uzun bir tahminle doğru olmak kolaydır, sorun üzerinde çalışmak ve daha iyi çözmek için daha fazla zaman alırsınız. Çok kısa bir tahmin, hiç nefes alma alanı bırakmaz, ya umutsuzca karşılarsınız ya da vidalanırsınız.
"İki hafta!"
Ciddi anlamda. İlk tahminim her zaman iki haftadır. Çünkü tuhaf bir zihinsel bloğum var, bu da bana her şeyin iki hafta gibi geleceğini düşündürüyor.
Etrafında çalışmaya çalışıyorum, gerçekten düşünmek Bir şeyin ne kadar süreceğini düşündüğüm hakkında, doğru tahmin edemeyeceğim kadar kara kutu-y gibi görünen tüm potansiyel sorunlu noktaları ve bitleri belirlemeye çalışıyorum. Ve cevabım "İki hafta!" İse, bunu yapamadığımı anlamaya çalışın.
Hemen hemen her iyi yönetici "İki hafta!" cevap olarak hafif bir sözel pezevenk tokat gerektiren bir cevap olarak.
Önceki tahminlerinizin ne kadar doğru gittiğini nasıl kaydedeceğinizi özetleyen bir blog girişi vardır ve daha sonra birisine "iki hafta olacak" dediğinizde, önceki tarih ve "iki hafta olacak" dediğin son seferde ne kadar sürdüğünü görün.
Kendim denemedim, ama tahminlerimin ne kadar doğru olduğunu görmek istiyorum.
Kuruluşa ve tahminlerin nasıl kullanıldığına bağlıdır.
Eğer tahmin sadece ne zaman hazır olacağına dair genel bir fikir vermekse, genellikle tecrübelerime dayanarak hızlı bir tahmin yapabilirim. Çoğu zaman, değişikliklerin sistemin diğer alanlarını nasıl etkileyebileceği ve gerekli regresyon testinin kapsamı ile birlikte tahminle ilgili herhangi bir belirsizlik veya olası varyasyon içereceğim.
Tahmin, sözleşmeye bağlı herhangi bir şey için veya daha kesin zamanlamanın gerekli olduğu bir senaryoda kullanılıyorsa, tam bir iş kesintisi yaparım. Bu daha fazla iştir ve tasarım ve sistemdeki değişiklikler hakkında daha fazla düşünmeyi gerektirir, ancak özellikle daha büyük iş parçaları için çok daha doğrudur.
Her iki durumda da, devam eden iletişim önemlidir. Beklenmedik bir şeyle karşılaşırsanız, son tarihe kadar beklemek yerine o anda bilinmesini sağlayın. Gereksinimler açık değilse, bunları anladığınızı ve sunmayı planladığınız işlevselliği belgelediğinizden emin olun. Bu, yaptığınız varsayımlarda da yardımcı olur. Ve rakip öncelikler, bir iş parçası diğerini çarptığında, bunun programı nasıl etkileyeceği konusunda net olun.
Ne için tahmin? Küçük görevler veya komple çözümler.
Ikincisi nadiren yapıyorum ama sonra sadece tahmin, biraz ekleyin, müdür biraz ekleyin ve yukarıdaki bir tahmin olduğunu belirten küçük bir not ile bir aralık içine yapmak var.
Küçük görevler - Planlama pokeri Gerçekten iyi çalıştığını buldum (mükemmel değil, bazı 1pt görevleri çok daha uzun sürdü ve bazı 5pt görevleri dakikalar aldı, ancak sonunda sonuçta ortaya çıkıyor).
Bugün bildiklerinizi temel alan bir aralık sunun. İlk tahminlerinizin etrafındaki aralığı sağlamak için Belirsizlik Konisi kullanın.
Her hafta ne kadar kalacağınızı hesaplayın, bildiklerinize göre yeniden tahmin edin. Her hafta ne kadar iş yaptığınıza dair yeterli bir örneklem büyüklüğüne sahip olduğunuzda, proje ilerledikçe ve kalan iş miktarı (umarım ) küçülür.
Kendine güvenerek. Tahmin verirken profesyonellik yapmayarak bir müşteriyle ilk toplantıyı kaç kez başlattığımı söyleyemem. Rakamları ince havadan temizliyor olsanız bile - her zaman tahminlerde bulunduğunuzdan emin olun. Bununla birlikte, kendinizi bir deliğe tahmin etmemeye dikkat edin. Farklı şeyler bir araya getirmek için farklı miktarda zaman, çaba ve kaynak gerektirir. İşte bunu yapmanın iyi bir yolu:
Onları: Ne kadara mal olacak?
Ben: Ne yapmamı istediğine bağlı. Genellikle, bu tür bir projeye yaklaşık X $ 'dan başlarım.
Bazen tahmin, özellikle yazılım projesi tahmini hakkında konuşurken, sizin ve ekibiniz için büyük bir zorluk haline gelir.
Deneyimimizi ve yazılım tahmin süreci hakkındaki bilgilerimizi paylaşmaya karar verdikten ve dört farklı tahmin türü :
Tabii ki, bu türler farklıdır. Ballpark, genellikle “guesstimate” olarak adlandırılır. Bu, genel bir maliyet fikri veren ve bir potansiyel müşterinin tartışmayı daha ileri götürmek isteyip istemediğine karar vermesine yardımcı olabilecek yaklaşık bir sayı veya aralıktır.
Kural olarak, müşteriler projenin başında bir ballpark figürüne ihtiyaç duyarlar. Ve tavsiyemiz: projenin tartışılması ve basketbol sahası figürlerinin sağlanması, sadece bileşen tahmini (esnek olan, Tüm geliştirme süreci için bileşen türü tahmini.Özellikler, hizmetler vb. eklemek, kaldırmak veya değiştirmek istediğinizde sıfırdan yeniden tahmin etmeye gerek yoktur).
Herkes yazılım geliştirme tahminiyle gelen riskleri akılda tutmalıdır: hafife alma, fazla tahmin etme, toplam destansı başarısızlık senaryosu vb.
Blogumuzda daha fazlasını okuyabilirsiniz!
Umarım bu bilgi size yardımcı olur!
Her zaman daha sonra yerine getiremeyeceğimin farkına varacağım tahminler veririm. Birçok kez oldu ve her zaman tekrar olmayacağına söz veriyorum.
Bir tahmin değil, bir taahhüt isteniyor gibi görünüyor. Bunlar farklı şeylerdir, ancak taahhütleri güvenilir bir şekilde yönetebilirseniz, güvenilirliğinize ve kariyerinize gerçekten yardımcı olacaktır.
~ 10 yıllık deneyimime dayanan bazı tavsiyeler:
İlk olarak, eğer bana bir görev atandıysa alt görevlere ayırırdım, her alt görev için zamanı tahmin ederdim ve muhtemelen alt görevlerle sorunlu alanı bulabilirim ve bu yüzden ne kadar süre olacağını tahmin edebilirim bir dereceye kadar almak.
Ancak yine de tüm planlama sadece belirli bir dereceye kadar yardımcı olacaktır. Yalnızca kodlamaya başladığınızda kesin sorunları bulabilirsiniz
Aynı patron veya müşteri için birçok proje yaparsanız, haftalar veya aylar yerine, muhtemelen t-shirt boyutlarında geniş karmaşıklık darbeleriyle tahmin etmeye çalışabilirsiniz. Geçmiş birkaç projeyi belirleyin ve onlara S, M, L, XL boyutlarını atayın.
Ve sonra kendinize sorun: Bu, hangi projenin kapsamına benziyor? Ve sonra "2 Ay" ile cevap vermek yerine, "bana bir L gibi geliyor" (veya proje için kalibrasyonunuz ne olursa olsun) ile cevap verebilirsiniz.
Bunu anlamak oldukça kolaydır ve bu tahminlerde çok fazla belirsizlik olduğu da açıktır.
Ardından, gereksinimler değiştiğinde, "bu değişiklik bir XL gibi ses çıkarır" diyebilirsiniz.
Biraz geç ama ordudayken tahminleri belirlemek için PERT kullanmamız istendi. Alanınızda ve mevcut görevinizde biraz deneyim gerektirir. Rutin bakım sırasında çok sayıda şeyin yanlış olabileceği veya bulunabileceği ve düzeltilmesi gereken elektronik cihazları (karmaşık telsizler ve uydu iletişim ekipmanları) korurken ve tamir ederken tahmini tamamlanma süresini belirlerken şaşırtıcı derecede doğruydu. Tahminler önemliydi, çünkü diğer birimler haberleşme teçhizatını geri alana kadar çalışmaz olabilir. Kullandığım şey bu Ücretsiz Çevrimiçi PERT Hesaplayıcı