1. Problemi ve gereken değişimi tanımlayın
Bugün olanı gözlenebilir biçimde anlatın. İşi kim başlatıyor, hangi bilgi gerekiyor, süreç nerede yavaşlıyor, tekrar yaratıyor veya görünürlüğünü kaybediyor? 'Bir gösterge paneline ihtiyacımız var' demek yerine yaşanmış bir örnek verin.
Ardından beklenen operasyonel değişimi yazın: ekip tek güvenilir durumu görebilsin, onay mesaj takibi olmadan tamamlansın, rapor yönetilen veriden hazırlansın veya müşteri baştan sona tutarlı bir hizmet yolu izlesin. Başlangıç ölçümü yokken sayısal sonuç garantisi vermeyin.
Problemin neden şimdi önemli olduğunu belirtin. Gerçek bir son tarih, büyüyen hacim, iş değişikliği, çöken geçici çözüm veya yeni müşteri ihtiyacı ilk kapsamı etkileyebilir.
2. Kullanıcıları, kararları ve istisnaları haritalayın
İşi yapan, onaylayan, destekleyen veya sonuçtan yararlanan kişileri listeleyin. Yalnız unvanı değil, kişinin neyi bilmesi ya da tamamlaması gerektiğini anlatın. Gerekirse müşteri ve iş ortaklarını ekleyin; iş sürecinin sahibini belirleyin.
Temsilî akışı tetikten tamamlanmaya kadar izleyin. Devirleri, onayları, gecikmeleri, paralel kayıtları ve muhakeme noktalarını kaydedin. Eksik bilgi, yinelenen talep, onay sonrası değişiklik, erişilemeyen sistem ve eskalasyon gibi istisnaları da ekleyin.
Bu senaryolar düz özellik listesinden daha güçlü tasarım ve kabul girdisidir. Nerede otomasyon, nerede insan kararını destekleyen ürün gerektiğini gösterir.
3. Sistemleri, veriyi ve kısıtları belirleyin
Elektronik tablolar ve resmî olmayan kanallar dahil kullanılan araç ve kayıtları adlandırın. Önemli her kaynağın sahibini, güncelliğini, erişimini ve hangi sistemin asıl kayıt olarak kalacağını belirtin. API veya dışa aktarma bilgisi yararlıdır; gerekirse keşifte araştırılabilir.
Yetki, gizlilik, saklama, dil, erişilebilirlik, cihaz, bağlantı, barındırma, satın alma, son tarih ve iç destek kapasitesi gibi tasarımı değiştirecek kısıtları yazın. Kısıt yalnız teknik engel değildir; işletme için kullanılabilir ürünün tanımını belirleyebilir.
Doğrulanmış gerçeklerle varsayımları ayırın. Böylece belirsizlik kapsamın içine gizlenmez; araştırma veya teknik test konusu olur.
4. En küçük yararlı sürümü tanımlayın
Minimum uygulanabilir ürün, eksik ekranlar toplamı değil bütünlüklü bir değer dilimidir. Tek kullanıcı grubu, karar, iş akışı veya hizmet sonucunu baştan sona ele alın. Bilinçli olarak dışarıda bırakılanları ve genişlemeyi hangi kanıtın gerekçelendireceğini yazın.
Kabul ölçütlerini gözlenebilir dille kurun: kullanıcı gerekli yetkiyle görevi tamamlar; kayıt adlandırılmış kaynakla eşitlenir; istisna sorumlu role görünür; rapor girdilerine kadar izlenebilir. 'Modern', 'akıllı' veya 'kolay' gibi ifadeleri test edilebilir hâle getirmeden kullanmayın.
Yayın sonrası kanıtı planlayın. Tamamlama, düzeltme yükü, destek sorunları, süreç süresi, nitel geri bildirim ve hata sınıfları bir sonraki karara hizmet etmelidir.
- Değerli bir iş akışını baştan sona çözmeli
- Önemli istisna ve hata durumlarını kullanılabilir kılmalı
- Sürüm dışındaki kapsamı açıklamalı
- Sonraki ürün kararı için kanıt üretmeli
5. Yararlı sorulara açık bir proje özeti hazırlayın
Problem, sonuç, kullanıcılar, akış örnekleri, sistemler, veri notları, kısıtlar ve ilk sürüm varsayımını kısa bir belgede toplayın. Sorumlu paydaşları ve gerçek son tarihi ekleyin. Destekleyici malzemeyi açıklamayla bağlayın.
Geliştirme görüşmesi bu özeti sınamalıdır. Sahiplik, istisna, erişim, benimseme ve projeyi anlamsız kılacak koşullar hakkında sorular bekleyin. Güvenilir bir ortak, özel ürün yerine yapılandırma, entegrasyon veya daha küçük değişiklik önerebilir.
Erken keşfin çıktısı daha net bir karar olmalıdır: önce ne yapılacak, hangi konu araştırılacak, ürün mevcut operasyona nasıl bağlanacak ve hangi risk aktif biçimde yönetilecek? Sabit özellik listesi çevresinde sahte kesinlik üretmemelidir.