Issue tracker'ınızdan genel roadmap, üç sütun

Genel bir roadmap, inşa etmeyi planladığınız şeylerin, müşterilerin görebileceği bir yerde yayımlanmış bir listesidir. İşi yapan kelime planlıyorsunuz: bir roadmap, gelecek hakkında bir dizi sözdür, ve üzerindeki her öğe ya tutacağınız ya da tutmadığınızın görüleceği bir öğedir. Bir tane yayımlamanın nedeni budur, ve aynı zamanda çoğu genel roadmap’in bir çeyrek içinde eskimesinin de nedenidir. Hayatta kalan versiyon küçüktür, zaten sahip olduğunuz veriden türetilmiştir, ve diğer uçta changelog’a bağlıdır, böylece bir söz kimse onu yeniden girmeden bir gerçeğe dönüşür.

Genel bir roadmap ne için var?

Genel bir roadmap, isteği olan bir müşteriye, gönderilmeden önce isteğinin duyulduğunu söyler. Döngüyü kapatmanın erken yarısıdır: “Planlandı” “biri bunu okudu mu” sorusunu cevaplar, ve “İnşa ediliyor” “bu gerçekten oluyor mu” sorusunu cevaplar. Hiçbiri son adımın, gönderildiğinde isteyen kişiye söylemenin yerine geçmez, ama ikisi de bu arada soran insanların sayısını azaltır.

Aynı zamanda ekip için bir şey yapar: genel bir taahhüdü zorlar, ki bu kimsenin inşa etmeyeceği dört yüz öğeyi sessizce tutan bir backlog’a karşı bilinen en ucuz çaredir.

Sabit sırayla üç sütun yeterlidir. Dördüncü bir sütun (“değerlendiriliyor”, “inceleniyor”, “backlog”) iyi niyetlerin bir müzeye dönüştüğü yerdir, ve müşterilerin görmezden gelmeyi öğrendiği ilk sütundur.

Roadmap’iniz genel olmalı mı?

Küçük ve dürüst tutabiliyorsanız genel yapın; alternatif uzun bir belki listesiyse özel tutun. Genel bir roadmap’in maliyetinin onu yayımlamakla hiçbir ilgisi yoktur: üzerindeki her öğe artık birinin destekte, satış görüşmelerinde ve yenileme konuşmalarında soracağı bir sorudur. İnşa edeceğiniz on öğe bir varlıktır. İnşa edebileceğiniz altmış öğe, neden yapmadığınıza dair altmış gelecek konuşmasıdır.

Yayımlamamak için iki dürüst neden: planlarınız bir çeyrekten daha hızlı değişiyor, veya rekabetiniz roadmap’inizi müşterilerinizden daha dikkatli okuyor. İkisi de gerçek, ve ikisi de hiçbir şey yerine daha azını yayımlayarak cevaplanır: sadece “inşa ediliyor”, “planlandı” dahili tutularak, yine de isteyen bir kişiye issue’sunun hareket ettiğini söyler.

GitHub issue’larından genel bir roadmap nasıl inşa edilir?

Zaten takip ettiğiniz issue’lara sütun başına bir etiket koyun, ve etiketli issue’ları roadmap olarak görselleştirin. Hiçbir şey yeniden girilmez, roadmap işten uzaklaşamaz, ve bir müşteri isteği olarak başlayan aynı issue kimliğini değiştirmeden sütunlar arasında hareket eder.

Mekanizma, çalıştırdığımız şekliyle:

1. Sabit önek ile sütun başına bir etiket: roadmap:planned, roadmap:building, roadmap:shipped. Bağlı bir repository’de bunlardan birini taşıyan herhangi bir issue o sütunda görünür. Bunlardan hiçbirine sahip olmayan bir issue roadmap’te değildir, ki bu çoğu issue’dur, ki bu doğrudur.
2. Sütunlar sıralı bir dizidir, her zaman aynı sırada. Planlandı, inşa ediliyor, gönderildi. İsme göre indekslenmiş bir harita değil, böylece bir okuyucu (veya bir widget) sırayı asla tahmin etmek zorunda kalmaz.
3. Bir issue iki etiket taşıyorsa, en ileride olan kazanır. Biri roadmap:planned’ı kaldırmadan önce roadmap:shipped’ı ekleyecektir; “hangi webhook son geldi” tarafından yönlendirilen bir durum makinesi, teslimat sırasına bağlı olarak öğeyi farklı sütunlara koyardı. Sadece etiket kümesinden karar vermek, olayların nasıl geldiğinden bağımsız olarak cevabı aynı yapar.
4. Gönderildi, diğerleri gibi bir etiket durumudur. Kart, issue roadmap:shipped aldığında veya bu etiketi taşırken kapatıldığında taşınır. Kartın kendisi changelog girdisine bağlanmaz; ayrıntılar, issue’yu kapatan pull request’ten hazırlanan girdidedir.
5. Onu veri olarak sunun. Roadmap, aynı önbellek başlıklarıyla changelog akışının yanında yayımlanan bu üç sütunlu bir JSON belgesidir, böylece bir doküman sitesi, bir widget veya bir durum sayfası ikinci bir entegrasyon olmadan onu görselleştirebilir. Feed dokümantasyonu tam şeklini içerir.

Bir etiket, bir maintainer’dan istenecek küçük bir şeydir, ve tüm entegrasyon budur. Senkronize tutulacak bir pano yok, giriş yapılacak ayrı bir araç yok, ve müşterinin dosyaladığı istek roadmap’teki öğedir; gönderildiğinde, aynı öğedir.

Genel bir roadmap neyi içermemeli?

Dokuz ay sonra sorulmasından utanacağınız tarihleri, tahminleri, veya herhangi bir şeyi içermemelidir. Tarihler klasik hatadır: bir roadmap’teki bir çeyrek bir satış sunumunda bir taahhüde dönüşür, “Q3 dediniz” adında bir bilete dönüşür. Sütunlar yeterince söyler. “İnşa ediliyor” zaten “biri üzerinde olacak kadar yakında” anlamına gelir.

Ayrıca dahili backlog’u içermemelidir. Üç yüz öğesi olan bir roadmap bir söz değil bir arama sorunudur, ve isteğini 212. pozisyonda bulan müşteri ona söylemek istemediğiniz bir şey öğrenmiştir.

Roadmap changelog’a nasıl bağlanır?

Roadmap ve changelog aynı issue’ları iki taraftan anlatır, biri gelecek için biri geçmiş için. Kimse ayrı bir panoda kart taşımaz. Bir maintainer zaten üzerinde çalıştığı issue’nun etiketini değiştirir, girdi pull request’ten hazırlanır, ve bir insan o girdiyi onayladığında widget geri bildirimi o issue’ya dönüşen isteyen kişi orada bilgilendirilir. Kartı gönderildi’ye taşımak yine ayrı bir adımdır, roadmap:shipped etiketi, bu yüzden onu aynı incelemenin parçası yapın; girdiyi onaylamak bunu sizin yerinize yapmaz.

Bu, geri bildirim döngüsü makalesinin changelog tarafından tarif ettiği aynı döngüdür; roadmap müşterinin ortasında gördüğü şeydir. Changelog araçları özeti, hangi ürünlerin bir roadmap görünümü sunduğunu ve hangilerinin onu ayrı bir pano olarak ele aldığını kapsar, ki bu doğru kalıp kalmadığına karar veren farktır.

İyi bir genel roadmap nasıl görünür?

Kısa görünür, ve üzerindeki her öğe herkesin açabileceği bir issue’dur. Test, bir müşterinin bir öğeden arkasındaki tartışmaya, ve gönderilen bir öğeden gerçekte neyin değiştiğini tarif eden girdiye gidip gidemeyeceğidir. Girişi olmayan özellik isimlerinin bir listesi olan bir roadmap bir broşürdür.

Bir widget’ın getireceği JSON olarak işlenmiş bir örnek:

{
  "columns": [
    { "column": "planned", "hasMore": false, "items": [
      { "id": "6b0c1f...", "column": "planned",
        "publicTitle": "Saved views on the inbox",
        "publicDescription": "Keep a filter you use often and come back to it.",
        "publishedAt": "2026-09-16T10:04:11.000Z" }
    ]},
    { "column": "building", "hasMore": false, "items": [
      { "id": "71a4e2...", "column": "building",
        "publicTitle": "Roadmap column in the widget",
        "publicDescription": "See what is coming without leaving the page.",
        "publishedAt": "2026-09-12T08:20:02.000Z" }
    ]},
    { "column": "shipped", "hasMore": false, "items": [
      { "id": "5c9d70...", "column": "shipped",
        "publicTitle": "Feedback filed as labelled issues",
        "publicDescription": "Widget submissions arrive as issues your triage already handles.",
        "publishedAt": "2026-09-02T15:41:37.000Z" }
    ]}
  ],
  "enabled": true,
  "language": "en"
}

Üç sütunda üç öğe, mükemmel iyi bir genel roadmap’tir. Neyin geldiğini, neyin olduğunu, ve neyin olmuş olduğunu söyler, ve her satırı kontrol edilebilir. Now/Next/Later’dan sonuç bazlıya kadar beş başka düzen, örnek maddelerle ürün roadmap örnekleri yazısında gösteriliyor.

FAQ

Genel bir roadmap’te kaç öğe olmalı? Savunabileceğiniz kadar az. Tüm sütunlarda on’un altı küçük bir ürün için normaldir; “planlandı”da otuzdan fazlası genellikle bir roadmap kılığındaki bir backlog’dur.

Genel bir roadmap’te tarihler olmalı mı? Hayır. Sütunlar, bir son tarih yaratmadan sıra iletir. Bir müşterinin bir tarihe ihtiyacı varsa, bu bir konuşmadır, bir roadmap öğesi değil.

Müşteriler roadmap öğeleri için oy vermeli mi? Oylar kimin geldiğini ölçer, neyin önemli olduğunu değil. Bugün kullandıkları geçici çözümü açıklayan issue üzerindeki bir yorum, elli oydan daha değerlidir, ve oy verene bir şeye mal olur, ki bu önemli olan noktadır.

İptal edilen bir roadmap öğesine ne olur? Etiketi kaldırın ve issue üzerinde nedenini söyleyin. Genel bir “bunu yapmayacağız” döngünün bir parçasıdır, ve çoğu ekibin hiç göndermediği mesajdır.

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 araçları karşılaştırması