Özel yazılım projeleri: İhtiyaçtan kapsam belgesine

“Satın alma taleplerini tek panelde görelim” cümlesi bir yazılım projesini başlatabilir; fakat geliştirme ekibine ne teslim edileceğini henüz söylemez. Talebi kim açacak, bütçeyi kim onaylayacak, tutar değişirse eski onay geçerli mi olacak? Sipariş iptal edildiğinde hangi kayıt korunacak? Bu sorular cevaplanmadan çizilen ekranlar düzenli görünebilir, ancak gerçek iş başladığında eksik kararlar birer geliştirme talebi olarak geri döner. Özel yazılım projelerinde kapsam belgesi, bu kararları görünür kılan çalışma aracıdır.

Bir kapsam belgesi yüzlerce sayfa olmak zorunda değildir. İş ihtiyacını, kullanıcıları, süreçleri, veri ilişkilerini ve kabul koşullarını birlikte anlatması gerekir. Aşağıdaki kurgusal satın alma örneği üzerinden belgeyi nasıl geliştirebileceğimizi ele alacağız. Amaç bir hazır şablonu doldurmak değil, işletmeyle yazılım ekibinin aynı işi tarif ettiğinden emin olmaktır. Belge, tasarım ve geliştirmeye yön verirken yeni bilgi ortaya çıktığında kontrollü biçimde güncellenebilmelidir.

Talep edilen ekranın arkasındaki problemi bulun

İlk görüşmede çözüm adı duymak yaygındır: panel, CRM, mobil uygulama veya rapor ekranı. Bu isimler çözüm alanını gösterir; neden ihtiyaç duyulduğunu açıklamaz. Satın alma örneğinde ekip aynı talebi farklı tablolarda takip ediyor olabilir. Sorun bilgi kaybı mı, geç onay mı, çift sipariş mi? Her biri başka bir iyileştirme gerektirir. İhtiyaç cümlesi, mevcut durumda kimin neyi yapmakta zorlandığını açıkça anlatmalıdır.

Mevcut işi bir işlem üzerinden baştan sona yürüyerek inceleyin. Talebin nerede doğduğu, hangi bilginin eklendiği ve kimin yanıtının beklendiği görünür olsun. Yöneticinin tarif ettiği süreçle günlük uygulama farklıysa bu farkı belgeleyin. Örneğin istenen rapordaki alanın hiçbir çalışan tarafından kaydedilmediği ortaya çıkabilir. Bu durumda önce verinin nasıl oluşacağı karara bağlanmalıdır. Yalnızca rapor ekranını tasarlamak bilgi eksikliğini gidermez; sürecin başlangıcındaki kayıt sorumluluğu da tanımlanmalıdır.

Hedefi gözlenebilir bir değişiklik olarak tarif edin

“Verimlilik artacak” ifadesi projenin yönünü anlatabilir ama kabul kararına temel olacak kadar açık değildir. Hangi iş daha az adımda yapılacak, hangi bilgi tek yerde görülecek, hangi bekleme nedeni ortadan kalkacak? Satın alma ekibi için onay bekleyen taleplerin sahipleriyle birlikte görünmesi somut bir hedeftir. Ölçülecek sonuç ile onu sağlayacağı düşünülen özellik birbirinden ayrılmalıdır. Panel geliştirmek araçtır; işin görünürlüğü beklenen değişikliktir.

Başlangıç verisi yoksa kesin kazanç yüzdeleri yazmayın. Önce mevcut süreyi veya hata türünü nasıl gözlemleyeceğinizi belirleyin. Bazı hedefler ilk aşamada nitel olabilir: kullanıcı kendi talebinin neden beklediğini anlayabilsin gibi. Daha sonra ölçüm düzeni geliştirilir. Hedeflerin gerçekçi olması, yazılımın bütün operasyon sorunlarını çözeceği beklentisini de azaltır. Yetki belirsizliği veya eksik ürün tanımı gibi konuların işletme içinde ayrıca karara bağlanması gerekebilir.

Kullanıcıyı yalnızca unvanıyla tanımlamayın

“Yönetici” ve “personel” ayrımı çoğu projede yetersiz kalır. Bir çalışan kendi talebini açabilir, başka bir çalışan bütün talepleri inceleyebilir, yetkili kişi belirli tutarın üzerindeki alımı onaylayabilir. Bunlar erişim ve işlem açısından farklı ihtiyaçlardır. Kullanıcı gruplarını hangi işi yaptıkları, hangi veriyi gördükleri ve hangi kararları verebildikleri üzerinden tanımlayın. Aynı unvanın farklı şubelerde farklı sorumluluk taşıması da mümkündür.

Yetki kapsamını yalnızca ekranı görme iznine indirgemeyin. Kaydı oluşturma, değiştirme, onaylama, iptal etme ve dışarı aktarma farklı işlemlerdir. Bir yöneticinin kendi açtığı talebi onaylayıp onaylayamayacağı gibi sorular erken konuşulmalıdır. Bu kararlar sonradan ekran tasarımına eklenen küçük ayrıntılar değildir; sürecin güvenilirliğini belirler. Kapsam belgesinde örnek işlemler üzerinden anlatıldığında hem iş birimi hem geliştirici aynı durumu değerlendirebilir.

Ana akışı ve istisnaları birlikte yazın

En kolay akışta kullanıcı talebi açar, yönetici onaylar ve satın alma sipariş oluşturur. Gerçek çalışma ise eksik bilgi, iade edilen talep, değişen miktar ve iptal gibi durumlar içerir. Önce temel akışı yazın; ardından her aşamada neyin farklı gidebileceğini sorun. İstisnalar listesi sonsuz olmak zorunda değildir. İş sonucunu veya veri bütünlüğünü belirgin biçimde etkileyen durumlara öncelik verin.

Örneğin onaylanmış talebin tutarı sonradan yükselirse ne olacak? Yeniden onay mı gerekecek, değişiklik sınırı mı tanımlanacak? Kullanıcı eski değeri görebilecek mi? Bu tek örnek kayıt geçmişi, bildirim ve yetkilendirme kararlarını etkiler. Sadece “talep düzenleme ekranı” yazmak bu davranışı tanımlamaz. Kapsam belgesinin gücü, ekran adlarının arkasındaki iş kuralını açık edebilmesidir. Kararı henüz verilmemiş konular da kesinleşmiş gibi değil açık soru olarak işaretlenmelidir.

Verinin nereden geldiğini ve kimin yönettiğini açıklayın

Talep kaydında ürün, miktar, birim, maliyet merkezi ve tedarikçi gibi alanlar bulunabilir. Bu bilgilerin kaynağı aynı olmayabilir. Ürün listesi başka sistemden geliyor, maliyet merkezlerini finans ekibi yönetiyor olabilir. Belge yalnızca alan isimlerini saymamalıdır. Hangi bilginin zorunlu olduğu, ne zaman değişebildiği ve hangi kaydın esas kabul edildiği anlaşılmalıdır. Aynı kavrama farklı ekiplerin başka adlar verdiği durumlar da birlikte netleştirilir.

Eski kayıtların taşınması gerekiyorsa bunu ayrı bir iş olarak görünür kılın. Yeni yazılımda müşteri alanı bulunması, eski tablolardaki müşterilerin otomatik ve temiz biçimde aktarılacağı anlamına gelmez. Mükerrer kayıt, eksik bilgi ve biçim farkları değerlendirilmelidir. Taşınacak dönem, temizliği yapacak ekip ve aktarım sonrası kontrol yöntemi kapsamda yer alır. Veri göçünü “bir Excel yükleriz” cümlesiyle geçiştirmek, projenin sonuna belirsiz bir iş bırakır.

Entegrasyonları isim değil davranış olarak tanımlayın

“Muhasebe entegrasyonu yapılacak” ifadesinin altında çok farklı işler bulunabilir. Hangi kayıt hangi yönde aktarılacak, ne zaman gönderilecek, hata oluştuğunda kim haberdar olacak? Aynı kaydın iki kere oluşması nasıl önlenecek? Karşı sistemde işlem tamamlanıp yanıt alınamazsa ne yapılacak? Bu soruların tamamı ilk toplantıda kesinleşmeyebilir. Yine de kapsam, cevap gerektiren başlıkları ve teknik incelemenin sahibini göstermelidir.

Dış sistemin güncel dokümantasyonu, erişim koşulları ve test ortamı incelenmeden entegrasyon süresi kesin kabul edilmemelidir. Teknik belirsizlik yüksekse küçük bir doğrulama çalışması planlanabilir. Ar-Ge yaklaşımı burada gösterişli bir etiket olmaktan çıkar: belirli bir varsayımı sınayan, sonucu ve devam kararını kaydeden iş hâline gelir. Denemenin üretim kalitesinde tamamlanmış entegrasyonla aynı teslim olmadığı da açıkça belirtilmelidir. Araştırma ve ürünleştirme aşamalarının beklentileri farklıdır.

İşlev dışı gereksinimleri proje sonuna bırakmayın

Kullanıcının işlemi yapabilmesi kadar hangi koşullarda yapabildiği de önemlidir. Aynı anda kaç kişinin çalışacağı, hangi cihazların kullanılacağı ve bağlantı kesildiğinde nasıl davranılacağı sorulmalıdır. “Hızlı olsun” yerine kabul sırasında değerlendirilebilecek bir senaryo kurun. Örneğin belirli veri hacmindeki talep listesinin kullanım koşulları tanımlanabilir. Hedef değerler ekip tarafından teknik değerlendirmeyle belirlenir; tahmini rakamlar gerçek gereksinim gibi yazılmaz.

Yedekleme, geri yükleme, kayıt geçmişi, izleme ve bakım sorumluluğu da bu bölümde düşünülmelidir. İşletme bir hata fark ettiğinde kime ulaşacak, hangi bilgiyle bildirim yapacak? Kullanıcı erişimleri kim tarafından kapatılacak? Bu ihtiyaçların tamamı aynı kapsamda geliştirilmeyebilir, fakat kararın görünür olması gerekir. Sessiz bırakılan operasyon işleri, canlıya çıkıştan sonra kendiliğinden tamamlanmaz. Yazılım projesi teslim dosyası kadar çalışma düzeni de gerektirir.

İlk sürümün sınırını anlaşılır biçimde çizin

İlk sürüme alınacak işler, gelecekte düşünülen özelliklerden ayrılmalıdır. Satın alma örneğinde talep, onay ve temel durum takibi ilk akış olabilir; gelişmiş tahminleme veya tedarikçi puanlaması sonraki araştırmalara kalabilir. Bu ayrım, ertelenen işlerin değersiz olduğu anlamına gelmez. İlk kullanımı mümkün kılan bütünü ve sonraki kararları öğrenmek için gereken sınırı tanımlar. Modülleri rastgele kesmek yerine tamamlanabilir bir iş akışı seçin.

Kapsam dışında kalanları yazmak yanlış anlaşılmaları azaltır. Mobil uygulama, eski kayıtların tümünün temizlenmesi veya üçüncü taraf lisans ücretleri dahil değilse açık olmalıdır. Aynı zamanda bağımlılıklar belirtilmelidir: hesap açılması, test verisi veya işletmenin onayı gibi. İyi kapsam, yalnızca yazılım firmasının yapacaklarını sıralamaz. İşletmenin sağlayacağı girdileri de görünür kılar. Zaman planının gerçekçi olması bu karşılıklı sorumlulukların anlaşılmasına bağlıdır.

Kabul koşullarını çalıştırılabilir örneklerle kurun

“Onay modülü tamamlanacak” yerine örnek bir işlem yazın. Kullanıcı gerekli alanları doldurup talebi gönderdiğinde kayıt ilgili inceleme kuyruğunda görünmeli; yetkisiz kullanıcı onay işlemini yapamamalı; iade edilen kayıtta gerekçe görülebilmelidir. Böyle anlatılan koşullar tasarım, geliştirme ve test ekibinin aynı sonucu tartışmasını sağlar. Her koşul otomatik test olmak zorunda değildir; kabul incelemesinde gözlenebilir olmalıdır.

Kabulü yalnızca mutlu akışla sınamayın. Zorunlu bilgi eksikse, dış sistem yanıt vermiyorsa veya kullanıcı aynı işlemi tekrar gönderiyorsa beklenen davranışı belirleyin. Her olasılığı baştan tüketmek mümkün değildir. Önemli olan en kritik kararları ve bilinen istisnaları teslim beklentisine bağlamaktır. Belgeyle ekran arasında iz kurulabildiğinde “böyle olacağını düşünmüştük” tartışması daha somut bir gereksinim değerlendirmesine dönüşür.

Açık sorular için ayrı bir karar listesi tutun

Kapsam çalışmasında bilinmeyenlerin ortaya çıkması normaldir. Sorun, bunların metin içinde görünmez biçimde kalmasıdır. Her açık soru için karar sahibi, gerekli bilgi ve sonraki kontrol noktası yazılabilir. Örneğin finans sisteminin hangi alanları kabul ettiği teknik inceleme bekliyor olabilir. Bu konu kapanmadan ilgili işin kesin kapsamda olduğu varsayılmamalıdır. Belirsizlik kaydı, projeyi durdurmak için değil doğru sırayla ilerletmek için kullanılır.

Yeni bir ihtiyaç geldiğinde mevcut belgeyle ilişkisini kurun. Önceden tanımlanan bir davranışın açıklığa kavuşması mı, yoksa yeni bir süreç mi ekleniyor? Etkisi veri, tasarım, geliştirme, test ve takvim açısından değerlendirilir. Değişiklik yolu açık olduğunda kapsam sabit bir duvar olmaktan çıkar; kontrol edilebilir bir karar kaydına dönüşür. Ekip hem öğrenebilir hem de her yeni fikrin görünmez bir ek işe dönüşmesini önleyebilir.

Keşif toplantısından kullanılabilir belgeye geçiş

İlk görüşmeye mevcut formlar, anonimleştirilmiş örnek kayıtlar, sık yaşanan sorunlar ve sürece katılan kişilerle gelmek yardımcı olur. Yalnızca istenen ekranların listesini getirmek yerine gerçek bir işlemi baştan sona anlatın. Yazılım ekibi bu anlatımdan süreç ve veri haritası çıkarabilir. Ardından kritik belirsizlikler için prototip veya teknik deneme gerekip gerekmediği değerlendirilir. Kapsam belgesi, bu çalışmanın ortak çıktısıdır.

BiKreatif’in Özel Yazılım Projeleri yaklaşımını değerlendirirken ihtiyaç analizi, Ar-Ge, prototipleme ve ürün geliştirme sorumluluklarını birlikte konuşabilirsiniz. Görüşmenin sonunda yalnızca bir ekran sayısı değil, hangi işin neden yapılacağı ve nasıl kabul edileceği anlaşılmalıdır. İyi hazırlanmış kapsam, değişimin olmayacağını iddia etmez. Değişiklik geldiğinde hangi kararı, maliyeti ve bağımlılığı etkilediğini tartışabilecek bir temel sağlar.

Sık Sorulan Sorular

Kapsam belgesini işletme mi yazılım ekibi mi hazırlamalı?

İş bilgisi işletmeden, teknik değerlendirme geliştirme ekibinden gelir. Belgenin birlikte geliştirilmesi daha sağlıklı olabilir. İşletme gerçek süreçleri ve karar sahiplerini açıklar; ekip bunları uygulanabilir davranışlara ve kabul koşullarına dönüştürür. Tek tarafın hazırladığı belge, diğer tarafın anlamadığı varsayımlar taşıyabilir. Sorumlu bir belge sahibi belirlemek güncelliğin korunmasını kolaylaştırır.

Henüz her ayrıntı belli değilse proje başlayabilir mi?

Keşif, araştırma ve prototip işleri belirsizliği azaltmak için başlayabilir. Ancak belirsiz olan konu kesinleşmiş teslim gibi fiyat ve takvime yazılmamalıdır. Kritik soruların hangi aşamada cevaplanacağı ve geliştirmeye geçiş kararının neye bağlı olduğu açıklanmalıdır. Her şeyi bilmek ile hiçbir belirsizliği kaydetmeden başlamak arasında uygulanabilir bir çalışma alanı vardır.

Ekran tasarımı kapsam belgesinin yerine geçer mi?

Ekranlar kullanıcı deneyimini tartışmayı kolaylaştırır; fakat yetki, veri kaynağı, entegrasyon hatası ve kabul koşulları görüntüde tam görünmeyebilir. Tasarım ile kapsam birbirini tamamlamalıdır. Bir düğmenin bulunması, kimlerin hangi koşulda o işlemi yapabileceğini açıklamaz. İş kurallarının yazılı ve örneklerle anlaşılır olması bu nedenle önemlidir.

Ar-Ge çalışması projenin neresinde olmalı?

Teknik veya kullanım belirsizliği karar vermeyi engelliyorsa hedefli bir araştırma planlanabilir. Sınanacak varsayım, denemenin kapsamı ve sonuçtan sonra verilecek karar belirli olmalıdır. Her geliştirme işini Ar-Ge olarak adlandırmak gerekli değildir. Araştırma çıktısı ile canlıda kullanılacak ürün tesliminin farklı beklentiler taşıdığını ayırmak planlamayı daha açık hâle getirir.

Kapsam sonradan değişirse ne yapılmalı?

Yeni talebin mevcut davranışı açıklayıp açıklamadığını veya yeni iş ekleyip eklemediğini birlikte değerlendirin. Veri, arayüz, entegrasyon, test ve takvim etkisini kaydedin. Uygun karar verilince belge ve ilgili işler güncellenir. Değişikliği tamamen yasaklamak da etkisini görünmez bırakmak da sorun yaratabilir. Açık bir değerlendirme yolu iki tarafın aynı bilgiyle karar vermesini sağlar.