Belajar Engineering Manager - Process Improvement

#Pendahuluan

Setelah di episode 16 kita menjaga orang tetap betah, episode ini menyentuh sistem tempat mereka bekerja: proses.

Proses adalah sistem operasi tim: ia menentukan seberapa cepat ide menjadi production, seberapa banyak energi habis di friksi alih-alih pekerjaan. Masalahnya, proses biasanya tidak didesain — ia mengendap: satu kebijakan lahir dari insiden tahun lalu, satu ritual dari kebiasaan pendiri tim, dan lima tahun kemudian semua orang menjalankannya tanpa tahu kenapa. EM adalah arsitek proses timnya; episode ini memberi toolkit mendesain ulangnya secara terukur.

#Retrospektif yang Tidak Membosankan

Retro adalah mesin improvisasi tim — kalau ia hidup. Gejala retro mati: format sama berbulan-bulan, keluhan berulang tanpa aksi, dan anggota datang dengan laptop terbuka. Obatnya tiga lapis:

Variasi format menghidupkan kembali persepsi:

Disiplin aksi: setiap retro menghasilkan maksimal 1-2 action item (bukan daftar tujuh yang mati), masing-masing punya owner dan masuk backlog sprint berikutnya. Retro membahas progres aksi retro lalu sebagai agenda pertama.

Rotasi fasilitator: selain mendistribusikan kepemilikan, ini melatih leadership tim (dan memberi kalian kesempatan jadi peserta yang jujur bicara).

#Mendesain Proses Seperti Mendesain Sistem

Engineer hebat mendesain sistem dengan prinsip yang sama persis bisa dipakai untuk proses:

• Single source of truth: setiap informasi penting (status, keputusan, runbook) punya satu rumah; duplikat adalah bug.
• Fail fast & visible: friksi dibuat muncul cepat — blocker harus terlihat dalam hitungan jam, bukan ditemukan saat deadline.
• Idempotency & repeatability: proses yang sama dijalankan orang berbeda menghasilkan hasil yang sama (checklist rilis, template incident).
• Least surprise: aturan sedikit tapi konsisten lebih baik daripada banyak tapi bertentangan.
• Cost of change: desain proses untuk kemungkinan ia akan diubah — hindari kebiasaan yang mahal dilepas.

Dan seperti sistem, proses punya telemetri: cycle time, throughput, jumlah handover per item kerja. Jangan desain proses dari nol di atas kertas putih; amati alur nyata (value stream mapping ringan: gambar langkah dari ide sampai deploy, tandai mana menambah nilai dan mana menunggu), lalu optimalkan bottleneck-nya. Teori antrian versi praktisnya: waktu total sebuah task didominasi oleh waktu antre, bukan waktu kerja — mempercepat orang yang bekerja jarang membantu; mengurangi antreannya selalu membantu.

#WIP Limits: Alat Paling Underrated

Konsekuensi langsung dari teori antrian: batasi work in progress. Intuisi manajer bilah "orang harus selalu sibuk"; fisika antrian bilang sebaliknya — terlalu banyak pekerjaan paralel membuat semuanya lambat (context switching, integrasi tertunda, review menumpuk).

Tanpa limit : [A][B][C][D][E][F][G][H]   -> semua setengah jadi,
                                          lead time rata-rata panjang
Dengan limit=3: [A][B][C] | antre [D][E] -> A-B-C selesai cepat,
                                          fokus, lead time turun

Implementasi pragmatisnya: mulai dengan limit pada kolom In Progress board (misalnya 1.5x jumlah engineer), biarkan antrean terlihat, dan ketika limit penuh — aturannya wajib — tim menyelesaikan pekerjaan lama sebelum menarik baru, bukan menumpuk lagi. Perlawanan awal pasti ada ("tapi saya bisa multitask!"); jawab dengan data dua sprint: bandingkan cycle time sebelum vs sesudah limit. Kanban method membangun seluruh sistemnya di atas prinsip ini dan layak dipelajari lebih dalam jika tim kalian flow-oriented.

#Improvement Backlog

Usulan perbaikan dari retro, survey, dan observasi kalian perlu rumah yang sama seperti backlog fitur: improvement backlog — daftar prioritas perbaikan proses dengan nilai dan effort. Tanpanya, perbaikan proses selalu kalah oleh fitur "yang mendesak" dan retro menjadi theater.

Format entri sederhana: masalah, usulan, metrik keberhasilan, owner, ukuran (S/M/L). Prioritaskan dengan logika RICE versi kasar (episode 7). Dan alokasikan kapasitas permanen padanya — 5-10% dari keranjang debt/improvement di capacity plan (episode 8) cukup, asalkan konsisten. Satu perbaikan proses per sprint yang benar-benar tereksekusi mengalahkan sepuluh resolusi tahun baru.

#Eksperimen Proses Terukur

Perubahan proses harus diperlakukan seperti eksperimen produk: hipotesis, durasi, metrik, keputusan.

eksperimen: "Review SLA + rotasi reviewer harian"
hipotesis: >
  Dengan SLA review 1 hari kerja dan reviewer siaga harian,
  median review turnaround turun dari 26 jam ke di bawah 12 jam
  tanpa menurunkan kualitas (change failure rate stabil).
metrik_baseline:
  review_turnaround_median_jam: "26"
  change_failure_rate_persen: "9"
durasi: "4 minggu"
pemilik: "EM"
keputusan_akhir:
  berhasil: "masukkan working agreement, lanjutkan permanen"
  gagal: "hentikan, dokumentasikan pembelajaran, uji hipotesis lain"
  ambigu: "perpanjang 2 minggu ATAU ganti metrik"

Tiga disiplin yang membuatnya jujur: baseline dicatat sebelum intervensi (episode 13 memberi kalian dashboard-nya), satu variabel diganti per eksperimen (jangan ubah WIP limit + format retro + SLA review bersamaan lalu bingung mana yang berpengaruh), dan hasil gagal dirayakan sebagai pembelajaran — tim yang takut gagal bereksperimen akan berhenti mengusulkan apa pun.

#Kapan Proses Harus Dipangkas

Terakhir, ingat bahwa setiap proses punya biaya maintenance. Sinyal saatnya memangkas: ritual yang hadirnya rendah dan keputusannya nol; checklist yang tidak pernah mencegah masalah nyata; approval layer yang tidak pernah menolak apa pun (berarti ia hanya pajak waktu); dan laporan yang tidak pernah dibaca siapa pun. Pangkas dengan ritual berkala: sekali per semester, ajak tim audit working agreement dan daftar ritual — "mana yang masih membayar sewanya?" Proses terbaik adalah yang minimal namun dipatuhi penuh, bukan yang lengkap tapi diabaikan.

#Penutup

Inti yang harus dibawa pulang:

• Retro hidup lewat tiga lapis: variasi format, disiplin aksi 1-2 item ber-owner, dan rotasi fasilitator.
• Desain proses dengan prinsip sistem: single source of truth, fail visible, repeatable, least surprise — plus telemetri.
• Lead time didominasi waktu antre: WIP limits adalah alat tercepat memperbaiki flow; buktikan dengan data dua sprint.
• Improvement backlog + alokasi kapasitas permanen membuat perbaikan proses bersaing adil dengan fitur.
• Eksperimen proses = hipotesis + baseline + satu variabel + durasi + keputusan akhir; pangkas proses yang tak membayar sewanya tiap semester.

Di episode 19 selanjutnya kita naik ke dimensi yang selama ini kita perlakukan sebagai urusan tim khusus: Security Culture in Team — menanamkan keamanan sebagai tanggung jawab kolektif, threat modeling ringan untuk tim fitur, security champions, dan checklist PR yang membuat keamanan jadi default bukan afterthought. Sampai jumpa!