Pemetaan proyek adalah praktik untuk memperjelas hubungan penting dalam proyek: bagaimana pekerjaan terhubung dengan hasil, deliverable mana yang bergantung pada hal lain, siapa yang berkontribusi, dan keputusan mana yang masih dibutuhkan. Istilah ini tidak menggambarkan satu diagram universal. Pilih peta berdasarkan pertanyaan yang perlu dijawab.
Peta proyek berguna ketika orang dapat membuat daftar tugas, tetapi tidak dapat menjelaskan keterkaitan tugas tersebut. Peta juga dapat mengungkap dua tim yang memakai nama proyek sama tetapi mengharapkan hasil berbeda. Peta membantu menampakkan perbedaan pendapat sebelum jadwal terperinci memberinya kepastian semu.
Pilih peta berdasarkan keputusan
| Pertanyaan | Peta yang berguna | Hal yang tidak digantikannya |
|---|---|---|
| Mengapa kita mengerjakan ini? | Peta hasil ke deliverable | Bukti bahwa hasil itu penting |
| Apa yang harus terjadi lebih dulu? | Peta dependensi | Jadwal dan rencana sumber daya yang dipelihara |
| Siapa yang perlu berkontribusi? | Peta pemangku kepentingan atau peran | Pelibatan nyata dan kepemilikan yang diterima |
| Bagaimana pekerjaan bergerak dalam proses? | Peta proses atau alur kerja | Pengamatan terhadap pengecualian dan praktik sebenarnya |
| Apa yang termasuk dalam batas proyek? | Peta cakupan | Proses pengambilan keputusan untuk perubahan |
Jangan gabungkan semua tampilan ke satu kanvas. Diagram dengan puluhan jenis panah mungkin lebih sulit digunakan daripada beberapa catatan terkait. Mulailah dengan satu pertanyaan yang menimbulkan ketidakpastian.
Tentukan hasil sebelum memetakan deliverable
Tuliskan perubahan yang diinginkan dalam satu kalimat. Lalu bedakan hasil dari keluaran. Formulir, layanan, atau laporan yang diserahkan adalah keluaran. Perubahan berguna pada hal yang dapat dilakukan seseorang adalah hasil yang membutuhkan bukti.
Panduan discovery GOV.UK menyarankan pemahaman tentang perjalanan pengguna yang lebih luas dan tim atau layanan di sekitar masalah. Ini adalah konteks yang relevan untuk memetakan batas proyek; panduan itu tidak menetapkan lokakarya khusus di bawah ini.
Tanyakan keluaran mana yang secara masuk akal mendukung hasil. Jika alur kerja tidak memiliki hubungan yang jelas, mungkin itu pekerjaan pendukung penting, asumsi yang belum diuji, atau cakupan yang tidak diperlukan. Beri label pada hubungan sebelum memutuskan apakah akan mempertahankannya.
Susun peta proyek awal dalam lima putaran
- Tempatkan hasil di bagian atas. Sertakan kelompok terdampak dan sinyal yang akan diperiksa.
- Tambahkan deliverable utama. Gunakan hasil yang dapat diamati, bukan nama aktivitas seperti “mengerjakan integrasi.”
- Hubungkan dependensi. Beri label apa yang dibutuhkan satu item dari item lain.
- Tambahkan pemilik dan keputusan. Tunjukkan siapa yang mengoordinasikan tiap hasil dan pilihan mana yang masih terbuka.
- Tandai ketidakpastian. Bedakan hubungan yang dikonfirmasi dari asumsi yang membutuhkan bukti.
Hindari tanggal pada putaran pertama kecuali benar-benar menjadi kendala. Tanggal awal dapat memengaruhi diskusi sebelum cakupan dan dependensi dipahami. Tambahkan waktu setelah hubungan cukup jelas untuk mendukungnya.
Contoh lengkap: perubahan akun mandiri
Contoh hipotetis: tim ingin pelanggan menyelesaikan perubahan akun rutin tanpa serah terima ke dukungan. Daftar tugas awal berisi desain antarmuka, pekerjaan API, konten bantuan, analitik, dan pengumuman peluncuran.
Peta hasil mengungkap pekerjaan yang hilang. API bergantung pada keputusan tentang siapa yang berwenang meminta perubahan. Konten bantuan bergantung pada pemahaman tentang pengecualian. Kesiapan dukungan bergantung pada pengetahuan tentang kasus yang tetap berada di luar layanan mandiri.
Tim menggambar tiga hubungan secara eksplisit:
| Hasil | Bergantung pada | Keputusan atau bukti yang dibutuhkan |
|---|---|---|
| Alur perubahan akun yang dapat digunakan | Aturan otorisasi | Konfirmasikan siapa yang boleh melakukan perubahan |
| Jalur pengecualian yang jelas | Kasus yang tidak didukung dan sudah diketahui | Telusuri kasus tepi yang mewakili |
| Pengukuran hasil | Peristiwa penyelesaian yang terdefinisi | Sepakati hal yang dihitung sebagai tugas selesai |
Ini mengubah rencana langsung. Alih-alih memulai semua alur kerja sekaligus, tim menyelesaikan pertanyaan otorisasi dan memeriksa kasus pengecualian lebih dulu. Eksplorasi antarmuka dapat berlanjut, tetapi diberi label sementara.
Peta tidak membuktikan implementasi mana yang terbaik. Peta menunjukkan keputusan mana yang memengaruhi beberapa bagian pekerjaan sehingga perlu mendapat perhatian awal.
Beri makna pada panah dependensi
Beri label kontribusi pada tiap panah: keputusan, data, lingkungan, peninjauan, antarmuka, atau kemampuan operasional. “Tim B” bukan deskripsi dependensi. “Tim B mengonfirmasi aturan kepemilikan akun” adalah deskripsi.
Untuk dependensi eksternal, catat apakah kontribusinya sudah diminta atau diterima. Peta Anda tidak dapat membuat komitmen atas nama tim lain. Sebutkan kontak, tanggal terakhir yang berguna, dan apa yang terjadi jika kontribusi berubah.
Pisahkan dependensi logis dari urutan yang disukai. Dua item dapat dijadwalkan berurutan karena dikerjakan orang yang sama, padahal secara teknis tidak saling bergantung. Perbedaan itu penting saat tim mempertimbangkan alternatif.
Selenggarakan lokakarya pemetaan proyek 45 menit
Mulai dengan lima menit membaca ringkasan proyek dalam diam. Habiskan sepuluh menit untuk meminta peserta menulis keluaran utama secara terpisah. Bandingkan daftar sebelum menghubungkannya; perbedaan mungkin menunjukkan asumsi cakupan yang belum terselesaikan.
Gunakan lima belas menit untuk menggambar dan memberi label pada hubungan. Sisihkan sepuluh menit untuk menantang asumsi dengan konsekuensi terbesar dan lima menit untuk menetapkan langkah bukti atau keputusan berikutnya.
Sediakan area khusus untuk detail yang tidak mengubah tujuan peta. Rincian implementasi lengkap dapat dibuat nanti dalam sistem pengiriman tim. Lokakarya harus selesai dengan keputusan berikutnya yang lebih jelas, bukan sekadar kanvas lebih besar.
Minta seseorang yang akan mengoperasikan hasil memeriksa peta. Tanyakan apa yang dapat gagal pada hari pertama setelah peluncuran. Pertanyaan itu dapat mengungkap pekerjaan dukungan, pemantauan, serah terima, dan pemeliharaan yang hilang dari gambaran berpusat pada pengiriman.
Ubah peta menjadi rencana yang dipelihara
Pilih satu tempat resmi untuk peta dan catat tanggal serta pemiliknya. Tautkan deliverable ke pelacak kerja alih-alih menyalin setiap tugas ke diagram. Simpan keputusan penting dalam log keputusan beserta alasan dan pemiliknya.
Perbarui peta ketika batas, dependensi, atau asumsi berubah. Peta yang hanya dipakai saat kickoff menjadi gambaran historis. Peta yang dipelihara membantu menjelaskan alasan rencana saat ini berbeda dari rencana awal.
Gunakan retrospektif agile untuk memeriksa cara tim berkoordinasi dengan bantuan peta. Tanyakan dependensi mana yang terlihat terlambat atau keluaran mana yang tidak dapat dihubungkan siapa pun dengan hasil. Kumpulkan pengamatan dalam format retrospektif sederhana, lalu uji satu perbaikan melalui proses tindak lanjut retrospektif.
Kesalahan yang membuat peta proyek menyesatkan
Hanya memetakan departemen. Label departemen dapat menyembunyikan keputusan, informasi, atau layanan yang sebenarnya dibutuhkan. Sebutkan kontribusinya.
Memperlakukan peta sebagai jadwal. Hubungan membantu perencanaan, tetapi tidak menentukan durasi, ketersediaan, atau keyakinan pada suatu tanggal.
Menampilkan semua asumsi sebagai fakta pasti. Gunakan label yang jelas dan daftar langkah pengumpulan bukti. Tampilan rapi jangan menghapus ketidakpastian.
Memasukkan semua detail yang mungkin. Jaga agar peta sesuai dengan pertanyaannya. Jika pembaca tidak dapat menemukan keputusan berikutnya, pisahkan tampilan atau hapus detail yang seharusnya berada di tempat lain.
Pertanyaan yang sering diajukan
Apakah pemetaan proyek sama dengan pemetaan pikiran?
Peta pikiran dapat membantu menghasilkan ide seputar topik. Peta proyek biasanya membutuhkan hubungan eksplisit seperti kontribusi, dependensi, kepemilikan, atau cakupan agar mendukung keputusan pengiriman.
Dapatkah peta proyek menggantikan rencana proyek?
Peta dapat mendukung dan menyederhanakan perencanaan, tetapi tidak menggantikan jadwal, keputusan sumber daya, manajemen risiko, atau catatan tata kelola yang diwajibkan. Gunakan peta untuk menjelaskan hubungan yang menjadi dasar catatan tersebut.
Apa yang harus dipetakan lebih dulu jika proyek belum jelas?
Mulailah dengan masalah, kelompok terdampak, dan hasil yang diinginkan. Jika hal-hal itu diperdebatkan, selidiki terlebih dahulu sebelum membuat peta terperinci dari deliverable yang masih diasumsikan.