Bir MVP kapsam belgesinde neler olmalı

Çoğu "kapsam belgesi" madde işaretli bir özellik listesi ve bir rakamdır. Bu bir kapsam belgesi değildir. Biçimlendirilmiş bir tahmindir.

Gerçek bir tanesi, yalnızca belgeyi okuyan iki farklı mühendislik ekibinin tanınabilir şekilde aynı ürünü inşa edeceği kadar spesifiktir. İşte bunun gerçekte gerektirdiği şey.

Kısa yanıt

Sekiz bölüm. İkisini veya üçünü kaçırırsanız, elinizde bir plan değil bir teklif vardır.

Özellik listesi değil, sorun tanımı

Belge, tek bir özellik adlandırılmadan önce, çözülen sorunu ve kimin bu soruna sahip olduğunu sade bir dille açmalıdır. Bu bariz görünür ve sürekli atlanır.

Neden önemli: sonraki her kapsam kararı buna karşı test edilir. Altıncı haftada bir özellik talebi ortaya çıktığında, "bu belirtilen sorunu çözüyor mu" sorusu "kulağa faydalı geliyor mu" sorusundan daha hızlı ve daha dürüst bir filtredir.

Zayıf bir versiyon: "Filo operatörlerini teknisyenlerle buluşturan bir uygulama." Çalışan bir versiyon gerçek acıyı adlandırır - operatörler şu anda her arıza için müsait bir teknisyeni telefonla bulmak için iki ila altı saat harcıyor, önceden yeterlilik doğrulama imkânı olmadan.

Özellik listelerinden önce kullanıcı akışları

Tek başına özellikler ürünün çalışıp çalışmadığını söylemez. Akışlar söyler.

Belge, bir kullanıcının gerçekten baştan sona kat ettiği iki veya üç temel yolu haritalamalıdır - her ekranı değil, ürünü işlevsel kılan sırayı. "Bir puanlama sistemi ekle"nin örtük olarak "puanlama haksız olduğunda anlaşmazlıkları ele al"ı gerektirdiğini tam burada keşfedersiniz, ki bunu kimse ayrı kapsamlamayı düşünmemiştir.

Gerçekten önceliklendirilmiş bir özellik listesi

Düz bir madde listesi değil - eksikse ürünü bozan şeye karşı sahip olmasının hoş olacağı şeye göre sıralanmış bir liste. Daha önce tam olarak bu testi kullanarak 46 özellikli bir listeyi 11'e indirmek hakkında yazmıştık: bu eksik olsa, çekirdek döngü hâlâ çalışır mı?

Bu testi geçen her özellik "Olmazsa Olmaz"a girer. Geri kalan her şey açıkça etiketlenmiş bir "İkinci Aşama" bölümüne gider - belgelenmiş, üst düzeyde tahmin edilmiş ve şu anda inşa edilenin açıkça parçası olmadığı belirtilmiş. Bu tek uygulama, herhangi bir sözleşme maddesinden daha fazla kapsam anlaşmazlığını önler.

Gerekçeleriyle birlikte teknik mimari

Sadece bir teknoloji listesi değil - her seçimin arkasındaki mantık, çünkü tam olarak bu, birinin kararların altı ay sonra hâlâ mantıklı olup olmadığını değerlendirmesine olanak tanır.

Bir kapsam belgesi, teknoloji yığınını, barındırma yaklaşımını ve geri almanın pahalı olacağı iki veya üç kararı belirtmelidir - işlemsel bir ürün için veritabanı seçimi, bildirimlerin WhatsApp üzerinden mi yoksa yalnızca e-posta üzerinden mi yönlendirileceği, mimarinin şu anda tek bir platformda başlatılsa bile daha sonra birden fazla platformu destekleyip desteklemeyeceği.

Açıklama değil, ekranlar veya prototip

"Temiz, modern bir kontrol paneli" bir spesifikasyon değildir. Beş ila sekiz ana ekran, tercihen tıklanabilir bir prototip olarak, inşa ortasındaki sürprizlerin en büyük kaynağını ortadan kaldırır: kurucu ve ekibin aynı özelliğin farklı resimlerini kafalarında taşıması.

Bunun piksel mükemmelliğinde bir nihai tasarım olması gerekmez. "Yönetim paneli"nin bir soyutlama olmaktan çıkıp gerçek, tartışılabilir bir şeye dönüşecek kadar spesifik olması gerekir.

Tek bir rakam değil, modül bazında ayrılmış bir tahmin

Tek bir fiyat, onu üreten her varsayımı gizler. Modül modül döküm - hesaplar ve izinler, çekirdek işlem akışı, ödemeler, yönetim paneli ve benzeri - tek bir rakamın yapamayacağı iki şeyi yapar: neyin pahalı olduğunu ve nedenini görmenizi sağlar, ve bütçe yetmezse tüm anlaşmayı yeniden müzakere etmek yerine belirli bir modülü kesmenize izin verir.

Spesifik olarak adlandırılmış riskler ve bağımlılıklar

Genel risk dili ("teknik risk", "takvim riski") değersizdir. Gerçek bir risk bölümü, projeyi yavaşlatabilecek spesifik şeyi adlandırır - bir ödeme sağlayıcısının onay takvimi, belirsiz hız sınırlarına sahip üçüncü taraf bir API, hâlâ beklemede olan bir kurucu kararı - ve bunu çözmekten kimin sorumlu olduğunu.

Bu bölüm aynı zamanda kritik yolun belirlendiği yerdir: geciktirilirse, mühendisliğin geri kalanı ne kadar iyi giderse gitsin lansman tarihini geciktiren iki veya üç şey.

Açıkça hariç tutulan şey

Bu, çoğu kapsam belgesinin tamamen atladığı bölümdür ve sonradan en çok anlaşmazlığı önleyen bölümdür.

Neyin dahil olmadığını açıkça belirtin: üçüncü taraf hizmet maliyetleri, içerik yazımı, veri taşıma, tanımlı bir pencerenin ötesinde destek, ikinci bir platform. Bu bölümün en iyi versiyonu uzun ve okuması biraz sıkıcıdır. Bu bir kusur değil bir özelliktir - buradaki belirsizlik "bunun dahil olduğunu sanıyordum" anlaşmazlıklarının kaynağıdır.

Gerçek bir tanesi neye benzer

Gerçek bir projeye karşı sekiz bölümün tamamının doldurulduğunu gösteren anonimleştirilmiş bir örnek Blueprint yayımlıyoruz - yer tutucu metinli bir şablon değil, gerçek kararlar ve gerçek rakamlarla gerçek bir kapsam belgesi. Onu okumak, bir tanımını okumaktan daha hızlıdır.

Sizinkinin gerçek olup olmadığının testi

Belgeyi sizinle hiç konuşmamış bir mühendise verin ve takvimi tahmin etmesini isteyin. Netleştirici bir görüşme olmadan yapabiliyorsa, bu bir kapsam belgesidir. On soruyla geri dönüyorsa, elinizde fiyat etiketi yapıştırılmış bir özellik listesi var demektir - ve o on soru, proje zaten başladıktan sonra, yanıtlamanın çok daha pahalı olduğu bir noktada değişiklik talepleri olarak ortaya çıkacak tam olarak o şeydir.

Gerçek bir projeye karşı tam bir kapsam belgesinin nasıl göründüğünü görmek ister misiniz? Örnek Blueprint'imiz alıntı değil, tam belgedir. Ya da projenizi anlatın, bir rakam söylemeden önce kapsamını doğru şekilde belirleyelim.