Özel yazılım projesi gerçekte ne kadar sürer, süreyi ne belirler

Bir özel yazılım projesinin ne kadar süreceğini, yazılacak kodun miktarı belirlemez. Süreyi belirleyen beş şey vardır: karar verecek kişinin haftada ne kadar zaman ayırabildiği, mevcut verinizin ne hâlde olduğu, bağlanılacak sistemin dokümantasyonunun bulunup bulunmadığı, testi yapacak gerçek bir kullanıcının ayrılıp ayrılmadığı ve kapsamın ne kadar net olduğu. Bu beşi yerindeyse iş, yazılım ekibinin ilk söylediği süreye yakın biter. Biri bile eksikse, kod tarafında hiçbir şey değişmese dahi takvim uzar. Bu yazı, süreyi hangi davranışların uzattığını ve müşteri tarafında hangi davranışların kısalttığını anlatıyor.

Yazılım firmaları genelde süreyi "geliştirme eforu" üzerinden hesaplar: şu ekran şu kadar, şu rapor şu kadar. Bu hesap kendi içinde tutarlıdır ama eksiktir, çünkü geliştirme süresi toplam sürenin yalnızca bir parçasıdır. Diğer parça bekleme süresidir: cevap bekleme, veri bekleme, onay bekleme, test bekleme. Gecikmelerin çoğu kodun yavaş yazılmasından değil, arada geçen boşluklardan doğar.

Karar verecek kişi haftada ne kadar zaman ayırabiliyor

Özel yazılım, sizin işinizin kurallarını yazıya döker. Bu kuralları yalnızca sizde çalışan biri bilir. "İskontoyu kim onaylar", "stoktan düşme ne zaman olur", "iptal edilen sipariş faturaya nasıl yansır" gibi sorular, geliştirme sırasında yüzlerce kez ortaya çıkar ve her biri bir karar bekler.

Projenin hızını, bu soruların ne kadar sürede cevaplandığı belirler. Karar verecek kişi günde bir kez bakabiliyorsa iş akar. Haftada bir toplantıda bakabiliyorsa, her soru bir haftalık gecikme demektir ve sorular tek tek gelmez, birikir. Daha kötüsü, karar verecek kişinin belirsiz olmasıdır: soru üç kişiye sorulur, üçü birbirine bakar, kimse sahiplenmez.

Bu yüzden proje başlarken sorulacak en önemli soru teknik değildir: Bu projede kararı kim verecek ve haftada kaç saatini ayıracak? Cevap "herkes" ise, süre tahminini ikiyle çarpmak gerekir.

Mevcut veriniz ne hâlde

Yeni sistem boş başlamaz. İçine müşteri listesi, ürün kataloğu, fiyat listesi, açık siparişler, cari bakiyeler girer. Bu verinin nereden geleceği ve ne hâlde olduğu, süreyi doğrudan etkiler.

Sık görülen tablo şudur: müşteri listesi üç ayrı Excel'de, aynı firma üç farklı yazımla kayıtlı, ürün kodları kimi yerde boşluklu kimi yerde tireli, bazı satırlarda fiyat var bazılarında not var. Bu veriyi taşımak bir aktarma işi değil, bir temizlik işidir; ve temizliği yapacak kişi yazılımcı değildir, çünkü hangi kaydın doğru olduğunu yalnızca işi bilen bilir.

Verinin dağınık olması projeyi bitirmez, ama takvimi kaydırır. Kaydırma miktarını da yazılım ekibi değil, verinin sahibi belirler. Bu yüzden "veriyi kim, hangi hâle getirecek" sorusu ilk haftada konuşulmazsa, canlıya çıkış tarihinde konuşulur ve o noktada seçenek kalmaz.

Bağlanılacak sistemin dokümantasyonu var mı

Projelerin büyük kısmı tek başına durmaz; muhasebe programına, e-fatura sağlayıcısına, kargo firmasına, banka ekstresine ya da mevcut bir üretim sistemine bağlanır. Burada süreyi belirleyen şey entegrasyonun "zorluğu" değil, karşı tarafın ne kadar açık olduğudur.

Üç durum vardır. Karşı sistemin düzgün bir dokümantasyonu ve test ortamı varsa, entegrasyon öngörülebilir bir iştir. Dokümantasyon var ama eski ya da eksikse, iş deneme yanılmaya döner: bir alan gönderilir, hata döner, sebebi araştırılır. Hiç dokümantasyon yoksa ve karşı tarafla iletişim bayi üzerinden yürüyorsa, süreyi artık sizin ekibiniz değil, o bayinin cevap hızı belirler.

Bu kalem, tahminlerin en çok saptığı yerdir; çünkü sözleşme imzalanırken çoğu zaman kimse karşı sistemin dokümantasyonuna bakmamıştır. Yapılabilecek en ucuz iş, proje başlamadan önce entegrasyon dokümanını ve test ortamı erişimini istemektir. Gelmiyorsa, bu bilgi de bir bilgidir.

Testi yapacak gerçek bir kullanıcı ayrıldı mı

Yazılım ekibi kendi testini yapar, ama o test "sistem hata veriyor mu" sorusunu cevaplar. "Bu ekran benim işimi görüyor mu" sorusunu yalnızca işi yapan kişi cevaplayabilir. Depocu, muhasebeci, saha teknisyeni, satışçı.

Sorun şu ki bu kişiler asıl işlerini yapmakla meşguldür ve test onların takviminde yer tutmaz. Sonuç: teslim edilen ekranlar haftalarca beklenir, kimse bakmaz, sonra canlıya çıkış öncesi hepsine birden bakılır ve o hafta "şu da olmalıydı" listesi çıkar. Geliştirme bitmiştir ama proje bitmemiştir.

Kısaltan yöntem basittir: testi yapacak kişi isim isim belirlenir, haftalık takvimine kısa ama sabit bir zaman konur ve bu kişinin bu iş için ayrıldığı yöneticisi tarafından bilinir. Test edecek kişi bulunamıyorsa, kapsamı küçültmek testi ertelemekten daha iyidir.

Kapsam netliği ve biriken küçük istekler

"Bir de şu olsa" cümlesi tek başına zararsızdır. Zarar, bu cümlenin proje boyunca düzenli aralıklarla tekrarlanmasından ve hiçbirinin takvime yansıtılmamasından doğar. Her biri küçüktür, toplamı büyüktür; üstelik yeni istekler çoğu zaman önceden yazılmış kısımlara dokunur, yani sadece eklenmez, mevcut işi de yeniden test ettirir.

Buradaki mesele isteklerin gelmesi değil — iş yürüdükçe yeni ihtiyaç görmek doğaldır. Mesele, isteğin geldiği anda "bu, teslim tarihini etkiler mi" sorusunun sorulmamasıdır. Soru sorulmazsa kapsam sessizce büyür, takvim sabit kalır ve sonunda takvim tutmaz.

Neden "kısa sürer" denip uzuyor

Tahminlerin sapmasının birkaç tekrar eden sebebi var. Birincisi, tahminin çoğunlukla en iyi senaryoya göre yapılmasıdır: veri temiz gelecek, entegrasyon sorunsuz olacak, cevaplar hızlı gelecek. Bu üçü aynı anda gerçekleşirse tahmin tutar; pratikte nadiren gerçekleşir.

İkincisi, ilk konuşmada anlatılan sürecin gerçek sürecin sadeleştirilmiş hâli olmasıdır. Yöneticinin anlattığı akış ile depoda fiilen yürüyen akış çoğu zaman aynı değildir; aradaki fark, geliştirme sırasında istisnalar olarak ortaya çıkar ve her istisna ek iştir.

Üçüncüsü, bekleme sürelerinin tahmine hiç konmamasıdır. Geliştirme eforu hesaplanır, arada geçecek onay ve test beklemeleri hesaplanmaz. Oysa toplam süre bu ikisinin toplamıdır.

Dördüncüsü, tek bir büyük teslim planlanmasıdır. Her şey aynı anda bitecekse, her şeyin de aynı anda doğru olması gerekir; bir parçadaki gecikme tüm takvimi kaydırır.

Süreyi kısaltan davranışlar ve aşamalı teslim

Müşteri tarafında, hiçbir teknik bilgi gerektirmeyen ama süreyi belirgin biçimde kısaltan davranışlar şunlar:

• Tek bir karar verici belirlemek ve bu kişinin cevap süresini kısa tutmak
• Projenin ilk gününde entegrasyon dokümanını ve test ortamı erişimini istemek
• Taşınacak veriyi kimin temizleyeceğini ve ne zaman hazır olacağını yazılı olarak netleştirmek
• Testi yapacak kullanıcıyı isim vererek belirlemek ve takviminde yer açmak
• Yeni her istekte "bu tarihi etkiler mi" sorusunu sormak ve cevabı kayda geçmek
• Toplantı yerine kısa yazılı cevaplar tercih etmek; bekleyen soruların açık bir listesini tutmak

Bunların üstünde tek bir yapısal karar var: aşamalı teslim. Yani her şeyi birden teslim etmek yerine, işin gerçekten çalışan küçük bir parçasını önce canlıya almak. Örneğin önce yalnızca teklif kaydı, sonra onay akışı, sonra muhasebe entegrasyonu.

Aşamalı teslim sezgiye aykırı gelir — parça parça yapmak daha yavaş görünür. Pratikte tersi olur. Küçük parça erken canlıya çıktığı için gerçek kullanım hemen görülür; yanlış varsayımlar, üzerine üç ay daha iş yığılmadan ortaya çıkar. Kullanıcı somut bir ekranla konuştuğu için geri bildirimi netleşir. Veri ve entegrasyon sorunları küçük bir alanda, tüm proje askıdayken değil, sınırlı bir kapsamda çözülür. Ve en önemlisi, iş her aşamada bir işe yarar hâle gelir; proje bitmeden de değer üretmeye başlar.

Bir özel yazılım projesi için gerçekçi bir cevap şudur: iyi tanımlanmış, tek bir sürece odaklanan bir işin ilk çalışan parçası birkaç hafta içinde kullanılabilir olur. Birden fazla süreci ve entegrasyonu kapsayan bir sistemin bütünü ise tek haneli ay mertebesinde bir işi ifade eder — ve bu sürenin ne kadarının beklemeyle geçeceğini, büyük ölçüde yazılım firması değil, müşteri tarafındaki hazırlık belirler.

Kısaca

• Süreyi kod miktarı değil; karar verici müsaitliği, veri kalitesi, entegrasyon dokümantasyonu, test kullanıcısı ve kapsam netliği belirler.
• Toplam süre, geliştirme eforu artı bekleme süresidir; tahminler genellikle bekleme kısmını hiç içermez.
• Tek karar verici, hazır veri ve isim verilmiş test kullanıcısı, projeyi hiçbir teknik müdahaleden daha çok hızlandırır.
• Yeni her istekte "bu tarihi etkiler mi" sorusu sorulmazsa kapsam sessizce büyür, takvim tutmaz.
• Aşamalı teslim yavaş görünür ama erken geri bildirim sağladığı için bütünü daha kısa sürede bitirir.