1.10 Efektivitas rekayasa dan produktivitas pengembang

Tinjauan dan motivasi

Setiap pemimpin organisasi perangkat lunak yang besar akhirnya mengajukan versi dari pertanyaan yang sama: apakah kita semakin baik dalam membangun perangkat lunak, dan bagaimana kita mengetahuinya? Bab ini membahas menjawabnya dengan jujur. Efektivitas rekayasa adalah seberapa baik organisasi Anda mengubah upaya rekayasa menjadi perangkat lunak yang bernilai dan andal. Produktivitas pengembang adalah sisi individual dan tim darinya: seberapa banyak keluaran berguna yang dapat dihasilkan seorang pengembang, dan seberapa banyak waktu serta perhatiannya dikembalikan oleh lingkungan kerja alih-alih diambil.

Masalah dimulai begitu seseorang mencoba mereduksinya menjadi satu angka. Hitung baris kode dan orang menulis lebih banyak kode. Hitung story point dan estimasi menggembung. Hitung commit, pull request, atau jam di meja, dan Anda menghargai gerakan alih-alih kemajuan. Produktivitas bagi pekerja pengetahuan bukan hitungan widget. Pengembang yang menghapus sepuluh ribu baris kode mati, atau yang menghabiskan sehari berpasangan agar rekannya menghindari pemadaman produksi, telah melakukan pekerjaan yang sangat baik yang tidak tertangkap metrik naif mana pun. Jawaban jujur atas “seberapa produktif kita?” bersifat multidimensi, dan memperlakukan pengalaman pengembang atas pekerjaan sebagai sinyal nyata, bukan yang lunak.

Ini lebih penting, bukan kurang, saat Anda menskalakan. Di enterprise dengan puluhan tim, gesekan kecil (build lambat, rangkaian tes yang goyah, tunggu dua hari untuk lingkungan) berlipat di ratusan insinyur menjadi kapasitas hilang yang sangat besar. Di pemerintahan, di mana tidak ada harga pasar atas keluaran, risikonya adalah “sandiwara keluaran”: mengukur dokumen yang dihasilkan atau tiket yang ditutup sementara nilai publik tidak terukur. Tujuan bab ini adalah membantu Anda mengukur dan memperbaiki efektivitas organisasi rekayasa dan pengalaman harian pengembangnya, tanpa permainan, pengawasan, atau memeringkat orang satu sama lain.

Prinsip utama

• Produktivitas bersifat multidimensi. Tidak ada satu angka yang menangkapnya. Metrik apa pun yang ditawarkan sebagai ukuran tunggal itu keliru.
• Ukur untuk menghilangkan gesekan, bukan memeringkat orang. Subjek pengukuran adalah sistem, bukan individu.
• Triangulasi. Gabungkan bagaimana pengembang mengatakan pekerjaan itu terasa dengan apa yang benar-benar dicatat sistem.
• Pengalaman pengembang adalah data. Lingkaran umpan balik, beban kognitif, dan aliran dapat diukur dan layak diperbaiki.
• Anggap setiap metrik akan dipermainkan. Rancang melawan hukum Goodhart dengan banyak dimensi dan niat yang jujur.
• Hubungkan dengan hasil, secara hati-hati. Efektivitas harus naik ke nilai bisnis tanpa menjadi target yang merusak.

Rekomendasi

Tolak jebakan metrik tunggal

Disiplin pertama adalah menolak menamai satu angka sebagai produktivitas. Baris kode, jumlah commit, velocity story point, dan jam tercatat semuanya memiliki cacat fatal yang sama: mengukur aktivitas, bukan nilai, dan aktivitas mudah digelembungkan. Ini hukum Goodhart beraksi, prinsip bahwa ketika sebuah ukuran menjadi target, ia berhenti menjadi ukuran yang baik. Velocity diciptakan sebagai alat bantu perkiraan milik tim sendiri; begitu manajer membandingkan poin satu tim dengan tim lain, tim diam-diam mengubah skala estimasinya dan angkanya menjadi tak bermakna. Ketika seseorang menuntut satu KPI produktivitas, perlakukan itu sebagai permintaan yang harus Anda bentuk ulang, bukan penuhi. Tawarkan sebagai gantinya seperangkat kecil yang seimbang, dan jelaskan mengapa satu angka akan menyesatkan mereka.

Gunakan SPACE untuk menstrukturkan apa yang Anda ukur

Kerangka SPACE memberi Anda lima dimensi yang layak dipegang bersama: Satisfaction dan kesejahteraan, Performance, Activity, Communication dan kolaborasi, serta Efficiency dan aliran. Inti SPACE adalah bahwa Anda sebaiknya memilih setidaknya beberapa dimensi, tidak pernah hanya satu, dan tidak pernah semuanya dari kategori yang sama. Metrik aktivitas (commit, deploy) menggoda karena mudah dikumpulkan, tetapi sendirian ia mendistorsi. Pasangkan dengan sinyal kepuasan dan sinyal kinerja agar tidak ada dimensi tunggal yang dapat dipermainkan tanpa terungkap oleh yang lain. Tim yang merilis lebih banyak deploy sementara kepuasan anjlok dan tingkat kegagalan perubahan naik tidak lebih produktif, dan perangkat seimbang menunjukkannya seketika.

Perlakukan pengalaman pengembang sebagai lingkaran umpan balik, beban kognitif, dan aliran

Pengalaman pengembang (DevEx) adalah bagaimana rasanya mengerjakan rekayasa di sini, dan lebih konkret daripada kedengarannya. Ia bertumpu pada tiga hal yang dapat Anda ukur dan perbaiki. Lingkaran umpan balik adalah berapa lama pengembang menunggu untuk mengetahui apakah sesuatu berhasil: waktu build lokal, durasi rangkaian tes, waktu balik tinjauan kode, waktu deploy. Lingkaran lambat memaksa peralihan konteks dan menunggu menganggur. Beban kognitif, total upaya mental yang dituntut suatu tugas, tumbuh ketika pengembang harus menyulap terlalu banyak perkakas, sistem tak terdokumentasi, dan dependensi kusut untuk membuat perubahan sederhana. Aliran adalah keadaan imersi yang terfokus dan produktif yang dihancurkan oleh kalender terfragmentasi dan interupsi konstan. Ketika Anda memperpendek lingkaran umpan balik, menghilangkan konsep yang harus dipegang pengembang di kepalanya, atau melindungi blok waktu fokus, Anda telah meningkatkan produktivitas dengan cara yang tidak tercatat oleh hitungan aktivitas mana pun. Ini kepedulian DevEx yang sama yang dilayani rekayasa platform lewat jalan beraspal dan swalayan (bab 8.4).

Triangulasikan persepsi dengan metrik sistem

Tidak ada satu sumber data yang dapat dipercaya sendirian, jadi gabungkan dua jenis. Data persepsi berasal dari pengembang sendiri melalui survei pengalaman pengembang: kuesioner berkala, sebagian besar anonim, yang menanyakan seberapa percaya diri mereka merilis, di mana mereka kehilangan waktu, dan apa yang membuat mereka frustrasi. Data sistem berasal dari perkakas Anda: waktu pipeline, latensi tinjauan, frekuensi insiden. Masing-masing mengoreksi yang lain. Survei menangkap rasa sakit yang terlewat instrumen, seperti rotasi on-call yang melemahkan semangat atau layanan warisan yang ditakuti. Metrik sistem menangkap masalah yang telah dinormalkan orang dan berhenti dilaporkan. Ketika survei mengatakan build menyakitkan dan data pipeline Anda mengonfirmasi build median lima belas menit, Anda memiliki investasi yang diprioritaskan dan dapat dipertanggungjawabkan. Jalankan survei dengan irama tetap, jaga singkat, dan selalu tutup lingkaran dengan menunjukkan apa yang berubah karenanya.

Gunakan DORA sebagai sinyal pengiriman, bukan papan peringkat

Empat metrik DevOps Research and Assessment (DORA) (frekuensi deployment, lead time perubahan, tingkat kegagalan perubahan, dan waktu pemulihan layanan) adalah pembacaan kuat berbasis riset atas kemampuan pengiriman Anda, memasangkan kecepatan dengan stabilitas sehingga tidak ada yang dikorbankan demi yang lain. Bab 11.5 memegang kedalaman tentang ini, dan bab 11.2 membahas pipeline pengiriman yang diukurnya; gunakan di sana. Di sini, panduannya adalah tentang cara memegangnya. Perlakukan DORA sebagai sinyal kesehatan tingkat tim yang menunjukkan apakah sistem pengiriman Anda membaik, bukan papan skor untuk memeringkat tim atau individu. Begitu angka DORA muncul dalam penilaian kinerja seseorang, tim mulai memecah deploy untuk menggelembungkan frekuensi dan menyembunyikan insiden untuk melindungi tingkat kegagalannya, dan sinyalnya mati.

Ukur sistem, jangan pernah mengawasi individu

Inilah garis yang tidak boleh dilanggar. Agregasikan metrik ke tingkat tim dan organisasi, dan gunakan untuk menemukan serta menghilangkan gesekan. Jangan bangun dasbor yang memeringkat pengembang berdasarkan commit, jam, atau “skor produktivitas,” dan jangan biarkan telemetri individual memberi masukan pada gaji atau promosi. Pengawasan menghancurkan rasa aman psikologis dan kepercayaan yang menjadi sandaran rekayasa efektif, dan mengajari orang mengoptimalkan metrik alih-alih pekerjaan. Pertumbuhan dan evaluasi individual termasuk dalam mekanisme manusiawi yang terpisah yaitu jenjang karier dan percakapan manajer (bab 1.3). Pengukuran efektivitas bertanya “apa yang memperlambat tim kita?” Ia tidak pernah bertanya “siapa insinyur kita yang paling lambat?”

Serang pekerjaan rutin dan gesekan secara langsung

Begitu Anda dapat melihat di mana waktu bocor, belanjakan kembali. Banyak dari yang membatasi efektivitas adalah pekerjaan rutin (toil), kerja manual, berulang, dan dapat diotomatiskan yang tumbuh seiring pertumbuhan dan tidak memberi nilai yang bertahan (bab 9.1). Tinjauan yang lambat juga gesekan, jadi menyederhanakan tinjauan kode (bab 2.5) dengan perubahan lebih kecil dan ekspektasi jelas memperpendek lingkaran umpan balik inti. Jalan beraspal dan platform swalayan (bab 8.4) menghilangkan seluruh kategori penantian dan beban kognitif sekaligus. Anggarkan juga untuk utang teknis, biaya akumulasi jalan pintas masa lalu yang memajaki setiap perubahan mendatang, karena basis kode yang tidak dapat diubah dengan aman oleh siapa pun adalah penyerap produktivitas terdalam.

Trade-off: kelebihan dan kekurangan

Pendekatan	Kelebihan	Kekurangan
Metrik produktivitas tunggal (LOC, velocity, commit)	Murah, mudah, satu angka untuk pemimpin	Langsung dipermainkan; mengukur aktivitas bukan nilai; merusak kepercayaan
Perangkat seimbang ala SPACE	Tahan permainan; mencerminkan kenyataan	Lebih banyak kerja untuk dikumpulkan; lebih sulit diringkas dalam satu angka
Survei DevEx (persepsi)	Menangkap rasa sakit yang terlewat instrumen	Subjektif; butuh kepercayaan dan tindak lanjut agar tetap jujur
Metrik sistem (DORA, waktu pipeline)	Objektif, berkelanjutan, sulit dipalsukan secara agregat	Buta terhadap moral dan konteks; berbahaya bila diterapkan pada individu
Triangulasi keduanya	Setiap sumber mengoreksi yang lain; kokoh	Membutuhkan investasi pada perkakas dan disiplin survei

Ketegangan pusatnya adalah ketelitian versus kejujuran. Satu angka mudah dilaporkan dan mudah dirusak; gambaran kaya dan multidimensi jujur tetapi lebih sulit dikomunikasikan kepada eksekutif yang sibuk. Selesaikan dengan memilih perangkat kecil yang seimbang (beberapa dimensi SPACE ditambah survei ditambah DORA sebagai pembacaan pengiriman), melaporkan tren alih-alih potret sesaat, dan bersikap eksplisit bahwa angka-angka itu ada untuk memperbaiki sistem, bukan menilai orang. Ketika pimpinan menginginkan “satu grafik,” berikan tren beberapa sinyal yang saling melengkapi dan tolak godaan menggabungkannya menjadi komposit palsu.

Pertanyaan untuk didiskusikan dengan tim Anda

1. Jika seorang pemimpin menuntut satu angka produktivitas besok, apa yang akan Anda berikan? Pertanyaan ini mengungkap apakah organisasi Anda memahami jebakannya. Jawaban jujurnya adalah bahwa tidak ada satu angka pun yang aman, dan tugas Anda adalah membentuk ulang permintaan itu menjadi perangkat kecil seimbang yang tahan permainan. Bawa metrik yang sudah Anda laporkan dan tanyakan untuk masing-masing, “bagaimana tim yang cerdik dan sinis menggelembungkan ini tanpa bekerja lebih baik?” Jika jawabannya mudah, metrik itu berbahaya begitu menjadi target. Diskusikan apa yang akan Anda tawarkan sebagai gantinya, dan bagaimana Anda akan menjelaskan kepada pimpinan mengapa satu angka akan menyesatkan mereka untuk mengoptimalkan hal yang salah. Kualitas percakapan itu memprediksi apakah pengukuran akan membantu atau merusak Anda.

2. Apa lingkaran umpan balik Anda yang paling lambat, dan berapa biayanya setiap hari? Lingkaran umpan balik adalah tempat produktivitas bocor diam-diam: build lima belas menit, tunggu tinjauan dua hari, rangkaian tes goyah yang mengikis kepercayaan pada setiap centang hijau. Bawa angka nyata dari survei pengalaman pengembang dan dari instrumen pipeline Anda, dan lihat apakah rasa sakit yang dirasakan dan latensi yang terukur sepakat. Perkirakan biaya harian dengan mengalikan waktu tunggu dengan berapa banyak pengembang yang terkena seberapa sering, dan argumen investasi biasanya membuktikan dirinya sendiri. Putuskan lingkaran mana yang diperpendek lebih dulu dan siapa yang memiliki perbaikannya. Tim yang tidak dapat menyebut lingkaran terlambatnya belum mulai mengukur hal yang paling penting.

3. Di mana pengukuran Anda berisiko terasa seperti pengawasan, dan bagaimana Anda mencegahnya? Beda antara mengukur sistem dan memantau orang adalah beda antara kepercayaan dan ketakutan, dan mudah dilintasi tanpa disadari. Telusuri setiap dasbor dan laporan dan tanyakan apakah ada yang dapat memeringkat individu atau memberi masukan pada penilaian kinerja. Putuskan secara eksplisit apa yang tetap teragregasi, apa yang tetap anonim, dan apa yang terlarang, lalu katakan secara terbuka kepada tim yang diukur. Dalam konteks enterprise dan pemerintah, di mana tekanan pengawasan dan audit kuat, godaan untuk menelusuri ke individu konstan, jadi pagar pembatasnya harus berupa prinsip yang dinyatakan, bukan harapan. Jika pengembang yakin angka-angka itu dipakai melawan mereka, mereka akan mengoptimalkan angkanya dan kebenaran akan lenyap.

4. Ketika terakhir kali kita bertanya kepada pengembang bagaimana rasanya pekerjaan, apa yang berubah karenanya, dan apakah mereka pernah mengetahuinya? Survei yang tidak menghasilkan tindakan terlihat mengajari pengembang berhenti menjawab dengan jujur, sehingga survei diam kedua menarik tanggapan yang lebih sedikit dan lebih hambar daripada yang pertama, dan instrumen yang Anda andalkan membusuk persis saat Anda menskalakannya. Bagi organisasi besar pemborosan itu berlipat: ratusan orang menghabiskan waktu melaporkan gesekan, laporan beredar, dan tidak ada yang dirilis. Bawa tiga temuan teratas survei terakhir, pekerjaan konkret yang dipicu masing-masing, dan bagaimana Anda mengomunikasikan hasilnya kembali kepada orang yang mengangkatnya. Timbang tarikan yang bersaing antara bertindak atas keluhan paling lantang dan atas yang paling meluas, karena itu sering masalah yang berbeda. Dalam konteks enterprise dan pemerintah, di mana kelelahan survei dan beban konsultasi sudah tinggi, perlakukan menutup lingkaran sebagai komitmen tata kelola: namai siapa yang memiliki tanggapan, terbitkan apa yang berubah, dan terima bahwa survei yang tak dijawab lebih buruk daripada tidak ada sama sekali.

5. Bagaimana kita membandingkan tim tanpa membangun papan peringkat yang menghukum kejujuran? Pemimpin organisasi besar wajar ingin tahu tim mana yang berkembang dan mana yang macet, namun memeringkat tim berdasarkan velocity mentah, frekuensi deploy, atau angka DORA mengabaikan bahwa tim pembayaran di bawah regulasi ketat dan tim prototipe greenfield hidup di dunia yang berbeda. Pertimbangan yang bersaing itu nyata: Anda memang perlu menemukan tim yang bermasalah dan menyebarkan apa yang berhasil, tetapi begitu perbandingan menjadi papan skor, tim mengubah skala estimasi, menyembunyikan insiden, dan memecah deploy untuk melindungi posisinya. Bawa contoh spesifik tentang bagaimana konteks tim berbeda di organisasi Anda, bersama usulan membandingkan setiap tim dengan lintasannya sendiri dari waktu ke waktu alih-alih dengan tetangganya. Dalam konteks enterprise dan pemerintah, di mana tekanan audit dan pengawasan mendorong keras ke arah pemeringkatan lintas tim, sepakati sebelumnya apa yang boleh dibandingkan, apa yang hanya akan dibaca sebagai tren per tim, dan siapa yang diberdayakan menolak perbandingan yang tidak adil.

6. Bagaimana kita menghubungkan efektivitas dengan hasil nyata tanpa mengubah metrik pengiriman menjadi target yang merusak? Efektivitas yang tidak pernah naik ke nilai tampak seperti merenungi pusar bagi pimpinan, tetapi begitu sinyal pengiriman seperti lead time atau frekuensi deployment menjadi tujuan dalam penilaian kinerja, tim mengoptimalkan angkanya dan meninggalkan hasil yang hendak diwakilinya. Bagi organisasi besar ketegangannya akut, karena eksekutif ingin garis bersih dari upaya rekayasa ke hasil bisnis sementara garis yang jujur berantakan dan tertunda. Bawa ukuran hasil Anda saat ini, sinyal pengiriman yang akan Anda kaitkan dengannya, dan penjelasan eksplisit bagaimana masing-masing dapat dipermainkan bila menjadi target. Timbang tarikan antara cerita sederhana yang dapat diceritakan ulang pimpinan dan gambaran jujur yang tahan distorsi. Di pemerintahan atau platform internal non-pasar, di mana tidak ada pendapatan untuk menjangkarkan nilai, bersiaplah mendefinisikan hasil sebagai keandalan layanan, cycle time perbaikan, dan manfaat publik alih-alih aktivitas mentah, dan membela pilihan itu kepada badan pengawas yang mungkin lebih menyukai artefak yang mudah dihitung.

Lensa sektor

Startup. Dengan segelintir insinyur dan runway terbatas, lewati dasbor sepenuhnya dan ukur dua hal yang bergerak tercepat: survei pengalaman pengembang sepuluh pertanyaan dan waktu pipeline dasar. Risiko produktivitas terbesar Anda adalah rangkaian tes yang lambat atau goyah dan peralihan konteks konstan, jadi temukan lingkaran umpan balik terburuk, perpendek, dan lanjutkan. Jangan dirikan program pengukuran yang tidak punya orang untuk menjalankannya, karena satu percakapan jujur tentang di mana hari bocor mengalahkan perkakas apa pun yang harus Anda pelihara.

Bisnis kecil. Tanpa spesialis pengukuran dan dengan anggaran ketat, bersandarlah pada apa yang sudah dicatat perkakas Anda: waktu build, latensi tinjauan, dan jumlah insiden dari sistem yang sudah Anda bayar. Beli perkakas survei ringan alih-alih membangunnya, dan tolak tawaran vendor untuk dasbor produktivitas individual, yang akan memakan kepercayaan yang tidak sanggup Anda lepas. Bingkai seluruh upaya sebagai menghilangkan gesekan bagi tim kecil yang tidak sanggup menyia-nyiakan hari siapa pun.

Enterprise. Di puluhan tim, hadiahnya adalah kapasitas yang direbut kembali pada skala besar, dan bahayanya adalah dasbor pusat yang diam-diam tergelincir menjadi memeringkat orang. Bakukan program seimbang (survei DevEx kuartalan, beberapa dimensi SPACE, dan DORA dibaca sebagai tren pengiriman per tim) dan atur agar telemetri individual tidak pernah dikumpulkan. Bandingkan setiap tim dengan lintasannya sendiri, benarkan investasi platform (bab 8.4) terhadap gesekan yang diungkap data, dan beri satu pemilik yang bertanggung jawab wewenang menolak metrik apa pun yang akan menjadi papan peringkat.

Pemerintah. Tanpa harga pasar atas keluaran dan dengan tekanan pengawasan kuat, tarikan ke sandiwara keluaran (menghitung dokumen dan tiket yang ditutup) konstan, dan tarikan untuk mengawasi individu bernama di bawah audit lebih kuat lagi. Ukur hasil dan kemampuan pengiriman sebagai gantinya: seberapa cepat layanan merilis perbaikan, seberapa andal ia, dan bagaimana staf serta kontraktor mengalami pekerjaan melalui survei anonim. Ukur pegawai negeri dan kontraktor pada basis tingkat sistem yang sama, terbitkan untuk apa pengukuran itu, dan bersiaplah berargumen kepada legislatif bahwa tren pengiriman per tim adalah pembacaan nilai publik yang lebih jujur daripada skor individu mana pun.

Contoh

Startup. Sebuah startup dua puluh orang memperhatikan pengiriman melambat padahal semua orang sibuk. Alih-alih memasang dasbor produktivitas, pimpinan rekayasa menjalankan survei DevEx sepuluh pertanyaan dan menarik waktu pipeline dasar. Survei dan data sepakat: rangkaian tes memakan dua puluh dua menit dan gagal secara acak, sehingga orang menggabung perubahan dan berpindah konteks sambil menunggu. Tim menghabiskan dua minggu memperbaiki tes goyah dan memparalelkan rangkaian, memangkasnya menjadi empat menit. Frekuensi deploy naik dengan sendirinya, kepuasan melonjak pada survei berikutnya, dan tak seorang pun diperingkat atau dinilai untuk mewujudkannya.

Enterprise. Sebuah bank dengan empat puluh tim rekayasa ingin membenarkan investasi berkelanjutan pada platform internalnya. Kelompok platform mengadopsi program pengukuran seimbang: survei DevEx kuartalan di semua tim, sinyal ala SPACE, dan metrik DORA dibaca di tingkat tim sebagai tren kesehatan pengiriman (bab 11.5). Yang krusial, mereka membandingkan tim secara adil dengan membandingkan setiap tim dengan lintasannya sendiri dari waktu ke waktu, bukan satu sama lain, karena konteks tim sangat berbeda. Data menunjukkan tim di jalan beraspal (bab 8.4) mengorientasi insinyur baru dalam hitungan hari alih-alih minggu dan melaporkan beban kognitif jauh lebih rendah. Bukti itu, dibingkai sebagai kapasitas yang direbut kembali di ratusan pengembang, mendanai platform untuk setahun lagi. Telemetri individual sengaja tidak pernah dikumpulkan.

Pemerintah. Sebuah lembaga layanan digital federal harus menunjukkan kepada legislatif bahwa belanja rekayasanya memberikan nilai, dalam lingkungan tanpa harga pasar atas keluaran. Ia menolak sandiwara keluaran (menghitung dokumen atau tiket yang ditutup) dan sebagai gantinya mengukur hasil dan kemampuan pengiriman: seberapa cepat layanan dapat merilis perbaikan, seberapa andal, dan bagaimana tenaga kerja serta kontraktornya mengalami pekerjaan melalui survei anonim. Sinyal pengiriman ala DORA menunjukkan apakah modernisasi benar-benar meningkatkan throughput dan stabilitas, dikaitkan kembali dengan hasil publik alih-alih aktivitas mentah (bab 11.5). Karena pengukuran tidak pernah memeringkat individu, dan karena staf kontraktor dan pegawai negeri diukur pada basis tingkat sistem yang sama, lembaga menghindari masalah pengawasan dan moral yang menenggelamkan upaya semacam itu, dan memberi badan pengawas pembacaan nilai yang jujur.

Kasus bisnis: motivasi, ROI, dan TCO

Imbal hasil mengukur dan memperbaiki efektivitas adalah kapasitas yang direbut kembali, dan pada skala besar angkanya besar. Gesekan kecil berlipat di organisasi besar: build sepuluh menit yang dialami seratus insinyur beberapa kali sehari adalah ribuan jam insinyur per tahun yang dihabiskan menunggu. Perpendek lingkaran itu dan Anda telah menambah kapasitas bermakna tanpa merekrut siapa pun. ROI dominan di sini sama seperti pada rekayasa platform (bab 8.4): waktu rekayasa yang mahal dialihkan dari menunggu dan pekerjaan rutin ke pekerjaan bernilai.

Total biaya kepemilikannya sederhana tetapi nyata. Anda membayar perkakas survei dan disiplin menjalankannya, untuk menginstrumentasi pipeline, dan untuk perhatian manajemen membaca tren dan bertindak. Risiko yang lebih besar terhadap ROI adalah melakukan pengukuran dengan buruk. Satu metrik yang dipermainkan atau program pengawasan dapat menghasilkan imbal hasil negatif: berbulan-bulan upaya mengoptimalkan angka sementara hasil nyata stagnan, ditambah pengikisan kepercayaan yang membuat setiap perubahan mendatang lebih sulit. Biaya tidak mengukur sama sekali tersebar dan sangat besar: gesekan dan pekerjaan rutin menumpuk tanpa terlihat, insinyur senior kelelahan karena pemborosan yang dapat dihindari, dan pimpinan tidak dapat mengetahui apakah investasi membantu. Ajukan kasusnya kepada pimpinan sebagai daya ungkit dan kejujuran: program pengukuran kecil, tepercaya, dan seimbang yang menemukan di mana tenaga kerja besar kehilangan waktu, dan balik modal berkali-kali lipat begitu Anda bertindak atas temuan pertama.

Anti-pola dan jebakan

• Metrik produktivitas tunggal. Satu angka apa pun (LOC, velocity, commit, jam) dipermainkan pada hari ia menjadi target.
• Memeringkat individu. Papan peringkat dan “skor produktivitas” individual menghancurkan kepercayaan dan mengajari orang mengoptimalkan metrik.
• Pengukuran sebagai pengawasan. Telemetri individual berbutir halus yang memberi masukan pada penilaian merusak rasa aman psikologis yang dibutuhkan kerja efektif.
• Survei tanpa tindak lanjut. Menanyakan kepada pengembang bagaimana rasanya pekerjaan lalu tidak mengubah apa pun mengajari mereka berhenti menjawab dengan jujur.
• Membandingkan angka mentah antartim. Konteks tim berbeda; perbandingan velocity atau DORA lintas tim menghukum kejujuran dan menghargai permainan.
• Sandiwara keluaran. Menghitung artefak yang dihasilkan (dokumen, tiket, fitur dirilis) sementara hasil nyata tidak terukur, lazim di tempat tanpa harga pasar.
• DORA dalam penilaian kinerja. Begitu metrik pengiriman menilai orang, tim menyembunyikan insiden dan memecah deploy, dan sinyalnya mati.

Model kematangan

• Tingkat 1, Memulai: Produktivitas dinilai dari firasat atau satu metrik yang dapat dipermainkan seperti baris kode, velocity, atau jam. Pengukuran ad hoc dan reaktif, gesekan tak terlihat, keluhan bersifat anekdot, dan tak seorang pun dapat mengatakan apakah organisasi menjadi lebih baik.
• Tingkat 2, Mengembangkan: Beberapa tim mengadopsi praktik dasar: beberapa metrik, sering hitungan aktivitas, dan survei pengalaman pengembang sesekali. Praktik tidak konsisten dari tim ke tim, data dikumpulkan tetapi jarang ditindaklanjuti, perbandingan mentah lintas tim menyelinap, dan tidak ada prinsip bersama yang melindungi individu dari pemeringkatan.
• Tingkat 3, Membakukan: Program pengukuran seimbang didokumentasikan dan diterapkan di seluruh organisasi, memakai dimensi ala SPACE, survei DevEx berkala, dan DORA sebagai sinyal pengiriman (bab 11.5). Metrik diagregasi ke tim berdasarkan kebijakan, individu tidak pernah diperingkat, dan temuan menggerakkan pekerjaan konkret untuk memperpendek lingkaran umpan balik dan memangkas pekerjaan rutin (bab 9.1).
• Tingkat 4, Mengelola: Program diukur dan dikendalikan terhadap garis dasar. Waktu lingkaran umpan balik, skor survei, dan tren DORA membawa target yang disepakati dan dilacak dari waktu ke waktu; setiap tim dibandingkan dengan lintasannya sendiri alih-alih dengan tetangganya; investasi platform dan pengurangan pekerjaan rutin dibenarkan dengan data sebelum-dan-sesudah tentang kapasitas yang direbut kembali; dan regresi pada sinyal mana pun memicu tinjauan alih-alih berlalu tanpa disadari.
• Tingkat 5, Mengorkestrasi: Pengukuran tepercaya, rutin, dan adaptif. Data persepsi dan sistem ditriangulasi, tren memberi makan perbaikan berkelanjutan, gesekan dan beban kognitif diburu dan dihilangkan secara aktif, perangkat pengukuran itu sendiri direvisi seiring perubahan organisasi, dan efektivitas terintegrasi dengan hasil bisnis dan publik tanpa metrik mana pun dibiarkan menjadi target yang merusak.

Gagasan untuk didiskusikan

1. Metrik Anda saat ini yang mana yang dapat digelembungkan tim sinis tanpa bekerja lebih baik, dan apa yang akan Anda gunakan sebagai gantinya?
2. Jika Anda bisa memperpendek tepat satu lingkaran umpan balik di seluruh organisasi, yang mana yang akan mengembalikan kapasitas terbanyak?
3. Bagaimana Anda membandingkan banyak tim secara adil ketika konteksnya berbeda, tanpa membuat papan peringkat yang menghukum kejujuran?
4. Di mana garis antara mengukur sistem dan mengawasi individu, dan siapa di organisasi Anda yang diberdayakan menegakkannya?
5. Dalam lingkungan tanpa harga pasar atas keluaran, seperti pemerintah atau platform internal, bagaimana Anda mengukur nilai nyata alih-alih aktivitas?
6. Apa yang akan Anda tunjukkan kepada pengembang untuk membuktikan bahwa survei kuartal ini mengubah sesuatu?

Poin-poin utama

• Produktivitas bagi insinyur bersifat multidimensi. Tolak satu angka apa pun (baris kode, velocity, commit, jam) sebagai ukuran tunggal, karena hukum Goodhart menjamin ia akan dipermainkan.
• Gunakan kerangka SPACE (kepuasan dan kesejahteraan, kinerja, aktivitas, komunikasi dan kolaborasi, efisiensi dan aliran) untuk memegang beberapa dimensi bersama sehingga tak ada dimensi yang dapat dipermainkan sendirian.
• Pengalaman pengembang bermuara pada lingkaran umpan balik, beban kognitif, dan aliran. Memperpendek lingkaran dan menghilangkan beban adalah produktivitas nyata yang tidak pernah ditunjukkan hitungan aktivitas.
• Triangulasikan data persepsi dari survei DevEx dengan data sistem dari perkakas Anda; masing-masing mengoreksi yang lain.
• Perlakukan metrik DORA sebagai sinyal pengiriman tingkat tim, bukan papan peringkat; kedalamannya ada di bab 11.5 dan pipeline-nya di bab 11.2.
• Ukur sistem, jangan pernah individu. Agregasikan ke tim, simpan evaluasi dalam kanal manusiawi terpisah bab 1.3, dan jangan pernah biarkan pengukuran menjadi pengawasan.
• Belanjakan waktu yang direbut kembali untuk memangkas pekerjaan rutin (bab 9.1), mempercepat tinjauan kode (bab 2.5), dan mengaspal jalan (bab 8.4). Hubungkan efektivitas dengan hasil bisnis tanpa membiarkan metrik mana pun menjadi target yang merusak.

Referensi dan bacaan lanjutan

• Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, dan Jenna Butler, “The SPACE of Developer Productivity” (ACM Queue, 2021): kerangka multidimensi.
• Abi Noda, Margaret-Anne Storey, Nicole Forsgren, dan Michaela Greiler, “DevEx: What Actually Drives Productivity” (ACM Queue, 2023): lingkaran umpan balik, beban kognitif, dan aliran.
• Nicole Forsgren, Jez Humble, dan Gene Kim, Accelerate: The Science of Lean Software and DevOps (metrik DORA dan dasar risetnya).
• DORA, Accelerate State of DevOps Report (tahunan): program riset berkelanjutan di balik empat metrik.
• Betsy Beyer, Chris Jones, Jennifer Petoff, dan Niall Richard Murphy, eds., Site Reliability Engineering (pekerjaan rutin dan penghapusannya).
• Matthew Skelton dan Manuel Pais, Team Topologies (beban kognitif sebagai kepedulian desain kelas satu).
• Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience (asal keadaan aliran).
• Tom DeMarco dan Timothy Lister, Peopleware: Productive Projects and Teams (fokus, interupsi, dan sisi manusiawi produktivitas).
• Goodhart, C. A. E., “Problems of Monetary Management: The UK Experience” (1975): asal hukum Goodhart; lihat juga rumusan Marilyn Strathern yang banyak dikutip.
• Panduan U.S. Government Accountability Office (GAO) tentang pengukuran kinerja: mengukur nilai di lingkungan sektor publik non-pasar.