Nama saya Maxim, dan selama delapan tahun terakhir saya telah bekerja di perusahaan besar sebagai analis bisnis dan pemilik produk. Hari ini saya ingin berbagi dengan Anda pemikiran saya tentang pengembangan produk, yang diatur dengan penggunaan sejumlah besar tim pengembang.
Mereka yang tertarik dan mau membicarakan topik ini - selamat datang di bawah cat.
Mari kita mulai dengan perusahaan besar. Yang saya maksud dengan perusahaan besar adalah perusahaan dengan ribuan pengembang, penguji, analis, insinyur pengembang, pemilik produk, dan manajer orang lain. Ini adalah lusinan divisi, ratusan tim, hierarki kompleks, dependensi tanpa akhir, dan area tanggung jawab.
Masuk ke perusahaan seperti itu, pada awalnya sulit dinavigasi. Tapi waktu berlalu, dan sekarang Anda bisa membayangkan "pulau" Anda. Biasanya, ini adalah:
- Beberapa sistem atau komponen yang dapat dipahami yang terlibat dalam proses bisnis yang sangat besar dan kompleks;
- Pemilik produk adalah orang yang tidak diragukan lagi tahu di mana harus mengembangkan sistem ini;
- Satu set dokumentasi dalam berbagai tingkat relevansi;
- Serangkaian pengujian, otomatis dan tidak terlalu.
Terdengar akrab?
Seperti inilah tipikal dan bukan sistem pengembangan perangkat lunak yang terburuk. Biasanya departemen pengembangan perusahaan dengan produk yang sukses datang ke bentuk ini dalam 10-15 tahun. Produk yang sukses menghasilkan uang, uang diinvestasikan dalam pengembangan. Pengembangan tumbuh pesat, diskalakan secara linier dan sampai pada situasi di mana manajer proyek tidak dapat lagi menyimpan semua ketergantungan di kepala mereka, banyak tim mulai menarik "selimut" ke atas diri mereka sendiri, dan, terkadang, merusak produk daripada mengembangkannya. Dalam situasi seperti itu, sangatlah normal bagi satu tim untuk berjuang demi kesuksesannya sendiri, tidak lagi mengkhawatirkan rekan-rekannya mengalami beberapa masalah, dan fitur umum mereka tidak akan tersampaikan karena hal ini. Ini adalah sifat dari hal-hal untuk mengembangkan fungsionalitas yang diminta oleh pemangku kepentingan tanpa akhir dengan yang paling keras, dan bukan yang dibutuhkan pengguna.Pengembangan "di atas meja" tidak jarang. Proses sedang berlangsung - persyaratan datang, diterapkan, diuji, dikirim. Sangat mudah untuk menyembunyikan hal utama di balik layar hiruk pikuk - pengembangan produk hampir tidak seefektif dulu.
Untuk memahami hilangnya efisiensi ini, mari beralih ke manajemen produk klasik. Sekarang ada cukup banyak sekolah atau universitas online yang dapat mengajari Anda sains ini dengan uang.
Daftar kecil saya jika Anda tidak mengenal mereka
Jadi, menurut "klasik", produk adalah apa yang dibeli orang. Tugas seorang manajer produk adalah menemukan audiens target, menentukan pesan nilai, memilih saluran penjualan yang sesuai, mengurangi ekonomi, menemukan poin pertumbuhan, memilah semua hipotesis yang sesuai. Jika perlu, ubah ide, target audiens, saluran, pesan, model bisnis, pasar. Atau bahkan mematikan produk jika jelas tidak memiliki prospek yang dapat diramalkan.
Kedengarannya tidak seperti cerita di atas, bukan?
Intinya adalah, ketika Anda baru memulai, semua proses pengembangan produk cukup transparan dan mudah. Sangat mudah untuk menemukan masalah dan memperbaikinya. Sangat mudah untuk memahami ide produk. Sangat mudah untuk memahami dan mengembangkan fungsionalitas yang dibutuhkan. Pengguna - ini mereka, di tangan. Prod - ini dia, dengan semua metrik.
Namun, seiring berjalannya waktu, produk berhasil mendapatkan pangsa pasar, berkembang menjadi lini produk, semakin banyak pengembang dipekerjakan, dan sebelum Anda menyadarinya, perusahaan Anda berubah menjadi tumpukan struktur, kepentingan, dan tanggung jawab.
- Pengguna produk kustom? Sekarang pemilik produk Anda tidak mengingatnya, mereka bergegas dari satu pemangku kepentingan ke pemangku kepentingan lainnya, mencoba memahami persyaratan apa yang harus diambil pada awalnya;
- Apakah unit ekonomi jelas dan transparan? Sekarang para pemilik produk bahkan tidak mempertimbangkan PnL (Untung dan Rugi), memuat seluruh tim di lantai sprint dengan sisi-sisi dengan manfaat yang meragukan;
- Apakah ada cerita pekerjaan, peta perjalanan pelanggan, dan orang lain? Sekarang mereka menulis di toko “Sebagai pemilik produk, saya ingin ini dilakukan karena departemen Operasi dan Pemeliharaan membutuhkannya”;
- Apakah ada pemahaman tentang tanggung jawab atas hasil dan persyaratan? Sekarang setiap tim adalah untuk dirinya sendiri, fitur Anda akan dikirimkan ke produksi untuk satu atau dua rilis nanti.
Kompleksitas pengelolaan pengembangan untuk produk skala besar tumbuh secara eksponensial. Apa yang harus dilakukan?
Hal pertama yang terlintas dalam pikiran manajemen puncak adalah kita membutuhkan kerangka kerja ajaib yang akan membuat seluruh sistem kompleks ini bekerja seperti jam tangan Swiss. Ada permintaan - ada penawaran. Saya tahu beberapa kerangka kerja yang, secara teori, dapat mengatasi tugas yang sedang dihadapi.
Apakah mereka "peluru perak"?
Saya telah mengalami beberapa transformasi bisnis di mana pelatih emas dipekerjakan, manajemen dan proses komunikasi paling modern diperkenalkan. Ribuan orang mengubah posisi mereka dalam semalam dan pindah ke struktur baru, tim baru, proses baru, proyek baru.
Dan saya dapat mengatakan yang berikut:
- itu mahal;
- itu tidak cepat;
- itu sangat berisiko;
- kesuksesan akhir sangat tergantung pada budaya perusahaan. Jika orang mengerti dan percaya, kemungkinan besar sukses.
Apakah pendekatan ini satu-satunya yang benar? Mari kita lihat apa lagi yang bisa Anda lakukan.
Saya yakin ada cara lain untuk meningkatkan pengembangan produk. Sayangnya, saya tidak memiliki petunjuk langkah demi langkah untuk Anda, tetapi berikut adalah ide saya yang mungkin membantu Anda dalam hal ini:
Produk . Produk harus menambah nilai. Pertimbangkan kebun binatang sistem dan komponen Anda dalam hal nilai. Sorot semua aliran nilai untuk pelanggan akhir, rekanan, atau pihak ketiga dan bagi peta sistem dengan aliran tersebut. Setiap pemilik produk harus memiliki rantai lengkap sistem nilai yang terkendali. Beri dia beberapa analis jika cakupan tanggung jawabnya terlalu besar.
Metrik... Untuk mengelola, pertama-tama Anda perlu mempelajari cara mengukur. Setiap pemilik produk harus mengidentifikasi metrik untuk produknya, yang menjadi dasar untuk melakukan pengembangan produk ini.
Pengguna . Mari kita kesampingkan para pemangku kepentingan. Hanya pengguna yang dapat memberikan gambaran yang benar tentang nilai suatu produk. Pemilik produk harus dipandu oleh hasil wawancara dan analisis tiket dukungan dalam hipotesis mereka.
Hipotesis . Tidak ada lagi implementasi fungsionalitas yang buta. Setiap epik atau fitur harus memiliki ekspektasi terhadap dampaknya pada metrik. Saat mengimplementasikan fitur dan mengujinya dengan pengujian A / B, pemilik produk harus memahami apakah hipotesisnya berhasil atau tidak.
Koordinasi... Tentu saja, pekerjaan beberapa produk perlu dikoordinasikan sesuai dengan kerangka kerja yang Anda pilih. Namun, Anda tidak boleh mengubah koordinasi ini menjadi dewan tanggung jawab kolektif manajer produk.
Saya percaya bahwa hanya dengan mempertahankan kondisi yang dijelaskan di atas Anda dapat berhasil menskalakan manajemen produk, dan pada umumnya tidak masalah kerangka kerja mana yang Anda pilih untuk penskalaan ini.