Tasarım Projelerinde Kapsam: Yedi Sorunun Dördü Sınır Çizer
Interaction Design Foundation'ın kapsam belirleme için önerdiği yedi soru çok dolaşan, az itiraz edilen bir liste. Sorular fena değil, ama liste tek başına kapsamı çizmiyor. Yedi sorudan dördü sınır çiziyor, üçü yön veriyor; ikisini aynı dokümana aynı ağırlıkla yazmak kapsamı niyet beyanına çeviriyor.
Sınır çizen dört soru
Ne teslim edilecek, ne zaman teslim edilecek, hangi bütçeyle, içeriği kim verecek. Bu dördünün ortak özelliği, cevabın yanlış olduğunun sonradan kanıtlanabilmesi. Teslim tarihi geçer ya da geçmez. Bütçe aşılır ya da aşılmaz. Ürün tanımı ise ancak yeterince ayrıştırılmışsa ölçülebilir hale gelir, en çok kaza da burada olur.
"E-ticaret sitesi" bir kapsam satırı değil, bir kategori adı. Bir projede "ürün listeleme" tek satır olarak yazılmıştı, teslimde filtreleme, varyant yönetimi, stok senkronu ve çok dilli açıklama olarak dört ayrı iş çıktı.
İçerik sorusu listenin en hafife alınanı. Tasarım tarafı biterken metinler ve görseller gelmediği için bekleyen proje sayısı, teknik nedenle bekleyenden az değil. Kim yazacak, ne zaman verecek, gelmezse ne olacak: bunlar yazılmadıysa içerik kapsamda değil demektir.
Yön veren üç soru
Hedef kitle kim, proje işletmeye ne kazandıracak, benzer ürünlerde ne beğeniliyor. Bu üçü tasarım kararlarını besler, sınır çizmez. Faydası tartışmasız, ama kapsam dokümanına madde olarak girdiklerinde ölçülemez kabul kriterine dönüşürler.
"Kullanıcı dostu bir arayüz" teslim edildi mi edilmedi mi, bunu kimse hakemsiz karara bağlayamaz. Aynı beklenti "kayıt formu üç alana iner ve mobilde tek ekranda görünür" diye yazıldığında ölçülebilir hale gelir. Hedef kitle analizi işte bu ikinci cümleyi üretmek için var, kendisi kapsam satırı değil.
Referans inceleme de öyle. Müşterinin beğendiği örnekleri toplamak beklentiyi hizalar, fakat "şuradaki gibi olsun" cümlesi kapsamda ne kadar iş olduğunu söylemez. Referansı iş kalemine çevirmeden dokümana yazarsanız, sonraki tartışma zevk tartışmasına döner ve kimse kazanamaz.
Üçü birden sabitlenemez
Kapsam, süre ve bütçe aynı anda kilitlendiğinde değişiklik talebi mekanizması kâğıt üstünde kalır. Talep gelir, üç değişkende de yer yoktur, iş kaliteye ya da mesai dışına yazılır. Kaynak metnin kendi içinde de bu çelişki duruyor: bir yandan kapsamı baştan ve kesin belirlemeyi öneriyor, öte yandan değişiklik taleplerini sürecin normal parçası sayıyor. İkisi ancak üç değişkenden biri açık bırakılırsa aynı anda doğru olur.
Pratikte esnetilen genelde kapsam oluyor, çünkü bütçe ve tarih sözleşmede yazılı, kapsam ise yoruma açık. Bunu tersine çevirmenin yolu kapsamı sürümlere bölmek: v1'de şunlar var, gerisi v2 başlığı altında bekliyor ve kendi bütçesiyle geliyor.
Asıl belge kapsam dışı listesi
Kapsam dokümanının işe yarayan yarısı, yapılacakların listesi değil, yapılmayacakların listesi. Ama bu liste tamamlanamaz. Bir projenin içermediği şeylerin kümesi sonsuzdur; hepsini saymaya kalkarsanız doküman biter, proje bitmez. O yüzden kapsam dışını üç yerden toplamak gerekiyor:
- Toplantıda konuşulup dahil edilmeyen her şey. Konuşulduysa beklenti oluşmuştur, yazılmalıdır.
- Benzer projelerde sonradan istenen işler. Mobil uygulama, çok dillilik, tek oturum açma, panel içi raporlama bu listenin klasikleridir.
- Kategorik sınırlar. "Ödeme entegrasyonu yalnızca tek sağlayıcı için yapılır" gibi bir satır, adı hiç geçmemiş yirmi sağlayıcıyı tek cümlede dışarıda bırakır.
Üçüncüsü diğer ikisinden daha çok iş görür. Tek tek saymak yerine sınırı tarif etmek, listeyi kısaltırken kapsamayı genişletiyor. Kapsam dokümanını imzalatmadan önce bakılacak yer de burası: yapılacaklar listesi kabaca herkeste aynıdır, projeleri birbirinden ayıran şey kapsam dışı bölümünün ne kadar açık yazıldığı.
Kaynaklar