Roadmap publik dari issue tracker Anda, tiga kolom

Roadmap publik adalah daftar apa yang Anda niatkan untuk dibangun, diterbitkan di tempat yang bisa dilihat pelanggan. Kata yang melakukan pekerjaan itu adalah niatkan: roadmap adalah kumpulan janji tentang masa depan, dan setiap item di dalamnya adalah yang akan Anda tepati atau akan terlihat tidak Anda tepati. Itulah alasan untuk menerbitkannya, dan itu juga alasan mengapa kebanyakan roadmap publik menjadi usang dalam satu kuartal. Versi yang bertahan itu kecil, diturunkan dari data yang sudah Anda pelihara, dan terhubung di ujung lain ke changelog, sehingga janji menjadi fakta tanpa ada yang memasukkannya kembali.

Untuk apa roadmap publik?

Roadmap publik memberi tahu pelanggan dengan permintaan bahwa permintaan mereka didengar, sebelum dirilis. Itu setengah awal dari menutup lingkaran: “Direncanakan” menjawab pertanyaan “apakah ada yang membaca ini”, dan “Sedang dibangun” menjawab “apakah ini benar-benar terjadi”. Tidak ada yang menggantikan langkah terakhir, memberi tahu peminta saat dirilis, tapi keduanya mengurangi jumlah orang yang bertanya sementara itu.

Ini juga melakukan sesuatu untuk tim: memaksa komitmen publik, yang merupakan obat termurah yang diketahui melawan backlog yang diam-diam menyimpan empat ratus item yang tidak akan dibangun siapa pun.

Tiga kolom, dalam urutan tetap, sudah cukup. Kolom keempat (“dipertimbangkan”, “sedang ditinjau”, “backlog”) adalah tempat niat baik berubah menjadi museum, dan itu yang pertama dipelajari pelanggan untuk diabaikan.

Haruskah roadmap Anda publik?

Buat publik jika Anda bisa menjaganya tetap kecil dan jujur; jaga tetap privat jika alternatifnya adalah daftar panjang mungkin-mungkin. Biaya roadmap publik tidak ada hubungannya dengan menerbitkannya: setiap item di dalamnya sekarang menjadi pertanyaan yang akan ditanyakan seseorang, dalam dukungan, dalam panggilan penjualan dan dalam percakapan perpanjangan. Sepuluh item yang akan Anda bangun adalah aset. Enam puluh item yang mungkin Anda bangun adalah enam puluh percakapan masa depan tentang mengapa tidak.

Dua alasan jujur untuk tidak menerbitkan: rencana Anda berubah lebih cepat dari satu kuartal, atau kompetisi Anda membaca roadmap Anda lebih hati-hati daripada pelanggan Anda. Keduanya nyata, dan keduanya dijawab dengan menerbitkan lebih sedikit alih-alih tidak sama sekali: hanya “sedang dibangun”, dengan “direncanakan” disimpan secara internal, tetap memberi tahu peminta bahwa issue mereka bergerak.

Bagaimana cara membangun roadmap publik dari issue GitHub?

Letakkan satu label per kolom pada issue yang sudah Anda lacak, dan render issue berlabel sebagai roadmap-nya. Tidak ada yang dimasukkan ulang, roadmap-nya tidak bisa menyimpang dari pekerjaannya, dan issue yang sama yang dimulai sebagai permintaan pelanggan bergerak melalui kolom tanpa mengubah identitasnya.

Mekanismenya, seperti yang kami jalankan:

1. Satu label per kolom, dengan awalan tetap: roadmap:planned, roadmap:building, roadmap:shipped. Issue mana pun di repositori yang terhubung yang membawa salah satunya muncul di kolom itu. Issue tanpa salah satu dari itu tidak ada di roadmap, yang merupakan kebanyakan issue, yang benar.
2. Kolom-kolomnya adalah array terurut, selalu dalam urutan yang sama. Direncanakan, sedang dibangun, dirilis. Bukan peta yang diindeks berdasarkan nama, sehingga pembaca (atau widget) tidak pernah harus menebak urutannya.
3. Jika issue membawa dua label, yang paling maju yang menang. Seseorang akan menambahkan roadmap:shipped sebelum menghapus roadmap:planned; mesin status yang dipandu oleh “webhook mana yang tiba terakhir” akan menempatkan item di kolom berbeda tergantung urutan pengiriman. Memutuskan hanya dari kumpulan label membuat jawabannya sama terlepas dari bagaimana peristiwa tiba.
4. Dirilis adalah status label seperti yang lain. Kartu berpindah saat issue mendapat roadmap:shipped, atau ditutup selagi membawa label itu. Kartu itu sendiri tidak menautkan ke entri changelog; detailnya ada di entri, yang disusun dari pull request yang menutup issue.
5. Sajikan sebagai data. Roadmap-nya adalah dokumen JSON dengan tiga kolom itu, diterbitkan di samping feed changelog dengan header cache yang sama, sehingga situs dokumen, widget atau halaman status bisa merendernya tanpa integrasi kedua. Dokumentasi feed punya bentuk pastinya.

Label itu hal kecil yang diminta dari maintainer, dan itu seluruh integrasinya. Tidak ada papan untuk dijaga tetap sinkron, tidak ada alat terpisah untuk login, dan permintaan yang diajukan pelanggan adalah item di roadmap; saat dirilis, itu item yang sama.

Apa yang tidak boleh dimuat roadmap publik?

Tidak boleh memuat tanggal, estimasi, atau apa pun yang akan membuat Anda malu jika ditanyakan sembilan bulan kemudian. Tanggal adalah kesalahan klasik: satu kuartal di roadmap menjadi komitmen di dek penjualan menjadi tiket bernama “kalian bilang Q3”. Kolom-kolom sudah cukup mengatakan. “Sedang dibangun” sudah berarti “cukup segera sehingga ada yang mengerjakannya”.

Juga tidak boleh memuat backlog internal. Roadmap dengan tiga ratus item adalah masalah pencarian, bukan janji, dan pelanggan yang menemukan permintaannya di posisi 212 sudah mempelajari sesuatu yang tidak ingin Anda katakan kepadanya.

Bagaimana roadmap terhubung ke changelog?

Roadmap dan changelog menggambarkan issue yang sama dari dua sisi, satu untuk masa depan dan satu untuk masa lalu. Tidak ada yang memindahkan kartu di papan terpisah. Maintainer mengubah label di issue yang memang sedang dikerjakannya, entrinya disusun dari pull request, dan saat seseorang menyetujui entri itu, peminta yang umpan balik widget-nya menjadi issue tersebut diberi tahu di sana. Memindahkan kartu ke dirilis tetap langkah tersendiri, label roadmap:shipped, jadi jadikan bagian dari tinjauan yang sama; menyetujui entri tidak melakukannya untuk Anda.

Ini lingkaran yang sama yang dijelaskan artikel lingkaran umpan balik dari sisi changelog; roadmap adalah apa yang dilihat pelanggan di tengah-tengahnya. Rangkuman alat changelog mencakup produk mana yang menawarkan tampilan roadmap dan mana yang memperlakukannya sebagai papan terpisah, yang merupakan perbedaan yang menentukan apakah tetap akurat.

Seperti apa roadmap publik yang baik?

Terlihat singkat, dan setiap item di dalamnya adalah issue yang bisa dibuka siapa pun. Tesnya adalah apakah pelanggan bisa pergi dari sebuah item ke diskusi di baliknya, dan dari item yang dirilis ke entri yang menjelaskan apa yang benar-benar berubah. Roadmap yang berupa daftar nama fitur tanpa jalan masuk adalah brosur.

Contoh yang dikerjakan, sebagai JSON yang akan diambil widget:

{
  "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"
}

Tiga item di tiga kolom adalah roadmap publik yang sangat baik. Mengatakan apa yang akan datang, apa yang sedang terjadi, dan apa yang sudah terjadi, dan setiap barisnya bisa diperiksa. Lima tata letak lain, dari Now/Next/Later sampai berbasis hasil, ditampilkan dengan item contoh di contoh roadmap produk.

FAQ

Berapa banyak item yang seharusnya dimiliki roadmap publik? Sesedikit yang bisa Anda pertahankan. Di bawah sepuluh secara total itu normal untuk produk kecil; lebih dari tiga puluh di “direncanakan” biasanya backlog yang menyamar sebagai roadmap.

Haruskah roadmap publik punya tanggal? Tidak. Kolom-kolom mengomunikasikan urutan tanpa menciptakan tenggat waktu. Jika pelanggan membutuhkan tanggal, itu percakapan, bukan item roadmap.

Haruskah pelanggan memilih item roadmap? Voting mengukur siapa yang muncul, bukan apa yang penting. Komentar di issue yang menjelaskan solusi sementara yang mereka gunakan hari ini bernilai lebih dari lima puluh suara, dan itu memberi biaya bagi pemberi suara, yang menjadi intinya.

Apa yang terjadi pada item roadmap yang dibatalkan? Hapus labelnya dan katakan alasannya di issue. “Kami tidak akan melakukan ini” yang publik adalah bagian dari lingkaran, dan itu pesan yang tidak pernah dikirim kebanyakan tim.

Klaim teknis dalam artikel ini belum ditinjau secara independen. Jika ada yang keliru, beri tahu kami dan kami akan memperbaikinya.

Terkait di changeloop: Dokumentasi developer, Perbandingan alat changelog