Yazılım Projesinde Kapsam Değişikliği: Talep, Etki ve Onay Akışı

Yazılım projelerinde kapsam değişikliği kaçınılmazdır. Pazar koşulları, mevzuat ya da kullanıcı geri bildirimi, proje başında yazılan listeyi er geç eskitir. Sorun değişikliğin kendisinde değil, nasıl yönetildiğindedir. Toplantıda sözlü söylenen bir ek istek kimsenin yazmadığı bir varsayıma dönüşür, sürüm sonunda da takvim ve bütçe tartışması başlar.

Bu rehber, bir değişikliği üç adımda yazılı ve izlenebilir hâle getirmenizi anlatıyor: talep, etki analizi ve onay. Amaç değişikliği engellemek değildir. Karar verenlerin neyi, neye karşılık değiştirdiğini görmesini sağlamak istiyoruz.

01Kapsam değişikliği nedir, neyi netleştirme sayarız?

Her yeni istek kapsam değişikliği değildir. Ayrımı baştan yapmak, gereksiz formalite üretmeden doğru işi yazılı sürece sokmanızı sağlar.

• Kapsam değişikliği: Yazılı kapsamda olmayan yeni bir özellik, ekran ya da entegrasyon eklemek. Mevcut bir maddenin kabul kriterini değiştirmek veya kapsamdan bir maddeyi çıkarmak da bu gruba girer.
• Netleştirme: Yazılı bir maddenin ayrıntısını belirlemek. Örneğin “raporlama ekranı” maddesindeki filtrelerin hangileri olacağına karar vermek, mevcut kabul kriterleri içinde kaldığı sürece netleştirmedir.

Pratik bir sınama sorusu kullanabilirsiniz: “Bu iş, yazılı kapsamdaki hangi maddeye dayanıyor?” Bir madde gösterilemiyorsa elinizde bir kapsam değişikliği vardır. Bu sorunun işlemesi için kapsamın baştan yazılı olması gerekir. OPEIS çalışma sürecinde kapsam, teklif ve planlama aşamasında yazılı olarak netleşir. Sonraki her değişiklik bu yazılı çerçeveye göre ölçülür.

02Talep: Değişikliği tek formda yazılı hâle getirin

İlk adım, isteğin kişiden bağımsız, standart bir biçimde kayda geçmesidir. Tek sayfalık bir değişiklik talep formu çoğu proje için yeterlidir. Formda şu alanlar bulunmalıdır:

1. Talep numarası ve tarih: Her talep benzersiz bir numara alır, örneğin DT-007.
2. Talep eden: İsteği kimin ilettiği ve hangi birimi temsil ettiği.
3. İhtiyacın tanımı: Çözümden önce sorun yazılır. “Bayiler toplu sipariş girebilmeli” ifadesi, “Excel yükleme butonu ekleyin” ifadesinden daha iyi bir başlangıçtır.
4. İş gerekçesi: Değişiklik neden gerekli, yapılmazsa ne olur?
5. Kabul kriterleri: Hangi koşullar sağlanınca iş tamamlanmış sayılacak?
6. Aciliyet: Belirli bir tarihe bağlı mı (kampanya, mevzuat vb.) yoksa sonraki sürüme bırakılabilir mi?

İyi yazılmış bir talep, yalnızca “ne istendiğini” değil, “neden istendiğini” de anlatır. Gerekçe bilindiğinde ekip aynı ihtiyacı daha küçük bir çözümle karşılayabilir.

Talepleri tek bir yerden toplayın. E-posta zincirleri, mesajlaşma grupları ve toplantı notları arasına dağılmış istekler izlenemez. Kural basittir: forma girmeyen talep, planlanmış sayılmaz.

03Etki analizi: Takvim ve bütçe etkisini görünür kılın

Talep kaydedildikten sonra proje ekibi etkiyi çıkarır. Etki analizi dört başlıkta yapılır: efor, takvim, bütçe ve teknik risk. Amaç, onaylayanın karar anında tam resmi görmesidir.

Aşağıdaki örnek yalnızca anlatım amaçlı, varsayımsal bir senaryodur. İki haftalık sürümlerle çalışan bir projede, ekibin sürüm başına yaklaşık 40 kişi-gün kapasitesi olduğunu düşünelim. Bayi portalına “toplu sipariş yükleme” eklenmesi talep ediliyor ve analiz yaklaşık 8 kişi-gün efor çıkarıyor. Bu, bir sürümün kabaca beşte biridir. Sonuç, karar verene şu seçeneklerle sunulur:

• Seçenek A, ekleme: Talep bir sonraki sürüme alınır. Planlanan canlıya alma tarihi bir sürüm kayar ve ek eforun bütçe kalemi yazılı olarak eklenir.
• Seçenek B, takas: Benzer eforlu, önceliği daha düşük bir madde kapsamdan çıkarılır. Tarih ve bütçe değişmez, kapsam içeriği değişir.
• Seçenek C, erteleme: Talep ilk canlı sürümden sonraki iyileştirme listesine alınır.

Etki analizinde şu soruların yanıtı da yazılmalıdır:

• Değişiklik, tamamlanmış veya devam eden başka maddeleri etkiliyor mu? Yeniden test gerektiren alanlar hangileri?
• Veri modeli, entegrasyon ya da güvenlik tarafında yeni bir risk doğuyor mu?
• Bütçe etkisi kalem kalem nedir? Fiyatlandırma modeline göre bu etki farklı görünür. Sabit fiyatlı projede ek bir kalem olarak eklenir, zaman-malzeme modelinde harcanan eforun güncellenmiş tahmini olarak raporlanır.
• Tahminin dayandığı varsayımlar neler? Varsayımlar değişirse tahmin de değişir ve bunun yazılı olması beklentiyi doğru yönetir.

Tahmin kesin bir söz değildir. Aralık olarak ifade etmek ve belirsizlik varsa bunu açıkça yazmak, sonradan çıkacak tartışmaları azaltır.

04Onay akışı: Kim, hangi sırayla karar verir?

Onay akışı, kararın kimde olduğunu önceden netleştirir. Küçük ve orta ölçekli projelerde dört adım çoğu zaman yeterlidir:

1. Talep sahibi formu gönderir.
2. Proje yöneticisi formu kayda alır ve teknik ekiple birlikte etki analizini hazırlar.
3. Müşteri tarafındaki yetkili karar verici seçeneklerden birini seçer. Bu kişi bütçe ve takvim üzerinde söz hakkı olan kişidir; her talep sahibi aynı zamanda onaylayan olmamalıdır.
4. Karar kaydedilir: Onay, ret ya da erteleme gerekçesiyle birlikte yazılı olarak arşivlenir ve plan güncellenir.

Sürecin sağlam çalışması için üç kural koyabilirsiniz. Birincisi, onaylanmamış değişiklik geliştirmeye alınmaz. İkincisi, onaylanan her değişiklik hem plana hem bütçe kaydına aynı gün işlenir. Üçüncüsü, acil durumlarda sözlü karar alınabilir ancak aynı iş günü içinde yazılı olarak teyit edilir.

Kayıtların tek bir yerde durması, sürecin izlenebilirliği için belirleyicidir. OPEIS müşterileri teklif ve sözleşme onaylarını, teslimat onaylarını ve proje güncellemelerini müşteri paneli üzerinden izleyebilir. Hangi aracı kullanırsanız kullanın, ilke aynıdır: karar nerede veriliyorsa kayıt da orada olmalıdır.

Her sürüm sonu demosunda şu kısa kontrol listesini gözden geçirin:

• Bu dönemde kaç değişiklik talebi geldi, kaçı onaylandı, kaçı ertelendi?
• Onaylanan değişikliklerin toplam takvim ve bütçe etkisi nedir?
• Başlangıçtaki yazılı kapsama göre projenin güncel durumu nedir?
• Bekleyen, karar verilmemiş talep var mı?

Bu dört soru kapsamın zamanla nasıl büyüdüğünü ya da şekil değiştirdiğini sürpriz olmadan gösterir.

05Sık sorulan sorular

Her küçük istek için form doldurmak gerekir mi?

Mevcut kapsam içinde kalan netleştirmeler için form gerekmez. Kapsam dışı ama çok küçük işler için tek satırlık bir kayıt yeterli olabilir. Önemli olan küçük işlerin birikmesini izlemektir: aynı sürümde birkaç küçük talep birleştiğinde etki, tek büyük bir talep kadar olabilir. Bu yüzden sürüm başına toplam eforu da takip edin.

Değişiklik talebi reddedilebilir ya da ertelenebilir mi?

Evet. Etki analizi karar vericiye gerçek bir seçim sunar; bu seçim “şimdi yapmak”, “bir şeyle takas etmek” ya da “sonraya bırakmak” olabilir. Ertelenen talepler silinmez, gerekçesiyle birlikte iyileştirme listesinde tutulur ve sonraki planlamada yeniden değerlendirilir.

Sabit fiyatlı projede kapsam değişikliği nasıl ele alınır?

Sabit fiyat, yazılı kapsam için geçerlidir. Kapsam dışı bir ekleme olduğunda etki analizi ile ek kalem ve takvim etkisi yazılı olarak sunulur, karar verici onayladıktan sonra plana işlenir. Takas seçeneği de burada yararlıdır: eşdeğer eforlu bir madde kapsamdan çıkarılırsa toplam kapsam büyüklüğü korunabilir. Bu tür bir düzenleme her projede sözleşmeye ve tarafların yazılı mutabakatına bağlıdır.

06Sonuç

Kapsam değişikliğini yönetmek, değişikliği yavaşlatmak anlamına gelmez. Talep yazılı olduğunda ihtiyaç netleşir, etki analizi yapıldığında takvim ve bütçe karar anında görünür olur, onay akışı tanımlandığında da kararın sahibi bellidir. Bu üç adım birlikte çalıştığında proje sonunda sürprizler azalır ve herkes aynı kayda bakarak konuşur.

Yazılım projenizde kapsam, sürüm planı ve değişiklik yönetimini nasıl kurguladığımızı görmek için yazılım geliştirme hizmet sayfamızı inceleyebilirsiniz.