Jika Anda harus memimpin pengembangan produk perangkat lunak, Anda mungkin bertanya-tanya - bagaimana cara membantu tim bergerak lebih cepat? Dan bagaimana Anda tahu seberapa cepat Anda bergerak?
Tampaknya logis menggunakan metrik untuk menjawab pertanyaan semacam itu. Bagaimanapun, kami telah menggunakannya untuk waktu yang lama dan berhasil untuk produk perangkat lunak itu sendiri. Ada metrik kinerja, beban server produksi, waktu kerja. Ada juga metrik produk berdasarkan perilaku pengguna seperti konversi dan retensi. Manfaat metrik tidak hanya pemahaman yang lebih jelas tentang keadaan saat ini, tetapi yang lebih penting, memberikan umpan balik. Anda membuat perubahan untuk memperbaiki sesuatu, dan Anda dapat melihat dari metrik seberapa besar peningkatan (atau kemerosotan) yang Anda dapatkan. Kebijaksanaan pemrograman populer mengatakan: setiap pengoptimalan kinerja program harus dimulai dengan pengukuran, dan itu sangat masuk akal.
Karena kami berhasil menerapkan metrik ke produk perangkat lunak itu sendiri, mengapa tidak menerapkannya pada kecepatan pengembangan produk tersebut? Dalam hal ini, kami dapat mencoba beberapa perbaikan dalam proses dan secara visual melihat apakah mereka membantu untuk bergerak lebih cepat. Dan masalah menentukan gaji yang adil untuk programmer juga akan disederhanakan. Metrik apa yang dapat Anda gunakan?
Kami tidak memiliki metrik yang bagus untuk ini.
Kecepatan pengembangan adalah jumlah pekerjaan yang diselesaikan per unit waktu. Kita bisa mengukur waktu, semuanya sederhana di sini. Tetapi bagaimana mengukur jumlah pekerjaan yang dilakukan? Upaya untuk melakukan ini dimulai beberapa dekade yang lalu, dengan lahirnya industri pemrograman itu sendiri. Namun, setiap kali metrik digunakan sebagai target peningkatan, pasti ada yang tidak beres. Contohnya:
- . , , , . , , , ;
- . , , ;
- . . , , . , , ;
- . , . , , , ;
- . , , , — , ;
- … .
Pengembang cerdas dan kreatif, dan mereka mengkhususkan diri dalam memecahkan masalah yang kompleks. Metrik apa pun yang Anda berikan kepada mereka, mereka akan menemukan cara termudah untuk meningkatkan kinerja mereka, tetapi kemungkinan besar itu tidak ada hubungannya dengan volume dan kualitas sebenarnya dari pekerjaan yang dilakukan. Apakah mereka akan menggunakan metode "curang" ini? Belum tentu, itu tergantung pada situasi khusus Anda, termasuk seberapa kuat insentif yang Anda buat. Tetapi mereka pasti akan menyadari bahwa mengevaluasi produktivitas mereka tidak ada hubungannya dengan nilai. Ini tidak hanya menurunkan motivasi, tetapi juga mengalihkan perhatian dari melakukan pekerjaan nyata.
Tapi kenapa?
Mengapa metrik berfungsi dengan baik untuk meningkatkan properti produk perangkat lunak, tetapi tidak untuk mengukur pekerjaan yang dilakukan oleh pemrogram? Mungkin ini semacam konspirasi programmer? Faktanya, jika kita melihat di luar pengembangan perangkat lunak, kita akan melihat contoh lain, di beberapa metrik bekerja dengan baik dan di lainnya tidak.
Contoh di mana metrik bekerja dengan baik adalah produksi atau penjualan massal. Biar ada produksi dan penjualan mug. Anda dapat mengukur volume produksi - jumlah cangkir per unit waktu, kualitasnya (persentase sisa), biaya satu cangkir. Dalam penjualan - volume penjualan, margin. Metrik ini cukup berhasil digunakan dalam manajemen. Misalnya, manajer produksi dapat diberi tugas untuk mengurangi tarif sisa sambil mempertahankan harga biaya, dan manajer penjualan - meningkatkan penjualan sambil mempertahankan harga. Perbaikan metrik ini akan menguntungkan bisnis, sehingga dapat dianggap sebagai indikator kinerja orang yang bertanggung jawab.
Contoh ketika metrik tidak berfungsi adalah evaluasi kinerja ilmiah. Ilmuwan melakukan penelitian, yang kemudian diterbitkan sebagai makalah ilmiah. Area ini juga memiliki metrik numeriknya sendiri - jumlah makalah, jumlah kutipan, signifikansi statistik dari hasil, dll. Apakah mungkin untuk mengatakan bahwa ilmuwan yang merilis 10 karya ilmiah membawa manfaat dua kali lebih banyak daripada ilmuwan yang merilis 5 makalah? Ini tidak mungkin, karena nilai pekerjaan mereka bisa sangat berbeda, dan pada saat yang sama, bahkan pada tingkat subyektif, sulit untuk memahami pekerjaan mana yang lebih berharga. Masalah kutipan dan publikasi yang "curang" sudah dikenal luas dalam komunitas ilmiah, sehingga sayangnya, kutipan dan publikasi tersebut tidak dianggap sebagai indikator nilai yang dapat diandalkan. Ada juga masalah memanipulasi signifikansi statistik .
Dua kriteria utama
Terlepas dari konteksnya, metrik yang berfungsi dengan baik memiliki dua kesamaan:
- Hubungan langsung (bukan tidak langsung) dengan nilai;
- Akurasi, yaitu metrik didasarkan pada pengukuran jumlah beberapa unit nilai dan unit-unit ini sama satu sama lain;
Mari kita lihat kembali contoh yang kita lihat di atas:
Metrik untuk produksi massal dan penjualan memenuhi kedua kriteria tersebut. Dalam produksi mug, yang di nilai adalah produk - mug itu sendiri. Sambungan langsung, perusahaan perlu memproduksi mug. Dan karena produksinya adalah massa, maka satuan nilai (lingkaran) sama satu sama lain. Jika kita berbicara tentang penjualan, maka unit nilainya adalah uang. Tujuan perusahaan adalah untuk mendapatkan keuntungan, oleh karena itu, hubungan dengan nilai, sekali lagi, bersifat langsung. Dan karena setiap dolar yang diperoleh sama dengan yang lain, kami dapat membuat metrik yang akurat.
Dalam evaluasi karya ilmiah, kriteria tersebut tidak dapat dipenuhi. Kita tidak bisa menemukan satuan ukuran yang secara langsung menentukan nilai karya ilmiah, karena semua karya ilmiah itu unik. Tidak bisa sebaliknya, hanya melanjutkan dari esensi sains - untuk menemukan pengetahuan baru. Tidak masuk akal bagi seorang ilmuwan untuk menulis karya ilmiah lain yang sama persis dengan yang lain. Setiap karya ilmiah harus menghadirkan sesuatu yang baru.
Karena kita tidak dapat menemukan metrik yang secara langsung mengukur nilai karya ilmiah, kita hanya memiliki metrik tidak langsung - misalnya, jumlah publikasi dan kutipan. Masalah dengan metrik tidak langsung adalah bahwa metrik tersebut berkorelasi buruk dengan nilai dan cenderung mudah "ditipu". Jika Anda mulai menggunakan metrik seperti itu sebagai sasaran, Anda sendiri yang menciptakan insentif untuk mengakhirinya secara artifisial.
Kembali ke pengukuran produktivitas programmer
Apa yang kita punya di sana? Baris kode, jumlah komit, tugas, skor tugas dalam jam atau storypoint ... Jika Anda mencoba memeriksa metrik ini dengan dua kriteria utama, Anda akan melihat bahwa tidak ada yang memenuhi metrik tersebut:
- Tidak ada hubungan langsung dengan nilai. Kami tidak memberi klien kami baris kode, jam kerja atau storypoint. Pengguna tidak peduli berapa banyak komit yang kami buat atau berapa banyak tugas yang kami tutup;
- Mereka tidak akurat. Komitmen untuk berkomitmen berbeda, satu baris kode tidak sama dengan yang lain, tugas juga berbeda, dan jam kerja serta storypoint diperkirakan secara subyektif, jadi keduanya juga akan berbeda.
Jadi, tidak mengherankan bahwa tidak satu pun dari metrik ini yang berfungsi - semuanya tidak langsung dan tidak tepat.
Mengapa tidak ada metrik yang secara langsung terkait dengan nilai pekerjaan programmer? Untuk alasan yang sama mengapa para ilmuwan tidak memilikinya. Pemrogram, seperti ilmuwan, terus menciptakan hal-hal baru. Mereka tidak menulis kode yang persis sama berulang kali - itu tidak masuk akal. Kode yang ditulis sebelumnya dapat digunakan kembali dengan cara yang berbeda, dipisahkan menjadi modul atau perpustakaan terpisah, baik, atau hanya disalin, paling buruk. Oleh karena itu, setiap hari kerja untuk programmer itu unik. Bahkan jika mereka memecahkan masalah yang sama, mereka menyelesaikannya setiap kali dalam konteks yang berbeda, dalam kondisi baru.
Pekerjaan programmer adalah produksi sepotong, bukan produksi massal. Mereka tidak menghasilkan hasil berulang yang sama, jadi tidak ada dasar untuk pengukuran. Metrik yang berfungsi dengan baik dalam produksi massal atau penjualan tidak berfungsi di sini.
Bukankah ada sesuatu yang lebih modern berdasarkan penelitian?
Tentu saja, saat ini tidak ada orang yang secara serius berbicara tentang mengukur pekerjaan programmer dengan baris kode. Pasti ada beberapa metrik yang lebih modern berdasarkan penelitian, bukan?
Ada beberapa. Dalam buku 2018 mereka "Mempercepat," penulis mengutip hasil studi terhadap 2000 organisasi dari berbagai industri. Para penulis mencoba mencari tahu metrik apa yang akan mengukur kinerja:
Sumber: Nicole Forsgren, Jez Humble, dan Gene Kim, “Mengukur Kinerja,” dalam Accelerate: The Science behind DevOps: Building and Scaling High Performing Technology Organizations
Berikut empat metrik. Mari kita lihat mana yang terkait dengan nilai dan dapat diukur secara akurat:
- . , . , . . . . , , . , . , — ;
- Lead time — , . , , . , , , — ;
- (MTTR) — , , , . . -, . , MTTR . -, , . , — ;
- , . , . , , , . Linux, “ — ”. SaaS- . , — - , , - . , . , — . , — .
Intinya: Tidak satu pun dari keempat metrik ini yang akurat, dan tidak selalu memiliki hubungan yang jelas dengan nilai pelanggan. Apakah ada peluang untuk “curang” dalam kasus ini? Tentu. Sampaikan perubahan berisiko rendah yang sepele sesering mungkin, dan semua metrik kecuali Waktu tunggu akan terlihat bagus.
Sedangkan untuk Lead time - bahkan jika kita menghilangkan fakta (penting) bahwa itu tidak akurat, penekanan pada hal itu akan mengarah pada prioritas keinginan klien yang paling sederhana dan mendorong ke sudut paling jauh dari segala sesuatu yang jelas tidak diminta oleh klien - biasanya ini adalah refactoring, tes, dan hanya perbaikan apa pun yang tidak dia pikirkan tentang dirinya sendiri.
Oleh karena itu, saya tidak akan merekomendasikan penggunaan metrik ini sebagai target.
Tapi mungkin kita akan menemukan metrik baru?
Tentu saja, Anda dapat berkata: “Tunggu, jika belum ada metrik yang sesuai yang ditemukan, ini tidak berarti bahwa tidak akan ada sama sekali! Kami adalah orang pintar, kami akan memaksakan diri dan menghasilkan sesuatu ”. Sayangnya, saya khawatir itu tidak akan terjadi. Ada alasan mendasar mengapa tidak ada metrik yang baik di bidang ini. Seperti yang kami katakan di atas, yang bagus akan memenuhi dua kriteria utama:
- Hubungan langsung (bukan tidak langsung) dengan nilai;
- Akurasi, yaitu metrik didasarkan pada pengukuran jumlah beberapa unit nilai, dan unit-unit ini sama satu sama lain.
Kita tidak dapat mengukur nilai langsung secara akurat, karena semua hasil pekerjaan programmer berbeda, mereka tidak pernah menghasilkan sesuatu yang persis sama. Ini adalah produksi potongan untuk tugas-tugas unik dan tidak berulang. Dan karena tidak ada yang berulang, maka tidak ada dasar untuk perbandingan dan pengukuran juga. Kita hanya tersisa dengan proxy, tetapi karena mereka memiliki nilai terikat yang buruk dan cenderung curang, ketergantungan pada mereka merugikan.
Dapatkah Anda meningkatkan area yang tidak memiliki metrik yang baik?
Metrik sangat bagus karena memberikan umpan balik. Anda membuat beberapa perubahan dalam prosesnya dan Anda dapat dengan jelas melihat apakah perubahan itu membawa perbaikan atau tidak. Jika tidak ada metrik, umpan balik menjadi kurang terasa dan bahkan mungkin terasa seperti Anda bergerak membabi buta. Ada pepatah terkenal yang dikaitkan dengan Peter Drucker:
Anda tidak dapat mengontrol apa yang tidak dapat Anda ukur.
Hanya ini yang tidak benar. Menurut Institut Drucker, Peter Drucker tidak benar-benar membayangkan bahwa metrik dapat ditemukan untuk aktivitas apa pun, dan tidak pernah mengucapkan kata-kata seperti itu . Tidak semua yang berharga bisa diukur, dan tidak semua yang bisa diukur itu berharga.
Kompleksitas dengan metrik tidak berarti tidak ada yang bisa ditingkatkan. Beberapa perusahaan merilis perangkat lunak jauh lebih cepat daripada yang lain, dan tanpa mengorbankan kualitas. Artinya ada beberapa perbedaan yang signifikan, dan oleh karena itu, perbaikan harus dimungkinkan.
Ringkasan
Mungkin dan perlu untuk meningkatkan produk perangkat lunak Anda menggunakan metrik. Metrik kinerja, muat, waktu kerja, atau produk seperti konversi dan retensi pelanggan adalah teman Anda.
Namun, Anda tidak boleh mencoba mempercepat proses pengembangan dengan bantuan metrik, karena kurangnya metrik yang sesuai. Banyak indikator di bidang ini telah ditemukan, tetapi, sayangnya, semuanya tidak langsung atau tidak tepat, dan lebih sering keduanya sekaligus, jadi ketika mencoba menggunakannya sebagai tujuan, hanya kerugian yang diperoleh.
Tapi jangan putus asa - ada harapan! Kurangnya metrik yang baik untuk kecepatan pengembangan menyedihkan, tetapi itu tidak berarti peningkatan kecepatan tidak mungkin dilakukan. Bagaimana mungkin. Ya, kami hanya memiliki penilaian kualitatif subjektif untuk umpan balik. Namun, ada cukup banyak dari mereka untuk menerapkan perbaikan dan memahami apakah ada efek dari mereka. Misalnya, salah satu hal yang dapat ditingkatkan adalah komunikasi antara pengembang dan manajemen . Tautan di atas memberikan contoh bagaimana meningkatkan komunikasi, dan mengapa perlu difokuskan padanya.
Itu saja, tulis di komentar apa yang Anda pikirkan. Selamat penerapan, bahkan pada hari Jumat.