Mengukur produktivitas developer: studi kasus nyata dari Google, Notion, dan lainnya
(newsletter.pragmaticengineer.com)- Analisis mendalam tentang bagaimana 17 perusahaan teknologi seperti Google, LinkedIn, Peloton, Amplitude, Intercom, Notion, dan Postman mengukur produktivitas developer
1. Metrik produktivitas developer di 17 perusahaan teknologi
- Mengukur produktivitas developer adalah masalah yang kompleks, karena makna dari menjadi "produktif" dalam software engineering sebagai pekerjaan berbasis pengetahuan itu sendiri ambigu
- Tim yang disebut tim produktivitas developer (DevProd) atau pengalaman developer (DevEx) membantu developer agar dapat dengan mudah merilis software berkualitas tinggi
- Tim-tim ini memerlukan metrik produktivitas developer untuk mengukur produktivitas dan hambatan pada tim engineering, serta melacak apakah pekerjaan mereka benar-benar memberikan dampak
- Metrik produktivitas developer yang digunakan di perusahaan-perusahaan ini
- Kemudahan delivery (Amplitude, GoodRx, Intercom, Postman, Lattice)
- Kecepatan eksperimen (Etsy)
- Stabilitas layanan/aplikasi (DoorDash)
- Metrik SPACE (Microsoft)
- Waktu fokus mingguan per engineer (Uber)
- Empat kategori dipilih berdasarkan ukuran perusahaan
- Google: lebih dari 100.000 karyawan
- LinkedIn: lebih dari 10.000
- Peloton: 1.000 hingga kurang dari 10.000
- Scale-up (100 hingga kurang dari 1.000 engineer): Notion, Postman, Intercom, Amplitude, GoodRx, Lattice
2. Pendekatan Google
- Google sering disebut sebagai praktik terbaik dalam mengukur produktivitas developer, tetapi ada juga pandangan bahwa meniru tingkat investasi Google tidak mungkin dilakukan bagi sebagian besar perusahaan
- Developer Intelligence team Google adalah organisasi khusus yang mengukur produktivitas developer dan memberikan insight kepada para pemimpin
- Google percaya bahwa satu metrik tunggal tidak dapat menangkap produktivitas, dan melihat produktivitas melalui tiga dimensi: kecepatan, kemudahan, kualitas
- Speed kecepatan: berapa lama waktu yang dibutuhkan hingga code review selesai?
- Ease kemudahan: seberapa mudah atau sulit bagi developer untuk melalui proses code review?
- Quality kualitas: seperti apa kualitas feedback yang diterima melalui code review?
- Google menghitung metrik dengan menggabungkan pengukuran kualitatif dan kuantitatif
3. LinkedIn
- LinkedIn beroperasi secara independen di dalam Microsoft dan mempekerjakan lebih dari 10.000 karyawan
- LinkedIn memiliki tim Developer Insights yang mengukur produktivitas dan kepuasan developer serta menyampaikan insight ke organisasi lainnya
- LinkedIn menangkap metrik menggunakan survei triwulanan, sistem feedback real-time, dan metrik berbasis sistem
- Survei triwulanan:
- Tim Developer Insights menilai pengalaman developer di berbagai alat, proses, dan aktivitas melalui survei triwulanan
- Survei mencakup sekitar 30 pertanyaan dan developer dapat menjawabnya dalam waktu sekitar 10 menit
- Survei dikirim melalui platform proprietari yang dikembangkan dan dikelola oleh tim Developer Insights, dan pertanyaan survei dapat disesuaikan serta dipersonalisasi secara tingkat lanjut berdasarkan data yang dikumpulkan dari sistem feedback real-time dan sistem metrik
- Sistem feedback real-time:
- Untuk mengumpulkan feedback di antara survei triwulanan, LinkedIn mengembangkan sistem feedback real-time yang melacak event dan tindakan yang dilakukan developer di dalam alat pengembangan dan mengirimkan survei tertarget berdasarkan trigger tertentu
- Sistem ini menggunakan mekanisme smart throttling agar permintaan feedback tidak terlalu membanjiri developer
- Metrik berbasis sistem:
- LinkedIn juga menggunakan data sistem untuk menghitung metrik sehingga memberikan pengukuran berpresisi tinggi untuk hal-hal seperti waktu build dan frekuensi deployment
- Tim Developer Insights memelihara sistem global untuk mengumpulkan dan menganalisis data ini, yang mereka sebut developer insights hub (atau iHub)
- Melalui sistem ini, semua tim di LinkedIn dapat membuat dashboard dan metrik kustom sesuai kebutuhan masing-masing
- Survei triwulanan:
- LinkedIn mempertimbangkan metrik kualitatif dan kuantitatif
- Developer Net User Satisfaction (NSAT): mengukur seberapa puas developer secara keseluruhan terhadap sistem pengembangan LinkedIn. Diukur per kuartal
- Developer Build Time (P50 dan P90): mengukur dalam detik berapa lama developer menunggu build selesai secara lokal selama pengembangan
- Code Reviewer Response Time (P50 dan P90): mengukur waktu yang dibutuhkan code reviewer untuk merespons setiap pembaruan code review dari author, berdasarkan jam kerja
- Post-Commit CI Speed (P50 dan P90): mengukur dalam menit berapa lama setiap commit melewati pipeline continuous integration (CI)
- CI Determinism: konsep kebalikan dari flaky test. Artinya, kemungkinan bahwa hasil test suite adalah hasil yang valid, bukan error
- Deployment Success Rate: mengukur seberapa sering deployment ke lingkungan production berhasil
- Winsorized Means: cara untuk mengenali perbaikan dalam metrik yang mengandung outlier. Dihitung dengan mengganti nilai tertinggi dan terendah dengan angka yang lebih dekat ke tengah
- The Developer Experience Index: metrik khusus yang diberikan LinkedIn kepada tim. Indeks ini adalah skor gabungan berdasarkan berbagai metrik seperti yang disebutkan di atas
4. Peloton
- Peloton adalah perusahaan besar dengan sekitar 3.000-4.000 karyawan, jauh lebih kecil dibanding LinkedIn
- Pendekatan pengukuran Peloton dimulai dengan memperoleh insight kualitatif melalui survei pengalaman developer, lalu kemudian menggunakannya bersama metrik kuantitatif
- Peloton mengukur produktivitas dengan berfokus pada empat area utama: engagement, velocity, kualitas, stabilitas
- Engagement: skor kepuasan developer
- Velocity: waktu hingga PR pertama dan PR ke-10 untuk semua karyawan baru, lead time, frekuensi deployment
- Quality: persentase PR di bawah 250 baris, line coverage, change failure rate
- Stability: waktu pemulihan layanan
- Survei pengalaman developer yang mengukur banyak bagian dari metrik ini dipimpin oleh tim dukungan teknis dan pengalaman developer Peloton, yang merupakan bagian dari organisasi product operations
- Tim dukungan teknis dan pengalaman developer juga bertanggung jawab menganalisis hasil survei dan membagikannya dengan para pemimpin di seluruh organisasi
5. Scale-up dan perusahaan kecil
- Berbagai perusahaan scale-up seperti Notion, Postman, Amplitude, GoodRx, Intercom, dan Lattice mempekerjakan 100 hingga 1.000 engineer
- Perusahaan-perusahaan ini berfokus pada "moveable metrics"
- Moveable metrics adalah metrik yang bisa "digerakkan" oleh tim produktivitas developer melalui dampak positif atau negatif pada pekerjaan. Ini berguna bagi tim produktivitas developer untuk menunjukkan pengaruh mereka
- Metrik umum
- Ease of Delivery (moveable):
- Sebagian besar perusahaan mengukur kemudahan delivery, yaitu ukuran kualitatif tentang seberapa mudah atau sulit yang dirasakan developer saat menyelesaikan pekerjaannya
- Beberapa pemimpin DevProd mengatakan bahwa mereka menjadikan metrik ini sebagai 'bintang utara' pekerjaan tim, karena tujuan tim adalah membuat hidup developer lebih nyaman
- Karena metrik ini cukup mudah digerakkan, ia juga berguna untuk menunjukkan dampak
- Dari sudut pandang teoretis, metrik ini juga menangkap aspek-aspek utama pengalaman developer seperti beban kognitif dan feedback loop
- Engagement
- Mereka melacak engagement, yang mengukur seberapa tertarik dan terstimulasinya developer terhadap pekerjaannya
- Biasanya engagement diukur dalam survei engagement HR, tetapi tim DevProd juga berfokus pada engagement karena alasan ini
- Engagement developer dan produktivitas berkaitan erat. Dengan kata lain, seperti ungkapan "developer yang bahagia adalah developer yang produktif", engagement developer dapat dilihat sebagai indikator produktivitas
- Manfaat nyata dari mengukur engagement adalah dapat menyeimbangkan metrik lain yang menekankan kecepatan. Merilis software lebih cepat itu baik, tetapi tidak boleh mengorbankan kebahagiaan developer
- Time Loss (moveable)
- GoodRx dan Postman memperhatikan rata-rata jumlah time loss
- Ini diukur sebagai persentase waktu developer yang hilang karena hambatan di lingkungan kerja
- Metrik ini mirip dengan kemudahan delivery karena menyediakan metrik yang dapat digerakkan dan dapat dipengaruhi langsung oleh pekerjaan tim developer
- Keuntungan besarnya adalah dapat dikonversi menjadi biaya, sehingga pemimpin bisnis dapat dengan mudah memahami time loss
- Misalnya, jika organisasi dengan biaya tenaga kerja engineering sebesar 10 juta dolar berhasil menurunkan time loss dari 20% menjadi 10% melalui sebuah inisiatif, hal itu akan menghasilkan penghematan biaya sebesar 1 juta dolar
- Change Failure Rate
- Ini adalah salah satu dari empat metrik utama dalam program riset DORA (DevOps Research and Assessment)
- Metrik tingkat atas yang dilacak di beberapa perusahaan, termasuk Amplitude dan Lattice
- Tim DORA mendefinisikan change failure rate sebagai berikut:
"Persentase perubahan rilis ke production atau ke pengguna yang menyebabkan penurunan layanan (misalnya gangguan layanan atau outage layanan) dan kemudian memerlukan perbaikan (misalnya hotfix, rollback, fix forward, atau patch)."
- Ease of Delivery (moveable):
6. Temuan menarik
- Metrik DORA dan SPACE digunakan secara selektif, dan semua perusahaan menggunakan pengukuran kualitatif dan kuantitatif
- DORA: DevOps Research and Assessment
- SPACE: Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow
- Ada penekanan besar pada "waktu fokus", dan Stripe serta Uber membagikan metrik spesifik seperti "jumlah hari dengan waktu fokus yang cukup" dan "waktu fokus mingguan per engineer"
- Metrik unik
- Adoption Rate (DoorDash, GoodRx, Spotify)
- Design Docs Generated per Engineer (Uber)
- Experiment Velocity (Etsy)
- Developer CSAT/NSAT (Chime, LinkedIn)
7. Cara memilih metrik Anda sendiri
- Disarankan menggunakan framework Goals, Signals, Metrics (GSM) milik Google untuk memandu pemilihan metrik
- Pertama definisikan tujuan dari masalah yang ingin diselesaikan, lalu temukan sinyal yang menunjukkan bahwa tujuan tersebut telah tercapai, kemudian pilih metrik yang sesuai
- Mendefinisikan tujuan
- Google: "Mendukung developer agar dapat menghadirkan produk hebat dengan cepat dan mudah."
- Slack: "Menyediakan lingkungan pengembangan yang mulus bagi setiap engineer."
- Stripe: "Membuat software engineering menjadi lebih mudah."
- Bekerja mundur dari tujuan untuk mendefinisikan metrik tingkat atas
- Seberapa mudah bagi developer untuk me-deliver software? (Ease): Ease of Delivery, Deployment Lead Time, Build Failure Rate
- Seberapa cepat developer me-deliver software? (Speed): Perceived Delivery Speed, Perceived Productivity
- Kualitas software yang dihadirkan (Quality): Incident frequency, Perceived Software Quality
- Mendefinisikan tujuan
- Jika Anda adalah CTO, VPE, atau engineering lead
- Saran terbaiknya adalah "membingkai ulang masalah" (reframe the problem)
- Pilih metrik dari tiga bucket
- Business impact
- Mengapa ini harus dibangun sekarang?
- Dengan cara apa proyek ini menghasilkan pendapatan atau mendukung tujuan bisnis?
- Apakah proyek ini berjalan lancar, atau mengalami keterlambatan?
- System performance
- Apakah sistem engineering cepat dan stabil?
- Apakah infrastruktur aman dan terpelihara dengan baik?
- Apakah pengguna puas dengan layanan yang mereka gunakan?
- Engineering efficiency
- Business impact
- Mengukur dengan mencampurkan metrik kualitatif dan kuantitatif adalah pola yang muncul di semua perusahaan
- Ambil inspirasi dari berbagai item pengukuran yang digunakan masing-masing perusahaan
- Ada perbedaan besar dalam item yang diukur secara prioritas, bergantung pada prioritas dan budaya engineering masing-masing perusahaan
1 komentar
Saya sudah tertarik sejak tulisan sebelumnya yang terkait McKinsey, jadi senang rasanya karena ini diringkas sekaligus menjadi pengingat.