Di Scrum, haruskah pengembang berbicara langsung dengan pelanggan (melewati PO)?

Bagaimana seharusnya seorang pemilik produk dalam scrum menangani pertanyaan-pertanyaan yang sangat rinci dari tim mengenai fitur-fitur yang mereka implementasikan yang tidak dapat dia jawab sendiri secara langsung? Kapan itu jelas akan menjadi solusi lebih cepat bagi pengembang untuk langsung berbicara dengan pelanggan sendiri?

Saya ingin tahu apakah komunikasi langsung antara tim dan pelanggan merusak peran pemilik produk. Saya merasa bahwa PO harus secara eksklusif mewakili pelanggan dan karena itu menjawab semua pertanyaan mengenai persyaratan - bahkan jika itu membutuhkan waktu lebih lama. Memotongnya sepertinya melemahkannya dan akhirnya membuatnya tak berguna ...

Apakah ada praktik terbaik dalam scrum?

scrum communication product-owner kewarganegaraan
sumber

Saya harus setuju dengan Anda bahwa pemilik harus menjadi satu-satunya titik kontak antara pengembangan dan pelanggan. Saya tidak setuju bahwa membuat pemilik produk tidak perlu adalah alasannya, atau lebih cepat untuk memotong peran. Saya akan begini: pada proyek dengan 10 pengembang Anda tidak ingin 10 orang terus-menerus berbicara dengan pelanggan dan menegosiasikan fitur. Pertama, itu mengganggu pelanggan, kedua dibutuhkan waktu untuk benar-benar berkembang. Jika Anda diblokir pada semua tugas karena Anda memerlukan informasi lebih lanjut maka Anda perlu memperbaiki fase penangkapan persyaratan dan tidak mencoba untuk memperbaiki kepemilikan.

Patrick Hughes

"Ketika itu jelas akan menjadi solusi yang lebih cepat ..." Hanya ingin menunjukkan yang sudah jelas: lebih cepat belum tentu lebih baik.

Eric King

Jawaban:

Itu selalu merupakan ide yang baik (terutama dalam apa yang disebut proyek Agile) untuk tidak menempel pada beberapa kultus kargo atau buku teks yang memberi tahu Anda "siapa yang harus (tidak) berbicara dengan siapa", tetapi nyalakan otak Anda dan lakukan apa pun yang paling berhasil dalam suatu proyek.

Meskipun komunikasi antara PO dan pelanggan harus menjadi standar (karena alasan yang dibuat oleh @PatrickHughes dalam komentarnya), Anda mungkin menghadapi situasi di mana persyaratan bisnis yang kompleks harus diklarifikasi, dan komunikasi langsung antara dev dan pakar bisnis akan mempercepat banyak hal. Dalam situasi seperti itu, seseorang harus menghindari bermain "bisikan Cina" dengan PO di tengah, dan biarkan dev dan pakar bisnis langsung berbicara satu sama lain - untuk konteks terbatas ini.

Namun, PO tidak boleh dilewati. Idealnya, dia mengambil bagian dalam percakapan itu, mungkin sebagai moderator. Dia dapat memverifikasi pelanggan tidak memunculkan persyaratan baru di atas meja selama pembicaraan, atau persyaratan yang bertentangan dengan apa yang telah disepakati sebelumnya.

Ini tergantung juga pada orang yang terlibat, dan situasi. PO mungkin memiliki kepercayaan yang cukup pada dev tertentu dan pakar pelanggan, untuk membiarkan keduanya berbicara tentang topik tertentu, dan membiarkan dia melaporkan apa yang dikatakan sesudahnya. Dalam situasi lain, dengan melibatkan orang lain, ia mungkin lebih suka mengambil bagian yang lebih aktif. Untuk mengambil keputusan ini dengan benar adalah inti dari manajemen proyek yang baik.

Doc Brown
sumber

"Seluruh gagasan pengembangan Agile adalah - bukan untuk tetap berpegang pada kultus kargo atau buku teks, tetapi aktifkan otak Anda dan lakukan apa pun yang paling berhasil dalam suatu proyek.": Benar, tetapi gagasan ini tidak spesifik untuk gesit.

Giorgio

+1 jika melakukan scrum dengan cara yang gesit, maka seorang pakar bisnis mungkin akan menjadi bagian dari tim dan tetap tersedia ...

Marjan Venema

Baik. PO seharusnya tidak pernah menjadi penjaga gerbang. Alih-alih, PO adalah yang paling bertanggung jawab atas produk.

Gort the Robot

@ SevenBurnap itu berarti PO harus menjadi ahli di bidang sejak awal ... dalam pengalaman saya, itu tidak selalu terjadi.

tizenegy

@Iorgio: tentu saja, "Pengembangan Agile" IMHO hanyalah kata kunci yang menggabungkan beberapa kebiasaan baik yang jauh lebih tua dari istilah tersebut, dan tidak terbatas pada dirinya sendiri.

Doc Brown

Anda harus ingat bahwa pelanggan perusahaan yang mempekerjakan Anda sebagai pengembang memiliki tujuan yang berbeda dengan perusahaan yang mempekerjakan Anda.

Pemilik produk harus mewakili tujuan perusahaan Anda, bukan tujuan pelanggan. Jadi jika para pengembang langsung ke pelanggan mereka dapat merusak perusahaan mereka sendiri.

Ewan
sumber

tujuan untuk semua adalah memberikan produk terbaik sesuai anggaran dan sesuai target. Hanya bagaimana melakukan itu yang berpotensi menjadi sumber diskusi.

jwenting

jangan naif. Perusahaan mungkin lebih suka menyelesaikan spesifikasi kontrak min dan beralih ke proyek yang lebih menguntungkan misalnya. Atau lebih mungkin dalam pengalaman saya, pelanggan ingin menambahkan fitur dan memperluas cakupan sambil menjaga harga tetap sama

Ewan

Bagi pengembang, pemilik produk adalah pelanggan. Idealnya (dan saya tahu itu tidak selalu mungkin) pemilik produk harus merupakan perwakilan langsung dari pelanggan, pakar domain, dan pengguna sistem di masa depan.
Itulah cara terbaik untuk memastikan Anda memiliki informasi langsung dan benar yang tersedia dan jalur terpendek yang mungkin dalam proses mereka.

Contoh yang ideal mungkin adalah tim tempat saya bekerja sekarang. Pemilik produk adalah pengguna akhir senior dan pakar domain dengan otoritas penuh untuk mengesahkan keputusan desain di tempat (dan kemauan dan kemampuan untuk benar-benar melakukannya). Dia merupakan bagian integral dari tim dan secara langsung membantu analis dan perancang dalam menulis cerita pengguna, serta programmer dan penguji dalam membangun produk dengan memberikan umpan balik instan tentang pertanyaan implementasi dan skenario pengujian.
Garis tidak dapat benar-benar lebih pendek daripada membuat pengguna masa depan Anda duduk di sebelah Anda saat melakukan coding :)

jwenting
sumber

"Garis tidak bisa benar-benar lebih pendek daripada membuat pengguna masa depan Anda duduk di sebelah Anda saat melakukan coding :)": Apakah ini selalu baik dipertanyakan.

Giorgio

@Iorgio tentu saja, tergantung pada orang yang terlibat. Tapi itulah yang SCRUM (dan praktik Agile secara umum) promosikan, garis pendek, pengambilan keputusan cepat. Dalam kasus kami, ini berfungsi karena pelanggan benar-benar bersemangat dan ingin produknya berhasil, tetapi mereka juga cukup realistis untuk menyadari bahwa tidak semuanya mungkin (tentu saja tidak dalam batas anggaran dan teknis yang harus kami kerjakan).

jwenting

Tentu, dan saya pikir itu juga tergantung pada jenis proyeknya. Beberapa proyek membutuhkan umpan balik lebih sering daripada yang lain. Juga, dalam beberapa proyek / produk Anda ingin menyimpan beberapa informasi untuk Anda sendiri. Tapi ya, untuk proyek-proyek tertentu membuat pelanggan duduk bersama Anda di kantor yang sama dan mengikuti pengembangan mungkin adalah pengaturan terbaik.

Giorgio

@Giorgio: "Pemilik produk adalah pengguna akhir senior dan pakar domain dengan otoritas penuh untuk mengesahkan keputusan desain di tempat" Kedengarannya seperti PO Anda dapat menjawab hampir setiap pertanyaan yang mungkin dimiliki pengembang. Saya merujuk pada situasi yang berbeda: PO yang masih belum pada tingkat keahlian yang sama dengan pelanggan itu sendiri dan oleh karena itu perlu kembali kepada mereka secara teratur untuk menjawab pertanyaan yang lebih sulit.

tizenegy