Apakah Team Ramp Up Menjamin Peningkatan Kecepatan Fitur?

Diterbitkan: 2020-03-28

Salah satu kunci penting saat meningkatkan tim untuk meningkatkan kecepatan rilis adalah transfer kejelasan dari tim produk ke tim sprint

Eksekusi sprint yang mulus adalah hasil dari kontribusi penting yang datang dari produk dan tim sprint

Filosofi 'first-time-right (FTR)' membantu semua anggota tim untuk menyelaraskan ke tujuan bersama

Ketika startup bergerak dari awal ke tahap pertumbuhan, prioritas mereka berubah secara signifikan. Di antara yang lainnya, kecepatan fitur menonjol sebagai prioritas dan memainkan peran penting dalam mengejar pertumbuhan mereka.

Pendiri startup yang didanai benih tempat saya bekerja, yang baru-baru ini meningkatkan putaran seri A, meminta saya untuk menggandakan tim teknik untuk merilis fungsionalitas baru dalam enam bulan. Namun, apakah itu satu-satunya faktor yang relevan dalam mengurangi waktu siklus? Untuk menjawabnya, saya memutuskan untuk membahas aspek-aspek yang diabaikan di balik 'kesalahpahaman' yang lazim ini.

Meskipun kapasitas sumber daya adalah salah satu faktor penting yang mendorong rilis yang sering ke produksi, ini saja tidak dapat menjamin pengurangan waktu siklus. Saat membangun produk untuk lebih dari 16 startup, saya telah menyaksikan transisi dari tahap awal ke tahap pertumbuhan beberapa kali. Dari pengalaman ini, berikut adalah beberapa faktor penting yang saya bagikan untuk dipertimbangkan oleh para pendiri startup.

Meneruskan Kejelasan: Esensi Top-Down

Salah satu kunci penting saat meningkatkan tim untuk meningkatkan kecepatan rilis adalah transfer kejelasan dari tim produk ke tim sprint. Ketika sprint dimulai dengan ambiguitas atau tidak memiliki cukup cerita untuk memulai, rasio pengiriman sprint akan terpengaruh. Cerita yang tidak jelas atau penyertaan tugas di tengah sprint memperlambat langkah, akibatnya tim sprint gagal memberikan hasil sesuai rencana.

Eksekusi sprint yang mulus adalah hasil dari kontribusi penting yang datang dari produk dan tim sprint. Tim produk dapat memainkan perannya dengan mempersiapkan dan membagikan peta jalan kepada tim sprint setidaknya untuk kuartal tersebut sehingga tim dapat merencanakan hasil yang sesuai.

Di sisi lain, tim sprint harus terus mendorong tim produk untuk mendapatkan backlog produk dan merawatnya setiap minggu/dua mingguan untuk memastikan pengiriman yang terfokus.

Otomatiskan Untuk Melepaskan 'Bebas Bug'

“Efisiensi adalah melakukan sesuatu dengan benar; efektivitas adalah melakukan hal yang benar.” – Peter Drucker

Ketika Anda memikirkan otomatisasi, ini adalah contoh dari kategori yang terakhir. Saat pengembangan fitur bertambah cepat, kemungkinan besar produksi akan gagal kecuali proses yang tepat dilakukan. Jika produk tidak cukup stabil untuk menangani pengembangan fitur baru, tim Anda menghabiskan lebih banyak waktu untuk memperbaiki masalah daripada membangun fitur baru. Akibatnya, kecepatan rekayasa Anda turun.

Di sinilah CI/CD (integrasi berkelanjutan dan penyebaran berkelanjutan) muncul. Di sini, unit lengkap, integrasi, dan cakupan uji otomatisasi memastikan bahwa apa pun yang dikirimkan tidak merusak sistem.

Direkomendasikan untukmu:

Bagaimana Kerangka Agregator Akun RBI Ditetapkan Untuk Mengubah Fintech Di India

Bagaimana Kerangka Kerja Agregator Akun RBI Ditetapkan Untuk Mengubah Fintech Di India

Pengusaha Tidak Dapat Menciptakan Startup yang Berkelanjutan dan Terukur Melalui 'Jugaad': CEO CitiusTech

Pengusaha Tidak Dapat Menciptakan Startup yang Berkelanjutan dan Skalabel Melalui 'Jugaad': Cit...

Bagaimana Metaverse Akan Mengubah Industri Otomotif India

Bagaimana Metaverse Akan Mengubah Industri Otomotif India

Apa Arti Ketentuan Anti-Profiteering Bagi Startup India?

Apa Arti Ketentuan Anti-Profiteering Bagi Startup India?

Bagaimana Startup Edtech Membantu Meningkatkan Keterampilan & Mempersiapkan Tenaga Kerja untuk Masa Depan

Bagaimana Startup Edtech Membantu Tenaga Kerja India Meningkatkan Keterampilan & Menjadi Siap Masa Depan...

Saham Teknologi Zaman Baru Minggu Ini: Masalah Zomato Berlanjut, EaseMyTrip Posting Stro...

Jangan Hanya Membangun Lebih Banyak, Jika Tidak, Anda Lebih Banyak Menghancurkan

Pengerjaan ulang adalah pembunuh produktivitas yang besar dan dapat menjadi hasil dari berbagai faktor seperti cerita yang tidak jelas, kurangnya pengujian pengembang, kurangnya cakupan pengujian, dan sebagainya. Pengerjaan ulang dapat menghabiskan produktivitas karena akan menghabiskan waktu dan upaya insinyur QA dalam pengujian dan kemunduran, pengembang dalam debugging, dan manajer rilis dalam rilis ulang.

Memperlambat sedikit dapat membantu tim Anda memberikan lebih cepat dan menambah nilai, karena kecepatan efektif selalu lebih bermanfaat daripada hanya kecepatan.

Filosofi 'first-time-right (FTR)' membantu semua anggota tim untuk menyelaraskan dengan tujuan yang sama - memberikan kode yang kuat dan stabil untuk pertama kalinya. Itu selalu sehat untuk menghabiskan waktu ekstra untuk menentukan kualitas kode, daripada terburu-buru, dan kemudian terjebak dengan pengerjaan ulang.

Beberapa cara yang telah dicoba dan diuji untuk meningkatkan rasio FTR adalah perawatan backlog reguler, pengulangan cerita, demo reguler ke manajer produk. Daripada hanya mengumpulkan persyaratan, tim sprint harus lebih fokus menjelaskannya untuk meningkatkan rasio FTR.

Susun Tim Anda Untuk Sprint Paralel

Saat startup Anda memiliki tim produk kecil, kebanyakan orang mengerjakan satu atau dua fitur pada saat yang bersamaan (umumnya berlaku untuk tim yang terdiri dari 4-6 anggota). Namun, seiring meningkatnya harapan untuk menghadirkan banyak fitur, sangat disarankan agar Anda membentuk beberapa sub-tim yang memiliki area fokus berbeda. Dengan cara ini, setiap sub-tim dapat menjalankan sprintnya dan menentukan peta jalannya.

Dibandingkan dengan satu tim besar, tim yang lebih kecil yang lahir dari kerangka 'pemisahan logis' lebih efektif dan menghasilkan hasil yang lebih baik. Tim individu untuk layanan mikro, lini produk yang berbeda, dan berbagai komponen adalah beberapa contoh pendekatan 'pemisahan logis'.

Selama restrukturisasi, selalu penting untuk menyertakan setidaknya satu anggota dari tim inti sebelumnya di masing-masing sub-tim ini untuk mempertahankan DNA. Meskipun koordinasi lintas tim untuk pengiriman memerlukan biaya tambahan, itu adalah pertukaran yang dapat dibenarkan.

Lacak Penggunaan Fitur Seiring Dengan Kecepatan

Pengalaman pengguna adalah metrik paling vital untuk mengukur keberhasilan rilis fitur baru. Saat Anda mulai menghadirkan banyak fitur dengan cepat, pengalaman pengguna sering kali tidak diperhatikan. Ketika produk Anda memiliki fitur terbatas, interaksi pengguna terus menjadi kurva mulus yang tidak terputus.

Namun, saat Anda mulai merilis fitur baru, kemungkinan besar pengguna akan kewalahan dan pengalaman mereka akan terpengaruh.

Untuk mencapai adopsi pengguna yang lebih baik, melacak keterlibatan pengguna bersama dengan kecepatan fitur terus menjadi cara terbaik ke depan. Sementara penelitian pengguna yang menyeluruh adalah salah satu cara yang terbukti, yang penting lainnya diluncurkan pada awalnya untuk pengguna yang dipilih melalui tanda fitur, pengujian AB, dan pelacakan perjalanan pengguna (melalui amplitudo atau alat analitik serupa) setelah setiap rilis baru.

Jangan Kehilangan Anggota Inti Anda

Ini mungkin aspek yang sangat sering diabaikan namun tetap kokoh sebagai salah satu yang sangat penting. Tim kecil tidak selalu membutuhkan proses dan memiliki struktur yang gesit, dan suara semua orang didengar. Ketika tim ini naik ke keadaan di mana proses diatur dan anggota rekayasa & fungsional baru ditambahkan, manajemen yang sehat adalah satu-satunya cara untuk menghindari kekacauan.

Saat tim teknik Anda berhasil meningkat, tim produk yang berkemampuan baik sangat penting untuk memberi makan tim teknik secara terus-menerus. Sebuah churn menjadi tak terelakkan ketika anggota tim tidak memiliki pekerjaan yang signifikan, tetapi tidak ada startup yang ingin kehilangan anggota intinya. Dalam hal ini, manajemen senior memegang kunci untuk memastikan hubungan yang baik dengan orang-orang dan memahami dinamika dengan baik.

Pembelajaran yang saya bagikan di sini adalah dari pengalaman dengan beberapa startup selama bertahun-tahun. Saya berharap ini berguna bagi para pendiri startup, yang sudah memiliki banyak hal, dengan cara yang tidak membuat mereka menemukan kembali rodanya.