Bir yazılım projesi planlanan tarihten geç bittiğinde, ilk tepki çoğu zaman geliştiricilere yönelir. Oysa gecikmenin büyük kısmı kodun kendisinden değil, projenin başında alınmamış kararlardan, netleşmemiş isteklerden ve geç gelen onaylardan doğar. Sorun görünür olduğunda ise artık düzeltmesi pahalı hâle gelmiştir.
Bu yazı, yazılım projelerinin neden geciktiğini ve özellikle kapsam kaymasının nasıl fark edilip önlenebileceğini anlatıyor. Amaç, projeyi bir teslim tarihine bağlamak yerine, takvimi bozan nedenleri proje başlamadan görünür kılmak. Özel yazılım sürecimizin genel çerçevesini görmek için özel yazılım hizmetimiz sayfasına bakabilirsiniz.
Gecikme çoğu zaman tek bir hatadan doğmaz
Yazılım projelerinde gecikme nadiren tek bir olaydan kaynaklanır. Genellikle küçük sapmalar üst üste biner: bir ekran biraz geç onaylanır, bir veri formatı sonradan değişir, bir entegrasyon beklenenden karmaşık çıkar. Her biri tek başına yönetilebilir görünür, ama birlikte bakıldığında takvim tamamen kaymıştır.
Bu yüzden projeyi izlerken tek bir “gecikme nedeni” aramak yanıltıcıdır. Takvim ilk haftalarda sağlıklı görünse bile, küçük sapmalar kayıt altına alınmadığında ilerleyen aylarda toplu bir gecikmeye dönüşebilir. Daha sağlıklı yol, sapmaların nerede birikmeye başladığını görmektir. Birikim genellikle üç yerde başlar: kapsamın sınırlarında, kararların zamanlamasında ve geri bildirim döngüsünde.
Kapsam kayması tam olarak nedir?
Kapsam kayması, proje devam ederken yazılı olmayan yeni isteklerin işe sessizce eklenmesidir. Toplantıda bir cümle olarak söylenen bir özellik, bir e-posta ile eklenen bir rapor ya da “bir de şu da olsa iyi olur” diye geçen bir ihtiyaç, ilk bakışta küçük görünür. Ancak her biri ekibin zamanından bir parça alır.
Kayma, kötü niyetten değil, çoğu zaman heyecandan doğar. Proje ilerledikçe iş sahibi daha fazla şey hayal eder ve bu hayaller doğal olarak talebe dönüşür. Sorun, bu taleplerin takvime, bütçeye ve öncelik sırasına etkisinin konuşulmadan işe alınmasıdır.
Kapsam neden başlangıçta netleşmez?
Birçok proje, kapsamı tam olarak tanımlanmadan başlar. Bunun nedeni, iş sahibinin ihtiyacını henüz kendi içinde netleştirememesi olabilir. Başka bir neden de, tanımın “bir web sitesi” ya da “bir yönetim paneli” gibi genel ifadelerle yapılmasıdır. Bu ifadeler herkes için farklı bir şey anlamına gelir.
Netleşmemiş kapsamın bedeli, geliştirme sırasında ortaya çıkar. Geliştirici bir modülü bitirdiğinde, iş sahibi aslında başka bir şeyi kastettiğini fark eder. Bu noktada yapılan iş ya yeniden yazılır ya da yeni bir talep olarak eklenir. İki durumda da takvim uzar.
Kapsamı netleştirmenin pratik yolu, süreci kullanıcının gözünden yazmaktır. Hangi kişi sistemi kullanacak, hangi işi yapacak, sonunda hangi çıktıyı görmek isteyecek? Bu soruların cevapları yazıya geçtiğinde, “bitti” kavramı da ortak bir anlam kazanır.
Geri bildirim gecikirse proje neden durur?
Yazılım geliştirme, birbirine bağlı kararlar zinciridir. Bir ekranın tasarımı onaylanmadan, o ekrana bağlı veri yapısı kesinleşmez. Veri yapısı kesinleşmeden de sonraki modüller başlayamaz. Bu yüzden tek bir onayın gecikmesi, projenin birkaç parçasını birden bekletebilir.
Geri bildirim gecikmesi ayrıca yeniden işe yol açar. Geliştirici bir karar bekleyip ilerlemeye devam ederse, sonradan değişen bir karar yapılan işi geçersiz kılar. Bu yüzden onay süreleri baştan takvime yazılmalı ve her aşamanın sonunda kimin, hangi tarihe kadar karar vereceği belirlenmelidir.
Pratikte iyi bir düzen, her haftanın sonunda kısa bir gözden geçirme ve bir sonraki hafta için açık soruların listesini çıkarmaktır. Açık sorular görünür olduğunda, kimsenin farkında olmadan beklediği bir karar da fark edilir.
Kapsamı yazılı tutmak neden işe yarar?
Yazılı kapsam, iki tarafın aynı projeden bahsettiğini doğrular. Kapsam belgesi uzun ya da karmaşık olmak zorunda değildir. Önemli olan, neyin dahil olduğunu, neyin dahil olmadığını ve hangi koşulda ne değişeceğini açıkça söylemesidir.
Yazılı kapsamın bir faydası da tartışmaları kişisel olmaktan çıkarmasıdır. Bir özelliğin işe dahil olup olmadığı sorusu, belgeye bakılarak cevaplanır. Böylece “sen söylemiştin” ya da “ben öyle anlamamıştım” türü tartışmalar, proje ortasında gerilim yaratmadan çözülür.
Kapsam belgesinin ayrıca bir sürüm mantığıyla güncellenmesi gerekir. Belge bir kez yazılıp unutulursa, bir ay sonra kimse onu referans almaz. Her onaylı değişiklik belgeye işlendiğinde ise belge projenin gerçek hafızası olur.
Değişiklik talebi nasıl yönetilir?
Her değişiklik talebi üç soruya cevap vermelidir: Bu istek mevcut kapsama dahil mi? Dahil değilse takvime ve bütçeye etkisi nedir? Ne zaman yapılabilir? Bu soruların cevabı yazılı olarak paylaşıldığında, iş sahibi kararını bilerek verir.
Değişiklikleri üç gruba ayırmak da işe yarar. Birinci grup, mevcut kapsama ait küçük düzeltmelerdir ve genellikle takvimi etkilemez. İkinci grup, yeni bir modül ya da önemli bir akış eklemeyi içerir ve ayrı bir aşama olarak planlanmalıdır. Üçüncü grup, projenin hedefini değiştiren isteklerdir ve yeni bir kapsam görüşmesi gerektirir.
Bu ayrımın en büyük faydası, küçük bir istek ile büyük bir değişikliğin aynı kolaylıkla kabul edilmesini önlemesidir. Her istek kendi büyüklüğüyle tartıldığında, takvim gerçekçi kalır.
Kapsam belgesinde neler yer almalı?
Kapsam belgesinin uzun olması gerekmez, ama bazı başlıkları mutlaka içermelidir. İlk olarak projenin amacı yazılmalıdır: hangi sorunu çözdüğü ve kimin kullanacağı. İkinci olarak dahil olan modüller ve akışlar listelenmelidir. Üçüncü olarak, açıkça dışarıda bırakılanlar yazılmalıdır, çünkü çoğu anlaşmazlık bu sınırdan doğar. Dördüncü olarak, her modülün “bitti” sayılma koşulu belirtilmelidir: hangi ekran, hangi veri ve hangi kontrolle kabul edileceği.
Son olarak, karar sahiplerinin isimleri ve onay sürelerinin yer alması yararlıdır. Bir ekranın onayı kimin sorumluluğunda ve ne kadar beklenmesi gerektiği yazılı olduğunda, takvim sahipsiz bir beklemeye dönüşmez. Belgede ayrıca bir değişiklik kaydı bölümü bulunmalıdır; her onaylı değişiklik tarih ve gerekçesiyle işlenmelidir. Böylece proje ortasında kimin neyi neden istediği sonradan tekrar tartışılmaz.
Gecikmeyi erken fark etmenin yolları
Gecikme genellikle son haftada fark edilir, ama işaretleri çok önce görünür. Açık karar sayısının artması, bir modülün iki kez yeniden yazılması ve test aşamasında beklenmeyen bulguların çoğalması, projenin sapmaya başladığını gösterir. Bu işaretler görüldüğünde, kapsamı yeniden görüşmek ve gerekirse teslim takvimini güncellemek daha az zarar verir.
Gecikmeyi erken görmek, iş sahibiyle geliştirici arasındaki iletişimi de rahatlatır. Sorun henüz büyümemişken konuşulduğunda, çözüm seçenekleri daha fazladır. Örneğin bir özelliği sonraki sürüme almak, geçici bir çözüm uygulamak ya da teslim sırasını değiştirmek mümkün olabilir.
Kontrol listesi
Projenin sağlıklı ilerlediğini anlamak için şu noktalar düzenli olarak kontrol edilebilir:
- Kapsam belgesi güncel ve her iki tarafça onaylı mı?
- Açık karar listesi görünür ve her kararın bir sahibi var mı?
- Onay süreleri takvimde yer alıyor mu?
- Yeni istekler yazılı olarak kaydediliyor ve etkisi konuşuluyor mu?
- Son haftada bir önceki hafta ile aynı sorunlar tekrar ediyor mu?
Sonuç: gecikmeyi önlemek bir alışkanlıktır
Yazılım projelerinde gecikme, çoğu zaman bir kişinin hatası değil, süreçteki boşlukların birikmesidir. Kapsamı yazılı tutmak, değişiklikleri ayrı bir talep olarak ele almak ve geri bildirimi takvime bağlamak bu boşlukları kapatır. Bu alışkanlıklar, projenin büyüklüğünden bağımsız olarak fark yaratır.
Bir yazılım projesine başlamadan önce, bu soruları kendinize sorabilirsiniz: Bu işin bittiğini nasıl anlayacağız? Hangi kararları kim, hangi tarihe kadar verecek? Bir istek geldiğinde nasıl değerlendirilecek? Bu cevaplar netse, takvim de büyük ölçüde gerçekçi olur. Özel yazılım maliyetinin hangi değişkenlere bağlı olduğunu görmek için özel yazılım maliyeti neye göre belirlenir yazımıza, sözleşmede kaynak kodun kime ait olduğu için de yazılım sözleşmesi ve kaynak kod yazımıza göz atabilirsiniz.
