Daftar isi kursus
1. Peran manajer produk dan kerangka kerja
2. Segmentasi pasar dan analisis persaingan
3. Persona pengguna
4. Pengujian hipotesis
5. Penentuan posisi
produk 6. Peta jalan produk <- Anda di sini
7. Menyusun persyaratan untuk pengembangan
8. Model bisnis dan Bisnis- Rencana
9. Rencana Keuangan dan Penetapan Harga
- Untuk Dilanjutkan
Memiliki peta jalan sangat penting untuk mengelola pengembangan produk. Namun, untuk menyusun roadmap dengan benar, masalah ini perlu didekati secara sistematis. Sangat penting untuk tidak mengacaukan peta jalan dengan visi, meskipun memiliki visi diperlukan untuk membangun peta jalan dengan benar.
Motto Perserikatan Bangsa-Bangsa: “Berpikir Secara Global, Bertindak Secara Lokal . " Menariknya, ini juga berfungsi saat membuat peta jalan untuk produk perangkat lunak yang bagus. Untuk melakukan ini, Anda perlu memiliki visi global agar aspirasi Anda tidak berakhir di sini dan sekarang. Dalam kerangka visi, tujuan ditetapkan - tujuan juga cukup global, dan peta jalan harus memimpin ke tujuan inilah. Ketika Anda bergerak sesuai dengan peta yang disiapkan, rilis menjadi tonggak dan tahapan gerakan ini - perwujudan langkah-langkah khusus untuk pengembangan produk.
Cakrawala apa yang harus Anda ayunkan dengan perencanaan? Ini bisa berbeda, tetapi sebagai permulaan lebih baik membatasi diri Anda hingga 6 bulan. Jika Anda tahu persis kemana produk Anda akan bergerak, bisa jadi 3 tahun atau 5 tahun. Tidak ada batasan. Misalnya dalam pidatonya baru-baru iniPendiri Amazon Jeff Bezos mengumumkan program luar angkasa Blue Origin dengan cakrawala perencanaan 50-100 tahun. Artinya, seseorang menciptakan perusahaan yang akan bekerja sebagian besar waktu setelah hidupnya. Bagaimana ini mungkin?
Hanya saja dalam hal ini kita berbicara tentang visi global - Blue Origin harus menyediakan kemungkinan penerbangan luar angkasa yang intens. Amazon mengandalkan infrastruktur kurir dan surat yang sudah ada, kata Bezos. Jika mereka tidak ada, Amazon tidak akan bisa bekerja atau menjadi sangat sukses. Hari ini Blue Origin berencana membuat infrastruktur untuk perjalanan luar angkasa di masa depan - roket, pelabuhan antariksa, satelit, stasiun orbit, dan sebagainya. Tujuan global Blue Origin adalah membangun pesawat luar angkasa pada tahun 2025.
Memahami tujuan global Anda membantu menyusun peta jalan, di mana kami menunjukkan langkah-langkah konkret, membangun rencana yang realistis untuk mencapai tujuan yang ditetapkan dalam waktu dekat. Dan Blue Origin, sebagai perusahaan dengan rencana ambisius, mencoba memenuhi misinya - untuk mengatur layanan di seluruh dunia untuk pergerakan orang dan barang yang dapat diakses dan nyaman.
Dari surga ke bumi ...
Pertimbangkan contoh yang lebih realistis. Jika sebuah perusahaan konstruksi bergerak dalam konstruksi berkualitas tinggi, konsep pekerjaannya mungkin akan terlihat seperti ini:
● Visi - untuk membangun kawasan pemukiman terbaik di utara Moskow (SAO).
● Tujuan - 5.000 apartemen, arsitektur modern, kenyamanan kelas, tata letak yang nyaman, halaman tanpa mobil.
● Peta jalan - antrian pembangunan dan perbaikan wilayah.
● Pelepasan - bangunan jadi, jalan, taman (pembagian dimungkinkan pada tahap penyelesaian).
● Fitur - komponen rilis. Misalnya taman bermain, menanam pohon, tempat parkir tertutup, ramp.
Bagaimana cara membuat peta jalan produk perangkat lunak?
Peta jalan perangkat lunak mencakup rilis, yang masing-masing harus berisi fitur tertentu. Sangat penting untuk menjadwalkan peta jalan berdasarkan tanggal, dengan mempertimbangkan kemampuan dan sumber daya yang tersedia (lebih lanjut tentang itu nanti). Misalnya, seperti inilah peta jalan untuk salah satu aplikasi sosial.
Ingatlah bahwa peta jalan harus direncanakan untuk semua departemen sekaligus. Jika perusahaan itu besar dan manajer penjualan memiliki peta jalannya sendiri, Anda perlu menautkannya ke peta jalan departemen pengembangan. Jika tidak, ketika saatnya tiba, misalnya, untuk mempromosikan suatu produk di pasar Asia, ternyata Anda belum memiliki pelokalan yang siap pakai ... dan memang dukungan untuk bahasa Mandarin.
Permintaan tentang apa yang seharusnya ada dalam suatu produk datang dari berbagai tempat. Kami sudah membicarakan hal ini di salah satu postingan sebelumnya .... Mereka perlu diatur dan direncanakan dengan hati-hati. Penting untuk dipahami bahwa tidak mungkin menyiapkan dan merilis semua fitur di versi 1.0, karena pada kenyataannya tidak pernah ada cukup sumber daya untuk menerapkan semua ide (jika tidak demikian, maka Anda memiliki sedikit ide dan Anda perlu berpikir lebih banyak).
Dengan pendekatan yang tepat, Roadmap adalah peluang untuk membagi proses pengembangan produk menjadi beberapa tahapan dan meluncurkan fungsionalitas dengan prioritas dan kepentingan yang menurun dalam iterasi.
Mari kita lihat kerangka pengembangan produk perangkat lunak lain (Kerangka Manajemen Produk Perangkat Lunak) yang mengontrol pengembangan perangkat lunak:
Matriks jatuh tempo perusahaan yang berada di bawah kerangka tertentu ditentukan oleh tabel berikut. Dan jika Anda secara resmi mengikuti proses penyusunan peta jalan, perusahaan segera mencapai tingkat kedewasaan kedua:
Secara umum, kerangka kerja ini adalah cabang terpisah untuk kursus apa pun tentang pengembangan produk. Kami tidak akan membahasnya sekarang. Jika seseorang tertarik membaca postingan tambahan tentang topik ini, silakan tinggalkan komentar di postingan ini.
Di sini, kami sendiri hanya akan menerima bahwa dengan mengamati beberapa prosedur formal dalam pengembangan perangkat lunak, sambil membangun proses ini, perusahaan itu sendiri meningkatkan budaya penyampaian perangkat lunak yang lebih baik. Peta jalan adalah bagian dari budaya ini.
Bagaimana cara mengumpulkan dan memproses persyaratan produk?
Ketika kami menerima persyaratan dari berbagai sisi, mereka perlu dimasukkan ke dalam beberapa jenis sistem. Misalnya, Acronis menggunakan Jira, yang merupakan alat yang cukup ampuh, tetapi untuk startup, Anda dapat menggunakan yang lebih sederhana, termasuk yang gratis, misalnya, Redmine atau Asana.
Yang utama adalah semua ide terdaftar, karena tidak ada pikiran buruk. Jika gagasan tersebut belum layak diimplementasikan, maka prioritasnya akan tetap rendah. Oleh karena itu, sangat penting untuk memasukkan setiap kalimat ke dalam sistem - bahkan tanpa penjelasan rinci tentang "cara kerjanya". Hanya dengan pendekatan ini Anda dapat merencanakan implementasi fitur yang diminta - yaitu, membuat Peta Jalan yang sebenarnya.
Semua ide datang ke apa yang disebut "Backlog masuk", mereka dapat diformalkan atau "mentah", tanpa evaluasi dan pemahaman siapa yang membutuhkan fitur ini. Setelah mengerjakan permintaan dan menambahkan detail, beberapa di antaranya dapat pergi ke rilis berikutnya. Sisanya akan dikirim ke Backlog dan saya bisa tinggal di sana untuk waktu yang lama.
Epik
Metodologi Agile atau Scrum menyiratkan istilah seperti "Epic". Untuk menjelaskan esensinya sesederhana mungkin, maka kita berbicara tentang beberapa fitur besar, yang implementasinya membutuhkan keterlibatan semua peserta - pengembang, penguji, perancang antarmuka, penulis teknis, dan sebagainya.
Biasanya, saat membuat epik, pentingnya dari sudut pandang bisnis dinilai, biaya tenaga kerja dihitung, dan keputusan dibuat apakah akan memasukkannya ke dalam rilis saat ini atau mengirimkannya ke backlog.
Untuk epos yang sudah dinilai, Anda dapat menetapkan prioritas di sistem. Misalnya, di Jira yang sama, Anda dapat menyetel "tinggi", "sedang", atau "rendah". Namun, misalnya, dalam backlog Acronis kami terdapat ratusan bahkan ribuan fitur. Dalam hal ini, prioritas sederhana sangat diperlukan.
Menghitung Skor Fitur
Metodologi penilaian yang lebih kompleks disebut Skor Fitur. Idenya adalah untuk membawa semua faktor yang mempengaruhi pembangunan menjadi satu peringkat. Kemudian, berdasarkan rating yang dinormalisasi, buat keputusan tentang menyertakan fitur dalam rilis atau mengabaikan pengembangan saat ini. Dengan demikian, metrik positif menambahkan poin ke fitur, sedangkan metrik negatif bertindak dengan proporsi terbalik (lebih banyak nilai - poin lebih sedikit). Beberapa metrik positif meliputi:
1. Urgensi.
2. Besar kecilnya klien yang membutuhkannya.
3. Meningkatkan pangsa pasar karena munculnya pelanggan baru.
4. Potensi keuntungan atau kerugian dari meninggalkan klien saat ini.
5. Prestasi Strategis (tujuan yang membawa kita pada perwujudan Visi).
Metrik negatif:
1. Besarnya biaya tenaga kerja.
2. Risiko potensial.
Skor Fitur harus berupa angka. Ini bukan penilaian kualitatif, tetapi semacam penilaian, dan metode penghitungannya harus disatukan dan disetujui dalam kerangka pengembangan produk tertentu.
Poin ditentukan berdasarkan nilai yang dinormalisasi, tujuan pasar perusahaan, dan parameter lainnya. Parameter pertama yang diperhitungkan dalam Skor Fitur adalah faktor pelanggan. Faktor Pelanggan yang disebut didefinisikan sebagai produk urgensi dan ukuran pelanggan. Anda bisa melihat contoh perhitungan pada gambar di bawah ini.
Penetrasi Pasardidefinisikan sebagai kemungkinan menarik pelanggan baru dan bergantung pada rencana Anda untuk memperluas basis pelanggan. Misalnya, untuk fitur yang tidak akan menarik pelanggan baru, parameter ini bisa sama dengan 0, dan untuk fitur yang dapat menghasilkan, katakanlah, 500 pelanggan, skornya akan menjadi 20.
Pertanyaan berikutnya adalah kepatuhan strategi. Untuk mengevaluasi Strategi, Anda perlu memeriksa apakah fitur tersebut membantu Anda bergerak di sepanjang arah pengembangan strategis. Dan semakin banyak arah yang dicakupnya, semakin tinggi skornya.
Pendapatan adalah potensi keuntungan yang dapat diberikan oleh penerapan fitur. Estimasi parameter ini bergantung pada ukuran perusahaan, karakteristik produk, dan pendapatan yang ingin Anda terima. Tabel menunjukkan contoh penilaian untuk indikator ini.
Tapi sekarang mari kita bicara tentang faktor-faktor yang berlawanan, yang memberikan lebih sedikit poin pada fitur, semakin mereka terwujud. Misalnya, biaya pengembangan juga dapat ditetapkan untuk perusahaan Anda pada tingkat perkiraan tertentu, tergantung pada seberapa banyak Anda bersedia mengeluarkan biaya untuk pengembangan fitur tertentu.
Risiko adalah aspek kedua. Semakin rendah kepercayaan diri Anda dalam penilaian, semakin tinggi risikonya, yang berarti semakin rendah nilai kriteria dalam rumus Skor Fitur.
Setelah memperhitungkan semua faktor yang disebutkan, rumus Skor Fitur mungkin terlihat seperti ini:
Baik jika skornya objektif, berdasarkan faktor tertentu. Tetapi jika Anda baru memasuki pasar, tetap buat Skor Fitur. Lebih baik bersikap subjektif daripada tidak sama sekali.
Peta jalan pada contoh aplikasi Taksi
Di salah satu postingan sebelumnya , kita sudah membahas tentang membuat aplikasi untuk memanggil taksi. Misalkan kita perlu memberi peringkat fitur berikut untuk produk ini:
Tabel dengan prioritas mungkin terlihat seperti ini:
Pertimbangkan fitur "Pesan berdasarkan waktu yang tepat". Menjumlahkan semua parameter, kita mendapatkan 56. Apa arti angka ini? Tidak ada! Ini adalah peringkat relatif, dan kami perlu menghitung semua 9 fitur, dengan mengikuti kriteria dan peringkat yang sama. Hasilnya adalah daftar prioritas. Dalam aplikasi kami, kami jelas perlu membuat aplikasi seluler di Android. Langkah kedua adalah tarif "Anak-anak".
Pendekatan sistematis memungkinkan untuk tidak melakukan apa yang tidak begitu penting untuk bisnis dan tidak memilih "fitur acak" untuk implementasi. Pengembalian pekerjaan bertahap dan bertahap akan lebih tinggi. Dan ini sangat penting, karena selalu ada faktor penghambat perkembangan setiap proyek: waktu, biaya, volume. Kombinasi yang memberi Anda kualitas.
Bukan hanya prioritas
Perencanaan rilis memperhitungkan kapasitas tim pengembangan. Beberapa produk memiliki lebih dari satu perintah seperti itu. Misalnya, untuk membuat layanan pemesanan taksi, setidaknya harus ada perintah backend, QA, Android, iOS.
Namun selain memprioritaskan, kami juga harus memperkirakan berapa jam yang dapat dialokasikan developer untuk mengerjakan setiap fitur berikutnya. Untuk melakukan ini, Anda perlu mengalikan jumlah orang dalam tim dengan jumlah hari yang dialokasikan untuk persiapannya. Memahami apa yang dapat dimasukkan ke dalam kapasitas yang tersedia untuk rilis (cakupan) berikutnya membantu menghindari pemborosan sumber daya.
Kapasitas tim yang berbeda untuk satu siklus rilis:
Jika Anda melihat tabel di bawah ini, jelas terlihat bahwa banyak sumber daya yang dibutuhkan untuk aplikasi seluler untuk iOS, tidak hanya tim pengembangan iOS, tetapi juga spesialis backend dan QA. Oleh karena itu, masuk akal bagi manajemen untuk mengambil keputusan untuk tidak menyertakan aplikasi seluler untuk iOS pada rilis pertama, karena tim tidak akan punya waktu untuk membuatnya, tetapi di sisi lain, mereka akan menyelesaikan “Pemesanan taksi pada waktu yang tepat”.
Jadi, jika kita mengikuti urutan prioritas semua fitur yang diurutkan, maka peta jalan untuk pengembangan aplikasi dengan memesan taksi akan terlihat seperti ini:
Setiap versi berikutnya akan menyertakan fitur prioritas berikutnya yang ditempatkan dalam kapasitas tim pengembang.
Roadmap - sebagai filosofi pengembangan produk
Ingatlah bahwa Roadmap bukanlah komitmen, melainkan prediksi. Saya akan menyarankan untuk memperlakukan peta jalan sebagai rencana saat ini. Ada kemungkinan dalam sebulan klien baru akan datang dan meminta fitur baru. Dan saat kami menambahkannya ke backlog, prioritasnya mungkin akan lebih tinggi dari apa pun yang direncanakan sebelumnya. Sebagai aturan umum, ketika mengerjakan sebuah produk, penting untuk memiliki Roadmap setiap saat, tetapi Anda tidak boleh membuatnya statis, karena saat ini Anda perlu beradaptasi dengan kondisi pasar yang berubah.
Pekerjaan yang diusulkan dengan peta jalan (memprioritaskan fitur sesuai dengan aturan umum) membutuhkan budaya internal. Semua pemangku kepentingan harus mengikuti prinsip penilaian yang sama, jadi langkah pertama adalah membahas rumus penghitungan dan kemudian mengikuti aturan ini. Tentu saja, semuanya bisa diubah jika ada pemahaman tentang bagaimana meningkatkan prioritas, tapi kemudian perlu menghitung ulang prioritas untuk keseluruhan backlog.
Untuk produk besar, juga disarankan untuk mengalokasikan kapasitas tim pengembangan yang berbeda untuk hal-hal yang tidak terkait langsung dengan pengembangan fitur kustom .) dibelanjakan untuk memelihara ekosistem yang ada di versi lama ”. Untuk mengatasi masalah tersebut, Anda dapat mengalokasikan, misalnya, 25% dari kapasitas tim untuk fitur yang terkait dengan memenangkan pelanggan baru, 45% untuk retensi pelanggan saat ini, 20% untuk hutang teknis dan refactoring, dan 10% untuk penyangga sehingga ada ruang untuk fitur. yang datang tiba-tiba atau overhead untuk memperhitungkan aktivitas yang tidak terkait langsung dengan pengembangan produk (penerapan sistem build baru, implementasi CI \ CD, dan sebagainya).
Kesimpulan
Untuk berhasil merencanakan pengembangan dan menyesuaikan roadmap, Anda perlu meninjau backlog Anda secara berkala dan menghitung ulang skor fitur untuk fitur-fitur yang Anda rencanakan untuk dikembangkan dan ingin mereka dalam cakupan rilis. Tetapi jika kita telah memutuskan rilis berikutnya, maka perlu untuk membangun interaksi antara manajer dan pengembang.
Untuk melakukan ini, pada posting berikutnya kita akan melihat mekanisme pembuatan persyaratan untuk fitur yang perlu diatur oleh departemen pengembangan. Ini diperlukan agar fitur dapat dikembangkan, sebaiknya dalam bentuk yang Anda inginkan untuk melihatnya. Kami akan berbicara tentang mengapa persyaratan harus jelas, bagaimana persyaratan itu harus diformalkan, dan praktik apa yang ada untuk bekerja dengan persyaratan untuk pengembang.
→ Rekaman video dari semua perkuliahan tersedia di YouTube
Kuliah tentang peta jalan dan persyaratan untuk pengembangan: