Halo, Habr! Seperti yang sudah saya janjikan di postingan sebelumnya , saya terus memperkenalkan Anda kepada Delivery Club Tech. Hari ini kita akan berbicara tentang transformasi produk.
Kebetulan, kedatangan saya di DC pada Oktober 2018 ditandai dengan restrukturisasi total semua proses dalam tim. Pada saat itu, departemen TI, dan bahkan seluruh perusahaan, menghadapi tantangan baru. Jelas bahwa proses lama tidak memenuhi persyaratan baru. Mereka terutama memperhatikan penurunan Time to Market.
Ini tentang perubahan ini, tantangan baru, struktur tim baru, bagaimana kita bekerja tanpa manajer proyek dan analis teknis, dan tentang pendekatan pengembangan produk yang ingin saya sampaikan kepada Anda hari ini.
Pada Oktober 2018, saya menjabat sebagai Head of Consumer. Ini adalah awal perjalanan saya ke Delivery Club. Tim produk harus dirakit sesuai arahan, menjelaskan proses, memformalkannya, dan menskalakannya ke semua area lainnya. Selain itu, tugasnya adalah mendapatkan metrik kinerja untuk tim dan mengembangkan kerangka kerja perekrutan dari awal.
Fitur Tim
Tantangan terpenting adalah mencapai prediktabilitas dan transparansi dari proses pembangunan. Situasinya diperumit oleh fakta bahwa tidak ada metrik kinerja pada saat itu. Tapi yang pasti: rilis tidak terjadi secara berkala, dan komposisinya jelas hanya pada saat rilis itu sendiri.
Masalah lainnya adalah tim tidak dibentuk di sekitar produk. Komunikasi yang rumit dengan bisnis ini, karena pengembang yang sama dapat berpartisipasi dalam proyek yang sama sekali berbeda, tidak ada fokus yang jelas pada tugas tertentu. Oleh karena itu, pada awalnya diputuskan untuk membangun kembali struktur departemen TI dan berpindah dari tim platform ke tim produk.
Dengan pendekatan platform, orang-orang bagian belakang duduk terpisah, bagian depan duduk terpisah, dan setiap tim memiliki pemimpin tim yang membagikan tugas. Kekurangan yang jelas dari struktur ini: pengembang tidak tenggelam dalam proses dan produk, mereka tidak tertarik pada tujuan bersama, tim memiliki fokus yang berbeda, dan tidak ada sumber daya khusus untuk produk juga. Akibatnya, pengembang tidak fokus, tujuan tetap tidak tercapai. Meskipun secara ajaib tujuan dapat dicapai, kurangnya komunikasi antara manajer produk dan pemangku kepentingan seringkali ternyata tidak seperti yang direncanakan semula.
Hal pertama yang diputuskan untuk dilakukan: satu tim - satu produk. Sumber daya dialokasikan, yaitu, tim melakukan tugas hanya untuk produk ini dan tidak untuk yang lain. Tim yang mengerjakan produk serupa membentuk arah pengembangan. Transformasi pertama menghasilkan 4 arah:
- Konsumen
- Logistik
- Penjaja
- Intern
Hal kedua yang harus dilakukan adalah: menugaskan manajer produk ke setiap tim. Dia juga salah satu tim. Manajer produk mengembangkan strategi untuk perubahan produk, membentuk metrik produk yang menjadi fokus tim, dan menetapkan tujuan untuk sprint.
Hasilnya, kami mendapat sel berikut: "Manajer Produk - Pimpinan Tim - Dev - QA". Kami menyertakan pengembang backend dan front end sebagai pengembang, tetapi ada juga tim tanpa front. Frontender adalah Web Angular dan JS, atau iOS / Android.
Sekarang setiap tim rata-rata beranggotakan 5 ± dua orang. Mengapa demikian? Kami tidak sampai pada formula ini sekaligus. Statistik kami menunjukkan bahwa komposisi tim inilah yang memungkinkan Anda mencapai hasil yang paling dapat diprediksi. Artinya, tim tersebut dapat menggunakan fitur yang cukup untuk membuat perubahan signifikan pada produk, tetapi pada saat yang sama kerumitan perencanaan tetap lebih rendah daripada jika melibatkan lebih banyak orang. Artinya, kesalahan perencanaan menjadi minimal.
Untuk sementara waktu kami bereksperimen dengan peran dalam tim, kami memiliki pemimpin tim pengembangan seluler (iOS / Android) dan pemimpin tim backend. Tapi kami berakhir dengan struktur matriks:
- Salah satu pemimpin tim (biasanya, seseorang dari backend), dia memiliki QA, backend dan penyedia front-end di bawah pelaporan langsungnya.
- product- « — — QA».
- — . . , QA- , CI/CD, QA- .
- - , .
- .
Fitur lain dari kami: kami tidak memiliki manajer proyek dan analis teknis. Ini awalnya terjadi di Delivery Club, dan kami memutuskan bahwa kami tidak akan mengubahnya. Ingatkah kita memiliki masalah dengan tim yang berfokus pada produk? Jadi mengapa membuat perantara antara tim dan manajer produk? Penting bagi kami bahwa tim, pertama-tama, peduli tentang bagaimana fitur mereka memengaruhi pengguna akhir, dan tidak hanya menutup tiket di Jira. Untuk melakukan ini, orang perlu membenamkan diri dalam konteks, domain, bisnis, dan bahkan metrik produk dan metrik keuangan.
Hasilnya, dialog antara tim pengembangan dan manajer produk terus berlanjut. Pengembang tidak hanya mengambil daftar tugas dari manajer produk dan pergi untuk mengembangkan semua ini, tetapi mereka dapat mendatanginya dalam beberapa jam dan berkata, misalnya, "Hai, kita dapat membuat tombol di sini sedikit lebih sederhana, tetapi seminggu lebih cepat", tunjukkan pada angka, dan manajer produk akan berkata OK.
Oleh karena itu, tim teknis melakukan tugas analisis teknis, penilaian, dan dekomposisi secara mandiri, kemudian bersama dengan manajer produk merencanakan sprint. Agar ini berhasil, kami memulai sprint, seperti sebelumnya, seminggu sebelum dimulai. Ini adalah bagian selanjutnya.
Pengembangan dan perencanaan sprint
Pra-Perencanaan
Seminggu sebelum dimulainya sprint, manajer produk membawa kasus dan desain, menjawab pertanyaan "Apa yang perlu dilakukan?" Tim teknis memutuskan bagaimana akan melakukannya dan kapan semuanya akan siap.
Untuk melakukan ini, tim memiliki waktu seminggu, di mana pemimpin tim, pengembang, dan QA berkumpul, mendiskusikan detail teknis, melakukan dekomposisi, dan mengatur ulang dengan merencanakan poker untuk evaluasi. Selama periode ini, QA membuat daftar kasus uji, yang kemudian akan diuji.
Perencanaan
Setelah tim selesai melakukan dekomposisi dan penilaian, perencanaan dimulai. Semua tugas dibagi menjadi 8 jam. Untuk menghitung jumlah tugas dalam sprint, kami mengalikan jumlah karyawan dengan 80 jam dari iterasi dua minggu, mengalikan hasilnya dengan faktor fokus 0,8.
Tugas lebih lanjut dipukuli dalam ember, hanya ada tiga di antaranya:
- Produk 60%
- Utang teknologi 20%
- Mendukung 20%.
Izinkan saya memberi Anda sebuah contoh. Kami memiliki tim yang terdiri dari 3 pendukung. Ini adalah 80 * 3 * 0,8 = 192 jam kerja. Kami akan menghabiskan 116 jam (60%) untuk pengembangan produk, 38 jam untuk hutang Teknologi (20%), dan 38 jam untuk Dukungan (20%).
Dandan
Pada hari Senin kami menjadwalkan tugas, dan di tengah sprint, yaitu, seminggu kemudian, perawatan dilakukan. Kami menyebut grooming menganalisis hasil minggu pertama dan memutuskan apakah kami punya waktu untuk mencapai tujuan sprint atau sesuatu harus dihentikan. Jika tujuan tercapai, maka manajer produk mempresentasikan rencana untuk sprint berikutnya pada pertemuan yang sama, dan seluruh siklus berulang.
Demo
Akhir sprint yang logis adalah Demo, di mana kami mengundang semua tim pengembangan, pemangku kepentingan, kolega dari bisnis dan bahkan kepala Klub Pengiriman.
Kolega yang bertanggung jawab atas rilis menyiapkan presentasi, berbicara tentang pencapaian sprint dan kesulitan yang telah diatasi. Kami membagikan kisah produk dan wawasan tentang bagaimana fitur baru akan bermanfaat bagi pengguna.
Ini adalah hari yang penting bagi seluruh tim!
Retro
Bagi kami, retro adalah salah satu cara untuk meningkatkan efisiensi. Pertama-tama, kami melihat metrik kinerja tim, seberapa sukses kami menutup sprint. Kami memeriksa rasio tugas dalam status selesai dengan tugas yang diambil pada awal iterasi, dan memperbaiki data ini dengan keranjang.
Sebagai contoh, pada Product kami mengambil 20 soal dan menyelesaikan 17. Oleh karena itu, tingkat keberhasilan bucket ini adalah 85%. Kemajuan yang baik dalam pengembangan produk bagi kami adalah indikator 90% atau lebih. Jika lebih rendah, kami menganalisis di Retro bagaimana metrik ini dapat ditingkatkan.
Pekerjaan sprint
Kami sering ditanya tentang peninjauan kode dan cara kerja pengujian. Semuanya cukup standar di sini.
Hari dimulai dengan stand-up. Selama 15 menit, tim membahas apa yang mereka lakukan kemarin dan apa yang akan mereka lakukan hari ini.
Kami menggunakan Jira Flow dan Git Flow untuk mengerjakan tugas, kami memiliki tumpukan Atlassian. Ada juga papan Scrum dengan kolom untuk dikerjakan - dalam proses - siap untuk peninjauan kode - siap untuk QA - siap untuk hidup - selesai.
Saat pengembang telah menyiapkan kode, dia membuat cabang dengan nomor terbitan saat ini di Jira - ini adalah cabang fitur. Dia juga mengirimkannya ke permintaan tarik di Bitbucket. Pengembang membutuhkan setidaknya dua persetujuan. Kami juga memiliki integrasi dengan Jenkins, jika build berwarna hijau, Anda dapat menggabungkan. Pimpinan bagian teknis dan ketua tim memiliki hak untuk bergabung. Terkadang Anda perlu mempersiapkan unit-test untuk permintaan tarik. Dan terkadang kami sengaja tidak menuliskannya jika kami mengetahui bahwa ini adalah area bisnis yang tidak kritis, domain yang tidak kritis, atau fitur eksperimental, dan kami kemudian dapat menghentikannya.
Ketika semuanya berbau busuk, kami mengirimkannya untuk pengujian. Seorang insinyur pengujian menulis autotests atau menjalankan kasus pengujian secara manual. Tergantung lagi pada seberapa kritis domain tersebut. Lalu terapkan.
Kita dapat mengatakan bahwa proses ini bekerja seperti sebuah jam. Namun nyatanya, saat ini ada komunikasi yang konstan di dalam tim. Fokus utamanya adalah tujuan sprint dan rilis tepat waktu. Untuk mencapai tujuan tersebut, kami dapat mendiskusikan perubahan produk atau merevisi implementasi teknis. Semua ini terjadi saat mengerjakan tugas - selalu ada dialog antara pengembang, pimpinan tim, manajer produk, dan QA.
Arah pengembangan dan struktur departemen TI
Dalam proses transformasi, kami sampai pada struktur baru arah pembangunan. Seperti yang Anda ingat, pada awalnya kami menulis sekitar empat. Lebih lanjut, menjadi jelas bahwa untuk implementasi tujuan yang berkualitas tinggi dan tepat waktu, dua area lagi perlu diidentifikasi. Jadi, sekarang ada 6 di antaranya:
- Konsumen adalah segalanya tentang produk khusus: situs web dan aplikasi seluler.
- Logistik - tentang ahli logistik, kurir dan pengiriman.
- Vendor - tentang integrasi dengan mitra kami (restoran / toko).
- Internal - pusat panggilan dan dukungan.
- R&D - menyelesaikan tugas-tugas intensif sains.
- Platform - meningkatkan arsitektur dan platform secara keseluruhan.
Setiap arah memiliki jangkauan tugas dan kesulitannya sendiri-sendiri.
Konsumen
Prioritas arah ini adalah kebahagiaan pengguna. Metrik produk utama ada di sini: retensi, tingkat konversi pesanan, NPS konsumen. Dari segi teknis, penting bagi kami agar semua data dikirim dengan cepat. Dalam arah ini, mungkin, beban tinggi terbesar, karena kami bekerja secara langsung dengan pengguna akhir. Dan ada juga sejumlah besar layanan mikro, sebagian besar di sini.
Produk utamanya adalah situs web, termasuk versi seluler, serta aplikasi untuk iOS dan Android. Dua arus utama adalah pengiriman bahan makanan dan pengiriman restoran. Tumpukan teknologi plus atau minus seperti di tempat lain: PHP, Go, Postgres, Redis dan Memcache untuk cache, Kafka untuk komunikasi asinkron.
Logistik
Tugas arahan ini adalah untuk memastikan pengiriman cepat pesanan ke pengguna yang lapar. Selain itu, kami sedang mengembangkan antarmuka untuk dispatcher yang, jika perlu, membantu kurir dengan kontrol manual.
Salah satu tantangan utama dalam logistik muncul ketika jumlah pesanan bertambah, dan dengan itu beban pada sistem. Untuk mengatasi beban, Anda perlu melakukan perubahan kualitas pada arsitektur. Selain itu, pengiriman makanan sangat berbeda dengan pengiriman, misalnya perlengkapan kantor, pakaian, buku, dan lainnya. Semuanya sedikit lebih sederhana di sana: kami membuat lembar rute, merencanakannya, dan pergi.
Dengan pengiriman makanan, jumlah seperti itu tidak akan berfungsi. Kami semua sesuai permintaan, situasinya berubah setiap 5-15 menit. Saat mulai hujan atau turun salju, permintaan selalu meningkat. Dan ketika cuaca cerah di luar dan Anda tidak ingin tinggal di rumah, permintaan menurun. Pada hari libur dan akhir pekan, profil permintaan berbeda dari hari kerja. Situasi lalu lintas dan kemacetan juga membuat penyesuaian sendiri-sendiri, terutama di daerah-daerah yang banyak dilalui jasa angkutan mobil / motor. Jam pagi, siang dan malam hari memiliki profil permintaan yang berbeda.
Migrasi permintaan ini dilacak oleh monitor kami. Jika permintaan menurun, kami mengubah hasil pencarian, memberikan penawaran yang lebih relevan di bagian "Promosi". Untuk meningkatkan relevansi, kami menghubungkan model ML yang membuat penyortiran dipersonalisasi baik untuk pengguna dan untuk zona logistik tempat kami mengamati perubahan.
Salah satu aplikasi utama yang sedang dikerjakan di bidang logistik adalah Aplikasi Pengendara. Ini adalah aplikasi Android di mana kurir dapat melihat ke mana harus mengambil pesanan dan ke mana harus dikirimkan.
Penjaja
Area ini bekerja dengan mitra internal kami: restoran dan toko. Atau lebih tepatnya, dengan manajer mereka, yang mengelola menu melalui akun pribadi mereka dan bereaksi terhadap statistik dalam hasil pencarian.
Berkat data dan statistik pesanan yang dikumpulkan, kami memiliki pemahaman yang baik tentang target audiens dan karakteristik restoran. Kami bekerja sama dengan mereka dalam kemitraan dan memberi mereka alat yang membantu mereka lebih memahami siapa pelanggan mereka dan memungkinkan mekanisme pemasaran. Kami juga membantu restoran mengembangkan model pengoptimalan harga, memahami hidangan mana yang terbaik untuk ditampilkan pada saat apa dan dalam urutan apa.
Produk lain yang sedang dikerjakan ke arah Vendor adalah dasbor, di mana pesanan untuk dapur jatuh. Dapur menerima pesanan, melihat komposisinya, menentukan bagaimana menyiapkannya dan, nyatanya, menyiapkannya. Saat pesanan disiapkan, dapur mengonfirmasi ini di aplikasi dan mentransfer pesanan ke kurir. Dan kemudian kurir bekerja dengan Aplikasi Pengendara.
Intern
Area ini bertanggung jawab atas alat untuk pusat panggilan kami, yang menyediakan dukungan pengguna. Sebenarnya, ini adalah "area admin" untuk segala sesuatu yang berhubungan dengan pesanan. Operator dapat membantu klien, memberikan informasi tambahan tentang status pesanan saat ini, melakukan penyesuaian pesanan sebelum dikirim ke restoran.
Tantangan dari arahan ini adalah membuat sistem seperti itu, yang pertama, nyaman dan mencakup semua kebutuhan operator, dan kedua, cepat, karena klien perlu dibantu secepat mungkin. Selain tugas utama, orang-orang dari Internal bekerja untuk mengurangi waktu pemrosesan satu masalah oleh operator dan mengurangi jumlah panggilan.
R&D
Saat Anda perlu mengubah proses bisnis dan pada saat yang sama memahami bagaimana perubahan ini akan memengaruhi seluruh platform secara keseluruhan, Riset & Pengembangan dilibatkan. Orang-orang melakukan eksperimen, membuat model, menghitung dan menimbang. Mereka juga berinteraksi paling dekat dengan departemen BI, tempat mereka bekerja dengan big data, model ML, merancang jaringan saraf, dan memperkirakan permintaan. Dalam kaitan ini, BI membantu R&D dengan penelitian dan perangkat.
Penelitian terutama tentang bekerja dengan data. Misalnya, bagaimana sistem akan berperilaku jika Anda mengubah beberapa faktor. Sebagian besar tugas untuk R&D sekarang berasal dari logistik, karena area ini memiliki tingkat ketidakpastian tertinggi.
Peron
Ini adalah arahan teknis. Pertama-tama, orang-orang itu bertujuan untuk meningkatkan inti sistem, memfaktorkan ulang pemrosesan pesanan, dan menguraikan monolit kami. Ini bukan pengembangan produk dalam arti klasik, tetapi semua peningkatan dengan satu atau lain cara bertujuan untuk membuatnya lebih nyaman dan lebih mudah bagi pengguna untuk berinteraksi dengan aplikasi Delivery Club: kurangi waktu respons sehingga halaman terbuka lebih cepat, tingkatkan kapasitas platform sehingga lebih banyak pengguna dapat melakukannya memesan dan pada saat yang sama pengalaman penggunaan senyaman mungkin bagi mereka.
Hasil transformasi dan tantangan baru
Tugas kami adalah membangun proses pengembangan yang akan memenuhi semua persyaratan perusahaan yang sedang berkembang: tim terlibat dalam bisnis, banyak berkomunikasi satu sama lain, bertanggung jawab atas tenggat waktu yang ditetapkan oleh mereka sendiri, dan memahami bagaimana pekerjaan mereka memengaruhi pengguna akhir. Prosesnya harus transparan, terukur, dan yang terpenting, dapat diskalakan.
Setelah melakukan transformasi produk dan mengoptimalkan proses pengembangan, kami sampai pada kesimpulan bahwa setiap rilis kami dapat diprediksi. Pada awalnya, kami mengetahui dengan akurasi 80% kapan dan dalam komposisi apa rilis tersebut akan dirilis. Sekarang, indikator kinerja rata-rata di semua tim dalam departemen telah berkembang menjadi 90%. Keterlibatan tim, yaitu motivasi orang-orang, telah meningkat pesat, mereka memahami apa yang mereka lakukan dan mengapa, kepada siapa itu penting.
Prosesnya mencakup kemampuan untuk menanggapi tugas secepatnya tanpa mengganggu pengembangan produk, ada cukup poin komunikasi untuk memperkirakan biaya tenaga kerja secara fleksibel dan merespons perubahan persyaratan dari manajer produk secara tepat waktu. Dalam praktiknya, kami memastikan bahwa prosesnya dapat diskalakan: kami berhasil berkembang dari 40 orang menjadi 170 dengan proses pengembangan yang sama dan tanpa kehilangan kinerja.
Di saat yang sama, kami tidak berhenti dan percaya bahwa transformasi produk masih terus berlangsung. Di akhir 2019, kami mulai memikirkan tentang bagaimana tim dapat lebih memengaruhi bisnis. Tim memiliki banyak keahlian produk, tampaknya Anda bisa menggunakannya, munculkan semacam simbiosis Teknologi dan Bisnis. Selain itu, kami perlu menemukan mekanisme untuk memverifikasi hipotesis produk. Artinya, untuk mengontrol nilai tugas yang termasuk dalam pengembangan kita. Untuk melakukan ini, kami menjelaskan proses GIST - kerangka kerja untuk memverifikasi hipotesis produk, yang akan kami diskusikan di salah satu artikel berikut.
Terima kasih sudah membaca!