Belajar Engineering Manager - Technical Quality Oversight

#Pendahuluan

Setelah di episode 8 kita menguasai aritmetika kapasitas, kita lengkapi tiga pilar dengan yang ketiga: technical quality oversight.

Bagian tersulit dari pilar ini adalah posisi EM: terlalu jauh dari kode, kalian kehilangan legitimasi dan kemampuan mendeteksi pembusukan dini; terlalu dekat (review semua PR line-by-line), kalian menjadi bottleneck sekaligus micromanager seperti yang dibahas episode 2. Solusinya bukan keseimbangan magis, melainkan sistem: standar yang tertulis, review culture yang hidup, utang teknis yang dicatat dan dibayar terjadwal, serta gate otomatis yang bekerja tanpa kalian.

#Standar Engineering: Definition of Done

Mutu dimulai dari definisi bersama tentang kata "selesai". Tanpanya, setiap diskusi kualitas menjadi debat selera. Contoh definition of done tim backend:

sebuah_fitur_disebut_selesai_jika:
  kode:
    - "PR lolos review minimal 1 senior (2 untuk jalur pembayaran)"
    - "Tidak ada TODO baru tanpa tiket terkait"
  pengujian:
    - "Unit test untuk logika bisnis baru, coverage tidak turun"
    - "Integration test untuk alur end-to-end utama"
    - "Skenario regresi masuk suite CI permanen"
  operasional:
    - "Metrics/logging/alert untuk perilaku baru sudah ada"
    - "Runbook diperbarui jika alur on-call terpengaruh"
    - "Feature flag disiapkan untuk rilis bertahap"
  dokumentasi:
    - "Design doc tertaut, keputusan penting tercatat"

Dua catatan implementasi. Pertama, DoD harus dipatuhi oleh semua orang termasuk kalian: satu pengecualian "karena urgent" dan standar berubah menjadi saran. Kedua, bedakan DoD (standar tetap) dengan acceptance criteria (spesifik per fitur); keduanya sering tertukar dan membuat DoD membengkak jadi checklist absurd.

#Budaya Code Review yang Sehat

Code review adalah mekanisme mutu sekaligus sekolah informal. Budayanya ditentukan oleh kecepatan dan nada:

Peran EM di sini adalah menjaga sistem, bukan ikut review semuanya: menetapkan SLA review di working agreement, memastikan rotasi reviewer adil (bukan selalu orang yang sama), dan mencontohkan nada yang baik saat kalian memang memberi review. Kalau review menjadi lambat, itu masalah kapasitas/alokasi (episode 8); kalau menjadi kasar, itu masalah budaya (episode 6) — keduanya bukan alasan untuk kalian mengambil alih semua review.

#Technical Debt Register: Utang yang Dicatat

Analogi favorit dunia engineering: utang teknis memang utang — ada pokok, ada bunga (waktu ekstra tiap kali menyentuh area itu), dan default (incident). Manajemen utang yang baik dimulai dari register: daftar utang yang diketahui, dinilai dampaknya, dan dijadwalkan pembayarannya:

debt_register:
  - id: "DEBT-001"
    item: "Modul ledger monolitik (4.200 baris, coupling tinggi)"
    bunga: "Setiap perubahan billing butuh regression test manual 2 hari"
    risiko: "SEV-1 saat perubahan pajak Q4"
    strategi: "pecah-bertahap"      # bayar | pecah-bertahap | terima-risiko | isolasi
    rencana: "7 hari/sprint dari keranjang debt (lihat episode 8)"
    status: "on-track"
  - id: "DEBT-002"
    item: "Test suite E2E flaky 12%"
    bunga: "CI retry menambah lead time 15 menit per run; trust test turun"
    risiko: "Engineer mulai skip test -> regresi lolos produksi"
    strategi: "bayar"
    rencana: "quarantine + perbaikan bertahap, target flaky di bawah 2%"
    status: "on-track"
  - id: "DEBT-003"
    item: "Framework versi lama di service pelaporan internal"
    bunga: "Minimal; jarang disentuh"
    risiko: "Rendah"
    strategi: "terima-risiko"
    rencana: "Review ulang saat service disentuh berikutnya"
    status: "monitoring"

Yang membuat register ini berguna adalah kolom strategi: tidak semua utang harus dilunasi. Utang di kode yang jarang disentuh boleh diterima risikonya; utang di jalur kritikal dibayar bertahap; utang yang membunganya lebih besar dari pokoknya (rewrite mahal untuk sistem yang akan dipensiunkan) cukup diisolasi. Register ini juga jadi bahasa kalian dengan stakeholder: "item DEBT-001 meningkatkan risiko SEV-1 di kuartal pajak" jauh lebih persuasif daripada "kode kita sudah jelek".

#Quality Gate Otomatis

Standar yang bergantung pada disiplin manusia akan terkikis pelan-pelan. Pindahkan sebanyak mungkin ke gate otomatis di pipeline:

• CI checks: lint, type check, test coverage threshold (turun = gagal), vulnerability scan dependency.
• PR policies: ukuran diff maksimum, wajib linked ticket, template deskripsi.
• Deploy gates: canary analysis, error budget burn rate sebagai rem rilis (jembatan ke SRE di episode 20).

Prinsip desainnya: gate otomatis untuk hal objektif dan murah diverifikasi (coverage, lint, scan), judgment manusia untuk hal nuanced (desain API, keterbacaan). Kebalikannya adalah resep bencana — menyerahkan lint kepada diskusi etika, dan menyerahkan keputusan arsitektur kepada robot.

#Sinyal Dini yang Dipantau EM

EM tidak perlu membaca kode setiap hari, tetapi perlu radar mingguan berbasis sinyal agregat:

Ritme praktisnya: 15 menit setiap Senin pagi membuka dashboard metrik (episode 13) plus debt register, cari tren dua-tiga minggu (bukan lonjakan sekali), lalu ajukan temuan ke forum yang tepat — retro untuk proses, architecture forum untuk teknis. EM yang punya radar begini mendeteksi pembusukan di bulan pertama; yang tidak, mendengarnya dari incident besar.

#Penutup

Inti yang harus dibawa pulang:

• Quality dijaga lewat sistem: definition of done tertulis, dipatuhi semua orang termasuk kalian sendiri.
• Review culture = kecepatan (SLA 1 hari) + nada (pertanyaan, bukan serangan); EM menjaga sistemnya, bukan mengambil alih semua review.
• Debt register mengubah keluhan vagu menjadi portofolio: bayar, pecah bertahap, terima risiko, atau isolasi — dengan bahasa risiko yang dipahami stakeholder.
• Quality gate otomatis untuk yang objektif; judgment manusia untuk yang nuanced.
• Radar mingguan 15 menit atas sinyal agregat (lead time, CFR, flaky ratio, onboarding time) mendeteksi pembusukan dini.

Di episode 10 selanjutnya kita hadapi bagian tersulit people management: Conflict Resolution — memahami akar konflik engineering, lima mode Thomas-Kilmann, skrip percakapan sulit, dan kapan konflik harus dieskalasi. Sampai jumpa!