Anda mengelola tim terbaik perusahaan: waktu siklus tercepat, akurasi perencanaan tertinggi, dan pengerjaan ulang paling sedikit. Tim Anda memiliki waktu peninjauan terendah, penerapan mingguan terbanyak, dan rasio bug/KLOC terbaik. Dan kemudian seseorang yang tinggi menutup proyek Anda - apa yang baru saja terjadi?

Paradoks Keluaran

Sebagai developer junior, saya diajari bahwa sering menggabungkan perubahan kecil adalah kunci untuk memberikan nilai dengan cepat. Sebagai manajer teknik junior, saya diberi tahu bahwa pelacakan & pengoptimalan metrik sangat penting untuk pekerjaan manajer. Hasil google pertama mengarahkan saya ke banyak istilah dan akronim, dan ini adalah perkenalan pertama saya ke metrik dev.

Metrik pengembang pada dasarnya adalah kumpulan metrik yang membantu tim teknik melacak kecepatan (bergerak cepat) dan kualitas (tanpa merusak barang). Metrik yang berbeda dapat digunakan untuk mengukur atribut ini. Waktu siklus, hitungan PR, atau masalah tertutup melacak kecepatan. Untuk melacak kualitas, pantau jumlah cacat, waktu penyelesaian rata-rata, atau jumlah penerapan yang menyebabkan kegagalan. Setiap metrik ini akan memberikan wawasan berbeda tentang atribut yang Anda periksa. Beberapa metrik juga membantu menganalisis atribut proxy. Lacak pengerjaan ulang untuk menganalisis efisiensi, yang memengaruhi kecepatan. Ketepatan perencanaan adalah indikator prediktabilitas yang baik, yang memungkinkan kecepatan dan kualitas serta memiliki nilai tersendiri.

Masalah dengan semua metrik di atas adalah meskipun metrik tersebut melakukan pekerjaan yang sangat baik dalam mengukur efisiensi, metrik tersebut biasanya tidak cukup untuk mengukur kesuksesan. Alasan utamanya adalah bahwa mereka sepenuhnya terputus dari KPI bisnis (indikator kinerja utama, namun nama keren lainnya untuk metrik). Pemutusan ini sering menyebabkan komunikasi yang tidak efektif antar organisasi di perusahaan, terutama produk dan teknik. Lagi pula, organisasi produk (dan bagian bisnis lainnya) tidak hanya memedulikan kecepatan atau kualitas, seperti output jalur tersebut . Organisasi produk biasanya memperhatikan hasil — pendapatan apa yang dihasilkan fitur baru kami? Berapa banyak pengguna baru yang kami tarik?

Sebagai manajer teknik baru, ini membingungkan saya. Di satu sisi, jelas bahwa melakukan pengukuran tim saya berdasarkan metrik pengembangan daripada metrik bisnis akan menyebabkan ketidaksejajaran dengan tim produk. Di sisi lain, tampaknya tidak adil untuk mengukur tim saya berdasarkan metrik bisnis: Bagaimana pengaruhnya terhadap mereka? Apakah ini pekerjaan kita? Apakah saya akan menginjak kaki organisasi produk?

Ukur Yang Penting

Saya mengambil lompatan keyakinan dan mencoba menggunakan metrik bisnis sebagai bintang utara saya. Seiring berjalannya waktu, hal itu membuahkan hasil yang lebih baik.

Pertama, menyederhanakan komunikasi. lebih mudah bagi mitra produk Anda untuk memahami mengapa penting untuk memprioritaskan peningkatan DB ketika Anda memasukkannya ke dalam KPI bersama yang akan dirugikan. Hanya karena jelas bagi Anda bahwa jika Anda tidak memprioritaskan peningkatan DB, beberapa cerita pengguna berikut akan memakan waktu dua kali lebih lama, dan Anda harus menghabiskan waktu untuk pemeliharaan, yang akan menunda rilis fitur ke titik di mana Anda menang. tidak punya cukup waktu untuk mencapai target penggunaan yang Anda tetapkan sebagai KPI, tidak berarti itu jelas bagi mitra produk Anda. Maksud saya, itu banyak lompatan; mengapa tidak mulai dengan yang penting? (tidak, ini bukan upgrade DB)

Kedua, mengukur tim saya berdasarkan metrik bisnis membuat saya melihat bahwa kami dapat sedikit memengaruhi mereka:

• Kami dapat mengidentifikasi fitur di mana kami dapat membangun 80% nilai pengguna untuk 20% upaya. Ini dapat membebaskan sumber daya untuk membantu menggerakkan KPI kami lebih cepat. Untuk melakukannya, tim harus memahami dengan jelas tujuan bisnis, kebutuhan pengguna, dan dorongan untuk memperbaikinya.
• Kita dapat menggunakan KPI untuk memandu hutang teknologi apa yang harus kita kumpulkan: Apakah kita mencoba untuk mendapatkan pengguna fitur pertama kita, dan kegagalan fitur adalah sebuah pilihan? Ayo rilis secepat mungkin dan khawatirkan utang teknologi nanti. Apakah kita mencoba meningkatkan retensi basis pelanggan yang besar? Mari kita pastikan kualitas tinggi untuk yang satu ini.
• Kami dapat menyarankan solusi untuk produk poin rasa sakit yang bahkan tidak dapat dipecahkan, berdasarkan kemajuan teknologi baru atau sudut pandang teknik yang inovatif.
• Kami dapat (meskipun menjengkelkan) menggunakan KPI untuk memahami bahwa tidak ada gunanya mengejar solusi teknologi keren tertentu yang ingin kami terapkan karena masalahnya sendiri tidak krusial bagi bisnis.

Bagaimana Mengukur Kesuksesan?

Setelah beralih ke metrik yang penting bagi bisnis, rekan produk saya dan saya harus memilih kerangka kerja untuk mengukurnya. Di Epsagon, kami menggunakan kerangka kerja OKR . Saya tidak akan merinci karena ada banyak sumber daya bagus untuk menerapkan OKR yang tersedia secara online. Intinya adalah bahwa ini adalah kerangka kerja yang sangat baik untuk organisasi menengah hingga besar, biasanya dalam fase pasca-produk-pasar-cocok. Ini membantu menyelaraskan tim, grup, dan organisasi yang berbeda dalam bisnis menuju tujuan yang digerakkan oleh hasil yang sama.

Di Epsagon, kami memiliki OKR untuk setiap tim produk, dan itu adalah tujuan para insinyur, produk, dan orang desain yang membuat tim produk. Setelah diimplementasikan, kami memiliki kolaborasi yang lebih baik antara produk dan teknik. Lebih sedikit berdebat tentang persyaratan dan lebih banyak kerja sama untuk memecahkan masalah. Kami juga memperhatikan bahwa peningkatan otonomi yang disebabkan oleh penetapan tujuan di atas tugas meningkatkan inovasi dan kepemilikan atas hasil. Tim menetapkan peta jalan, dan solusi datang dari teknik serta produk.

Kelemahan dari metodologi ini adalah membutuhkan usaha dalam penerapannya dan juga mengharuskan Anda untuk dapat menyatakan tujuan Anda selama beberapa bulan. Ini biasanya sulit untuk perusahaan kecil, terutama sebelum produk-pasar-cocok. Untuk tahap awal, tidak apa-apa untuk bekerja dengan satu metrik utama dan tetap didorong oleh tujuan bisnis sambil tetap cukup gesit untuk mengubah tujuan dan fokus Anda dalam perincian minggu atau hari.

Apakah tim Anda besar atau kecil, miliki satu misi atau prioritas yang saling bersaing — selama Anda mengukur hal yang penting, Anda memiliki peluang sukses yang lebih tinggi. "Bagaimana" hanyalah pengoptimalan.

Komunikasi adalah Kunci

Setelah kami menetapkan KPI bisnis, langkah selanjutnya adalah menindaklanjuti. Dalam pengalaman saya, ada dua aspek penting untuk mengkomunikasikan dan mengimplementasikan perubahan ini. Yang pertama adalah konsistensi: tidak cukup hanya menetapkan metrik tersebut dan meninjaunya kembali tiga bulan kemudian untuk mengetahui bahwa kami melewatkan sasaran kami. Sebagai pemimpin, adalah tugas kami untuk terus memantau metrik ini dan memastikan status dan peta jalan mereka untuk memperbaikinya selalu dikomunikasikan ke seluruh tim kami.

Aspek kedua adalah komitmen: tergoda untuk kembali ke kebiasaan lama dalam mengukur individu menggunakan metrik dev untuk mengoptimalkannya. Ini akan mengirim pesan yang salah ke tim Anda, mengisyaratkan bahwa meskipun Anda mengatakan Anda peduli dengan KPI bisnis, yang sebenarnya Anda pedulikan adalah metrik pengembangan. Pastikan untuk mengubah kebiasaan Anda untuk mencerminkan prioritas Anda: rayakan hasil bisnis, hentikan fitur yang tidak harus dimiliki alih-alih mendorong tenggat waktu, dan angkat bendera saat KPI bisnis turun. Anda masih dapat menggunakan metrik dev sebagai indikator; ingatlah untuk menautkannya ke efeknya pada KPI bisnis.

Apakah Metrik Dev Tidak Digunakan Lagi?

Terlepas dari tajuk umpan klik dari artikel ini, jawabannya adalah tidak - mereka harus digunakan dengan benar. Pertama, metrik pengembang adalah alat yang ampuh untuk memecahkan masalah metrik bisnis Anda. Misalnya, penurunan retensi pengguna dapat dijelaskan dengan peningkatan jumlah kerusakan. Dalam hal ini, Anda dapat menggunakan metrik dev sebagai indikator utama: Daripada menunggu retensi turun, Anda harus memantau jumlah cacat untuk mencegahnya turun (serupa dengan cara Anda memantau penggunaan CPU untuk menghindari jumlah kesalahan API 5xx dari spiking dan menyebabkan kerugian yang sebenarnya bagi pengguna Anda). Kasus penggunaan lainnya adalah metrik dev sebagai indikator utama untuk pengalaman dan kepuasan developer (yang, pada gilirannya, memengaruhi retensi developer).

Namun, hal penting yang harus diingat adalah Anda tidak boleh mengoptimalkan metrik dev. Anda harus selalu mengoptimalkan metrik bisnis dan menggunakan pengoptimalan metrik dev hanya sebagai alat untuk mencapai tujuan tersebut. Dan, tentu saja, Anda hanya boleh menetapkan, melacak, atau mengoptimalkan sasaran metrik pengembang setelah Anda memiliki pemahaman yang jelas tentang hasil bisnis yang ingin Anda capai dan KPI bisnis yang ingin Anda capai. Statistik teknik yang bagus tidak akan menyelamatkan proyek Anda jika tidak memiliki nilai.

Apa berikutnya?

Jika Anda memimpin organisasi teknik, beralih ke pengoptimalan hasil bisnis melalui metrik pengembangan akan meningkatkan peluang tim Anda untuk menciptakan dampak nyata bagi bisnis. Jika Anda berkomitmen untuk menjadi pemimpin yang digerakkan oleh hasil, saya mendorong Anda untuk bertanya pada diri sendiri pertanyaan-pertanyaan ini:

• Apakah saya tahu hasil bisnis apa yang diharapkan dari saya?
• Apakah saya melakukan apa pun yang saya bisa untuk mengoptimalkan hasil ini?
• Bagaimana saya melacak kesuksesan? Apa kriteria untuk mengibarkan bendera atau mengubah rencana saya?
• Apakah tim saya mengetahui tujuan bisnis dan peta jalan untuk mencapainya? Apa masukan mereka tentang itu?
• Manakah dari KPI bisnis saya yang dapat ditingkatkan dengan meningkatkan metrik dev yang mana?