Metrik Engineering Tanpa Jira
Anda tidak memerlukan Jira untuk mengukur hal yang penting. Cara melacak kesehatan tim engineering dari Git, CI, dan alat yang sudah digunakan tim Anda.
By Ellis Keane · 2026-03-23
Tim kecil yang mendapatkan visibilitas engineering terbaik cenderung adalah yang berhenti mengejar metrik yang ingin dilacak Jira.
Saya menyadari itu terdengar seperti saya hanya bersikap kontradiktif demi kontradiksi – dan jujur saja, mungkin sedikit memang begitu. Tapi saya menghabiskan hampir tiga tahun dengan setia memelihara papan sprint, merapikan backlog, dan memperbarui estimasi pada tiket yang sudah setengah selesai sebelum siapa pun membuka Jira pagi itu. Setiap dua minggu, kami duduk di sebuah ruangan (yah, Zoom – ini 2023) dan menatap grafik velocity yang tidak memberitahu kami sama sekali hal yang belum kami ketahui dari berbicara satu sama lain. Metrik engineering tanpa Jira bukan sesuatu yang saya cari. Itu yang terjadi ketika saya berhenti berpura-pura bahwa grafik velocity memberitahu saya sesuatu yang berguna.
Jika tim Anda cukup kecil untuk duduk di satu meja, Anda mungkin tidak memerlukan Jira untuk mengetahui bagaimana kinerja Anda. Anda membutuhkan sinyal yang lebih baik dari alat yang sudah Anda gunakan.
Ini bukan artikel "Jira itu buruk". Jira adalah alat yang baik untuk organisasi yang membutuhkan pelacakan ala Jira (dan pada skala tertentu, mereka benar-benar membutuhkannya). Tapi jika Anda adalah engineering manager di startup 10 hingga 40 orang, membayar Jira semata-mata untuk menghasilkan grafik velocity sedikit seperti membeli oven industri untuk menghangatkan makan siang Anda.
"Membayar Jira semata-mata untuk menghasilkan grafik velocity sedikit seperti membeli oven industri untuk menghangatkan makan siang Anda." attribution: Chris Calo
Apa yang Sebenarnya Diukur Metrik Jira
Mari saya berterus terang: sebagian besar metrik Jira mengukur penggunaan Jira, bukan output engineering. Story point mengukur kemampuan tim untuk memperkirakan story point. Velocity mengukur seberapa konsisten tim mengisi sprint hingga kapasitas yang kira-kira sama. Burndown chart mengukur apakah seseorang ingat untuk memindahkan tiket di papan pada Kamis sore.
Tidak ada yang benar-benar tidak berguna. Tapi ini adalah metrik proses yang menyamar sebagai metrik produktivitas developer, dan kesenjangan di antara keduanya adalah di mana engineering manager kehilangan gambaran.
Saya pernah menjadi EM yang menghabiskan hampir satu jam sebelum rapat dengan pemangku kepentingan untuk mengolah data Jira menjadi slide deck yang menunjukkan "kami sesuai jadwal". Pemangku kepentingan mengangguk, mengajukan satu pertanyaan tentang bug login dari Selasa lalu, dan rapat berakhir. Satu jam itu untuk slide deck. Jawaban sebenarnya adalah "tanya engineernya".
Jika metrik Anda membutuhkan lebih banyak pemeliharaan daripada pekerjaan yang diukurnya, metrik itu sendiri yang menjadi masalah.
Waktu Siklus dari Git, Bukan dari Papan Tiket
Untuk tim produk kecil, waktu siklus biasanya adalah metrik dengan sinyal tertinggi yang bisa Anda lacak. Ini mengukur durasi dari commit pertama hingga deploy produksi, dan Anda bisa menurunkannya sepenuhnya dari riwayat Git dan pipeline CI – tidak perlu papan tiket.
Komponen-komponennya:
- Timestamp commit pertama pada branch atau PR
- Timestamp merge PR
- Timestamp deploy (dari CI/CD Anda – GitHub Actions, CircleCI, atau apa pun yang Anda jalankan)
Delta antara 1 dan 3 adalah waktu siklus Anda. Pecah menjadi segmen – waktu coding (1 hingga PR terbuka), waktu tinjauan (PR terbuka hingga merge), dan antrean deploy (merge ke produksi) – dan Anda punya diagnostik yang memberi tahu di mana pekerjaan sebenarnya macet.
Ketika pertama kali saya melakukan ini untuk tim kami, angkanya benar-benar mengejutkan. Saya berasumsi waktu tinjauan adalah hambatan kami (semua orang selalu berasumsi waktu tinjauan adalah hambatan, bukan?). Ternyata fase coding-ke-PR kami baik-baik saja, tinjauan baik-baik saja, dan kami kehilangan rata-rata sekitar dua hari antara merge dan deploy karena lingkungan staging kami tidak stabil dan tidak ada yang memprioritaskan perbaikannya. Grafik velocity tidak akan pernah mengungkap itu.
Cara Mengukurnya
Jika Anda menggunakan GitHub, Anda bisa mengambil ini dengan CLI:
```bash
Dapatkan PR yang telah di-merge dalam 30 hari terakhir
gh pr list – state merged – limit 50 – json number,createdAt,mergedAt,headRefName ```
Untuk timestamp deploy, sebagian besar sistem CI mengeksposnya melalui API atau webhook. Petakan SHA merge PR ke event deploy, dan Anda punya waktu siklus tersegmentasi per fase.
Tips: Jika CI Anda tidak mengekspos timestamp deploy dengan bersih, pendekatan yang sangat sederhana adalah bot Slack yang memposting ke channel #deploys dengan SHA commit. Anda mendapat timestamp, log yang bisa dibaca manusia, dan – sebagai efek samping – channel yang memberi tahu seberapa sering Anda mengirimkan produk.
Throughput Tinjauan Kode
Throughput tinjauan – jumlah PR yang ditinjau per engineer per minggu, dan waktu median dari PR terbuka hingga tinjauan pertama – memberi tahu lebih banyak tentang kesehatan tim daripada metrik sprint apa pun. Ini sering diremehkan.
Mengapa? Karena perilaku tinjauan adalah indikator terdepan. Ketika waktu tinjauan meningkat, biasanya berarti engineer kelebihan beban, terlalu banyak melakukan peralihan konteks, atau – dan ini yang tidak nyaman – menghindari kode satu sama lain. Salah satu dari itu layak diketahui sebelum muncul sebagai tenggat waktu yang terlewat dua minggu kemudian.
GitHub memberi Anda data ini melalui API-nya. Field kunci adalah createdAt pada PR dan submittedAt pada event tinjauan pertama.
Angka yang saya perhatikan adalah jam median hingga tinjauan pertama. Berdasarkan pengalaman kami di beberapa tim kecil, ritme tinjauan yang sehat cenderung di bawah sekitar 8 jam. Ketika secara konsisten melewati satu hari, sesuatu yang struktural telah berubah – dan apa pun itu, tidak terlihat di Jira.
Rasio Rapat-ke-Keputusan
Ini bukan metrik engineering tradisional, dan saya harus jujur: ini adalah heuristik kasar, bukan KPI. Tapi untuk tim kecil, saya menemukan ini sangat mengungkapkan.
Hitung rapat yang diadakan tim Anda minggu ini. Hitung keputusan konkret yang dihasilkan dari rapat tersebut (bukan "kita harus menyelidiki X" – keputusan nyata dengan pemilik dan langkah selanjutnya). Bagi yang kedua dengan yang pertama.
Jika kurang dari setengah rapat Anda menghasilkan keputusan, ada baiknya bertanya apakah rapat-rapat itu sepadan dengan waktunya. Beberapa rapat ada untuk mengurangi risiko atau berbagi konteks, dan itu sah – tidak semuanya harus berakhir dengan resolusi. Tapi ketika Anda mulai melacak ini bahkan secara informal (saya benar-benar membuat catatan di buku catatan saya), Anda mengembangkan insting untuk rapat mana yang produktif dan mana yang hanya ritual yang tidak pernah dipertanyakan siapa pun.
Saya melacak ini selama sekitar sebulan, dan itu mengubah cara saya menjadwalkan rapat lebih dari artikel produktivitas apa pun. Ketika Anda bisa melihat bahwa standup Senin Anda tidak menghasilkan nol keputusan dalam tiga minggu berturut-turut, membatalkannya tidak lagi terasa radikal.
Membangun Metrik Engineering Tanpa Jira: Dashboard Ringan
Anda tidak memerlukan alat BI untuk ini. Halaman Notion, Google Sheet, atau postingan Slack mingguan dengan empat angka sudah cukup:
- Waktu siklus median (dari Git/CI) – apakah kami mengirimkan lebih cepat atau lebih lambat?
- Waktu median hingga tinjauan pertama (dari GitHub) – apakah tim meninjau dengan cepat?
- Frekuensi deploy (dari CI atau channel #deploys) – seberapa sering kami mengirimkan?
- Rasio rapat-ke-keputusan (hitungan manual) – apakah rapat kami sepadan waktunya?
Empat angka, semuanya bisa diturunkan dari alat yang sudah Anda miliki, tidak ada yang memerlukan pemeliharaan papan Jira. Perbarui setiap minggu. Jika angka bergerak ke arah yang salah selama dua minggu berturut-turut, selidiki. Jika stabil, biarkan saja.
Tujuannya bukan untuk membangun sistem pengawasan (tolong jangan – engineer Anda akan membenci Anda, dan mereka benar untuk melakukannya). Visibilitas tim engineering harus berasal dari pekerjaan itu sendiri, bukan dari meminta orang melaporkan pekerjaan.
Metrik engineering terbaik murah untuk dikumpulkan, sulit dimanipulasi, dan memberi tahu Anda sesuatu yang bisa Anda tindaklanjuti. Story point gagal dalam ketiga hal tersebut.
Kapan Anda Benar-Benar Membutuhkan Papan Tiket
Saya bilang ini bukan artikel "Jira itu buruk", dan saya serius. Ada situasi yang sah di mana melacak metrik tanpa alat manajemen proyek menjadi benar-benar tidak bertanggung jawab:
- Industri yang padat kepatuhan di mana jejak audit status tugas diwajibkan secara hukum
- Organisasi engineering yang lebih besar di mana ketergantungan antar tim membuat koordinasi informal tidak dapat dijalankan
- Organisasi dengan fungsi manajemen proyek khusus yang membutuhkan sumber kebenaran kanonik lintas tim
Jika itu situasi Anda, Jira (atau Linear, atau Shortcut) adalah pilihan yang tepat. Yang saya argumenkan adalah bahwa untuk tim kecil, memelihara alat yang berat semata-mata untuk metrik adalah pertukaran yang buruk. Anda akhirnya mengoptimalkan untuk model kerja alat tersebut daripada pekerjaan nyata tim Anda.
Dan jujur saja? Bahkan tim yang menggunakan Jira pun akan mendapat manfaat dari melengkapi data papan mereka dengan metrik berbasis Git di atas. Jira memberi tahu Anda apa yang orang katakan sedang mereka kerjakan. Git memberi tahu Anda apa yang sebenarnya mereka kerjakan. Keduanya berguna, tapi hanya satu yang kebal terhadap teater pembaruan status.
Jika pertanyaan metrik terus muncul di startup Anda, coba dashboard empat angka selama sebulan. Metrik engineering tanpa Jira mungkin terdengar seperti bekerja tanpa jaring pengaman – tapi begitu Anda melihat betapa banyak sinyal yang ada di riwayat Git dan pipeline CI Anda, Anda akan bertanya-tanya apa yang sebenarnya ditambahkan papan tiket.
Tampilkan waktu siklus, PR yang macet, dan hambatan tinjauan secara otomatis – tanpa skrip kustom atau papan Jira.
Q: Bisakah mendapatkan metrik engineering yang bermakna tanpa alat manajemen proyek? A: Bisa. Waktu siklus (commit pertama hingga deploy), throughput tinjauan, dan frekuensi deploy semuanya ada di riwayat Git dan pipeline CI Anda. Untuk tim dengan kurang dari sekitar 40 engineer, ini cenderung lebih tajam dan lebih sulit dimanipulasi daripada apa pun yang dihasilkan papan tiket – dan tidak memerlukan siapa pun untuk memindahkan kartu di papan agar tetap akurat.
Q: Apakah Sugarbug menampilkan metrik engineering secara otomatis? A: Sugarbug terhubung ke GitHub, Linear, Slack, dan kalender untuk membangun grafik pengetahuan aktivitas tim Anda. Ini menandai pola seperti PR yang macet, hambatan tinjauan, dan keputusan yang belum terselesaikan – yang mencakup banyak sinyal yang dijelaskan di sini tanpa mengharuskan Anda menulis dan memelihara skrip kustom terhadap GitHub API.
Q: Bagaimana mendapatkan dukungan untuk berhenti menggunakan Jira untuk metrik? A: Bingkai sebagai eksperimen, bukan pemberontakan. Jalankan metrik berbasis Git bersama dashboard Jira Anda yang ada selama empat minggu, lalu bandingkan angka mana yang mendorong perubahan nyata. Jika metrik Git terbukti lebih dapat ditindaklanjuti (dan berdasarkan pengalaman kami, cenderung demikian), argumennya terbentuk sendiri.
Q: Apa perbedaan antara metrik proses dan metrik kinerja? A: Metrik proses (story point, velocity, burndown) mengukur seberapa konsisten tim mengikuti alur kerja. Metrik kinerja (waktu siklus, frekuensi deploy, throughput tinjauan) mengukur apa yang sebenarnya dikirimkan tim dan seberapa cepat. Tim kecil hampir selalu mendapat lebih banyak sinyal dari yang terakhir, karena metrik kinerja diturunkan dari pekerjaan itu sendiri daripada pembaruan status manual.