Blog KaryaVirtual

Gudang Pengetahuan Digital

Buy-in semua orang dengan Roadmap Anda

January 23, 2020 Product Management 0

Presentasi dari roadmap dapat membuat grogi untuk baik developer dan manajer produk; salah satu pihak telah bekerja keras untuk datang dengan sebuah visi sementara pihak lain menunggu untuk melihat yang tidak diketahui yang akan mempengaruhi pekerjaan mereka.

Aku merasa ketegangan ini ketika saya bekerja sebagai seorang developer dan saya sering mendapati diriku tidak puas dengan manajemen produk roadmap  . Aku tidak sepenuhnya teryakinkan dalam keputusannya, dan aku sering berjalan keluar dari pertemuan perencanaan dengan sentimen “Yah, ini tidak masuk akal bagi saya, tetapi jika mereka berpikir begitu…”, atau bahkan lebih buruk, sebuah “kita harus mencari tahu hal diri kita sendiri dan membuatnya fits dengan roadmap.

Anda mungkin berpendapat masalah itu mungkin saya menderita NIH (Not Invented Here Syndrome) dan Anda mungkin benar. Sebagai seorang developer, saya memiliki pendapat yang sangat kuat pada apa yang benar untuk dilakukan. Tapi sekarang sebagai manajer produk, saya melihat apa yang menyebabkan ini seperti disconnect, dan apa  product manger dapat pelajari dari disconnection ini untuk memukul homerun dengan presentasi Roadmap berikutnya. Setelah semua, jika tim teknis setuju dengan dan memahami gambaran besar, hari-hari desain dan keputusan pelaksanaan akan dibuat dengan konteks yang tepat, dan Anda akan mendapatkan produk yang Anda bayangkan.

1. Pilih substansi lebih dari Buzzwords

Sementara Buzzwords seperti “analitik data besar”, “pembelajaran mesin”, atau “Internet of Things Initiative (IoT)” mungkin beresonansi dengan pemangku kepentingan bisnis  , mereka tidak membantu dan dapat ditindaklanjuti item untuk tim teknis. Engineering perlu tahu persis apa yang mereka sedang dibangun, bagaimana kaitannya dengan produk saat ini, bagaimana harus disampaikan, dan siapa yang akan menggunakannya pada akhirnya, dan untuk tujuan apa.

Menetapkan tema tingkat tinggi sangat bagus untuk menyusun roadmap dan konteks, tetapi pastikan Anda tidak berhenti di sana dan memiliki jawaban yang baik untuk apa yang ada di balik setiap item tingkat tinggi. Misalnya, jika Anda telah menggunakan tema “Intelligent theme” tema, pastikan untuk memecah ini menjadi key initiatives dan epics yang diperlukan agar dapat menghasilkan tema ini.

2. Atur konteks yang tepat

Tim teknis membutuhkan konteks untuk mengapa Anda membangun sesuatu pada roadmap. Tidak ada tim teknis yang akan mengatakan, “katakan saja apa yang Anda inginkan dan saya akan membangunnya.” Sebaliknya, para enginner perlu melihat bukti mengapa ada permintaan untuk sebuah fitur. Biarkan data berbicara, tetapi juga menceritakan sebuah cerita yang kuat dari perspektif pengguna Anda. Gunakan Personas, dan berbicara tentang beberapa alternatif yang Anda telah dikecualikan, dan mengapa. Untuk membantu seluruh tim memahami roadmap “Mengapa” penting seperti “apa.”

3. Pertimbangkan komitmen dengan cermat

Jika sebuah fitur tampaknya tidak dipikirkan dengan baik atau realistis, namun masih dalam Roadmap, ini harus menjerit bendera merah. Anda tidak ingin tim teknis mendapatkan kesan bahwa mereka harus membangun barang hanya karena Anda berjanji kepada seseorang. Ini bisa menjadi komitmen untuk pelanggan atau karena karena “manajemen menginginkannya.” Jadi bijaksana tentang membuat komitmen. Bahkan jika Anda memiliki fungsi memaksa di belakang diri Anda yang memerlukan perubahan tertentu, pastikan Anda memahami dan meneruskan alasan untuk tim.

4. membuat rencana yang realistis

Sebuah visi yang baik, tetapi bahkan lebih baik jika semua orang merasa yakin bahwa hal itu dapat dicapai. Rencana tidak perlu tepat, tetapi jika hal pertama manajer developer Anda melihat ketika melihat roadmap ada  hambatan besar, jika roadmap terlihat sangat berat dalam desain dan berpusat frontend, tetapi tim hanya memiliki satu perancang dan telah berjuang dengan frontend topik dalam beberapa bulan terakhir-maka Anda akan memiliki dia berjuang dengan roadmap sepanjang sisa presentasi Anda.

Pastikan Anda melakukan pemeriksaan realitas dimuka dengan tim dan bermain dengan skenario What-if. Anda perlu memiliki jawaban, rencana tindakan yang jelas, dan pertimbangan singkat tentang “bagaimana hal itu dapat dilakukan” sebelum meminta komitmen setiap orang.

Presenting product roadmaps | Atlassian agile coach

5. berpikir besar, mulai kecil

Anda perlu menyadari di mana keterampilan produk dan tim hari ini versus di mana Anda ingin mereka menjadi. Ini bagus untuk maju ke bidang baru, yang mungkin memerlukan keterampilan baru dalam tim atau bergerak menjauh dari teknologi yang ada, tetapi tidak hanya menuliskan mimpi di mana Anda ingin berada dalam satu tahun. Sebaliknya, berpikir tentang bagaimana untuk sampai di sana secara realistis. Memperoleh bakat membutuhkan waktu, mengadopsi teknologi baru membutuhkan waktu, dan meninggalkan produk yang ada memerlukan komitmen yang jelas dan rencana transisi.

6. membangun kasus bisnis

Kasus bisnis? Ya. Tim teknis peduli tentang kasus bisnis. Mungkin tidak pada tingkat yang sama seperti manajemen senior, tetapi seluruh tim developer  peduli tentang mengapa sesuatu yang relevan dengan bisnis, jika menghasilkan hasil yang nyata, dan tunjukkan bagaimana hal ini akan diukur. Setiap orang memiliki kepentingan dalam bisnis berhasil secara keseluruhan, dan dapat menjadi sumber   umpan balik atau gagasan tambahan.

Juga, kejelasan penuh pada dampak bisnis dan melihat hal itu terjadi dapat menjadi motivator yang besar; memberikan hasil /impact jauh lebih    memuaskan melampaui hanya sekedar membangun fitur.

7. Seimbangkan  ide pasaran dengan memotivasi

Engineer ingin membangun produk yang unik, produk inovatif yang mereka dapat   banggakan. Jika itu hanya cerita lama yang sama orang lain telah mengatakan sebelumnya, dapat mendemotivasi . Pastikan Anda melakukan penelitian untuk mengkonfirmasi bahwa cerita Anda adalah sebagai inovatif seperti yang Anda pikirkan. Selain developer yang kehilangan motivasi, dampak bisnis dari kurangnya inovasi bahkan lebih buruk.

Dengan kata ini, bahkan roadmap akan selalu menjadi tindakan menyeimbangkan antara fitur baru yang menarik, dan secara teknis tidak terlalu menarik yang harus dimiliki yang hanya harus dilakukan. Cobalah untuk memastikan bahwa bahkan  fitur biasa cukup memotivasi pada roadmap Anda.

8. berpikir di luar MVP dan v1

Membuat minimum viable product, dan kemudian versi 1 adalah satu hal, tapi ada juga segala sesuatu yang terjadi pasca-peluncuran: operasi, pemeliharaan, permintaan fitur dari pengguna, perbaikan terus-menerus, dan versi baru dari produk lain dan/atau platform yang terintegrasi. Sebuah pikiran cepat   tentang apa yang tantangan dan rintangan mungkin setelah peluncuran akan membawa ini ke pencerahan tanpa banyak usaha, dan engineer akan berterima kasih bahwa Anda tidak mengabaikan realitas ini. Perkiraan kasar menunjukkan bahwa upaya awal membangun fitur baru sering hanya sepertiga untuk setengah dari total upaya yang dihabiskan di atasnya sepanjang seumur hidup. Dengan kata lain: akibatnya lebih mahal maka membangun awal, dan beberapa “cepat hal kecil” menjadi sangat mahal dalam jangka panjang.

9. bersikap terbuka dan jujur

Sebuah roadmap ada untuk memberikan bimbingan. Ini bukan rencana rinci untuk eksekusi dan semua orang di tim perangkat lunak tahu itu. Tidak perlu menjualnya sebagai sesuatu yang berbeda dari itu. Jadi jika Anda tidak memiliki semua rincian tentang topik  , terbuka tentang hal itu. Berbagi apa yang Anda miliki, apa tujuannya adalah, apa pertanyaan terbuka dan risiko tertinggi yang masih perlu diatasi. Tandaskan area yang memerlukan eksperimen dan lebih banyak penelitian untuk melakukan “apa.” Hanya ingat untuk memperhitungkan waktu eksperimen ini dalam perencanaan.

Intinya?

Tim Anda layak mendapatkan roadmap yang dengan jelas melukis gambaran besar, tetapi tidak mengabaikan realitas. Tim Anda juga layak mendapatkan roadmap yang memotivasi, menarik, dan memiliki cukup detail sehingga seluruh tim perangkat lunak tahu apa yang harus dilakukan di 1-2 Sprint berikutnya dengan perasaan percaya diri bahwa mereka akan mencapai hasil yang bagus dengan dampak material untuk bisnis.

Leave a Reply

Your email address will not be published. Required fields are marked *