Yazılım Projesine Başlamadan Önce Sorulması Gereken 10 Soru

Bir yazılım projesinde başlangıçta sorulmayan sorular, ilerleyen aşamalarda değişiklik talebi olarak geri gelir. Bütün ayrıntıları önceden bilmek mümkün değildir; fakat amaç, sorumluluk ve sınırlar konusunda ortak anlayış oluşturmak mümkündür. Aşağıdaki sorular bir teklif görüşmesini daha somut hale getirir.

Yanıtları tek kişinin hazırlaması yerine süreci kullanan ekiplerle birlikte çalışın. Yönetimin istediği raporlarla günlük işi yapanların ihtiyaçları farklı olabilir. İki bakışın da görünür olması daha sağlıklı kapsam oluşturur.

1. Hangi problemi çözüyoruz?

“Bir uygulamaya ihtiyacımız var” çözüm tanımıdır. Önce mevcut problemi yazın: aynı bilgi birkaç kez mi giriliyor, onaylar mı bekliyor, müşteri talepleri mi kayboluyor? Problemi gözlenebilir bir örnekle anlatmak önceliklendirmeyi kolaylaştırır.

2. Kullanıcılar kimler?

Müşteri, saha çalışanı, yönetici ve operasyon sorumlusu aynı işi yapmaz. Her rolün hangi bilgiyi göreceğini ve hangi işlemi yapacağını belirleyin. Dış kullanıcılarla iç kullanıcıları aynı varsayımlarla ele almayın.

3. İlk sürümde hangi iş tamamlanmalı?

Bütün fikirleri tek seferde geliştirmek zorunda değilsiniz. İlk sürümde baştan sona çalışacak temel akışı seçin. Kapsamı yalnızca ekran adlarıyla değil, işlem sonucu ve kabul kriteriyle ifade edin.

4. Mevcut veriler nerede?

Excel dosyaları, eski uygulamalar ve kişisel notlar aynı bilgiyi farklı biçimde tutabilir. Veri aktarımından önce eksik, tekrarlı ve tutarsız kayıtlar değerlendirilmelidir. Veri temizliğinin sorumlusu belirlenmeden taşıma takvimi gerçekçi olmayabilir.

5. Hangi sistemlerle bağlantı gerekiyor?

Muhasebe, ödeme, e-posta veya stok sistemiyle entegrasyon varsa teknik erişim ve veri paylaşım koşulları araştırılmalıdır. Dış sistemin sınırları projenin planını etkiler. “Bağlanırız” demek yerine hangi verinin hangi yönde ve ne sıklıkta aktarılacağını yazın.

6. Başarıyı nasıl anlayacağız?

Sadece yazılımın teslim edilmesi başarı değildir. Bir işlemin daha az elle müdahaleyle tamamlanması, yanlış kayıtların azalması veya ekibin tek veri kaynağında çalışması hedef olabilir. Ölçülebilir sonucu başlangıçta belirleyin; gerçekçi olmayan oranlar vaat etmeyin.

7. Kararları kim verecek?

Çelişen talepler ve geciken onaylar geliştirmeyi yavaşlatır. İş sahibi, teknik sorumlu ve son onay yetkilisi belli olmalıdır. Her görüşün alınması değerlidir; ancak öncelik kararının kimde olduğu açık kalmalıdır.

8. Bütçe hangi dönemi kapsıyor?

İlk geliştirme, barındırma, üçüncü taraf servisleri, eğitim ve bakım ayrı maliyetler olabilir. Kullanıcı sayısı ve veri hacmi arttığında maliyetin nasıl değişeceğini konuşun. Kapsam değişikliği için değerlendirme ve onay yöntemi oluşturun.

9. Güvenlik ve süreklilik ihtiyacımız ne?

Hangi bilgilerin hassas olduğunu, kimlerin erişeceğini ve kesintinin işi nasıl etkileyeceğini tarif edin. Yedekleme, kayıt tutma ve hesap kapatma süreçleri sonradan düşünülmemelidir. Özellikle dış sistemler üzerinden gönderilen verileri baştan belirleyin.

10. Yayından sonra kim sorumlu olacak?

Hataları kim takip edecek, kullanıcıları kim eğitecek ve yeni çalışanların erişimini kim açacak? Bakım sorumluluğu, kaynak koduna erişim ve teknik dokümantasyon teslimi netleşmelidir. Sistemin yalnızca bir kişinin bilgisine bağlı kalması işletme riski yaratabilir.

Soruları örnek bir sipariş akışında cevaplayın

Bir toptancının siparişleri mesajlaşma uygulamasından aldığını düşünelim. Sorun yalnızca dijital formun bulunmaması değildir: ürün kodları eksik geliyor, fiyat teyidi farklı kişilerden alınıyor ve siparişin depoya ulaşıp ulaşmadığı bilinmiyor. İlk sorunun yanıtı “Sipariş uygulaması yapmak” yerine “Onaylanan siparişin eksiksiz biçimde depoya ulaşmasını sağlamak” olabilir. Bu tanım, ilk sürümde hangi işin tamamlanacağını da daraltır.

Kullanıcılar satış temsilcisi, fiyat onaylayan yönetici ve depo çalışanı olarak ayrılır. Depo çalışanının fiyatı değiştirmesi gerekmeyebilir; satış temsilcisi ise stok bilgisini görebilir ama kesin teslim tarihini tek başına taahhüt edemeyebilir. Bu ayrıntılar, ekran sayısından önce iş kurallarını belirler. İhtiyaç görüşmesine her rolden bir kişinin katılması, yöneticinin göremediği günlük istisnaları ortaya çıkarır.

Veri ve entegrasyon sorularında ürün kodunun hangi sistemden geldiği, stok bilgisinin ne kadar güncel olduğu ve yeni siparişin hangi kayda bağlanacağı netleşir. Bu bağlantı çalışmadığında uygulamanın davranışı da yazılır. Eksik teknik erişim varsa tahminle takvim oluşturmak yerine erişimi doğrulayacak araştırma işi açılır. Web tabanlı yazılımın avantajları, merkezi sistemin bu tür bağımlılıklarını ayrıca ele alır.

Çelişen yanıtları görünür hale getirin

Yönetici her alanın zorunlu olmasını isterken satış ekibi bilgilerin ilk görüşmede bilinmediğini söyleyebilir. Çözüm iki görüşten birini otomatik seçmek değildir. İlk kayıt için gerekli alanlarla sipariş onayı öncesinde zorunlu olanlar ayrılabilir. Böylece veri kalitesi korunurken başlangıç aşaması gereksiz yere durmaz. Kararın gerekçesini kaydetmek, sonraki değişikliklerde aynı tartışmanın tekrarlanmasını önler.

Teklif istemeden önce cevapları üç grupta değerlendirin: üzerinde anlaşılanlar, araştırılması gerekenler ve ilk sürüm dışında kalanlar. Her bilinmeyen için bir sorumlu ve beklenen çıktı belirleyin. “Entegrasyon incelenecek” yerine örnek veri alışverişinin doğrulanması gibi somut bir sonuç isteyin. Bu belgeyi özel yazılım hizmeti görüşmesine taşımak, fiyatın hangi varsayımlara dayandığını anlamayı kolaylaştırır. Soruların amacı bütün belirsizliği yok etmek değil, belirsizliğin bütçe ve takvim üzerindeki etkisini açık tutmaktır.

Yanıtları çalışma belgesine dönüştürün

Bu soruların her biri için kısa bir yanıt, bilinmeyen noktalar ve bir sorumlu yazın. Bilinmeyenleri gizlemek yerine araştırılacak iş olarak kaydedin. Ardından özel yazılım geliştirme sürecini bu belgeye göre planlayın.

İyi bir başlangıç belgesi yüzlerce sayfa olmak zorunda değildir. Doğru sorulara verilen açık yanıtlar, aynı kelimelerle farklı şeyler anlatma ihtimalini azaltır ve proje boyunca daha sağlıklı karar alınmasını sağlar.