Yeni bir ürün fikriyle gelen ekipler ilk toplantıya çoğu zaman uzun bir özellik listesiyle gelir. Liste genellikle doğrudur; sorun, listenin tamamının ilk sürüme sığdırılmaya çalışılmasıdır. İlk sürüm büyüdükçe takvim uzar, uzayan takvimde pazar değişir ve ürün çıktığında listeyi yazdıran varsayımlar eskimiş olur.
Kapsamı daraltmak için üç soru soruyoruz. Sorular basit. İşe yaramalarını sağlayan şey, cevapların yazılı verilmesi ve kesilen her özelliğin bir sonraki sürüm listesine adıyla yazılması.
1. Bu özellik olmadan ilk müşteri parayı öder mi? #
İlk soru özelliği değil müşteriyi konuşturur. "Kullanıcılar bunu ister" cevabı yeterli sayılmaz. Belirli bir müşteri, belirli bir iş için, bu özellik olmadan ürünü kullanmaya devam eder mi diye sorarız. Cevap "eder" ise özellik ilk sürümden çıkar.
Bu soruda ilk elenen kalemler çoğu zaman raporlama ekranları, ayrıntılı ayarlar sayfaları ve ikinci kullanıcı rolü olur. Üçü de ürün büyüdüğünde gerekir; ilk müşterilerde ise nadiren belirleyicidir.
2. Bu iş bir süre elle yapılabilir mi? #
İkinci soru, özelliği yazılım yerine insanla çözmenin maliyetine bakar. Faturalandırma, karşılama e-postaları ve veri içe aktarma gibi işler ilk aylarda elle yürütülebilir. Haftada birkaç saat tutan bir iş için haftalarca geliştirme yapmak ilk sürümde çoğu zaman doğru yatırım değildir.
Elle yapılan işleri bir tabloya yazıyoruz: iş, kim yapıyor, haftada ne kadar zaman alıyor. Bir satır ekibin baştan belirlediği eşiği geçtiğinde o özellik bir sonraki sürümün adayı olur. Böylece kapsam kararı tahminle değil, izlenen zamanla verilir.
3. Bunu ilk sürümden sonra eklemek neyi bozar? #
Üçüncü soru tersini sorar: bazı kararlar sonradan alınamaz ya da alındığında her şeyi değiştirir. Çok kiracılı veri yapısı, kullanıcı rolleri ve ödeme altyapısının temel kararları böyledir. Ekranda görünmeseler de ilk sürümde kurulmaları gerekir.
Bu yüzden kapsam listesi iki sütuna ayrılır: kullanıcının göreceği özellikler ve altyapı kararları. İlk sütun kısaltılır, ikinci sütun neredeyse hiç kısaltılmaz. Tersi yapıldığında ekranlar çoğalır, altyapı sonraya kalır ve ikinci sürüm bir yeniden yazma projesine dönüşebilir.
Kendi ürünümüz Reshape bu türden bir karar örneği: vitrin seti ile mağazayı işleten sistem baştan ayrı katmanlar olarak kuruldu. Set değiştiğinde ürünler, siparişler ve ayarlar yerinde kalıyor. Bu ayrım ekranda görünmez ama sonradan eklenmesi en pahalı kararlardan biridir. Tasarım ve yazılım kararlarının aynı masada verilmesi bu ayrımı kolaylaştırır; SaaS ve iş yazılımları çalışmalarında kapsam belgesini bu iki sütunla kuruyoruz.
Kesilen özelliklere ne olur #
Kesilen bir özelliğin önünde üç yol vardır: sonraki sürümlerden birinde planlandığı gibi eklenir, ilk kullanıcıların isteğiyle başka bir biçimde eklenir ya da hiç eklenmez. Hangi özelliğin hangi yola gireceği ilk toplantıda bilinemez. Listeyi silmek yerine saklamanın nedeni budur.
Üçüncü grup en öğretici olanıdır. İlk toplantıda "olmazsa olmaz" denen bir özellik, ürün gerçek kullanıcıyla buluştuğunda gündemden düşebilir. Kapsamı daraltmanın kazancı yalnız hız değildir; gerekmeyeceği sonradan anlaşılan işleri hiç yapmamaktır.
İlk kapsam çalışması nasıl ilerler #
- Özellik listesi tek tabloya alınır; her satıra üç sorunun cevabı yazılır.
- Liste iki sütuna ayrılır: ekranlar ve altyapı kararları.
- Kesilen özellikler silinmez, "sonraki sürüm" başlığı altında aynı tabloda kalır.
- Elle yapılacak işler için sorumlu ve izlenecek süre yazılır.
- Kapsam belgesi taraflarca onaylanır; sonraki değişiklikler aynı tabloya işlenir.
Bu belge geliştirme boyunca ortak referans olur. Takvim ve kapsam tartışmalarında ilk bakılan yer bu tablodur. Girişimler için bu çalışmayı nasıl kurguladığımızı Startuplar İçin sayfasında anlatıyoruz.
Kaynaklar #
- The Lean Startup, Eric Ries; MVP kavramının kaynağı
- Shape Up, Basecamp; kapsam belirleme ve "appetite" yaklaşımı
