Lokakarya roadmap proyek menyelaraskan peserta pada urutan umum hasil, tonggak, dan ketergantungan yang diperlukan untuk mencapai tujuan proyek. Lokakarya menghasilkan pandangan bersama tentang arah dan keputusan penting. Tujuannya bukan menjadwalkan setiap tugas atau mengubah gagasan masa depan yang belum pasti menjadi janji pengiriman tersirat.
Roadmap menjawab, “Kemajuan penting apa yang berikutnya, dan mengapa?” Rencana proyek menjelaskan cara proyek akan dikelola, termasuk ruang lingkup dan keputusan. Jadwal mengoordinasikan aktivitas dan tanggal. Pertahankan perbedaan itu agar lokakarya tidak berakhir dengan garis waktu rapi yang menyembunyikan pilihan yang belum diselesaikan.
Agenda di bawah ini adalah pendekatan fasilitasi orisinal. Makalah PMI tentang perencanaan tonggak membahas perencanaan berdasarkan tonggak. Di sini, kondisi hasil yang dapat diamati dipakai agar roadmap lebih mudah ditinjau.
Tetapkan audiens dan rentang waktu
Tanyakan siapa yang membutuhkan roadmap dan keputusan apa yang perlu dibantu olehnya. Eksekutif mungkin perlu melihat pilihan investasi dan paparan utama. Tim pelaksana mungkin perlu memahami ketergantungan lintas tim. Pelanggan mungkin perlu kejelasan tentang perubahan yang dijanjikan. Pandangan ini bisa tumpang tindih, tetapi tidak dapat saling menggantikan.
Pilih rentang perencanaan yang sesuai dengan ketidakpastian. Pekerjaan terdekat dapat lebih spesifik daripada kemungkinan yang masih jauh. Gunakan legenda eksplisit seperti “komitmen,” “perkiraan,” dan “kandidat,” lengkap dengan definisi tiap label. Warna saja tidak cukup jika pembaca tidak tahu artinya.
Pisahkan tenggat nyata dari urutan yang diinginkan. Jika acara eksternal menetapkan tanggal, catat bukti dan konsekuensinya. Jika tanggal hanya perkiraan awal, beri label yang sesuai. Jangan biarkan kolom kuartal menyiratkan komitmen yang belum disetujui siapa pun.
Siapkan bukti, bukan jawaban yang sudah jadi
Bawa hasil proyek, batas yang diketahui, komitmen saat ini, ketergantungan utama, dan keputusan yang belum terselesaikan. Minta setiap peran peserta mengidentifikasi batasan dan asumsi sebelumnya. Undang orang yang dapat menjelaskan penerimaan operasional, kelayakan teknis, dan alasan bisnis pekerjaan tersebut.
Jangan kirim roadmap yang sudah diputuskan seluruhnya lalu menyebut pertemuannya lokakarya. Jika keputusan penting sudah diambil, jelaskan bagian mana yang masih terbuka. Dengan begitu, peserta dapat menggunakan waktu untuk menguji ketergantungan atau memperjelas penerimaan, bukan berpura-pura mencapai kesepakatan.
Papan kolaborasi bersama dapat mengumpulkan kartu hasil, risiko, dan pertanyaan. Jika Anda membutuhkan garis waktu terperinci atau perhitungan ketergantungan, simpan di sistem perencanaan proyek dan tautkan ke catatan lokakarya.
Lokakarya roadmap 90 menit
| Menit | Fokus | Pertanyaan |
|---|---|---|
| 0–10 | Tujuan dan wewenang | Keputusan apa yang dapat dibuat kelompok ini? |
| 10–25 | Hasil yang diinginkan | Kondisi bermanfaat apa yang harus terwujud? |
| 25–45 | Ketergantungan | Apa yang harus terjadi lebih dahulu, dan mengapa? |
| 45–60 | Kapasitas dan batasan | Urutan mana yang layak dengan peran yang tersedia? |
| 60–75 | Ketidakpastian dan opsi | Apa yang perlu ditemukan sebelum berkomitmen? |
| 75–90 | Keputusan dan komunikasi | Apa yang disepakati, sementara, atau belum selesai? |
Tuliskan kartu hasil dengan kondisi yang dapat diamati. “Laporan diluncurkan” terlalu samar. “Pimpinan dukungan dapat mencocokkan laporan mingguan dengan tiket sumber” dapat diperiksa. Tetapkan pemilik keputusan berikutnya, bukan daftar setiap orang yang mungkin berkontribusi.
Urutkan kartu menurut ketergantungan yang sebenarnya. Tanyakan apakah ketergantungannya teknis, operasional, regulasi, atau hanya preferensi lama. Sebagian pekerjaan dapat berjalan paralel; sebagian lainnya tidak. Sebutkan alasannya, bukan sekadar menggambar panah yang tidak dapat dijelaskan siapa pun.
Contoh lengkap: proyek pelaporan dengan pekerjaan kesiapan tersembunyi
Bayangkan organisasi hipotetis yang membangun kemampuan pelaporan dukungan. Roadmap awalnya menunjukkan “bangun,” “uji coba,” dan “luncurkan.” Pemangku kepentingan mengharapkan peluncuran luas begitu dasbor tersedia.
Dalam lokakarya, tim dukungan menemukan definisi kepemilikan eskalasi yang belum disepakati. Tim engineering menemukan pengenal tiket yang tidak konsisten. Tim operasi menanyakan siapa yang akan menyelidiki ketidakcocokan setelah peluncuran. Ini bukan tiga tugas kecil di dalam “bangun.” Semuanya memengaruhi apakah laporan dapat dipercaya dan dipelihara.
Roadmap revisi memiliki empat tonggak hasil: definisi kepemilikan disepakati; sampel sumber direkonsiliasi; uji coba digunakan dalam tinjauan nyata; pemeliharaan berkelanjutan diterima. Tim menandai tanggal uji coba sebagai perkiraan sampai rekonsiliasi data selesai. Tim mempertahankan fitur perkiraan masa depan sebagai item kandidat yang terpisah.
Contoh ini hanya ilustrasi, bukan hasil pelanggan. Intinya, roadmap yang bermanfaat menampilkan kesiapan dan kondisi keputusan, bukan menyamakan perangkat lunak yang terlihat dengan hasil bisnis yang selesai.
Salin kartu roadmap yang mencatat asumsinya
Gunakan bidang berikut untuk setiap item utama:
- Hasil: kondisi yang ingin diwujudkan proyek;
- Alasan: masalah pengguna atau bisnis yang ditangani;
- Bukti penerimaan: cara kondisi tersebut akan diperiksa;
- Ketergantungan: hal yang harus tersedia lebih dahulu;
- Keyakinan: komitmen, perkiraan, atau kandidat sesuai definisi yang disepakati;
- Pemilik keputusan: orang yang menyelesaikan pertanyaan penting berikutnya;
- Pemicu peninjauan: tanggal atau bukti yang mengharuskan keputusan dipertimbangkan ulang.
Simpan detail tugas di tempat lain. Jika setiap kartu berkembang menjadi puluhan subtugas, roadmap telah berubah menjadi pelacak pekerjaan. Tautkan rinciannya tanpa mewajibkan setiap pemangku kepentingan membacanya.
Catat juga hal yang sengaja tidak disertakan. Daftar singkat “bukan bagian dari tahap ini” mencegah gagasan menarik tetapi belum disetujui muncul kembali sebagai komitmen yang diasumsikan. Jika permintaan baru penting, nilai komprominya dan perbarui roadmap secara sadar.
Tinjau arah ketika bukti berubah
Pilih frekuensi tinjauan yang sesuai untuk proyek dan tambahkan pemicu berdasarkan peristiwa. Uji kelayakan yang gagal atau perubahan tenggat eksternal tidak seharusnya menunggu presentasi bulanan berikutnya. Jelaskan hasil atau urutan mana yang berubah dan bukti apa yang melandasi keputusan itu.
Setelah tonggak, adakan retrospektif agile untuk memeriksa perilaku perencanaan: apakah ketergantungan dikenali cukup awal? Apakah label keyakinan memiliki arti sama bagi semua orang? Apakah roadmap membantu orang mengambil keputusan atau sekadar menenangkan mereka?
Pilih format sederhana dari ide retrospektif dan kaitkan diskusi dengan keputusan roadmap yang nyata. Jangan menilai roadmap hanya berdasarkan apakah setiap tanggal awal tetap berlaku. Roadmap yang baik dapat berubah karena tim mempelajari sesuatu yang penting.
Pertanyaan yang sering diajukan
Apakah roadmap perlu mencantumkan tanggal?
Kadang-kadang. Tenggat nyata dan komitmen yang perlu dikoordinasikan membutuhkan waktu yang terlihat. Pekerjaan yang belum pasti mungkin lebih baik disampaikan melalui urutan dan tingkat keyakinan. Format apa pun yang dipilih, bedakan perkiraan dari janji.
Siapa yang perlu hadir di lokakarya roadmap?
Libatkan orang yang memahami hasil yang dituju, batasan pelaksanaan, ketergantungan, dan penerimaan. Perjelas kewenangan untuk mengambil keputusan. Jika pengambil keputusan penting tidak hadir, catat rekomendasi alih-alih berpura-pura kelompok telah menyetujui komitmen.
Apa perbedaan roadmap dengan backlog?
Roadmap menyampaikan arah dan hasil utama dari waktu ke waktu. Backlog memuat pekerjaan atau opsi berurutan dengan tingkat detail lebih tinggi. Hubungkan keduanya agar pekerjaan mendukung hasil, tetapi jangan berharap roadmap menggantikan koordinasi pelaksanaan sehari-hari.