Belajar Engineering Manager - Resource & Capacity Planning

#Pendahuluan

Setelah di episode 7 kita membangun sistem delivery — planning berlapis, prioritisasi RICE, commitment jujur — sekarang kita garap bahan bakunya: kapasitas.

Mengapa capacity planning layak episode sendiri? Karena mayoritas overcommitment bukan lahir dari ambisi, melainkan dari aritmetika yang salah: manager menghitung kapasitas sebagai jumlah orang dikali hari kerja, padahal kapasitas riil selalu lebih kecil karena meeting, on-call, cuti, interview, dan context switching. Tim yang dihitung 60 person-hari tapi riilnya 38 akan gagal memenuhi komitmen apa pun yang dibangun di atas angka 60 — bukan karena malas, melainkan karena matematis mustahil.

#Focus Factor: Kapasitas Riil vs Nominal

Konsep paling penting di episode ini: focus factor — rasio waktu yang benar-benar tersedia untuk pekerjaan terencana terhadap waktu nominal.

Waktu nominal          : 10 hari kerja
Dikurangi meeting rutin: -1.5 hari (standup, sync, demo)
Dikurangi on-call      : -0.5 hari (rata-rata termasuk follow-up)
Dikurangi support/ops  : -1.0 hari (bug harian, pertanyaan internal)
Dikurangi admin & HR   : -0.5 hari (1:1, review, administrasi)
Dikurangi buffer       : -1.5 hari (unknowns, context switch)
------------------------------------------------------------
Kapasitas efektif      : ~5 hari = focus factor 0.5

Focus factor realistis untuk tim engineering dengan meeting sehat berkisar 0.5 sampai 0.7 — jarang lebih tinggi. Kalau kalian menemukan diri menaikkan asumsinya demi membuat rencana terlihat bagus, itu bukan planning; itu wishful thinking yang ditagihkan dua minggu kemudian. Hitung focus factor tim kalian dari data historis: total story points selesai dibagi kapasitas nominal tiga sprint terakhir, lalu pakai median hasilnya sebagai baseline.

#Alokasi Kapasitas: Portofolio, Bukan Satu Keranjang

Kapasitas efektif lalu dibagi ke empat keranjang. Rasio awal yang sehat untuk tim produk matang:

Angka pastinya fleksibel — tim dekat rilis besar bisa 80% feature; tim di atas codebase warisan mungkin butuh 30% debt. Yang tidak boleh dinegosiasikan adalah keberadaan keranjang debt dan innovation: begitu mereka "dipotong demi deadline", utang teknis berbunga diam-diam dan enam bulan kemudian velocity turun persis saat kalian paling butuh cepat. Perlakukan alokasi ini sebagai kebijakan yang dibicarakan terbuka dengan stakeholder, bukan rahasia dapur engineering.

#Capacity Plan Praktis

Bentuk konkret dokumen kapasitas tim cukup tabel sederhana:

Tim: Payments Platform - 6 engineer + 1 EM
 
Kapasitas nominal : 7 orang x 10 hari        = 70 hari
Fokus faktor      : 0.6                      = 42 hari efektif
 
Pengurangan spesifik:
- Cita cuti 3 hari                -> -3 x 0.6 = -1.8
- Andi interview panel 2 sesi     -> -1.0
- On-call carry-over dari insiden -> -1.5
Efektif setelah penyesuaian      : ~37.7 hari (~34%)
 
Alokasi rencana:
- Feature  : checkout v2 lanjutan     : 22 hari (58%)
- Debt     : pecah modul ledger       : 7 hari  (19%)
- Support  : baseline bug             : 4 hari  (11%)
- Innov    : spike observability eBPF : 4.7 hari (12%)
 
Uji feasibility roadmap:
- Permintaan stakeholder tambahan: dashboard refund (estimasi 6 hari)
- Kapasitas tersisa              : 0 hari -> JAWABAN: masuk antrian
  sprint 37 ATAU tukar dengan item debt (keputusan prioritisasi)

Perhatikan pola kalimat terakhirnya: ketika permintaan baru datang tanpa kapasitas tersisa, jawaban EM bukan "tidak bisa" atau "ya sudah dipaksakan", melainkan pilihan eksplisit — tambah ke antrean, atau tukar dengan item lain. Trade-off yang dinyatakan menjaga integritas plan; trade-off yang disembunyikan merusak semuanya diam-diam.

#Menguji Feasibility Roadmap

Level organisasi: gunakan kapasitas kuartalan untuk menguji apakah roadmap realistis sebelum dikomunikasikan keluar. Caranya:

1. Jumlahkan kapasitas efektif kuartal (orang × hari × focus factor − cuti musiman).
2. Kurangi alokasi wajib: support baseline, on-call rotation, compliance.
3. Bandingkan sisa dengan total effort roadmap (dalam person-bulan estimasi).
4. Keputusan: jika sisa kapasitas 70% dari kebutuhan roadmap, ada tiga opsi jujur — kurangi scope roadmap, geser timeline, atau tambah headcount. Yang tidak boleh adalah menandatangani roadmap 100% dengan kapasitas 70% dan berdoa.

#Kapan Hiring Benar-Benar Jawaban

Permintaan kapasitas biasanya berujung pada satu pertanyaan: harus hire? Gunakan urutan keputusan ini:

Jika hiring memang jawabannya, ingat ramp-up: engineer baru butuh 2-3 bulan sebelum kontribusinya setara penuh. Artinya keputusan hire bulan ini baru terasa penuh di kuartal depan — rencanakan ke belakang, jangan berharap menyelamatkan kuartal ini (ingat hukum Brooks dari episode 7).

Untuk demand jangka pendek yang nyata, contractor adalah katup yang sah — dengan catatan knowledge transfer yang direncanakan sejak kontrak ditulis, agar tim tidak mewarisi sistem hantu setelah kontraknya habis.

#Penutup

Inti yang harus dibawa pulang:

• Kapasitas riil = orang × hari × focus factor (realistis 0.5-0.7); hitung dari data tiga sprint terakhir, bukan optimisme.
• Bagi kapasitas menjadi portofolio: feature ~60%, debt ~20%, support ~10%, innovation ~10% — debt dan innovation tidak boleh hilang.
• Capacity plan membuat trade-off eksplisit: permintaan baru dijawab dengan antre atau tukar, bukan pemaksaan senyap.
• Uji roadmap kuartalan dengan aritmetika kapasitas; jangan tanda tangani janji 100% di atas kapasitas 70%.
• Hiring adalah jawaban terakhir setelah potong backlog, redistribusi, dan perbaikan proses — dan butuh 2-3 bulan ramp-up.

Di episode 9 selanjutnya kita kembali ke pilar ketiga: Technical Quality Oversight — cara EM menjaga standar engineering, membangun budaya code review yang sehat, mengelola technical debt sebagai portofolio terukur, dan mendesain quality gate tanpa menjadi bottleneck. Sampai jumpa!