Apa yang Perlu Diketahui Manajer Produk

Apakah kita sudah sampai? Ini adalah pertanyaan yang sulit untuk dijawab ketika tidak ada yang setuju di mana tempatnya “ada”. Di dunia Agile yang penuh dengan solusi berbasis cloud, tidak ada container yang dibungkus menyusut penuh dengan widget yang benar-benar menandakan penyelesaian. Dan selalu ada kesempatan untuk mengirim kode yang jauh dari produk “jadi”. Itulah sebabnya menyetujui apa yang kami sebut “Definisi Penyelesaian” sangat penting untuk mencapai konsensus tentang kapan proyek, inisiatif, dan fitur benar-benar lengkap.

Semuanya dimulai dengan kosakata umum jika orang tidak berbicara bahasa yang sama ada cukup ruang untuk kebingungan, frustasi, sinyal campuran. Untuk menghindari skenario ini, tim produk harus mengambil waktu untuk bekerja dengan rekan-rekan teknik dan pengujian mereka untuk menyetujui apa yang memenuhi syarat sebagai “penyelesaian” dalam kasus yang berbeda.

Untuk mendapatkan halaman yang sama, berikut adalah panduan cepat untuk mendekonstruksi manajemen produk yang gesit.

Baca juga :Kriteria Penerimaan

Mendefinisikan definisi penyelesaian

Definisi selesai adalah sekumpulan item yang disepekati yang harus diselesaikan sebelum proyek atau cerita pengguna  dapat dianggap lengkap. Ini diterapkan secara konsisten dan berfungsi sebagai gerbang resmi yang memisahkan hal-hal dari “dalam proses” menjadi “selesai.

Meskipun detailnya berbeda dari setiap organisasi, definisi khas yang dilakukan terdiri dari daftar periksa yang berisi item seperti :

• Kode ditinjau sejawat
• Kode diperiksa
• Kode digunakan untuk menguji lingkungan
• Kode/fitur melewati pengujian regsei
• Kode/fitur melewati pengujian asap
• Kode dikomentasikan
• Dokumentasi bantuan diperbarui
• Fitur disetujui oleh pemangku kepentingan

Perusahaan dan kelompok pengembangan yang berbeda akan muncul dengan varian mereka sendiri, tetapi mereka semua kembali ke cita-cita yang sama : kode melakukan apa yang seharusnya dan tidak merusak apa pun. Membuat setiap fitur/rilis/sprint melalui langkah-langkah ini untuk memastikan penyelesaian adalah hal yang terpenting yang terpenting untuk memastikan kualitas dan kelengkapan yang konsisten.

Juga harus ada elemen transparansi, karena semuanya dapat dikaitkan kembali ke daftar periksa selesai itu. Jika sebuah rilis atau fitur belum mencentang semua kotak, maka itu tidak dapat bergerak maju dan semua orang tahu alasanya.

Siapa yang mendefinisikan penyelesaian?

Organisasi teknik bianya adalah pemain utama dalam mendefinisikan Definisi Penyelesaian, karena sebagian besar diantaranya adalah untuk menjamin bahwa segala sesuatu berjalan dengan baik dan memenuhi persyaratan teknis dasar.  Definisi tersebut mungkin dipimpin oleh ScrumMaster atau kepala bagian teknik.

Tapi, itu harus menjadi latihan kolaboratif untuk menyetujui apa yang memenuhi syarat sebagai “penyelesaian”. Tanpa masukan dan persetujuan dari produk, jaminan kualitas, dan pemangku kepentingan lainnya, tidak akan ada penerimaan luas apakah sesuatu benar-benar dilakukan atau rekayasa hanya mengatakannya.

“Pikirkan tentang semua tugas yang harus dilakukan untuk memasukkan cerita ke dalam produksi. Jadilah imajinatif dan sertakan semuanya, bahkan tugas yang mungkin diluar kendali tim Anda,” kata konsultan pengembangan produk Luís Gonçalves. Dari visi ideal tentang “penyelesaian” ini, Anda dapat meringkasnya menjadi definisi yang lebih realitas.

Mempraktikannya

Mendefinisikan penyelesaian merupakan penghemat waktu jangka panjang, karena ini mengurangi revisi yang tidak perlu di kemudian hari. Ketika kode tersebut memenuhi jaminan bahwa kode tersebut siap untuk prime time.

“Definisi Penyelesaian (DoD) adalah ketika semua kondisi, atau kriteria penerimaan, yang harus dipenuhi oleh produk perangkat lunak terpenuhi dan siap untuk diterima oleh pengguna, pelanggan, tim, atau sistem konsumen,” kata Derek Huether dari ALM Platfroms. “Kita harus memenuhi definisi yang dilakukan untuk memastikan kualitas. Ini menurunkan pengerjaan ulang, dengan mencegah cerita pengguna yang tidak memenuhi definisi agar tidak dipromosikan ke lingkungan tingkat yang lebih tinggi. Ini akan mencegah fitur yang tidak memenuhi definisi agar tidak dikirimkan ke pelanggan atau pengguna”.

Begitu definisi ada, itu berlaku untuk segala hal, memastikan konsistensi dan kualitas.

“Aturan ini berlaku untuk setiap item pekerjaan yang[p melewati papan tulis kami, selama itu melibatkan kode. Baik itu cerita pengguna besar dengan beberapa ketergantungan atau perbaikan bug kecil, orang yang melakukan pekerjaan diharapkan menjalankan daftar periksa ini,” kata Danny Smith dari CharlieHR. “Namun, itu tidak berarti bahwa semua yang ada di daftar periksa harus dicentang untuk setiap item pekerjaan, meskipun peningkatan teknis kecil tidak mungkin memerlukan email pemasaran yang ditulis tentang hal itu, misalnya. Ini berarti bahwa semua yang ada dalam daftar periksa harus dipertimbangkan untuk setiap item pekerjaan. Kami memercayai teknisi kami untuk menggunakan penilaian mereka.”

Mengapa manager produksi harus peduli tentang definisi penyelesaian

Membiarkan apakah sesuatu “penyelesaian” terbuka untuk interpretasi dapat menyebabkan konflik, kesalah pahaman, dan mengarah pada pengalaman pengguna yang negatif dan dampak pendapatan, yang merupakan alasan yang baik untuk menetapkan kriteria tersebut sebelum Sprint dimulai. Berbagi visi yang sama tentang hasil akhir yang seharusnya adalah tempat yang baik untuk memulai proyek apa pun, dan menyetujui gerbang yang harus dilalui fitur untuk mencapai penyelesain menciptakan konsensus ekspektasi.

Manfaat tambahan dari tidak memberikan setiap proyek ukuran “penyelesaian” sendiri juga merupakan penghemat waktu yang besar dan memungkinkan orang fokus pada inovasi dan pelaksanaan versus definis, jadi menginventasikan sedikit waktu dalam mencipakan pemahaman dasar tentang apa artinya selesai bagi semua orang adalah usaha yang layak. Dengan menghilangkan ambiguitas, setiap orang dapat berkonsentrasi pada tanggung jawab inti mereka alih-alih berdebat di kemudian hari dalam proses tentang kesesuaian untuk pembebasan.

Selain itu, meskipun sebuah fitur mungkin tampak selesai di permukaan, jika tim teknis belum memadai dan melewati di belakang layar, sumber daya tersebut akan terus berputar kembali ke proyek “penyelesaian” untuk membersihkan dan menangani semuanya masalah terbuka.

“Pekerjaan yang tidak lengkap memiliki kebiasaan buruk untuk meningkat, dan tanpa visisbilitas berapa banyak usaha yang benar-benar tersisa, defisit dapat dengan cepat lepas kendali,” kata Ian Mitchell dari proAgile. “Tirani pekerjaan yang hampir selesai, dapat membuat tim menjadi budak utang teknis.”

Definisi kriteria penyelesaian vs penerimaan

Jika Anda mulai bertanya-tanya mengapa ini adalah masalah manajemen produk dan bukan topik kendali mutu untuk tim teknis, itu sebagian karena perbedaan antara Definisi umum Penyelesaian dan kriteria penerimaan khusus untuk cerita pengguna tertentu.

DoD diterapkan secara universal (dengan beberapa pengecualian) untuk semua yang coba dikirimkan oleh organisasi teknik. Meskipun manajemen produk “OK” mungkin menjadi salah satu item di daftar periksa, ini adalah definisi yang cukup umum.

Kriteria penerimaan, bagaimanapun, adalah unik untuk cerita pengguna atau fitur yang dipermasalahkan. Kriteria ini harus ditentukan oleh manajemen produk, dengan memasukan dari tim teknis tentang kasus penggunaan tertentu atau parameter yang harus dipenuhi untuk menyalakan item ini sebelum dianggap selesai.

Karena DoD dipertimbangkan untuk segala hal, manajemen produk harus meninjau definisi tersebut dan memastikan mereka setuju bahwa definisi tersebut cukup komprehensif. Namun, kepemilikan dana manajemen definisi tidak harus menjadi tanggung jawab manajemen produk. Selama produk puas bahwa item “penyelesaian” lulus tes yang dijabarkan di Departemen Pertahanan, mereka sebagian besar dapat membiarkannya.

Tetapi produk atau fitur yang dikirim hampir tidak dapat dianggap dilakukan di mata produk juga.

“Untuk seorang manajer produk, Anda belum selesai dengan produk (atau fitur) sampai Anda meletakkannya di padang rumput,” kata Adam Sigel dari Hometap. “Setelah diluncurkan, Anda memulai dukungan pelanggan yang panjang, perubahan harga, perbaikan bug, dan pembaruan kompatibilitas. Setelah Anda selesai mendukungnya, inilah waktunya untuk memadamkannya. Kemudian, dan baru setelah itu, Anda selesai dengan sebuah produk.”

Mulai dari mana

Proses penetapan tidak boleh terjadi dalam ruang hampa, itu harus kolaboratif antara pemangku kepentingan dan mereka yang benar-benar melakukan pekerjaan. Baik itu dimulai dengan brainstroming atau saran dari tim teknis, harus ada banyak kesempatan untuk berkomentar dan dukungan bulat untuk produk akhir.

Menugaskan pemilik untuk setiap kriteria juga merupakan ide yang baik, karena mereka  dapat menjadi penengah jika ada ketidaksepakatan jumlah kemampuan item tertentu untuk mencentang kotak itu. Ini memperkuat konsistensi dan menghikangkan keraguan dari persamaan.

Dan deperti semua metodologi yang bertujuan baik, Definisi Penyelesaian harus sederhana dan sesingkat mungkin. Idenya adalah untuk menciptakan kualitas yang konsisten dan bukan rintangan birokrasi yang memperlambat segala sesuatunya secara tidak perlu.

“DoD adalah kontrak antara pemilik produk dan tim, jadi Anda tergoda untuk memasukkan sebanyak mungkin item di DoD untuk memastikan kualitas produk. Tapi ini bisa menjadi bumerang,” kata Yves Riel dari Okapya. “Ketika tim dihadapkan dengan terlalu banyak item DoD mereka hanya bekerja pada subset atau mencoba dan gagal melakukan semuanya, menghilangkan nilai dari membangun DoD di tempat pertama.”

Jarak tempuh Anda mungkin berbeda

Definisi selesai terutama berkaitan dengan kode dan kesesuaiannya untuk dirilis. Tetapi untuk tim produk, Anda pasti belum selesai ketika sesuatu dikirimkan, jadi Anda harus membuat definisi Anda sendiri yang meluas lebih jauh ke dalam siklus hidup produk.

Sasaran berbasis metrik seperti adopsi, penggunaan, retensi, atau pendapatan dapat menjadi pananda bawah suatu fitur telah “selesai” atau bisa juga sesederhana pelanggan yang meminta agar menyetujui bahwa fitur tersebut memenuhi persyaratan mereka. Dan mengingat bahwa umpan balik dan analitik pengguna dapat mendorong pengembangan tambahan belum lagi umpan balik UX atau perubahan dalam model bisnis tim teknik harus bersiap untuk mengunjungi kembali item yang sebelumnya mereka anggap “selesai”.

Dari sumber : https://www.productplan.com/blog/agile-definition-of-done/