Kapsam çıkarma, kapasite kazandırması beklenen düzenlerin sessizce çöktüğü yerdir. Keşif aşaması atölyelerle yürür, atölyeler de kıdemli mühendislerinizin takvimiyle yürür; yani ekibinizi serbest bırakması gereken çalışma, tek satır kod yazılmadan o ekibin üç haftasını harcar.
Bunun böyle olması şart değil. Yetkin bir dış ekip, elinizde zaten olan belgelerden ve tek günlük soru-cevaptan kapsam çıkarabilir. Aşağıda bunun sizden ne istediği ve size ne kazandırdığı var.
Önemli noktalar
- Belgeden kapsam çıkarmak toplantıdan çıkarmayı yener: Sisteminiz kendini zaten anlatıyor.
- Atölye serisi değil, tek günlük soru-cevap: Fazlası, sizin hesabınıza öğrendikleri anlamına gelir.
- Mimariye değil arayüze karar verin: Önemli olan kapsam sorusu sınırdır.
- Çıktı reddedilebilir olmalı: Hayır diyemediğiniz kapsam, kapsam değildir.
Dış ekibin sizsiz okuyabilecekleri
Bir atölyenin çıkardığı şeylerin çoğu zaten bir yerde yazılıdır:
- Veritabanı şeması. Bir işletmenin gerçekte ne yaptığının en dürüst tarifi ve dokümantasyonun yanıldığı gibi nadiren yanılır.
- API tanımları ve entegrasyon noktaları. Sistemin zaten dışarı açtığı ve bağımlı olduğu şeyler.
- İş takip sistemi. Ne bozuluyor, ne sıklıkla ve hangi alanlar dikkat tüketiyor.
- Depo geçmişi. Hangi kısımlar sık değişiyor, hangileri durağan, hangilerine iki yıldır kimse dokunmamış.
- Dağıtım yapılandırması. İşler nasıl, nerede ve neyle çalışıyor.
- Son arızalar. Sistemin nerede kırılgan olduğunu anlamanın genelde en hızlı yolu.
Bunlara okuma erişimi vermek birinin bir saatini alır. Aynı malzemeyi toplantıda anlatmak haftalar alır ve daha kötü bir tablo üretir, çünkü insanların söylemeyi hatırladıklarından süzülür.
Sizin sağlamanız gerekenler
İş sonucu
Sizin yazdığınız bir iki cümle; kurulmasını istediğiniz yazılımı değil, işletmede istediğiniz değişikliği anlatan. Bu şemadan türetilemez ve onu sizin yerinize kimse yazamaz.
Bir günlük soru-cevap
Sistemi en iyi bilen bir iki kişiyle bir zaman bloğu. Tanıtım değil, malzemeyi zaten okumuş insanlardan gelen gerçek sorular.
Dış ekibin bunu doğru yapıp yapmadığının testi: sorular somut ve biraz rahatsız edici olmalı. "Siparişler tablosunda neden iki durum sütunu var" diyen ekip sisteminizi okumuştur. "İşinizi bize anlatır mısınız" diyen ekip işi size yaptırmak istiyordur.
Sınır için bir karar verici
Arayüz sorularını bir gün içinde yanıtlayabilecek biri. Tek süregelen taahhüt budur ve ayda saatler demektir.
Kısıtlarınız
Pazarlığa açık olmayan şeyler: bir mevzuat gereği, entegre olmak zorunda olduğunuz bir platform, gerçek bir iş sebebiyle var olan bir tarih, standartlaştığınız bir teknoloji. Bunları başta söyleyin. Altıncı haftada keşfetmek, kapsamın yeniden yapılmasının yoludur.
Mimariye değil arayüze karar verin
Gerçekten yanıtlanması gereken soru "bu nasıl kurulmalı" değildir. "Bu yeni şey nerede bitiyor ve bizim sistemimiz nerede başlıyor" sorusudur.
Dört şeyi çözün, gerisi sonra gelebilir:
- Yeni ürün neyi, hangi yoldan okuyabilir.
- Neyi yazabilir, yazabiliyorsa.
- Neyi asla yapmamalı. Genelde şema değişikliği yok, çekirdek tablolara yazım yok, üretime ağır sorgu yok.
- İki taraftan birinin değişmesi gerektiğinde kim karar verir.
Bu, iki teknik kişi arasında birkaç saatlik iştir. Aynı zamanda en sık ertelenen şeydir, çünkü mimari tartışmasının yanında ayrıntı gibi görünür; oysa işin başlayabilmesi için anlaşılması gereken tek kısım budur.
İyi bir kapsam çıktısı nasıl görünür
Onu reddedebiliyor olmalısınız. Bu da somut şeyler içerdiği anlamına gelir: ilk sürümde ne var, açıkça neler dışarıda, hangi varsayımlara dayanıyor, tahmini ne değiştirir ve tek bir tarih yerine bir aralık.
Herhangi bir projeyi tarif edebilecek bir kapsam belgesi kapsam değil, tekliftir. Faydalı hâli, başkasının işine uygulandığında yanlış olacak şeyleri sizin işiniz için adlandırır.
Ayrıca dış ekibin hâlâ bilmediklerini ve bunları neyin çözeceğini de söylemelidir. O liste, kendinden emin kısımlardan daha iyi bir kalite göstergesidir.
Gelen kapsam sizinkiyle uyuşmazsa
Dış ekibin çıkardığı kapsam sizin beklediğinizden büyük geldiğinde ilk tepki pazarlık olur. Daha faydalı hamle, farkın nerede olduğunu sormaktır: hangi maddeyi siz hesaba katmamıştınız, hangisini onlar sizin işinizde gereksiz yere varsaydı?
Bu sorunun cevabı genelde üç yerden birine düşer. Ya sizin bilmediğiniz bir teknik gereklilik vardır, örneğin bir entegrasyonun beklenmedik bir davranışı. Ya sizin için açık olan bir iş kuralı belgelerde görünmüyordur ve ekip en kötü ihtimali fiyatlamıştır. Ya da kapsam, ilk sürümde olması gerekmeyen şeyleri içermektedir.
Üçü de konuşulabilir ve üçünün de farklı bir çözümü vardır. Rakamı doğrudan aşağı çekmek ise hiçbirini çözmez; yalnızca aynı işin daha az bütçeyle yapılacağı sözünü alırsınız ve o söz teslim tarihinde geri gelir.
Ali Boran Gazel