Bir yazılım projesinin başlangıcında en faydalı çalışma, yapılacak ekranları sıralamadan önce çözülecek sorunu anlatmaktır. Çünkü aynı soruna farklı çözümler bulunabilir: mevcut bir aracın doğru ayarlanması, iş akışının değiştirilmesi veya yeni bir uygulama geliştirilmesi.
Hangi iş bugün zor yapılıyor?
“Bir yönetim paneline ihtiyacımız var” yerine, hangi işte zaman kaybedildiğini tarif edin. Örneğin bir ekip, gelen talepleri farklı dosyalarda takip ettiği için aynı işi iki kez yapıyor olabilir. Buradaki ihtiyaç yalnızca bir ekran değil; ortak kayıt, sorumluluk takibi ve güncel bilgiye erişimdir.
Problemin hangi sıklıkla yaşandığını ve kimleri etkilediğini yazın. Haftada bir yapılan kısa bir iş ile gün içinde tekrar tekrar yapılan bir iş aynı öncelikte olmayabilir. Mümkünse mevcut adımları basit bir listeyle çıkarın.
Çözümü kim kullanacak?
Kullanıcıları yalnızca görev adlarıyla tanımlamak yeterli değildir. Kullanıcının nerede çalıştığını, hangi cihazı kullandığını ve hangi bilgilere erişmesi gerektiğini de düşünün. Sahada telefon kullanan biri ile ofiste büyük bir ekranda çalışan birinin beklentileri farklılaşabilir.
Bir kişi talebi oluştururken başka biri onaylıyor olabilir. Bu ayrım, erişim yetkileri ve iş akışları açısından önemlidir. Her kullanıcının bütün bilgileri görmesi gerekip gerekmediğini başlangıçta konuşun.
İlk sürümde gerçekten ne gerekli?
İlk kapsamı, ana sorunu çözen işlerle sınırlayın. Gerekli özellikler, daha sonra eklenebilecek özellikler ve kapsam dışındaki işler ayrı ayrı yazılabilir. Bu ayrım bir özelliği değersiz saymak anlamına gelmez; hangi sırayla ele alınacağını belirler.
Örneğin ortak talep kaydı ve durum takibi ilk sürümde gerekli olabilirken, ayrıntılı raporlar sonraki bir adım olarak değerlendirilebilir. Bu tercih, ekibin gerçek kullanımını daha erken görmeyi sağlar.
İşin tamamlandığını nasıl anlayacaksınız?
“Kullanımı kolay olsun” gibi bir beklenti anlaşılır ama tek başına ölçülebilir değildir. Kullanıcının bir talep oluşturabilmesi, yetkili kişinin talebi görebilmesi ve durum değişikliğinin kaydedilmesi daha somut kabul koşullarıdır.
Başlangıçta birkaç gerçek iş örneği yazın. Proje ilerlediğinde bu örnekler, ortaya çıkan çözümün beklentiyi karşılayıp karşılamadığını kontrol etmeye yardımcı olur.
Görüşmeye neyle gitmeli?
Kısa bir problem tanımı, mevcut iş akışının özeti ve temel öncelikler iyi bir başlangıçtır. Hazır bir teknik şartname olmaması görüşmeye engel değildir. Önemli olan, bilinmeyen noktaları gizlemek yerine görünür hâle getirmektir.
Bu bilgiler bir araya geldiğinde teknoloji seçimi daha anlamlı bir zemine oturur. İlk amaç en fazla özelliği istemek değil, doğru problemi ve sınırları birlikte anlamaktır.