Belajar Technical Product Manager - Launch & Rollout Teknis

#Pendahuluan

Setelah di episode 16 kita menyelesaikan cost analysis settlement T+0 dan memasang guardrail biaya, kini tiba momen paling menegangkan siklus produk: meluncurkan. Settlement T+0 sudah lolos QA, SLO terpasang, biaya masuk akal — tinggal satu pertanyaan berbahaya: bagaimana cara melepasnya ke produksi tanpa membakar kepercayaan merchant?

Kenapa rollout layak direncanakan serinci build-nya? Karena mayoritas insiden produk finansial bukan terjadi saat coding, melainkan saat pelepasan: konfigurasi salah, dampak tak terduga pada segmen user tertentu, atau kombinasi kondisi yang tidak pernah muncul di staging. Rollout yang baik mengubah risiko tunggal besar menjadi serangkaian eksperimen kecil yang bisa dibatalkan.

#Rollout Berlapis: Dari Internal ke GA

Prinsip dasarnya: setiap lapisan pelebaran adalah gerbang dengan criteria lolos. Untuk settlement T+0:

Dua hal yang membuat tabel ini bekerja: lapisan bisa mundur kapan saja (bukan hanya maju), dan criteria tiap gerbang ditulis sebelum rollout dimulai — bukan dirancang ulang saat sudah terlanjur antusias.

#Feature Flag dan Kill Switch

Feature flag memisahkan deploy kode dari aktivasi fitur — fondasi semua pola rollout modern:

feature: settlement_t0
state: enabled
rollout:
  strategy: percentage_by_merchant
  percentage: 5
  allowlist: ["MID-beta-001", "MID-beta-002"]
guardrails:
  kill_switch: true
  auto_disable_when:
    - metric: error_budget_burn_rate
      above: 6x
    - metric: ledger_reconciliation_mismatch
      above: 0
owner: payments-core-tpm

Tiga disiplin flag yang wajib dijaga TPM:

1. Kill switch teruji: matikan fitur lewat flag di staging sebelum rilis. Kill switch yang belum pernah dicoba adalah teori, bukan alat.
2. Auto-disable untuk risiko fatal: selisih rekonsiliasi lebih dari nol harus mematikan fitur sendiri — lebih cepat dari manusia mana pun.
3. Higienitas flag: setiap flag punya owner dan tanggal rencana pencabutan. Flag zombie menumpuk kompleksitas yang diam-diam memperlambat semua orang.

#Canary Deployment

Canary adalah versi otomatis dari lapis 2-3: trafik baru dialihkan sedikit-sedikit (1% → 5% → 25% → 100%) dengan metrik kesehatan dipantau tiap langkah, otomatis berhenti bila ambang terlanggar.

Peran TPM dalam canary bukan mengatur persentase — itu domain engineering — melainkan:

• Menyetujui metrik gerbang: apakah success rate cukup sebagai sinyal, atau perlu metrik bisnis spesifik?
• Menentukan durasi observasi minimum per langkah: pola anomali harian butuh minimal 24-48 jam, bukan 30 menit.
• Menyiapkan keputusan jika abu-abu: metrik sedikit turun tapi masih dalam budget — lanjut atau tahan? Keputusan semacam ini lebih mudah saat kriterianya sudah disepakati di awal.

#Metrik Kesehatan Selama Rollout

Dashboard rollout T+0 memantau empat keluarga metrik secara bersamaan:

• Teknis: error rate, p95 latency, burn rate error budget (episode 13).
• Korektif: selisih rekonsiliasi ledger — untuk fintech ini metrik veto.
• Produk: adopsi (berapa merchant memakai T+0), volume transaksi via jalur baru.
• Dampak operasional: tiket support masuk bertopik settlement — naik atau turun?

Aturan pembacaannya: teknis dulu, produk kemudian. Adopsi yang meroket saat error rate ikut naik bukan sukses — itu kebakaran yang ramai.

#Criteria Rollback yang Ditulis di Depan

Keputusan mundur harus murah secara sosial. Definisikan eksplisit:

Wajib rollback (otomatis via guardrail):
- Selisih rekonsiliasi > 0
- Burn rate error budget > 6x selama 15 menit
 
Manual review (TPM + eng lead, keputusan < 30 menit):
- Success rate turun 0.5% vs baseline selama 2 jam
- Tiket support settlement > 20/hari selama 3 jam
 
Proses rollback: flip flag -> verifikasi metrik pulih -> comms
template -> postmortem ringkas dalam 48 jam.

Catatan budaya penting: rollback yang cepat dan tenang adalah tanda sistem sehat, bukan kegagalan tim. Kalau tim takut rollback karena stigma, mereka akan menahan keputusan sampai masalah membesar — justru itulah kegagalan sesungguhnya.

#Launch Checklist Terpadu

Satu pekan sebelum GA, jalankan checklist yang menyatukan seluruh series ini:

[ ] PRD final + acceptance criteria lolos UAT (episode 5)
[ ] NFR terverifikasi: p95, availability, audit log (episode 5)
[ ] SLO terpasang + dashboard burn rate hidup (episode 13)
[ ] Compliance: requirement C1-C3 terverifikasi sampling (episode 14)
[ ] Cost: proyeksi biaya vs aktual beta selisih <= 20% (episode 16)
[ ] Flag + kill switch teruji di staging (episode ini)
[ ] Criteria rollback disetujui eng lead + support (episode ini)
[ ] Docs & changelog siap; support team sudah briefing (episode 15)
[ ] Comms: email merchant, status page draft, FAQ (episode ini)
[ ] Post-launch review terjadwal H+7 dan H+30 (episode ini)

Perhatikan checklist ini adalah rekapan mini series kita — bukti bahwa launch bukan acara terpisah, melainkan puncak dari disiplin-disiplin yang dibangun sejak discovery.

#Praktik: Rollout Plan Lengkap

Susun rollout plan satu halaman untuk GA settlement T+0: tabel lapis 0-4 dengan criteria, konfigurasi flag (salin struktur yaml di atas), criteria rollback dua tingkat, dan jadwal komunikasi (internal, merchant beta, publik). Simpan di 06-launch/rollout-t0.md.

#Penutup

Inti yang harus dibawa pulang:

• Rollout berlapis mengubah satu risiko besar menjadi deretan gerbang kecil yang bisa maju maupun mundur; criteria gerbang ditulis sebelum mulai.
• Feature flag memisahkan deploy dari aktivasi; kill switch harus teruji dan risiko fatal layak auto-disable.
• Di canary, kontribusi TPM adalah metrik gerbang, durasi observasi, dan aturan main keputusan abu-abu.
• Pantau empat keluarga metrik — teknis dulu, baru produk; adopsi ramai saat error naik adalah kebakaran.
• Rollback cepat tanpa stigma adalah fitur organisasi sehat; tulis criteria-nya di depan.

Di episode 18 selanjutnya kita masuk fase security mendalam: Security by Design — threat modeling STRIDE untuk fitur payout, abuse cases vs user stories, klasifikasi data, dan proses security review yang tidak membunuh velocity. Sampai jumpa!