"Bu iş iki gün sürer" denilen bir özelliğin iki hafta sürmesi yazılım dünyasında neredeyse bir klişedir. Tahminlerin şaşması tembellik veya beceriksizlik değil, işin doğasındaki belirsizliğin sonucudur. Yine de bu belirsizliği yönetmek ve tahminleri daha güvenilir hale getirmek mümkündür.
Tahminler neden şaşar?
- Bilinmeyenler: Mevcut kodun içinde ne olduğu, entegre edilecek sistemin nasıl davranacağı önceden tam bilinmez.
- Sadece kodlamayı saymak: Test, inceleme, dağıtım, dokümantasyon ve toplantılar unutulur.
- İyimserlik: Her şeyin ilk seferde çalışacağı varsayılır.
- Kapsamın değişmesi: İş yapılırken yeni istekler eklenir. Bkz. kapsam kayması.
- Kesintiler: Destek talepleri, acil hatalar ve bağlam değiştirme.
İşi parçalara bölün
"Fatura modülü" tahmin edilemez; "fatura listesi ekranı", "PDF çıktısı", "e-posta ile gönderim" gibi parçalar edilebilir. Kural: bir parça birkaç günden büyükse daha da bölün. Küçük işlerde tahmin hatası küçük kalır ve ilerleme görünür olur.
Tek sayı yerine aralık
| Senaryo | Süre |
|---|---|
| İyimser | 3 gün |
| En olası | 5 gün |
| Kötümser | 10 gün |
Aralık vermek, belirsizliği gizlemek yerine görünür kılar. Kötümser senaryonun neden uzun olduğunu söylemek de değerlidir: "Bankanın test ortamı çalışmazsa beklemek zorunda kalırız."
Belirsizliği azaltmak için keşif
Çok belirsiz bir iş için önce kısa ve süresi sınırlı bir keşif (spike) yapılır: "Bir gün içinde entegrasyonun nasıl çalıştığını inceleyip daha net bir tahmin vereceğim." Bu, büyük bir belirsizliği küçük ve kontrollü bir maliyetle çözer.
Geçmiş veriden öğrenin
- Tahminlerinizi ve gerçekleşen süreleri kaydedin.
- Genellikle ne kadar saptığınızı görün; çoğu kişi düzenli olarak belirli bir oranda iyimserdir.
- Benzer geçmiş işlere bakarak tahmin yapın: "Son üç entegrasyon ortalama bir buçuk hafta sürdü."
Story point ve göreli tahmin
Ekipler bazen saat yerine göreli büyüklük (story point) kullanır: işler birbirleriyle karşılaştırılarak puanlanır ve ekibin bir dönemde ortalama kaç puan tamamladığına bakılarak planlama yapılır. Bu yöntem bireysel hız farklılıklarını ve iyimserliği kısmen dengeler. Süreç yöntemleri için bkz. Agile, Scrum ve Kanban.
Müşteriye tahmin iletmek
- Tahminin varsayımlarını yazılı belirtin.
- Belirsizlik payını açıkça söyleyin.
- Kapsam değişirse tahminin de değişeceğini baştan konuşun.
- Gecikmeyi fark ettiğiniz anda bildirin; son gün sürpriz yapmayın.
- Büyük projelerde aşamalı teslimat ve ara sürümlerle güven oluşturun.
Bütçe tarafı için bkz. yazılım projesi bütçe planlama.
Sık sorulan sorular
Tahmine güvenlik payı eklemek dürüst mü?
Evet, açıkça belirtildiği sürece. Belirsizliği hesaba katmak profesyonelliktir; gizli şişirme ise güveni zedeler.
Tahmin vermemek bir seçenek mi?
İş planlaması için tahmin gereklidir. Ancak çok belirsiz işlerde önce keşif yapıp sonra tahmin vermek daha sağlıklıdır.
Sonuç
İyi tahmin, belirsizliği yok saymak değil, yönetmektir. Küçük parçalar, aralıklı tahminler, geçmiş veri ve açık iletişim; hem ekibin hem müşterinin daha gerçekçi planlar yapmasını sağlar.
