Teknik değilseniz haftalık güncelleme elinizdeki tek ölçüm aracıdır ve çoğu haftalık güncelleme doğrulanabilir olmak için değil içinizi rahatlatmak için tasarlanmıştır. Çözüm kod okumayı öğrenmek değil. Kendinden emin bir paragrafla geçiştirilemeyen dört soru sormak.
İyi bir sorunun tek bir özelliği vardır: ona verilen belirsiz cevap, belirsiz olduğu görülür. "Ödeme tarafı nasıl gidiyor?" bu testi geçemez, çünkü "iyi ilerliyor, birkaç uç durum kaldı" kulağa kabul edilebilir gelen ama içi boş bir cevaptır. Aşağıdaki dört soru bu şekilde cevaplanamaz.
Önemli noktalar
- Durum değil, somut şey isteyin: Bir demo, bir tarih, bir sayı. Durum bir iddiadır; çıktı kanıttır.
- İçerik değil, belirsizlik sinyaldir: Cevabı denetlemiyorsunuz, somut bir cevabın var olup olmadığını denetliyorsunuz.
- Cevapları yazın: Değerin çoğu bu haftanın cevabını geçen haftanınkiyle karşılaştırmaktan gelir.
- Dört soru yeterlidir: Uzun liste toplantıyı ritüele çevirir; ritüeller cevaplanmaz, icra edilir.
Soru 1: Geçen hafta kullanamadığım neyi bugün kullanabiliyorum?
Ne üzerinde çalışıldığı değil. Sizin kendi başınıza açabileceğiniz ne değişti?
Emekle tatmin edilemeyen tek soru budur. Dürüst cevabın "henüz görebileceğiniz bir şey yok, veri modelini yeniden kuruyoruz" olduğu bir hafta gayet iyi bir haftadır, ama bir şeyin çıktığı haftadan farklı bir haftadır ve hangisini yaşadığınızı bilmeniz gerekir.
Bir bağlantı, bir test hesabı ya da ekran kaydı bekleyin. Cevap düzenli olarak "görünür bir şey yok" ise, bunun kaç haftadır böyle olduğunu sorun. Zor bir altyapı işinde üç hafta normaldir. Sekiz hafta, yolunu kaybetmiş bir proje ya da işi bitirilebilecek küçüklükte parçalara bölmeyi bırakmış bir ekip demektir.
Soru 2: Bitecek bir sonraki şey ne ve ne zaman?
Tek madde, tek tarih. Liste değil, sprint hedefi değil, yüzde değil.
Değer tekrarda. Cevabı yazın. Gelecek hafta karşılaştırın. Kendi bir haftalık öngörüsünü çoğu zaman tutturan ekip, kendi işini anlayan ekiptir. Sıradaki-iş-ve-tarih cevabı her hafta değişen bir ekip, size işin dibini göremediğini doğru biçimde söylüyordur ve bunu teslim tarihinde değil erken bilmek gerekir.
Kimseyi tarihe bağlamıyorsunuz. Ne kadar iyi öngördüklerini ölçüyorsunuz ki bu, problemi ne kadar iyi anladıklarını ölçmeye en yakın şeydir.
Soru 3: Şu an sizi ne engelliyor ve sahibi kim?
Engeller her projede en az raporlanan kalemdir, çünkü engel bildirmek itiraf gibi hissettirir. Her hafta rutin olarak sormak bu maliyeti ortadan kaldırır.
İstediğiniz cevapta bir isim geçer. "Ödeme sağlayıcısını bekliyoruz" eksik bir cevaptır; "ödeme sağlayıcısını bekliyoruz, salı e-posta attım, dönmediler, perşembe tekrar yazacağım" tam cevaptır. Tipik bir projedeki engellerin yarısı sizin on dakikada kaldırabileceğiniz şeylerdir: bir onay, bir hesap, bir tanıştırma, kimsenin vermek istemediği bir karar.
Tarihler kayarken cevap sürekli "bizi engelleyen bir şey yok" ise, engel işin içindedir ve kimse ona ad koymamıştır.
Soru 4: Planı değiştiren ne öğrendik?
Yazılım projeleri bir şeyler keşfeder. Dokümantasyonda yazdığı gibi çalışmayan bir entegrasyon, herkesin sandığından kirli bir veri kümesi, kendi işinizde kimsenin yazıya dökmediği bir kural. Bu keşifler tahminlerin kaymasının başlıca sebebidir ve genelde raporlanmadan haftalar önce bilinir.
Doğrudan sormak, bunları bildirmeyi normalleştirir. Ayrıca asıl önemli yargı için ham madde verir: bu proje zamanla netleşiyor mu, yoksa bulanıklaşıyor mu? Netleşen proje teslim edilir. Her hafta yeni bir bilinmeyen ekleyen proje edilmez ve baskı bunu değiştirmez.
Kötü cevaplarla ne yapmalı
Bu tür sorulara üç tepkiden biri gelir: somut bir cevap, dürüst bir "henüz bilmiyorum, öğrenip döneceğim" ya da cevap gibi duran bir paragraf. Dikkat edilmesi gereken üçüncüsüdür ve çözüm yüzleşme değildir. Aynı soruyu gelecek hafta aynı kelimelerle sormak ve iki cevabı da yazmaktır.
Kalıplarla tartışmak tek tek olaylarla tartışmaktan çok daha zordur. Dört haftalık kayıtlı cevap size herhangi bir denetimden fazlasını söyler ve haftada yirmi dakikaya mal olur.
Kalıp kötüyse ve sebebin zorluk mu başka bir şey mi olduğunu hâlâ ayırt edemiyorsanız, artık raporlara değil işin kendisine teknik birinin bakması gerekir. Bu ayrı bir çalışmadır ve teknik denetimin neyi kapsadığını ayrı bir yazıda anlattık.
Ali Boran Gazel