Bagian kedua dengan kesalahan saya, yang pertama di
sini .
Biarkan saya mengingatkan Anda bahwa saya adalah pemilik produk dalam tim yang hanya terdiri dari pengembang, dan kami membuat platform TI untuk mengelola jaringan afiliasi pompa bensin.
Kesalahan empat.
Faktor bus: apa yang awalnya tampak seperti banyak kesalahan, tetapi ternyata itu menjadi jackpot yang jelas bagi tim
Untuk merekrut 8 orang yang tidak dapat saling menggantikan sama sekali, tanpa penguji, dan pertama tanpa analis? Tampaknya saya menjadi gila dan memutuskan untuk menenggelamkan produk tersebut.
Bahkan , saya perlu membuat 6 kelompok layanan yang berbeda, karena masing-masing sudah ada "praktik terbaik", yang cepat dan mudah digunakan, pasar pengembang berpengalaman besar.
Apa arti
tim seperti
itu bagi saya ? Kemampuan untuk dengan cepat menemukan tim dengan kompetensi yang tepat, dengan cepat menggunakan MVP dan mulai memvalidasi hipotesis bisnis, dan menempati ceruk yang sangat bebas di pasar.
Apa ini
untuk tim ? Pada level awal, ada banyak kompetensi berbeda yang dapat mereka bagi satu sama lain, kemampuan setiap fitur untuk menggunakan solusi tercepat yang mungkin, dan yang paling penting, mereka mempelajari sesuatu yang baru secara terus-menerus, dan ini, Anda lihat, menarik bahkan untuk senior. (Setidaknya tim pengembangan saya berbagi prinsip-prinsip ini).
Sementara menguji hipotesis bisnis, tim pengembangan saling bertabrakan dan dari waktu ke waktu mulai menguji hipotesis teknis dalam diri mereka sendiri, sehingga, dalam perselisihan, arsitektur target platform yang dibuat oleh TIM, dan bukan hanya satu arsitek, dibentuk. "Semua arsitek" adalah seseorang, menurut pendapat saya, tidak berguna, mahal, dan mereka tidak ada :) Ketika sebuah tim memiliki tanggung jawab yang sama, produk menjadi gagasan bersama, semua orang mendukungnya, saya tidak ingin mengalihkan tanggung jawab lagi. Sedemikian rumit, tim tumbuh, membuat keputusan, BAGAIMANA untuk membuat produk lebih lanjut, kompetensi berkembang, interchangeability dan self-organisasi muncul. Kita belum melewati jalan ini, tetapi cepat atau lambat kita akan berlalu. Tentu saja, sekarang kami memperluas tim ke penguji khusus, tetapi pada awalnya, tim cukup mampu menangani fungsi ini sendiri.
Ya, lebih mudah untuk mengambil 6 pengembang java dan sekarang mereka segera dipertukarkan, tetapi dengan cepat dari awal mereka tidak akan membuat produk yang berfungsi, dan akan sangat banyak dibatasi oleh kompetensi mereka.
Ngomong-ngomong, sangat sulit untuk menjadi pemilik produk TI tanpa pengalaman dalam TI itu, misalnya, pengembang, analis sistem atau konsultan (siapa pun kecuali manajer proyek), dan bahkan jika Anda memiliki guru arsitek, itu akan menjadi produknya, bukan milik Anda, bukan milik Anda. . Di sini Anda dapat berdebat, tetapi praktik dan statistiknya adalah sebagai berikut.
Kesalahan lima.
Ini tidak nyaman bagi saya, jadi orang lain tidak akan menyukainya
Tim kami sering bertanya "Siapa yang butuh ini?", "Klien menginginkannya seperti itu", "Pasti tidak nyaman karena saya tidak menyukainya" dan seterusnya. Pada awalnya, tentu saja, Anda dapat berpikir tentang klien, menawarkan sesuatu kepadanya, dan berdasarkan umpan balik, masukkan jaminan simpanan. Hal utama di sini adalah melakukan studi kualitatif dan mendengar rasa sakit, bukan solusi siap pakai, jika tidak mereka akan meminta "kuda lebih cepat", dan bukan mesin yang berfungsi dengan baik.
Adalah perlu untuk membenamkan tim dalam kesengsaraan
klien , memanggil
klien dan tim untuk perawatan, memberikan kontak tim dari klien-klien yang mereka selalu dapat meminta pendapat atau dengan cepat memeriksa fungsi.
Saya mulai berkata pada diri saya lebih sering: "Jangan pernah mencoba peran klien jika Anda tidak berada di tempatnya dan jangan biarkan tim melakukannya." Mengapa berdebat sia-sia jika Anda dapat meminta orang yang Anda lakukan ini?
Kesalahan enam.
Tidak ada yang membutuhkan prototipe
Kesalahan yang sangat besar untuk RO pemula adalah tidak membuat prototipe atau menguji hipotesis. Saya ingin cepat menciptakan yang indah dan segera menjadi yang produktif.
Jika klien sakit: dia tidak melihat bintang-bintang di malam hari karena cuaca buruk, dan Anda segera membuat pesawat ruang angkasa untuknya, berusaha melampaui harapannya dan melakukan 100 kali lebih baik dari yang bisa dibayangkannya, maka ini adalah kesalahan yang jelas. Dia memiliki tugas, rasa sakit, dan keinginan yang berbeda.
Anda dapat menghabiskan tiga hari atau seminggu, menggambar dengan tangan bagaimana produk akan terlihat, dan juga menunjukkannya kepada klien. Minta dia untuk mencari tahu bagaimana dia akan menggunakannya dan jangan lupa melakukannya setiap kali ide ditransfer ke jaminan simpanan produk.
Nah, ketika Anda datang dengan fitur yang brilian, membuat prototipe, pengguna Anda bertepuk tangan dan benar-benar menginginkannya - tidak, Anda masih tidak bisa menggunakannya :) Jangan lupa tentang metrik fitur, baik bahan makanan dan bisnis. Metrik umumnya adalah cerita khusus dengan kesalahan - lebih banyak tentang mereka nanti dan lebih rinci dalam angsuran berikutnya. Sementara pengumuman ...
Kesalahan tujuh.
Metrik kemahakuasaan
Biarkan saya mengingatkan Anda bahwa tim kami adalah bagian dari startup besar di perusahaan besar. Berurusan dengan metrik produk dengan pemangku kepentingan sulit. Menempatkan metrik bisnis pada solusi TI yang masih dalam tahap desain adalah ide yang buruk. Tetapi investor perlu menunjukkan pekerjaan mereka, bahkan jika belum ada peningkatan untuk pengguna.
Setiap metrik uang akan menurunkan motivasi Anda dan tim, tetapi justru pada mereka itulah para pemangku kepentingan ingin menonton. Dan sekarang Anda sudah berada di jalur licin PI, dengan percaya diri berjuang keras, Anda tidak dapat memengaruhi metrik ini dalam arti positif. Dan dalam segala hal, mulai sekarang, produk terlihat tidak efisien dan tidak menguntungkan.
Jika Anda tidak membuat kesalahan nomor 6, maka Anda memiliki setiap kesempatan untuk meyakinkan pemangku kepentingan, menggunakan dan menunjukkan prototipe kepada pengguna, mengumpulkan umpan balik, dan menggantung metrik daya tarik di atasnya. Buat pengembangan setransparan mungkin, tunjukkan apa yang Anda lakukan pada prototipe ini, tombol atau formulir mana yang akan bekerja, apa yang akan Anda lakukan, dan bagaimana menggunakan jadwal yang indah yang akan segera muncul. Hal utama di sini adalah jangan terlalu banyak
berjanji dan menepati semua
janji Anda
.Ringkasan kesimpulan:
- Coba pertama, jika milik Anda - pergi ke sekolah RO
- Anda tidak abadi, jangan mengambil semuanya sekaligus, merekrut tim yang siap Anda percayai
- Anda pasti membutuhkan master scrum. Penuh waktu.
- Ambil kesempatan. Tim scrum akan dipertukarkan cepat atau lambat, dan hipotesis bisnis tidak terletak di lantai, lebih baik mengambil kursi kosong di pasar lebih cepat dengan MVP Anda, meskipun dengan risiko faktor bass pada awalnya, daripada tidak punya waktu untuk mengambilnya.
- Berkomunikasi lebih banyak dengan klien, ingat tentang rasa sakitnya, cobalah untuk menyelesaikannya.
- Tanyakan semua ide Anda, buat prototipe dan uji hipotesis, lihat reaksi klien, kami di sini untuk berkumpul bersama :)
- Pilih metrik sendiri, mereka akan membantu Anda membuat produk yang berkualitas dan iteratif bagus. Ingatlah bahwa ada banyak produk yang tersisa di "lembah kematian" karena kurangnya kualitas.