Bir web yazılımı projesi için teklif isterken “müşterilerimiz giriş yapacak ve işlerini panelden takip edecek” demek başlangıçtır, fakat kapsamı belirlemek için yeterli değildir. Giriş yapan kişi ne görecek, hangi bilgileri değiştirecek, bir talep kim tarafından onaylanacak? Bu sorular yanıtsız kalırsa aynı cümleden birbirinden farklı projeler çıkar.
İhtiyaç dokümanı uzun bir teknik dosya olmak zorunda değil. İşletmenin bugün nasıl çalıştığını, yeni yazılımda nelerin yapılacağını ve hangi kararların henüz verilmediğini anlaşılır biçimde yazmak çoğu zaman daha yararlıdır. Böylece hem teklifleri karşılaştırmak hem de proje sırasında aynı hedefe bakmak kolaylaşır.
Önce çözmek istediğiniz işi anlatın
Yazılımın ekranlarından önce mevcut süreci tarif edin. Siparişler e-postayla mı geliyor, personel bilgileri bir tabloda mı tutuyor, müşteri telefonla mı durum soruyor? İşin bugün nasıl yürüdüğünü bilmek, yeni sistemin hangi adımları gerçekten kolaylaştırması gerektiğini gösterir.
“Daha hızlı çalışmak istiyoruz” gibi geniş bir hedef yerine gözlenebilir bir sorunu yazın. Örneğin “müşteri talebi üç kişiye ayrı ayrı iletildiği için son durum karışıyor” cümlesi, kullanıcı rolleri ve durum takibi ihtiyacını açık eder. Sorunu tarif etmek, henüz gerekli olmayan özelliklerin de ayıklanmasına yardım eder.
Kullanıcıları ve yetkilerini ayrı ayrı düşünün
Sistemi kimler kullanacak? Müşteri, satış ekibi, operasyon sorumlusu ve yönetici aynı bilgileri görmeyebilir. Her rol için yapabileceği işlemleri birkaç cümleyle yazın: Müşteri talep açar, operasyon ekibi durum günceller, yönetici raporları görüntüler gibi.
Yetki sınırlarını erkenden belirlemek gerekir. Bir şube çalışanı diğer şubenin kayıtlarını görebilecek mi? Müşteri yalnızca kendi siparişlerini mi izleyecek? Yanlış kişiye açılan bir ekran, yalnızca kullanım sorunu değildir; özel bilgilerin paylaşılması açısından da sorun yaratabilir. Kesin karar veremediğiniz noktaları “kararlaştırılacak” diye işaretleyin ve görüşmede ele alın.
İş akışını baştan sona örnekleyin
Bir işlemin başlangıcından bitişine kadar neler olduğunu sıralayın. Örneğin müşteri form doldurur, ekip talebi inceler, eksik bilgi ister, fiyat verir, müşteri onaylar ve iş tamamlanır. Bu akışı gerçek bir örnek üzerinden yazarsanız unutulan ara adımlar daha kolay ortaya çıkar.
Yalnızca normal akışı düşünmeyin. Müşteri yanıt vermezse, fiyat değişirse, talep iptal edilirse veya aynı kişi birden fazla kayıt açarsa ne olacak? Her olasılığı ayrıntılı tasarlamak şart değil; fakat sık yaşanan istisnaları listelemek kapsamı daha doğru belirler.
Ekranları değil, yapılacak işlemleri listeleyin
“Yönetim paneli olsun” ifadesi tek başına açıklayıcı değildir. Panelde ürün ekleme, teklif hazırlama, dosya yükleme, durum değiştirme, arama ve dışa aktarma gibi hangi işlemlerin yapılacağını belirtin. Benzer şekilde “raporlama” ihtiyacı varsa hangi sorunun yanıtını aradığınızı yazın: Haftalık tamamlanan iş sayısı mı, geciken talepler mi, müşteri bazında sipariş toplamı mı?
Elinizde bir çizim varsa ekleyin; yoksa kâğıda yapılan basit bir taslak da yeterli olabilir. Görsel tasarımın baştan bitmiş olması gerekmez. Ama kullanıcı bir işi hangi sırayla yapacağını anlatabilirse ekranların nasıl düzenleneceği üzerine daha sağlıklı konuşulur.
Mevcut sistemleri ve veri kaynaklarını belirtin
Yeni yazılımın tek başına mı çalışacağını, yoksa mevcut muhasebe, ödeme, kargo, e-ticaret veya müşteri yönetimi sistemleriyle bilgi alışverişi mi yapacağını yazın. Kullanılan sistemlerin adları kadar aktarılacak verinin yönü de önemlidir. Örneğin sipariş yeni sisteme mi gelecek, yoksa yeni sistem siparişi başka bir servise mi gönderecek?
Bugünkü veriler elektronik tabloda, eski bir panelde veya çeşitli dosyalarda tutuluyorsa bunu saklamayın. Kayıtların biçimi, tekrar eden satırlar, eksik alanlar ve taşınacak geçmiş miktarı proje kapsamını etkileyebilir. Veri taşıma ayrı bir iş kalemi olabilir; teklif alırken bunun açıkça konuşulması gerekir.
Öncelikleri üç seviyeye ayırın
Bütün fikirleri ilk sürüme koymak projenin yönetimini zorlaştırır. Özellikleri “ilk kullanım için gerekli”, “sonraki aşamada yararlı” ve “henüz fikir” şeklinde ayırın. Bu sınıflandırma, farklı bütçe ve teslim seçeneklerini değerlendirmek için ortak bir zemin sağlar.
Önceliği işletme etkisine göre düşünün. Müşterinin talep göndermesi işin özü ise bu özellik ilk sürümde yer almalıdır. Daha sonra eklenecek gelişmiş grafikler ilk aşamada şart olmayabilir. Bir özellik başka bir özelliğe bağlıysa bunu da not edin; örneğin raporun çalışması için önce doğru verinin kaydedilmesi gerekir.
Başarı ölçütünü ve kabul örneklerini yazın
Projenin tamamlandığına nasıl karar vereceksiniz? “Sistem sorunsuz çalışsın” ifadesini birkaç gerçek senaryoyla somutlaştırın. Müşteri formu doldurduğunda kayıt oluşması, yetkili personelin bildirimi görmesi ve müşterinin güncel durumu kendi hesabında izlemesi örnek bir kabul akışıdır.
Mobil kullanım, erişim hızı ve yoğun dönemlerdeki işlem sayısı gibi beklentileri de işletmenizin gerçek koşullarıyla anlatın. Kesin rakam bilmiyorsanız mevcut kullanıcı veya günlük işlem sayısını yaklaşık olarak paylaşın. Tahmin ile kesin gereksinimi ayırmak, proje planında yanlış varsayımları azaltır.
Güvenlik ve bakım sorumluluğunu da ihtiyaç görüşmesinde sorun. Hesaplara erişim nasıl verilecek, personel ayrıldığında yetkisi nasıl kapatılacak, yedekler kim tarafından izlenecek? İşletmenin kendi ekibinin yapacağı işleri ve dış destek gerektiren işleri ayırmak, yazılım kullanıma açıldıktan sonra karşılaşılabilecek aksaklıklar için kime başvurulacağını netleştirir.
Ayrıca dokümanın tarihini ve sürümünü kaydedin. Görüşmeler sırasında kapsam değişirse eski dosyanın üzerine sessizce yazmak yerine değişen kararı ve nedenini not edin. Böylece teklif aşamasındaki beklentiyle sonradan konuşulan yeni isteği birbirinden ayırabilirsiniz.
Teklif isterken paylaşılacak kısa bir özet hazırlayın
İyi bir başlangıç dosyasında işletmenin amacı, mevcut sorun, kullanıcı rolleri, temel iş akışı, gerekli işlemler, entegrasyonlar, taşınacak veriler ve öncelikler bulunur. Bunların hepsini kusursuz yazmanız beklenmez; açık kalan soruları ayrıca işaretlemek daha dürüst ve yararlıdır.
Çağ Medya ile bir web yazılımı projesini görüşürken bu özet üzerinden ilerlemek, ihtiyacın ve olası kapsamın birlikte değerlendirilmesine yardımcı olur. Geliştirme başlamadan önce ortak bir ihtiyaç tanımı oluşturmak, proje ilerledikçe alınacak kararları da kolaylaştırır.