Ürün roadmap şablonu: kopyalayıp doldurulacak alanlar

Ürün roadmap şablonu, her satırın bir madde, her sütunun da dolu tutmayı vaat ettiğiniz bir alan olduğu kısa bir tablodur. Çoğu küçük ekipte işe yarayan sürüm altı alandan oluşur: sonuç, kimin istediği, durum, sahip, güven düzeyi ve gözden geçirme tarihi. İndirilebilir şablonlarda gördüğünüz geri kalan her şey, yani swimlane’ler, story point’ler ve çeyrek sütunları, isteğe bağlıdır ve roadmap’in güncellenmeyi bırakmasının genellikle asıl nedenidir.

Bir ürün roadmap şablonu neleri içermelidir?

Yalnızca okuyucunun karar vermek için kullandığı alanları ekleyin ve bir alanı ancak onu kimin okuyacağını söyleyebiliyorsanız ekleyin. Sonuç, satırın var olma nedenidir. Kaynak, bir müşterinin kendi talebini orada bulmasını sağlar. Durum, işin ilerleyip ilerlemediğini söyler. Sahip, soru sorulacak kişidir. Güven, bir tahminin söz gibi okunmasını engeller. Gözden geçirme tarihi de satırın bayatlamasını önler.

Ekibiniz isterse iki alan daha eklemeye değer. Tablonun yanında tutulan bir “yapmayacağız” listesi, neye karşı karar verdiğinizi ve nedenini kaydeder, böylece aynı tartışmayı her çeyrekte yeniden yapmazsınız. “Son değişiklik” sütunu satırın ne zaman düzenlendiğini gösterir, böylece okuyucu güncel bir roadmap’i terk edilmiş olandan ayırabilir.

İlk sürümde dışarıda bırakılacak alanlar: gözden geçirme tarihinin ötesindeki tarihler, efor tahminleri, story point’ler ve gelir tahminleri. Bunlar planlama belgelerine aittir; orada kimse onları taahhüt diye okumadan değişebilirler.

Dolu bir ürün roadmap şablonu nasıl görünür?

Aşağıda ürün olarak uydurma bir görev uygulaması kullanılan tablo var. Tüm maddeler kurgudur ve durum sütunu yalnızca üç değer kullanır.

İki satır dersi taşıyor. “Çevrimdışı mod” satırında sahip yok ve güven düşük; bu, “bunu düşünüyoruz” demenin dürüst bir yolu. “Bitiş tarihlerini toplu düzenleme” silinmek yerine kapatılmış, böylece isteyen müşteriler onun nereye gittiğini hâlâ bulabilir.

Düz metni tercih ederseniz aynı tablo depoda bir Markdown dosyası olarak da çalışır ve işin yanında sürüm kontrolünde durur:

| Outcome | Source | Status | Owner | Confidence |
|---|---|---|---|---|
| Keep the last filter | 14 requests | Building | Dana | Committed |
| Company SSO sign-in | 9 requests | Planned | Marcus | Forecast |

Şablon hangi formatı kullanmalı?

Roadmap’inizde on madde veya daha azı varsa ve okuyucular ayrıntı istiyorsa tablo kullanın. Sık yön değiştiriyorsanız ve tarih savunmak istemiyorsanız Now, Next ve Later olmak üzere üç sütun kullanın. Now/Next/Later düzeni, zaman çizelgesi ve tema bazlı düzenlerle birlikte Atlassian’ın ürün roadmap’leri rehberinde anlatılıyor.

Yukarıdaki tablo ile üç sütunlu bir pano aynı veriyi tutar. Tablo roadmap’in içinde çalışanlar için, pano ise ona göz gezdirenler için daha iyidir. Ürün roadmap örnekleri yazısı gerçekçi maddelerle altı formatı gösterir ve her birinin nasıl başarısız olduğunu anlatır; alanlar netleştikten sonra düzeni oradan seçebilirsiniz.

Şablonu tahmin yürütmeden nasıl doldurursunuz?

Elinizdeki taleplerle başlayın ve sonucu en son yazın. Açık talepleri anlattıkları soruna göre gruplayın, sayın ve sayıyı kaynak sütununa yazın. Kaynağı olmayan bir satır görüştür; görüşe izin var, ama görüş gibi görünmeli.

Sonra satırları bir müşteriye açıklayabileceğiniz bir kurala göre sıralayın. Özellik taleplerine öncelik vermek yazısı puanlama yöntemlerini ve yalnızca oyların neden yanıltıcı olduğunu ele alır. Satırların sırası “önce ne gelir” sorusunun cevabıdır, durum sütunu ise “ne oluyor” sorusunun.

Güveni dürüstçe yazın. Taahhüt satırı, ekibin o pencerede yayımlamamasına şaşıracağı anlamına gelir. Tahmin satırı, bir şey değişmedikçe plan budur demektir. Araştırma satırı hiçbir söz olmadığı anlamına gelir; müşterilere araştırma satırları gösteren bir roadmap bu kelimenin ne demek olduğunu da söylemelidir.

Şablonu ne sıklıkla güncellemelisiniz?

Bir madde durum değiştirdiğinde güncelleyin ve her satırı gözden geçirme tarihinde kontrol edin. Güncelleme ayrı bir iş olduğunda roadmap bayatlar, o yüzden onu işin zaten olduğu yerde tutun. Doğruluk kaynağınız issue tracker’sa durum sütununu etiketler yönetebilir ve kimse hiçbir şeyi yeniden yazmaz. Genel bir roadmap dürüst nasıl kalır yazısı, Changeloop’un kullandığı sütun başına bir etiket düzenini gösterir.

Bir satır yayımlandığında isteyenlere haber verin. Hiçbir şablon alanı bunu sizin yerinize yapamaz ve kaynak sütununu tutmanın nedeni de budur. Müşteri geri bildirim döngüsü yazısı, talepten duyuruya kadar olan tüm yolu anlatır.

Şablon herkese açık olmalı mı?

Müşterilerin taleplerinin duyulduğunu görmesini istiyorsanız küçültülmüş bir sürüm yayımlayın. Herkese açık şablon sonuç ile durumu tutar; sahip, güven ve gözden geçirme tarihini bırakır. Bir satış görüşmesinde savunmayacağınız her şeyi de bırakır. Güncel kalan kısa bir liste, sessizleşen uzun bir listeden güven açısından daha çok iş görür; ProdPad’in şablon sayfası bir satıcının kendi şablonunu nasıl yapılandırdığını gösteriyor.

FAQ

Ürün roadmap şablonu nedir? Sonuç, durum, sahip ve güven gibi her roadmap maddesi için sabit bir alan kümesi içeren, yeniden kullanılabilir bir tablo veya panodur. Kopyalarsınız, madde başına bir satır doldurur ve güncel tutarsınız.

Bir ürün roadmap’inde hangi sütunlar olmalı? En azından bir sonuç, bir durum ve bir sahip. Roadmap’te bir avuçtan fazla madde olduğunda talebin kaynağını, bir güven düzeyini ve bir gözden geçirme tarihini ekleyin.

Bir ürün roadmap’inde tarihler olmalı mı? Çoğu ekip için yalnızca gözden geçirme tarihi. Takvim tarihleri satışın ve müşterilerin size geri alıntıladığı taahhütlere dönüşür; onun yerine bir güven etiketi ve Now, Next, Later gibi bir zaman penceresi kullanın.

Roadmap’i bir hesap tablosunda veya Markdown dosyasında tutabilir miyim? Evet. Hesap tablosu birlikte düzenleyen bir ekibe, depodaki Markdown tablosu ise sürüm kontrolü isteyen bir ekibe uyar. İşin zaten takip edildiği yeri seçin, böylece güncellemeler ayrı bir angarya olmaz.

Bu yazıdaki teknik iddialar bağımsız olarak kontrol edilmedi. Yanlış bir şey varsa bize söyle, düzeltelim.

changeloop'ta ilgili sayfalar: Geliştirici dokümantasyonu, Changelog örnekleri