Bir yazılım projesi ne kadar sürer? Süreyi belirleyen etkenler
Bir yazılım projesinin süresini takvim değil, kapsam belirler. Ne kadar işlev yapılacağı, ne kadar belirsizlik olduğu, kaç sistemle bağlantı kurulacağı, mevcut verilerin taşınıp taşınmayacağı ve kararların ne hızda verildiği süreyi doğrudan şekillendirir. Bu yüzden kapsamı netleşmemiş bir proje için verilen kesin bir süre, çoğu zaman bir tahminden fazlası değildir.
Bu yazıda süreyi belirleyen etkenleri açıyor, sürenin nerede uzadığını, nasıl kısaltılabileceğini ve bir teklifteki süre bilgisini nasıl okumanız gerektiğini anlatıyoruz. Rakam vermiyoruz; çünkü dürüst bir rakam, ancak kapsam netleştikten sonra verilebilir.
Neden “ne kadar sürer?” sorusunun tek cevabı yok?
“Bir yönetim paneli” cümlesi, üç ekranlı bir kayıt listesini de, onlarca rolü, raporu ve entegrasyonu olan bir iş sistemini de anlatabilir. İkisi aynı adı taşır; ama aynı iş değildir.
Süre tahmini, bir haritanın ölçeğine benzer. Kapsam ne kadar ayrıntılıysa tahmin de o kadar isabetlidir. “Müşterilerimizi takip edecek bir sistem” cümlesiyle verilen süre kaba bir aralıktır. Ekranları, rolleri, veri yapısı ve bağlantıları yazılmış bir planla verilen süre ise bir taahhüde yaklaşır.
Bu yüzden biz kesin süreyi ilk görüşmede değil, kapsamın yazılı bir plana dönüştüğü aşamada konuşuyoruz.
Süreyi belirleyen yedi etken
1. Kapsam: kaç işlev, kaç rol?
En büyük etken budur. Kapsam; ekran sayısından çok, işlevlerin ve kullanıcı rollerinin sayısıyla ölçülür. Yalnız yöneticinin kullandığı bir panel ile yönetici, çalışan ve müşterinin farklı yetkilerle girdiği bir sistem arasında büyük fark vardır. Her rol; ayrı ekranlar, ayrı izinler ve ayrı testler demektir.
2. Belirsizlik: ne kadarı biliniyor?
İş akışı bugün nasıl işliyor? Kurallar net mi, yoksa “duruma göre” mi değişiyor? Belirsizlik, sürenin en sinsi uzatıcısıdır. Geliştirme ortasında ortaya çıkan “aslında bu iş şöyle yürüyordu” cümlesi, hem yapılanı yeniden ele almayı hem de planı güncellemeyi gerektirir.
Belirsizliği azaltmanın yolu, kod yazmadan önce mevcut akışı birlikte çıkarmaktır. Bu adım kısa görünür; ama sonraki her aşamanın hızını belirler.
3. Entegrasyonlar: kaç sistemle konuşuyor?
Muhasebe programı, CRM, ödeme altyapısı, e-posta ya da mesajlaşma servisi. Her bağlantı ayrı bir iş kalemidir. İyi belgelenmiş bir servisle bağlantı öngörülebilirdir. Belgesi eksik, eski ya da üçüncü bir firmanın kontrolündeki bir sistemle bağlantı ise keşif, deneme ve bazen karşı tarafın cevabını beklemeyi gerektirir. Bu bekleme, takvimde en kolay gözden kaçan kalemdir.
4. Veri aktarımı: eski kayıtlar ne olacak?
Mevcut veriler tablolardaysa ya da eski bir sistemdeyse, yeni yapıya taşınmaları gerekir. Bu iş kâğıt üzerinde basit görünür; pratikte ise tutarsız kayıtlar, eksik alanlar, aynı müşterinin üç farklı yazımı gibi sorunlar çıkar. Verinin temizlenmesi ve doğrulanması ayrı bir aşamadır.
5. Geri bildirim ve karar hızı
Süre yalnız geliştirme ekibine bağlı değildir. Bir ekranın onayı, bir kuralın netleşmesi, bir test sürümüne dönüş — bunlar sizin tarafınızda bekleyen kararlardır. Kararın tek bir kişide olduğu ve düzenli dönüş yapıldığı projeler belirgin biçimde daha hızlı ilerler. Onayın birden fazla birimden geçtiği yapılarda ise takvim, en yavaş onayın hızına iner.
6. Kapsam değişiklikleri
Yeni fikirler gelişme sürecinin doğal bir parçasıdır. Sorun, her yeni fikrin mevcut aşamaya eklenmesiyle başlar. Değişiklik taleplerinin yazılı olarak ayrıca değerlendirilmesi, hem süreyi hem de bütçeyi korur. Bunun bir teklifte nasıl yazılması gerektiğini yazılım teklifi nasıl okunur yazımızda anlattık.
7. Dış kurallar ve onaylar
Mobil uygulamalarda mağaza incelemesi, mesajlaşma servislerinde platform onayı, bazı sektörlerde mevzuat gereklilikleri. Bunlar sizin ya da bizim kontrolümüzde olmayan aşamalardır. Takvim planlanırken ayrı bir satır olarak düşünülmeleri gerekir. Mobil tarafı mobil uygulama yaptırmak yazımızda ayrıca ele aldık.
Tek bakışta: süreyi uzatanlar ve kısaltanlar
| Etken | Süreyi uzatan | Süreyi kısaltan |
|---|---|---|
| Kapsam | Her şeyi ilk sürüme koymak | En çok yükü kaldıran parçayla başlamak |
| Belirsizlik | Kuralları geliştirme sırasında keşfetmek | Akışı kod öncesi yazıya dökmek |
| Entegrasyon | Belgesi zayıf, dış kontrollü sistemler | Az sayıda, iyi belgelenmiş bağlantı |
| Veri | Dağınık, tutarsız kayıtlar | Önceden temizlenmiş tablolar |
| Karar | Çok aşamalı onay | Tek karar verici, düzenli dönüş |
| Değişiklik | Her fikri hemen eklemek | ”Sonraki sürüm” listesi tutmak |
Bir yazılım projesinin aşamaları
Süreyi konuşurken projeyi aşamalara bölmek, tek bir büyük rakamdan daha anlamlıdır. Bizim çalışma biçimimiz şöyle ilerler:
- Keşif görüşmesi. Bugün iş nasıl yürüyor, nerede tıkanıyor? Mevcut akışı birlikte çıkarırız.
- Mimari not. Ekranlar, veri yapısı ve entegrasyonlar kısa bir yazılı planda toplanır. Kapsam ve süre buradan netleşir; yazılı teklif de bu plana dayanır.
- Parça parça yapım. En çok iş yükü kaldıracak bölümden başlarız. Her teslimde elinizde çalışan bir parça olur.
- Devreye alma. Veri aktarımı, ekibe kısa bir eğitim ve ilk haftaların desteği.
- Bakım. Yayından sonra hata düzeltmeleri, küçük iyileştirmeler ve yeni modüller; istenirse aylık bakımla.
Parça parça ilerlemenin en büyük faydası şudur: proje tamamlanmadan da işe yarar. İlk parça kullanılmaya başladığında gelen geri bildirim, sonraki parçaları doğru yöne çevirir.
Süreyi kısaltmanın yolları
- İlk sürümü küçültün. Her şeyi yapan bir sistem yerine, en çok zaman kaybettiren tek bir işi çözen bir başlangıç seçin. Bu yaklaşımın ürün tarafını SaaS ürünü geliştirmek: MVP’den ilk müşteriye yazımızda anlattık.
- Hazır olanı kullanın. Ödeme, e-posta gönderimi, harita gibi işler için çoğu zaman olgun hazır servisler vardır. Her şeyi sıfırdan yazmak gerekmez. Hangi parçanın özel, hangisinin hazır olması gerektiğini hazır yazılım mı, özel yazılım mı yazımızdaki sorularla tartabilirsiniz.
- Bir karar verici belirleyin. Sorulara cevap verecek ve onay yetkisi olan tek bir kişi, takvimi en çok koruyan şeydir.
- Verinizi önceden toparlayın. Aktarılacak tabloları baştan gözden geçirmek, devreye alma aşamasını hızlandırır.
- Örnek gösterin. Beğendiğiniz ya da beğenmediğiniz ekranlar, uzun tariflerden daha hızlı anlaşılır.
Teklifteki süreyi nasıl okumalı?
Bir teklifte süre gördüğünüzde şu sorular işinize yarar:
- Süre hangi kapsam için verilmiş? Kapsam yazılı mı?
- Süreye sizin tarafınızdaki onay ve geri bildirim beklemeleri dahil mi?
- Dış onaylar (mağaza, platform, üçüncü taraf) ayrı mı düşünülmüş?
- Aşamalar ve her aşamanın teslimatı belli mi?
- Kapsam değişirse süre nasıl güncellenecek?
Kapsamı belirsiz bir projeye kesin bir bitiş tarihi veren teklif, ilk bakışta güven verir. Ama süre aşıldığında neyin feda edileceği — kalite mi, test mi, kapsam mı — çoğu zaman yazılı değildir. Bu yüzden biz süre garantisi vermek yerine, kapsamı netleştirip aşamalı bir plan sunmayı tercih ediyoruz.
Sık sorulan sorular
Neden kesin bir süre vermiyorsunuz?
Çünkü kapsamı netleşmemiş bir iş için verilen kesin süre, ya gereksiz yere uzun bir güvenlik payı içerir ya da sonradan aşılır. Kapsamı mimari notta netleştirdikten sonra yazılı teklifte aşamalı bir plan sunuyoruz.
Ekip büyütülürse proje hızlanır mı?
Her zaman değil. Yazılım projelerinde ekibe yeni kişi eklemek, bir süre için iletişim ve uyum yükü getirir. Süreyi asıl kısaltan, ekip büyüklüğünden çok kapsamın netliği ve kararların hızıdır.
Proje ortasında yeni bir özellik istersek ne olur?
Yeni talep ayrıca değerlendirilir: mevcut aşamaya mı eklenecek, yoksa sonraki sürüme mi bırakılacak? Etkisi süre ve kapsam açısından yazılı olarak paylaşılır; karar sizindir.
Yarım kalmış bir projeyi devralırsanız süre nasıl belirlenir?
Önce mevcut kodu, belgeleri ve durumu inceliyoruz. Ardından neyin kullanılabileceğini, neyin yeniden yazılması gerektiğini açıkça söylüyor ve süreyi bu incelemeye dayanarak konuşuyoruz.
Kendi projenizin kapsamını ve onu belirleyen etkenleri birlikte çıkarmak isterseniz özel yazılım ve SaaS sayfamıza bakabilir ya da bize yazabilirsiniz. En geç iki iş günü içinde dönüyoruz.