Pahalı sorunları erken bulun.
Çoğu yazılım projesi, ilk kod gönderiminden (commit) önce alınan kararlar yüzünden başarısızlığa uğrar: kimsenin yazıya dökmediği süreçler, kimsenin dile getirmediği uç durumlar veya aslında bir kişinin elektronik tablo kopyalamasından ibaret olduğu sonradan anlaşılan entegrasyonlar. Biz önce bunları tespit ediyor, ardından neyin ve neden inşa edilmesi gerektiğini yazıya döküyoruz.
Ne yapıyoruz.
Projenin geri kalanının neye mal olacağını belirleyen kısım.
- 01İşin bugün nasıl yürüdüğünü haritalıyoruz; sistemin dışında kalan kısımlar dahil.
- 02Geliştiricinin üzerinden geliştirebileceği, test edenin karşılaştırabileceği gereksinimler yazıyoruz.
- 03Entegrasyonları söküyor, hangisinin API hangisinin insan olduğunu çıkarıyoruz.
- 04Düzenleyici kurumun, denetçinin ya da finans ekibinin bundan ne isteyeceğini belirliyoruz.
- 05Kapsamı yayına çıkabilecek hâle getiriyor, nelerin elendiğini ve neden elendiğini söylüyoruz.
Çıkan iş, geliştirmenin üzerinden fiyatlandığı liste oluyor; işi biz geliştiriyorsak kendimizi de o listeye bağlıyoruz. Bir daha açılmayan bir belge, sizin paranızı ve bizim emeğimizi harcıyor.
Elinize ne geçiyor.
- 01Bugünkü işleyişin haritasıBirinin gelen kutusunda, bir beyaz tahtada veya kurumda en uzun süredir bulunan kişinin zihninde yer alan adımlar da dahil olmak üzere.
- 02Doğrudan geliştirmeye uygun gereksinimlerSistemin yapması gereken şeyler olarak, kabul kriterleriyle birlikte yazılır. Böylece “bitti” sizin için de bizim için de aynı anlama gelir.
- 03Adı konmuş ve sıralanmış risklerTahmini altüst edebilecek unsurlar; gerçekleşme olasılıkları ve yaratacakları maliyet sırasına göre belirlenir. Ekler kısmında gizlenmiş hiçbir şey olmaz.
- 04Altından kalkabileceğiniz bir kapsamNelerin önce piyasaya sürüleceği, nelerin bekletileceği ve neleri asla inşa etmemeniz gerektiğini düşündüğümüz; ayrıca (üzerinde fikir ayrılığına düşebilmeniz adına) bunların gerekçeleri.
- 05Plan yapabileceğiniz bir tahminYanına varsayımları yazılmış bir aralık ve bu varsayımlardan hangisinin rakamı en çok oynatacağına dair bir not.
- 06Gerekçeler duruyorKararlar, tartılan seçenekler ve neden birinin tercih edildiği... Aradan uzun zaman geçtikten sonra, birisi işlerin neden böyle yürüdüğünü sorduğunda, cevap hâlâ ortadadır.
Sorumluluğunu üstlenebileceğimiz teknik özellikler yazıyoruz.
Daha önce hiç yazılım ürünü çıkarmamış bir analist; sessiz sedasız imkansız veya farkında olmadan devasa boyutlarda gereksinimler yazar ve bu durum, ancak işin tahmini maliyeti ortaya çıktığında fark edilir. Sizin gereksinimlerinizi hazırlayan kişiler ise bizzat yazılım geliştirmiş ve piyasaya sürmüşlerdir. İçinde gizli bir proje barındıran bir gereksinim, bütçesini ayırdıktan sonra değil, henüz bir cümle halindeyken işaretlenir. Üstelik bu belge, bizi daha önce hiç duymamış bir geliştiriciye bile teslim edilebilecek şekilde hazırlanır.
Sık sorulanlar, açık cevaplarla.
Evet. Bazı müşteriler analizi kendi ekiplerine götürüyor; analiz de her iki durumda da yararlı olacak şekilde hazırlanıyor. Çoğu zaman ise bu analiz, sonrasında bizzat bizim hayata geçirdiğimiz bir geliştirme sürecinin ilk aşamasını oluşturuyor.
Bu durum, incelenecek ne kadar çok şey olduğuna ve kaç kişiyle görüşmemiz gerektiğine bağlıdır. Süre; işi fiilen yapan kişilere ulaşmaya yetecek kadar uzun, ancak analizin başlı başına ayrı bir projeye dönüşmesine yol açmayacak kadar da kısa tutulur. Süreç başlamadan önce kapsam ve fiyat üzerinde mutabık kalırız; dolayısıyla iş hiçbir zaman ucu açık bırakılmaz.
İşi sadece yönetenler değil, bizzat yapanlar. Operasyon biriminden biriyle geçirilen bir saat, genellikle belgeleri okumaktan daha fazla şey ortaya çıkarır; çünkü belgeler süreci tasarlandığı şekliyle anlatırken, onlar sürecin fiilen nasıl yürütüldüğünü bilirler.
Bazen durum böyle olmayabilir; biz de bunu açıkça belirtiriz. İşin asıl değer kattığı noktalar; teknik şartnamenin işletmenin fiili faaliyetleriyle karşılaştırılması ve tek bir satır olarak yazılmış olmasına rağmen aslında başlı başına birer proje niteliği taşıyan kalemlerin fiyatlandırılmasıdır.
O zaman bunu açıkça ifade ederiz. Bu yanıtın maliyeti, inşaat sürecinde verilmesine kıyasla inşaat öncesinde çok daha düşüktür; işi üstlenip sürecin kötüye gitmesini izlemektense, bu yanıtı vermeyi tercih ederiz.
Neyi düzeltmeye çalıştığınızı anlatın.
İşlemeyen süreci veya ürünü tarif edin. Size geri dönüş soruları yöneltilecek; böylece bir sonraki adımın analiz mi olması gerektiği yoksa geliştirme aşamasına geçmek için halihazırda yeterli bilgiye sahip olup olmadığınız konusunda bir fikir edineceksiniz.