Metrik EM: Kelajuan Penyampaian, Kualiti, Pengekalan, Pengambilan Pekerja
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
Kali pertama saya memasuki QBR dengan carta story points, VP saya membiarkan saya meneruskan selama kira-kira sembilan puluh saat sebelum dia berkata, "Camellia, berapa pusing ganti yang dikesali anda? Dan kekerapan penggunaan anda? Lupakan mata itu."
Saya tidak mempunyai satu pun nombor tersebut. Saya mempunyai carta bar berwarna indah tentang kelajuan penyampaian mengikut sprint dan slaid bertajuk "Q3 Daya Pemprosesan +18%." Tiada satu pun daripadanya bertahan apabila berhadapan dengan soalan itu. Dia tidak kasar. Dia jujur. Lapisan eksekutif membiayai hasil. Saya telah membawa aktiviti. Kami tidak bercakap dalam bahasa yang sama, dan perbualan belanjawan yang berikut adalah sedingin yang dijangka.
Mesyuarat itu mengubah cara saya menjalankan papan pemuka. Panduan ini adalah papan pemuka yang saya harap ada: enam metrik, julat nombor sebenar, diagnosis bernama, satu slaid QBR. Tidak lebih, kerana lebih banyak adalah cara Goodhart's law menghakis anda.
Mengapa hasil mengatasi daya pemprosesan
Metrik daya pemprosesan, story points, tiket ditutup, baris kod, jam dicatatkan, mengukur aktiviti. Aktiviti adalah apa yang dilakukan pasukan anda. Hasil adalah apa yang syarikat dapat. Lapisan eksekutif membiayai hasil: kelajuan penghantaran, kebolehpercayaan, ketahanan pasukan, daya pemprosesan pengambilan pekerja. Jika anda tidak boleh menterjemahkan kerja pasukan ke dalam empat baldi tersebut, anda akan dipotong daripada perbualan headcount, dan anda tidak akan melihatnya datang sehingga pembekuan tawaran tiba dalam peti masuk anda.
Ada sebab kedua. Metrik daya pemprosesan mudah dimainkan tanpa sesiapa berniat. Beritahu pasukan bahawa anda mengukur tiket ditutup dan dalam satu suku anda akan mendapat tiket yang lebih kecil. Beritahu mereka bahawa anda mengukur story points dan dalam dua suku anda akan mendapat inflasi yang akan membuat jurubank pusat melongo. Metrik hasil lebih sukar dimainkan kerana ia terikat kepada realiti. Penggunaan sama ada berlaku atau tidak, jurutera sama ada kekal atau pergi, tawaran sama ada diterima atau ditolak.
Jadi: enam metrik. Empat untuk penghantaran dan kebolehpercayaan, dua untuk kesihatan pasukan. Itulah setnya.
Kekerapan penggunaan
Berapa kerap kod pasukan anda sampai ke pengeluaran? Setiap hari, setiap minggu, setiap bulan, atau kurang. Ini adalah metrik DORA pertama dan isyarat terbersih sama ada saluran penyampaian anda sebenarnya adalah saluran atau satu siri pintu berkunci dengan kunci tangan.
Peringkat sasaran mengikut kematangan pasukan:
| Peringkat | Kekerapan penggunaan | Apa yang ia biasanya bermakna |
|---|---|---|
| Elite | Atas permintaan (berbilang setiap hari) | Trunk-based, feature flags, CI yang matang |
| Tinggi | Setiap hari hingga setiap minggu | Pasukan sihat, CI yang munasabah, beberapa gerbang manual |
| Sederhana | Setiap minggu hingga setiap bulan | Kereta pelepasan, terikat pada sprint, risiko yang dibatch |
| Rendah | Setiap bulan atau kurang | Pelepasan sekali gus, kadar kekerapan berasaskan ketakutan |
Kebanyakan pasukan produk seharusnya berada di peringkat Tinggi. Jika anda berada di peringkat Sederhana dan kerja membenarkan (industri terkawal, kitaran QA panjang), katakan begitu pada slaid. Jika anda berada di peringkat Rendah dan anda adalah pasukan SaaS, itu adalah penemuan, bukan nombor.
Masa pendahuluan untuk perubahan
Masa dari commit ke pengeluaran. Ini adalah metrik DORA kedua dan yang memberitahu anda di mana kesesakan sebenarnya berada. Jam, hari, atau minggu.
Apabila anda mengukur ini dan memecahkannya, anda biasanya mendapati salah satu daripada tiga punca: semakan kod (PR duduk terbuka selama dua hari menunggu jurutera kanan yang sedang dalam mesyuarat), CI (suite ujian mengambil masa 47 minit dan gagal satu dalam lima kali), atau gerbang penggunaan (kelulusan manual yang berada dalam kalendar seseorang). Pilih yang paling panjang dan betulkan. Jangan cuba membaiki ketiga-tiga sekaligus.
Julat sihat mengikut jenis pasukan:
- Pasukan produk, aplikasi web: kurang daripada 24 jam, idealnya kurang daripada 8.
- Pasukan platform, infra: kurang daripada 48 jam.
- Pasukan mobile: 3-7 hari, dikawal oleh semakan kedai aplikasi.
Jika masa pendahuluan anda adalah dua minggu dan kekerapan penggunaan anda adalah harian, ada sesuatu yang tidak betul secara matematik. Anda sama ada menggunakan kebanyakan perubahan remeh sementara yang besar reput, atau anda mengira dengan silap. Siasat sebelum anda meletakkan slaid itu.
Kadar kegagalan perubahan
Peratusan penggunaan yang menyebabkan rollback, hotfix, atau insiden produksi. Metrik DORA ketiga. Julat sasaran adalah 0-15%, dengan pasukan yang sihat berada di 5-10%.
Dua perkara perlu diperhatikan. Pertama, kadar kegagalan perubahan sifar adalah bendera, bukan kemegahan. Ia biasanya bermakna pasukan anda menguji berlebihan, menggunakan terlalu jarang, atau mengira insiden secara kurang. Kedua, metrik ini mempunyai lantai semula jadi. Perisian adalah sukar, manusia menghantar pepijat, dan kadar 2% adalah kebisingan, bukan isyarat kemerosotan. Jangan kejar peratusan terakhir dengan mengorbankan kelajuan penyampaian.
Apabila kadar kegagalan perubahan melebihi 15%, diagnosisnya hampir selalu salah satu daripada: liputan ujian tidak mencukupi pada laluan kritikal, proses pelepasan yang membatch terlalu banyak (jadi kegagalan menjadi kusut), atau pekerja baharu yang menghantar ke pengeluaran sebelum mereka memahami radius kesan. Namakan yang mana satu. Jangan puratakan semuanya.
MTTR
Masa purata untuk pulih. Apabila sesuatu rosak dalam pengeluaran, berapa lama sehingga ia berfungsi semula? Jam, bukan hari. Ini adalah metrik DORA keempat dan yang paling terikat kepada kebersihan on-call.
MTTR yang baik adalah kurang daripada 4 jam untuk produk SaaS. Kurang daripada 1 jam untuk pasukan elite. Triknya adalah bahawa MTTR sebenarnya bukan tentang seberapa cepat anda boleh menulis pembaikan. Ia tentang seberapa cepat anda boleh mengesan, mendiagnosis, dan menggunakan. Kebanyakan MTTR yang perlahan yang saya pernah debug datang daripada salah satu daripada tiga tempat: amaran yang tidak dicetuskan (jadi pasukan mengetahui tentang gangguan perkhidmatan daripada pelanggan), runbook yang tidak wujud (jadi jurutera on-call menyelesaikannya dari awal), atau saluran penggunaan yang mengambil masa 90 minit (jadi walaupun selepas pembaikan ditulis, anda menunggu).
Jika MTTR meningkat, lihat beban on-call. Jurutera on-call yang keletihan kerja adalah jurutera on-call yang perlahan. Ini adalah metrik di mana kekerapan penggunaan, kadar kegagalan perubahan, dan kesihatan pasukan saling menyentuh.
Pusing ganti yang dikesali 12 bulan
Pertama daripada dua metrik kesihatan pasukan, dan yang paling VP anda ambil berat.
Pusing ganti yang dikesali hanya mengira orang yang anda mahu kekalkan. Jika ahli prestasi rendah pergi, itu tidak dikesali. Jika jurutera peringkat pertengahan yang mantap yang tidak pernah membuat kekecohan pergi dan anda angkat bahu, itu tidak dikesali. Jika IC kanan, tech lead, atau junior bertrajektor tinggi pergi, itu dikesali. Jujurlah kepada diri sendiri apabila anda melabelkannya. Pengurus cenderung untuk secara retroaktif memutuskan bahawa semua orang yang pergi adalah "tidak sesuai," yang merupakan cara anda berakhir dengan 0% pusing ganti yang dikesali dan pasukan yang separuh hilang.
Garis asas industri untuk teknologi, 2026:
- Sihat: 8-12% tahunan.
- Zon perhatian: 13-15%.
- Bahaya: melebihi 15%.
- Kebakaran lima loceng: melebihi 20%.
Jejak pada asas bergolek 12 bulan, bukan mengikut suku kalender. Nombor suku terlalu bising pada pasukan kecil. Jika anda mempunyai lapan jurutera dan satu pemergian yang dikesali dalam Q2, itu adalah 12.5%: baik pada asas bergolek, menakutkan pada carta suku.
Kadar penerimaan tawaran ditambah masa penyesuaian
Metrik kesihatan pasukan kedua, dan yang memberitahu anda sama ada pasukan anda boleh berkembang.
Dua sub-metrik, satu baris slaid. Kadar penerimaan tawaran: daripada tawaran yang anda hulurkan suku lepas, berapa peratus diterima? Sasaran adalah 70% atau lebih tinggi. Di bawah 60% bermakna tawaran anda tidak kompetitif (biasanya gaji, kadang-kadang tajuk, sesekali cerita).
Masa penyesuaian: dari tarikh mula hingga PR pertama yang tidak remeh yang digabungkan ke pengeluaran, berapa hari? Sasaran di bawah 30. Jika pekerja baharu biasa anda mengambil masa 60 hari untuk menghantar sesuatu yang nyata, proses orientasi pekerja baharu anda rosak atau pangkalan kod anda adalah labirin. Dalam apa keadaan sekalipun, itu adalah penemuan.
Kedua-dua nombor bersama menceritakan kisah pengambilan pekerja. Kadar penerimaan tinggi, penyesuaian cepat: enjin pengambilan pekerja berfungsi. Kadar penerimaan tinggi, penyesuaian perlahan: anda menjual dengan baik, anda orientasi dengan buruk. Kadar penerimaan rendah, penyesuaian cepat: apabila orang benar-benar menyertai mereka berkembang, tetapi anda tidak dapat menutup. Kadar penerimaan rendah, penyesuaian perlahan: enjin rosak di kedua-dua hujung.
NPS Kejuruteraan
Tinjauan nadi suku, satu soalan: "Adakah anda akan mengesyorkan pasukan ini kepada jurutera lain?" Skala sifar hingga sepuluh. Tolak pengkritik (0-6) daripada promotor (9-10), abaikan pasif (7-8). Hasilnya adalah antara -100 dan +100.
Pasukan kejuruteraan yang sihat mendapat markah 30-50. Melebihi 50 adalah cemerlang. Di bawah 20 adalah amaran. Negatif adalah kebakaran yang sudah bermula; anda hanya belum melihat asapnya lagi.
Jalankan pada minggu yang sama setiap suku. Tanpa nama. Sentiasa sertakan satu soalan susulan terbuka: "Apakah satu perkara yang akan menaikkan markah anda sebanyak satu mata?" Baca setiap respons. Nombor adalah tajuk berita; ulasan adalah diagnostik.
Diagnostik "kelajuan penyampaian tinggi tetapi pusing ganti tinggi"
Inilah arketaip yang mengejutkan kebanyakan EM. Kekerapan penggunaan tinggi. Kadar kegagalan perubahan rendah. Masa pendahuluan cemerlang. MTTR kukuh. Dengan empat metrik DORA, pasukan menghantar seperti juara.
Dan pusing ganti yang dikesali semakin meningkat. NPS Kejuruteraan semakin menurun. Orang yang anda mahu kekalkan sedang pergi.
Pasukan sedang menghantar dirinya keluar dari syarikat.
Saya pernah mengalami ini tepat sekali. Kami melakukan 60 penggunaan sebulan, kadar kegagalan perubahan 4%, MTTR kurang daripada 90 minit, dan saya kehilangan tiga jurutera dalam satu suku, dua daripada mereka adalah kanan. Papan pemuka metrik berbohong melalui peninggalan. Kebenaran muncul dalam temu bual keluar: "Saya penat." "Saya tidak berkembang dalam 18 bulan." "Rakan saya di pesaing mendapat 30% lebih untuk kerja yang sama."
Biasanya ada tiga punca, dan ia sering bertindih:
- Keletihan kerja. Kelajuan penyampaian yang tinggi adalah mampan selama satu suku, kadang-kadang dua. Selepas itu, anda meminjam daripada masa depan pasukan.
- Jurang gaji. Pasaran bergerak, band gaji anda tidak, dan jurutera kanan anda tahu kerana mereka menerima mesej LinkedIn setiap hari Selasa.
- Tiada laluan pertumbuhan. Orang kekal apabila mereka belajar. Setelah pangkalan kod terasa kecil, mereka mencari yang lebih besar.
Namakan punca pada slaid. Jangan ratakan ia menjadi "orang pergi, kami akan bekerja pada penglibatan" yang generik. Ayat itu tidak pernah menyelamatkan mana-mana pasukan.
Metrik kosmetik yang perlu berhenti dilaporkan
Goodhart's law: apabila ukuran menjadi sasaran, ia berhenti menjadi ukuran yang baik. Setiap metrik dalam senarai ini, termasuk enam di atas, terdedah. Tetapi empat ini cukup terdedah sehingga anda seharusnya bersaranya sepenuhnya:
- Story points yang diselesaikan. Inflasi dijamin. Menghantar cerita yang lebih kecil yang dirangkakan sebagai yang lebih besar. Tidak memberitahu anda apa yang sampai ke pengeluaran.
- Tiket ditutup. Masalah yang sama, papan markah yang berbeza. Menggalakkan tiket untuk membiak.
- Baris kod. Ukuran menaip, bukan kejuruteraan. Menghukum pemadaman, yang biasanya adalah PR terbaik.
- Jam dicatatkan. Mengukur kehadiran, bukan output. Menghukum ibu bapa dan memberi ganjaran kepada mesej Slack pada waktu malam yang bersifat persembahan.
Tukarkannya. Story points dan tiket menjadi kekerapan penggunaan dan masa pendahuluan. Baris kod menjadi kadar kegagalan perubahan. Jam dicatatkan menjadi NPS Kejuruteraan, kerana jika pasukan anda sihat dan menghantar, anda tidak perlu mengira jam.
Slaid QBR
Satu slaid, enam baris metrik, tiga lajur: semasa, sasaran, anak panah arah aliran. Tambah satu ayat diagnosis setiap baris. Itulah formatnya.
Susun atur sampel:
| Metrik | Semasa | Sasaran | Arah Aliran | Diagnosis |
|---|---|---|---|---|
| Kekerapan penggunaan | 12/minggu | Setiap hari | naik | Penambahbaikan CI dilancarkan pada Mac; trunk-based berfungsi |
| Masa pendahuluan | 31 jam | Kurang daripada 24 jam | mendatar | Barisan semakan adalah kesesakan; merintis auto-assign dalam Q2 |
| Kadar kegagalan perubahan | 7% | Kurang daripada 10% | mendatar | Band sihat; proses penghantaran pekerja baharu bertahan |
| MTTR | 2.4 jam | Kurang daripada 4 jam | turun | Liputan runbook mencapai 80% suku ini |
| Pusing ganti yang dikesali (12 bulan) | 14% | Kurang daripada 12% | naik | Dua pemergian kanan Q1; semakan gaji dan audit laluan pertumbuhan sedang berjalan |
| NPS Kejuruteraan | 38 | 40 ke atas | mendatar | Beban on-call adalah aduan terbuka utama |
Enam baris. Enam diagnosis. Tiada story points. Tiada carta kelajuan penyampaian yang disembunyikan dalam lampiran. Jika nombor tidak baik, katakan dengan terus terang dan namakan apa yang anda lakukan mengenainya. VP mempercayai EM yang menamakan masalah lebih cepat daripada VP akan mengesannya. Mereka tidak mempercayai EM yang menyembunyikannya.
Apa yang perlu diminta daripada VP anda
Tutup QBR dengan soalan, bukan perarakan kemenangan. Tanya dua daripada enam metrik yang paling penting untuk syarikat suku ini, dan apa julat sasaran yang akan dianggap sebagai kemenangan.
Cuba mengoptimumkan kesemua enam sekaligus adalah cara anda tidak mendapat apa-apa. Pasukan yang sedang mengerjakan kelajuan penghantaran tidak juga mengerjakan daya pemprosesan pengambilan pekerja, dan pasukan yang mengerjakan pengambilan pekerja akan mengambil pukulan sementara pada masa pendahuluan sementara jurutera kanan menemu duga calon berbanding menyemak PR. Pilih dua. Dapatkan penjajaran pada sasaran. Jalankan semula soalan suku seterusnya.
Jika VP anda berkata "kesemua enam," tolak balik dengan lembut. Katakan: "Jika saya perlu melabur kurang dalam dua daripadanya suku ini untuk melabur sepenuhnya dalam dua yang lain, yang mana dua yang perlu saya kurangkan keutamaannya?" Soalan itu hampir selalu mendapat jawapan sebenar, kerana ia memaksa pertukaran ke dalam terbuka.
Ini adalah versi QBR yang seharusnya saya masuki kali pertama. Enam metrik. Nombor sebenar. Diagnosis bernama. Satu slaid. Carta story points kekal dalam laci di mana ia sepatutnya.
Ketahui Lebih Lanjut

Principal Product Marketing Strategist
On this page
- Mengapa hasil mengatasi daya pemprosesan
- Kekerapan penggunaan
- Masa pendahuluan untuk perubahan
- Kadar kegagalan perubahan
- MTTR
- Pusing ganti yang dikesali 12 bulan
- Kadar penerimaan tawaran ditambah masa penyesuaian
- NPS Kejuruteraan
- Diagnostik "kelajuan penyampaian tinggi tetapi pusing ganti tinggi"
- Metrik kosmetik yang perlu berhenti dilaporkan
- Slaid QBR
- Apa yang perlu diminta daripada VP anda
- Ketahui Lebih Lanjut