10 kesalahan PO muda (kesimpulan)

Dan sekarang 3 kesalahan utama. Jika itu dilakukan berulang-ulang, saya khawatir bahwa dari PO muda Anda bisa masuk ke peran mantan PO. Mulai di sini dan di sini .


8. Anda tidak dapat memecat siapa pun dari tim dev
Kalau tidak, seluruh tim akan terdemotivasi

Ya, dalam genre klasik, tim scrum diatur sendiri, dan Anda duduk di "tahta" dan memprioritaskan jaminan simpanan. Tidak peduli bagaimana)

Pada kenyataannya, tim yang mengatur diri sendiri tidak takut untuk membahas masalah, dengan jujur ​​menyuarakan kepada anggota tim yang lain bahwa "pada kenyataannya, kita tidak akan mengobrol di sini." Misalnya, jika seseorang muncul di tim - penunda, mereka membahas semua ini dalam retro, menyadari bahwa "ini tidak akan berhasil" dan dengan kata-kata " Ini Sparta " ... mengucapkan selamat tinggal kepadanya. (Saya bahkan tidak tahu bagaimana terus bekerja di tim seperti itu :)

RO - dia adalah manajer, pemilik anggaran, dan, dengan demikian, jika dia tidak membenamkan dirinya dalam urusan tim "swakelola" dan tidak memantau "kesehatan" -nya, tidak mungkin cerita seperti itu akan berakhir dengan baik. Anda dan tim mencoba hal-hal yang berbeda, tetapi tidak membantu? Lalu pemecatan, peringatan, dan semua itu adalah tanggung jawab Anda. Meskipun praktik terbaik menunjukkan bahwa keputusan seperti itu harus dibuat oleh tim, sangat sedikit dari mereka tumbuh ke tingkat interaksi psikologis.

Saya ingin berbicara tentang dua kasus dari tempat praktik saya. Tim kami memiliki 2 contoh keren.

• Contoh pertama. Terpaksa . pengembang mengambil bagian dalam perencanaan, mendiskusikan fitur-fiturnya, mendukung, membombardir, dan kemudian dia bisa berkata: "Teman-teman, saya punya pelatihan 2 bulan." Dia kembali, semua dalam lingkaran lagi. Tetapi tim itu sendiri tidak bisa mengatakan apa-apa kepadanya, tidak mau dan diam, dan sebagian pekerjaan berhenti, seluruh tim menyeret tugas-tugas yang direncanakan ini, dan tentu saja, tidak punya banyak waktu. Saya menonton ini untuk waktu yang lama, berbicara dengan pengembang, sebagai hasilnya, kami mengucapkan selamat tinggal padanya. Dan tidak ada yang terjadi pada kesehatan tim, semua orang berkata: "Ya, keputusan yang tepat, tetapi secara umum akan menyenangkan untuk membuat keputusan seperti itu sebagai seluruh tim" (matang :)).
• Contoh yang kedua . Positif . Pengembang menderita penundaan, sama sekali tidak jelas apa yang dia lakukan. Tetapi pada retro, tim mengatakan bahwa itu tidak baik, mereka menggambarkan pro dan kontra orang tersebut dari tim mereka sendiri. Dan tahukah Anda? Kami menyadari bahwa kami sama sekali tidak mengerti satu sama lain. Pengembang mulai bekerja dengan cara yang berbeda, ia banyak mengelola, menulis lebih baik. Itu cukup retro. Jadi kadang-kadang pencerahan tim juga datang jika ada master scrum yang baik yang akan membantu mulai berbicara.

9. Bisnis apa pun harus diselesaikan.

Tidak, tidak ada Secara umum, hal yang sangat langka perlu diselesaikan dalam pengembangan produk. Tentu saja, jika itu akhir didefinisikan dengan benar :)

Misalnya, Anda datang dengan fitur, berbohong tentang hal itu, ia hidup dalam imajinasi, prototipe itu indah, dan ia juga memiliki tombol biru dengan batas putih. Untungnya, ada mvp yang menyelamatkan jiwa yang tidak akan membiarkan Anda melakukan sesuatu yang berlebihan. Klien akan menerima pertama-tama yang paling diperlukan, dan hanya setelah itu - sesuatu yang perlu, kemudian tambahan dan hanya sesuatu untuk jiwa.

Banyak pemula PO khawatir bahwa mereka tidak melakukan salah satu ide mereka (epik), perasaan ini membuat mereka mengambil tugas yang akan membawa sedikit nilai tetapi menghabiskan banyak sumber daya, sementara klien akan menderita dari masalah yang Anda dapat dengan cepat dan putuskan saja.

Matikan perfeksionis dan miliki perasaan yang hebat untuk sementara waktu. Akan tiba saatnya klien akan cukup puas, dan dimungkinkan untuk melakukan semua tugas di akhir jaminan (walaupun saya sendiri belum pada tahap pengembangan produk ini, tetapi memahami hal ini membantu membuat keputusan dengan mudah).

Cara ini akan bekerja dengan sendirinya jika tugas tersebut memiliki kisah pengguna yang dideskripsikan dengan tepat, saya akan menggambarkan tampilannya:



10. Bekerja dan takut kehilangan pekerjaan Anda

Anda datang ke perusahaan baru / memulai startup, tetapi pada saat yang sama Anda bekerja dan membuat keputusan berdasarkan pengalaman masa lalu. Dalam realitas baru, pasti akan ada orang / aturan / pendapat yang akan memberi tahu Anda bahwa di sini "tidak mungkin ", tetapi " tidak diterima ", dan "jangan mengucapkan kata ini sama sekali. Ini menjadi pembatasan artifisial pada suatu produk, seringkali hanya didasarkan pada dugaan, pendapat subyektif, dan rasa takut orang lain. Tapi Anda tidak tahu ini, dan membangun dinding beton di sekitar produk Anda, yang mereka tidak membiarkannya berkembang.

Sebuah contoh Tim kami menghabiskan enam bulan tanpa server untuk produk, karena "aturan seperti itu - semua orang di sini menunggu server selama 6 bulan", harganya seperti Ferrari F60 America, dan hosting awan dilarang. Ok, tunggu - server di bawah meja tidak terlalu buruk.

Ambil kesempatan, cobalah. Tidak berhasil? Coba lagi! Atau ternyata Anda tidak perlu membangun tembok beton atau Anda dapat menghancurkannya, atau hal terburuk yang dapat terjadi adalah Anda akan mengetahui bahwa itu benar-benar mustahil untuk dihancurkan. Namun sepanjang jalan Anda akan menemukan konteks masalah sebanyak mungkin, Anda akan menemukan lebih banyak opsi untuk solusi. Ya, kemungkinan besar Anda akan membuat marah seseorang dengan upaya Anda untuk memecahkan sesuatu yang tidak dapat dilanggar. Tidak ada yang akan menghukum Anda karena mencoba melakukan segala yang mungkin untuk produk dan perusahaan, dan bahkan lebih dari itu mereka tidak akan memecat Anda :) tiga kali pertama - pasti. Pada yang keempat - itu mungkin, tetapi Anda melakukan semua yang Anda bisa.

Ngomong-ngomong, sekarang kita dihosting di cloud, dan menyebarkan mesin virtual dalam 1 menit dalam jumlah yang kami anggap perlu. Dan saya masih bekerja di sini :)