Ini lanjutan dari artikel sebelumnya: AI Berubah Setiap 6 Bulan. Cara Berpikir Tidak
Bagaimana caranya tim bisa bergerak lebih cepat tanpa mengorbankan kualitas?
Sebagian orang bilang itu mustahil.
Kalau ingin cepat ya pasti kualitas turun.
Kalau ingin kualitas bagus ya pasti proses menjadi lambat.
Logika yang terdengar masuk akal.
Tetapi ternyata data berkata sebaliknya.
Itulah inti dari buku Accelerate, karya Nicole Forsgren, Jez Humble, dan Gene Kim. Publish pertama di tahun 2018. Jauh sebelum AI hype.
Berbeda dengan banyak buku manajemen yang dipenuhi opini, Accelerate dibangun di atas riset bertahun-tahun terhadap ribuan organisasi teknologi di berbagai negara. Mereka ingin menjawab satu pertanyaan:
Apa yang benar-benar membedakan tim teknologi berkinerja tinggi dengan tim biasa?
Jawabannya ternyata bukan gaji, atau jam kerja, dan bukan juga metodologi Agile atau Scrum.
Yang membedakan adalah cara mereka mengukur dan memperbaiki sistem kerja.
Berhenti Menyalahkan Orang. Mulailah Mengukur Sistem.
Di perusahaan, ada satu hal yang sering menghabiskan energi.
Semua orang sibuk berdebat.
“Metode kita salah.”
“Kita harus Agile.”
“Tidak, kita harus Waterfall.”
“Kita kurang meeting.”
“Kita terlalu banyak meeting.”
Diskusi seperti ini bisa berlangsung berjam-jam.
Masalahnya, hampir semuanya berbasis opini.
Accelerate mengajak kita melakukan sesuatu yang jauh lebih sederhana.
Ukur dulu.
Saya teringat ketika pertama kali membangun perusahaan.
Kalau ada proyek terlambat, rasanya mudah sekali menyalahkan orang.
Programmer dianggap lambat.
Project manager dianggap kurang tegas.
QA dianggap terlalu cerewet.
Setelah beberapa waktu, saya baru menyadari bahwa sebagian besar masalah bukan berasal dari individu.
Masalahnya berasal dari sistem.
Kalau sistemnya buruk, orang hebat pun akan terlihat biasa.
Sebaliknya, kalau sistemnya sehat, orang biasa pun bisa menghasilkan pekerjaan yang luar biasa.
Empat DORA Metrics yang Mengukur Seberapa Sehat Tim Software Anda
Hasil riset itu melahirkan empat indikator yang hari ini dikenal sebagai DORA Metrics.
DORA adalah singkatan dari DevOps Research and Assessment.
Empat metrik ini menjadi salah satu standar paling berpengaruh dalam dunia software engineering.
1. Deployment Frequency: Seberapa Cepat Anda Belajar dari User?
Seberapa sering tim berhasil melakukan deployment ke production?
Semakin sering Anda bisa merilis perubahan dengan aman, semakin cepat organisasi belajar dari pengguna.
Bayangkan dua restoran.
Restoran pertama mengganti menu setiap enam bulan.
Restoran kedua mencoba menu baru setiap minggu.
Menurut Anda, siapa yang lebih cepat mengetahui menu mana yang disukai pelanggan?
Jawabannya jelas.
Di dunia software pun sama.
Produk berkembang bukan karena perencanaan yang panjang. Tetapi karena siklus belajar yang cepat.
2. Lead Time for Changes: Dari Ide ke Nilai, Berapa Lama?
Berapa lama waktu yang dibutuhkan sejak perubahan kode dibuat sampai benar-benar digunakan user?
Misalnya programmer selesai membuat fitur hari ini.
Kalau user baru bisa menggunakannya tiga bulan lagi, maka ada sesuatu yang salah.
Semakin pendek Lead Time for Changes, semakin cepat organisasi mengubah ide menjadi nilai nyata.
Saya sering mengibaratkannya seperti dapur restoran.
Pelanggan memesan makanan.
Kalau makanan datang tiga jam kemudian, masalahnya bukan resep.
Masalahnya adalah proses di dapur.
3. Mean Time to Recovery: Seberapa Cepat Anda Bangkit Saat Gagal?
Tidak ada sistem yang sempurna.
Cepat atau lambat, pasti ada masalah.
Pertanyaannya bukan, “Apakah sistem akan gagal?”
Tetapi, “Seberapa cepat kita bisa pulih?”
Itulah Mean Time to Recovery.
Bayangkan listrik di rumah padam.
Kalau menyala lagi dalam lima menit, kita mungkin hanya mengeluh sebentar.
Tetapi kalau padam tiga hari, cerita menjadi berbeda.
Dalam dunia AI, konsep ini semakin penting.
Model bisa berubah.
API bisa mengalami gangguan.
Prompt yang kemarin bekerja sempurna bisa tiba-tiba menghasilkan jawaban yang kacau setelah model diperbarui.
Organisasi yang hebat bukan organisasi yang tidak pernah gagal. Melainkan organisasi yang cepat bangkit ketika kegagalan datang.
4. Change Failure Rate: Seberapa Sering Perubahan Justru Menjadi Masalah?
Setiap perubahan membawa risiko.
Semakin sering melakukan deployment bukan berarti semakin banyak membuat masalah.
Yang penting adalah, berapa persen perubahan yang justru menyebabkan kegagalan?
Inilah Change Failure Rate.
Tujuannya bukan menghindari perubahan.
Justru sebaliknya.
Mampu berubah sesering mungkin, dengan tingkat kegagalan serendah mungkin.
Tim Elite Bukan Hanya Lebih Cepat. Mereka Juga Lebih Stabil.
Yang membuat menarik bukan sekadar empat metrik itu. Tetapi hasil penelitiannya.
Dalam penelitian itu, tim dengan performa terbaik memiliki Lead Time hingga sekitar 200 kali lebih cepat dibanding tim berkinerja rendah, sekaligus memiliki Change Failure Rate yang jauh lebih rendah, sekitar 7 kali lebih baik.
Perhatikan baik-baik.
Bukan hanya lebih cepat. Tetapi juga lebih stabil.
Ini seperti melihat pembalap Formula 1.
Mobilnya paling cepat. Tetapi justru paling jarang mogok.
Selama ini kita menganggap kecepatan dan kualitas adalah dua kutub yang saling bertentangan.
Data menunjukkan sebaliknya.
Organisasi terbaik justru unggul di keduanya.
Masalahnya Sering Bukan Tools. Melainkan Budaya.
Banyak perusahaan mengira solusi produktivitas adalah membeli tools baru.
Ganti Jira. Ganti Git. Ganti IDE. Ganti AI Coding Assistant.
Padahal Accelerate menemukan sesuatu yang jauh lebih mendasar.
Kinerja organisasi sangat dipengaruhi oleh Psychological Safety dan Westrum Generative Culture.
Mari kita sederhanakan.
Psychological Safety berarti setiap anggota tim merasa aman untuk bertanya, mengakui kesalahan, dan mengemukakan pendapat tanpa takut dipermalukan.
Sedangkan Westrum Generative Culture adalah budaya yang mendorong informasi mengalir bebas, kolaborasi lintas fungsi, dan penyelesaian masalah bersama, bukan saling menyalahkan.
Analogi sederhananya seperti rumah sakit.
Kalau seorang perawat takut melaporkan kesalahan dokter, masalah kecil bisa berubah menjadi tragedi.
Tetapi kalau semua orang bebas menyampaikan fakta, kesalahan lebih cepat diperbaiki.
Perusahaan teknologi pun demikian.
Semakin orang takut berbicara, semakin mahal harga kesalahan.
AI Sedang Memindahkan Bottleneck
Di sinilah menurut saya buku Accelerate menjadi semakin menarik.
Hari ini diperkirakan 30–70% kode baru di banyak tim mulai dihasilkan oleh Claude Code, Cursor, GitHub Copilot, dan berbagai autonomous coding agents.
Kalau AI bisa menghasilkan kode dalam hitungan detik, apakah Deployment Frequency masih memiliki makna yang sama?
Kalau AI membuat ribuan baris kode dalam sehari, apakah Lead Time for Changes masih menjadi ukuran utama?
Ini pertanyaan yang belum memiliki jawaban pasti.
Buku Accelerate memang belum membahas era AI Agent seperti sekarang.
Tetapi justru karena memahami fondasi metrik tersebut, kita bisa mulai bertanya, “Metrik mana yang masih relevan? Metrik mana yang perlu berevolusi?”
Misalnya, di era AI mungkin kita tidak lagi hanya mengukur kecepatan menghasilkan kode. Yang lebih penting adalah kecepatan menghasilkan kode yang benar, aman, dan memberikan nilai bisnis.
Karena bottleneck mulai bergeser.
Dulu bottleneck ada pada manusia yang menulis kode.
Sekarang bottleneck berpindah ke validasi → evaluasi → keamanan → observability → kualitas keputusan.
Produktivitas Bukan Seberapa Cepat Kita Mengetik
Saya melihat banyak orang salah memahami AI.
Mereka berpikir AI membuat programmer bekerja lebih cepat karena bisa mengetik lebih sedikit.
Padahal itu hanya efek samping.
Nilai terbesar AI bukan mempercepat jari. Melainkan mempercepat siklus belajar.
Hari ini kita bisa membuat prototipe dalam satu hari.
Besok langsung diuji ke pelanggan.
Lusa diperbaiki. Minggu depan di-deploy lagi.
Yang menjadi keunggulan bukan lagi siapa yang paling sempurna sejak awal. Tetapi siapa yang paling cepat belajar dari kenyataan.
Dan itulah sebenarnya pesan terbesar Accelerate.
Pelajaran dari Accelerate di Era AI
Jika The Mom Test mengajarkan kita memilih masalah yang layak diselesaikan…
Maka Accelerate mengajarkan bagaimana organisasi terus bergerak tanpa kehilangan kendali.
Di era AI, semua orang bisa membuat software lebih cepat.
Tetapi hanya sedikit organisasi yang mampu belajar lebih cepat.
Karena pada akhirnya, yang memenangkan perlombaan bukan perusahaan yang memiliki AI paling canggih. Melainkan perusahaan yang memiliki sistem belajar paling cepat.
AI hanya mempercepat mesin.
Sistemlah yang menentukan apakah mesin itu melaju ke tujuan, atau justru melaju lebih cepat ke arah yang salah.
Nanti kita akan lanjutkan buku berikutnya: The Art of Doing Science and Engineering. InsyaAllah.
Terima kasih sudah membaca. Semoga bermanfaat.
