Discovery'den Delivery'ye: One-Pager, PRD ve Kararın Backlog'a Dönüşmesi

Sürüm notu: Bu yazı kavramsaldır; serinin önceki yazılarındaki Bookstore sepet terk çalışmasının sayılarını (07. yazıdaki funnel, 08. yazıdaki deney) kullanır.

Önce Tahmin Et

Bookstore ekibine aynı hafta iki doküman geliyor. Birincisi bir Jira kaydı: "Ürün sayfasında kargo ücreti gösterilsin. Acceptance criteria: ücret fiyatın altında görünür." Üç satır. İkincisi başka bir ekipten gelen, on dört sayfalık bir PRD (Product Requirements Document): ekran görüntüleri, her alanın pixel ölçüleri, otuz iki madde hâlinde gereksinimler, ama ilk sayfada neden yapıldığına dair tek bir cümle yok.

Hangisiyle çalışmak daha kolay? İkisinde de eksik olan şey ne? Bir de şunu düşün: üç satırlık kayıtla işe başlayan geliştirici, sepette birden fazla kitap olduğunda kargo ücretinin nasıl hesaplanacağını kime, ne zaman soracak?

One-Pager ve PRD: Ne İçin Varlar?

Discovery bir karar üretir: hangi problemi, hangi outcome için, hangi çözüm adayıyla ele alacağız. Delivery ise bu kararı koda çevirir. Arada bir köprü gerekir; köprü yoksa karar toplantıda kalır, kod da Jira kaydında yazanı yapar. One-pager ve PRD bu köprüdür.

One-pager, adından anlaşılacağı gibi tek sayfalık bir dokümandır ve amacı hizalanmaktır: ekip, ürün sahibi ve paydaşlar aynı problemi, aynı hedefi ve aynı sınırları mı anlıyor? PRD daha ayrıntılıdır ve geleneksel olarak gereksinimlerin tam listesini taşır. Pratikte ikisi arasındaki çizgi bulanık; birçok ekip "PRD" deyip bir iki sayfalık bir doküman yazar. Bazı şirketlerin kendi biçimleri de vardır: Amazon'un "working backwards" yaklaşımında ekip işe ürün çıktığında yayımlanacak basın bültenini ve sık sorulan soruları yazarak başlar.

Biçimden bağımsız olarak iyi bir doküman iki soruya cevap verir: neden yapıyoruz ve başarılı olduğumuzu nasıl anlayacağız? Baştaki iki doküman da bu iki soruyu cevaplamıyor. Jira kaydı ne yapılacağını söylüyor ama nedenini söylemiyor; on dört sayfalık PRD ise nasıl görüneceğini söylüyor ama neden ve nasıl ölçüleceğini söylemiyor.

İskelet: Problem, Outcome, Non-Goal, Risk, Açık Soru

Bookstore ekibinin sepet terk çalışması için yazdığı one-pager'ın iskeleti ve her bölümün içeriği:

Tablodaki her satır serinin bir yazısına karşılık geliyor. Problem tanımı 02. yazıdaki dört parçalı şablondan, hedef outcome ve guardrail'ler 06. yazıdaki metric ağacından, kanıt 03., 07. ve 08. yazılardan, riskler 01. yazıdaki Cagan'ın dört riskinden geliyor. One-pager yeni bir düşünce üretmez; önceki adımlarda üretilen düşünceyi tek sayfada bir araya getirir. Bu yüzden discovery yapılmamış bir işin one-pager'ını yazmak zordur ve bu zorluk iyi bir sinyaldir.

Non-Goal'ların Değeri

Dokümanın en çok atlanan bölümü non-goal'lardır, ama ekibe en çok zaman kazandıran bölüm de odur. Non-goal, "bu çalışmanın kapsamında bilinçli olarak yapmayacağımız şey"dir ve iki işe yarar.

Birincisi kapsamın sessizce büyümesini engeller. "Kargo ücretini gösteriyorsak uluslararası siparişleri de ekleyelim" önerisi geldiğinde cevap yazılıdır ve tartışma bir toplantı sürmez. İkincisi beklentiyi yönetir. Genel müdürün one-click checkout fikri non-goal listesinde açıkça duruyor; bu, fikrin reddedildiği değil, bu çalışmanın konusu olmadığı anlamına geliyor ve kimse çalışma bittiğinde onun neden yapılmadığını sormuyor.

İyi bir non-goal, birinin makul olarak bekleyebileceği bir şeydir. "Bu çalışmada veritabanını MongoDB'ye taşımayacağız" bir non-goal değil, çünkü kimse bunu beklemiyordu. "Kargo ücretini düşürmeyeceğiz" ise iyi bir non-goal, çünkü görüşmelerde "kargo pahalı" diyen müşterileri okuyan biri bunu bekleyebilir.

Karardan Backlog'a

One-pager onaylandığında karar backlog'a dönüşür. Scrum ekibinde bu, Product Backlog'a bir epic ve onun altında Product Backlog item'ları demektir; Product Backlog'un mekaniği Scrum serisinin konusu. Burada önemli olan bölme biçimi: item'lar katmanlara göre değil, uçtan uca çalışan dilimlere göre bölünmeli. "Backend: kargo ücreti endpoint'i", "Frontend: ürün sayfası bileşeni" diye bölünen bir epic, ilk değer ancak her iki item bittiğinde ortaya çıkar. "İstanbul adresli kayıtlı müşteriye ürün sayfasında kargo ücretini göster" ise tek başına production'a çıkabilen ve ölçülebilen ince bir dilimdir.

Bookstore ekibinin epic'i bu yüzden şu sırayla bölündü: önce kayıtlı ve adresi bilinen müşteri için ürün sayfasında ücret, sonra adresi bilinmeyen misafir için varsayılan şehrin ücreti ve "şehrini seç" bağlantısı, sonra sepette aynı bilgi, en son ücretsiz kargo eşiği göstergesi. Her dilim, 07. yazıdaki event'lere experiment ve variant property'lerini ekleyen işi ve deney bittikten sonra flag'i kaldıracak temizlik item'ını da yanında getiriyor.

Bu bölmeyi görselleştirmenin yaygın bir yolu Jeff Patton'ın "User Story Mapping" (2014) kitabında anlattığı story map'tir: kullanıcının yolculuğu yatay eksende, her adımdaki işler dikey eksende, ilk sürüme girecekler bir çizginin üstünde. Story mapping'in ayrıntısı, user story yazımı ve acceptance criteria ilerideki Requirements Analysis serisinin konusu.

Geliştiricinin PRD Review'da Sorması Gerekenler

Bir one-pager ya da PRD ekibe geldiğinde, onu en dikkatli okuması gereken kişilerden biri geliştiricidir. Ürün sahibi problemi ve hedefi iyi bilir; edge case'leri, verinin nereden geldiğini ve sistemin nerede zorlanacağını ise en iyi kodu bilen görür. Bookstore ekibinin geliştiricilerinin review'da sorduğu sorular:

• Edge case: Sepette farklı satıcılardan ya da depolardan gelen kitaplar varsa kargo ücreti tek mi, ayrı ayrı mı hesaplanıyor? Ön sipariş kitaplarında durum ne?
• Veri: Ücret nereden geliyor; kargo firmasının API'sinden mi, bizim tablomuzdan mı? İkisi farklı çıkarsa hangisi doğru kabul ediliyor?
• Performans: Ürün sayfasının p95 yanıt süresi bir guardrail; ücret her sayfa açılışında hesaplanırsa bu hedef tutar mı, yoksa şehir bazında cache'lenmeli mi?
• Migration: Sipariş tablosunda gösterilen ücret ile tahsil edilen ücretin farkını izlemek için yeni bir kolon gerekiyor mu? Mevcut siparişler için değeri ne olacak?
• Rollout ve geri alma: Değişiklik flag arkasında mı çıkıyor, geri almak tek bir configuration değişikliği mi?
• Ölçüm ve gizlilik: Hangi event'ler ve property'ler gerekiyor, taxonomy'de var mı, içlerinde kişisel veri var mı?

Bu sorular dokümanı eleştirmek için değil, onu tamamlamak içindir. Her birinin cevabı ya dokümanın "Açık sorular" bölümüne girer ya da bir backlog item'ının acceptance criteria'sına. Review'da sorulmayan her soru, Sprint'in ortasında bir geliştiricinin ürün sahibine attığı bir mesaja dönüşür; daha pahalı ve daha geç.

Üretimde Dikkat

Doküman yaşar. One-pager onaylandığı gün dondurulmaz; açık sorular cevaplandıkça, deney sonuçları geldikçe güncellenir. Ama değişikliklerin izi kalmalı: dokümanın sonuna kısa bir karar günlüğü eklemek ("12 Kasım: misafir için varsayılan şehir İstanbul, çünkü misafir siparişlerinin en büyük payı İstanbul'a gidiyor") altı ay sonra "bunu neden böyle yapmıştık?" sorusunun cevabını verir.

Dokümanı backlog'dan erişilebilir kıl. Epic'in açıklamasında one-pager'ın bağlantısı olmalı; her item'ı okuyan geliştirici, iki tıkla nedenine ulaşabilmeli. Bir Architecture Decision Record'un kodla birlikte repository'de yaşaması gibi, ürün kararları da işin yapıldığı yerin yanında durmalı.

Bittiğinde kapat. Çalışma tamamlandığında one-pager'a bir sonuç bölümü eklenir: hedef outcome'a ulaşıldı mı, guardrail'ler ne durumda, neler öğrenildi. Bu bölüm bir sonraki çalışmanın kanıt bölümüne girer.

Sık Düşülen Tuzaklar

İlk tuzak PRD'yi bir sözleşme gibi kullanmak. Doküman "burada yazanı yap" diye ekibe verilir, ekip yazanı yapar, sonuç tutmazsa "dokümanda böyle yazıyordu" denir. Bu, 01. yazıdaki feature factory'nin doküman biçimidir. One-pager bir hizalanma aracıdır; ekip onu birlikte yazar ya da en azından birlikte gözden geçirir.

İkinci tuzak çözümle başlayan doküman. "Ürün sayfasına kargo ücreti ekleyeceğiz" cümlesiyle başlayan bir doküman, problemi ve hedefi sonradan gerekçe olarak ekler. Okuyan herkes çözümü sorgulamadan kabul eder. Dokümanın ilk bölümü her zaman problemdir.

Üçüncüsü ölçülemeyen success metric. "Kullanıcı deneyimini iyileştirmek" bir success metric değildir. Doküman, 06. yazıdaki metric tanımlarından birini ve hedef değerini içermiyorsa, çalışmanın başarılı olup olmadığını kimse söyleyemez.

Dördüncüsü kimsenin okumadığı uzun doküman. On dört sayfalık bir PRD'yi ekipte baştan sona okuyan genellikle yoktur ve önemli bir cümle yedinci sayfada kaybolur. İlk sayfa tek başına anlaşılır olmalı; ayrıntı eklerde durabilir.

Küçük Bir Deneme

★☆☆ Ekibinin son büyük işinin dokümanını (Jira epic'i, PRD, wiki sayfası) aç ve bu yazıdaki tablonun satırlarını ara. Hangi bölümler eksik? Özellikle non-goal ve success metric var mı?

★★☆ Ürünündeki bir problem için tek sayfalık bir one-pager yaz: problem (sayıyla), hedef outcome, success metric ve en az iki guardrail, en az üç non-goal, dört riskin her biri için bir cümle, açık sorular.

★★★ Ekibine gelecek bir sonraki PRD'yi bu yazıdaki altı soru başlığıyla review et ve her soruyu ya dokümanın açık sorular bölümüne ya da bir backlog item'ının acceptance criteria'sına yerleştir. Review'dan sonra kaç yeni item ya da criteria ortaya çıktı?

Seri burada bitiyor. "Kampanya modülü yapın" talebiyle başladık; output ile outcome'u ayırdık, problemi müşteriyle konuşarak anladık, fikirleri önceliklendirdik, roadmap'te paydaşlara anlattık, metric'leri tanımlayıp kodda ölçtük, deneyle karar verdik ve kararı backlog'a taşıdık. Bu adımların hiçbiri yalnız ürün yöneticisinin işi değil; her birinde geliştiricinin sorusu kararı daha iyi hâle getiriyor. Bu kararların nasıl aktığını ölçmek ve yönetmek ise Kanban serisinin konusu.