2010'dan bu yana 500'ün üzerinde projede çalıştık. Bu sayının bize öğrettiği en net şey, projelerin teknik sebeplerden gecikmediği. Gecikmeler neredeyse her zaman aynı üç yerden çıkıyor ve üçü de kod yazmaya başlamadan önce oluşuyor.
Bir: karar verecek kişinin belirsiz olması
En pahalı gecikme türü, teknik bir sorun değil bir soru işareti. "Bu ekranda indirim kuralı nasıl çalışacak?" sorusunun cevabını verecek kişi belli değilse, soru bir haftada üç toplantı gezip geri geliyor. Bu süre boyunca geliştirme durmuyor — daha kötüsü oluyor: ekip bir varsayımla ilerliyor ve sonra geri alıyor.
Uyguladığımız çözüm sıkıcı ama etkili: her projede tek bir karar verici tanımlanır ve açık soruların listesi paylaşılan bir yerde, tarihli olarak tutulur. Bir soru üç iş günü cevapsız kalırsa, biz makul bir varsayımı yazılı olarak bildirip o varsayımla devam ediyoruz. Yanlış varsayımı düzeltmek, cevap beklemekten daha hızlı.
İki: kapsamın yavaş büyümesi
Kapsam kayması genellikle büyük bir taleple gelmiyor. "Buraya küçük bir filtre ekleyelim" cümlesiyle geliyor ve tek başına gerçekten küçük. Sorun, on beş küçük talebin toplamda bir ay olması ve bu ayın hiçbir plana yazılmamış olması.
Bizim yaklaşımımız talepleri reddetmek değil, görünür kılmak. Her yeni talep, tahmini iş yüküyle birlikte listeye giriyor ve şu soru soruluyor: bu neyin yerine geçecek? Takas açıkça konuşulduğunda müşteri çoğu zaman kendi önceliklendirmesini yapıyor. Konuşulmadığında ise teslim tarihi sessizce kayıyor ve fatura ilişkiyi zedeliyor.
Üç: entegrasyonların hafife alınması
Teknik tarafta en çok yanıldığımızı gördüğümüz tahminler, hep başka bir sistemle konuşan işler oldu. Kendi kodunuzu tahmin etmek kolaydır; ERP'nin, bankanın veya kargo firmasının API'sini tahmin etmek değil. Sık rastladığımız gerçekler: dokümantasyon güncel değil, test ortamı yok veya haftalarca kapalı, yetkilendirme süreci bir ayı alıyor, hata mesajları belirsiz.
- Entegrasyon içeren her projede en erken işi entegrasyon keşfi yapıyoruz — arayüz henüz çizilmemişken.
- Test ortamına erişim, projenin başlangıç koşulu olarak sözleşmeye yazılıyor.
- Karşı tarafın yanıt vermediği durumlar için plan B baştan tanımlanıyor.
Peki teknik borç nerede
Teknik borç gecikmelerin sebebi değil, çarpanı. Temiz bir kod tabanında bir gün süren değişiklik, ihmal edilmiş bir tabanda üç gün sürüyor; ama projeyi raydan çıkaran şey yine yukarıdaki üç madde oluyor. Yine de şunu söylemek gerek: test yazılmamış bir sistemde her yeni özellik, geri dönük hata riskini artırıyor ve bir noktada ekip değişiklik yapmaktan korkmaya başlıyor. O korku, hızın gerçek düşmanı.
Ölçtüğümüz tek şey
Proje sağlığı için tek bir gösterge takip ediyoruz: bir işin "başlandı" durumundan "müşteri onayladı" durumuna geçmesi ne kadar sürüyor. Bu süre uzuyorsa, sebebi neredeyse her zaman yukarıdaki üç maddeden biri — kodun karmaşıklığı değil. Sprint hızı gibi ölçümler ekibi meşgul gösterir; bu gösterge işin akıp akmadığını gösterir.
Tahmin yapmanın dürüst yolu
Tek bir sayı vermek, herkesi memnun eden ama kimseye yardımcı olmayan bir alışkanlık. Biz tahminleri aralık olarak veriyoruz ve aralığın genişliğini bilinmeyenin miktarına bağlıyoruz. Net bir şartname varsa aralık dar; entegrasyon belirsizse geniş. Genişlik, riskin kendisi hakkında bilgi taşıyor ve müşteri bunu okuyabiliyor.
İkinci alışkanlığımız, projeyi en riskli parçadan başlatmak. Sezgi tersini söylüyor — kolay işleri bitirip hızlı ilerleme göstermek cazip. Ama kolay işlerle başlanan projelerde risk, takvimin sonuna, yani düzeltmek için en az zamanın olduğu yere itilmiş oluyor. En belirsiz parçayı ilk iki haftada denemek, kötü haberi erken duymanın en ucuz yolu.
İyi giden projelerin ortak yanı
Zamanında ve bütçesinde biten projelere baktığımızda teknoloji seçimi ortak değil; ortak olan şey haftalık ritim. Her hafta aynı gün, çalışan bir sürümün gösterildiği kısa bir görüşme. Gösterilecek bir şey yoksa bu da bilgidir ve sorun küçükken ortaya çıkar. Aylık raporla yönetilen projelerde ise kötü haber, düzeltmek için çok geç olduğu anda geliyor.
Devam eden bir projeniz tıkandıysa veya yeni bir işe doğru kurulumla başlamak istiyorsanız, iletişim sayfamızdan bize yazın. Bazen en değerli katkımız kod yazmak değil, hangi kararın verilmesi gerektiğini net biçimde söylemek oluyor.