Belajar Technical Product Manager - Migration & Platform Initiatives

#Pendahuluan

Setelah di episode 10 kita menetapkan budget debt 20% dan menyusun debt register — termasuk TD-1, settlement batch single-thread yang akan dibayar penuh Q4 — episode ini membahas bentuk pembayaran debt yang paling berisiko: migrasi. NusaPay akan memindahkan settlement engine dari batch malam ke event-driven; ini bukan fitur, tapi proyek yang bisa membunuh platform kalau salah kelola.

Kenapa migrasi layak perlakuan khusus? Karena ia punya karakter unik: user tidak memintanya, nilainya tak terlihat sampai selesai, dan risikonya menyentuh seluruh sistem hidup. TPM yang menjalankan migrasi seperti menjalankan fitur biasa hampir pasti gagal — atau lebih tepatnya, berhasil membuat semua orang frustrasi.

#Kenapa Big Bang Hampir Selalu Gagal

Pola klasik kegagalan: freeze pengembangan 6 bulan, bangun sistem baru secara diam-diam, lalu satu akhir pekan "cutover besar". Masalahnya tumpuk:

1. Nilai tertunda: selama 6 bulan tidak ada benefit yang mengalir; stakeholder hanya melihat biaya.
2. Realitas bergerak: sistem lama tetap berubah (bug fix, regulasi); targetnya seperti memindahkan rumah sambil rumahnya direnovasi.
3. Risiko terkonsentrasi: satu momen cutover berisi seluruh risiko; jika gagal, rollback-nya juga big-bang.
4. Paritas tak terverifikasi: perbedaan perilaku halus (pembulatan, urutan event) baru ketemu saat produksi.

Aturan praktisnya: migrasi besar harus bertahap dan dapat dibatalkan di setiap langkah.

#Pola Strangler Fig

Pola andalan migrasi platform: sistem baru tumbuh di sekeliling yang lama, mengambil alih tanggung jawab satu per satu, sampai yang lama bisa dicabut. Untuk migrasi settlement NusaPay:

100%

Tiga properti pola ini yang membuatnya aman:

• Routing layer memutuskan trafik mana ke sistem baru; persentase bisa dinaikkan/diturunkan kapan saja.
• Kedua jalur menulis ke ledger yang sama, sehingga data konsisten selama masa transisi.
• Rollback = setel routing balik — operasi detik, bukan proyek.

Urutan yang disarankan: mulai dari segmen berisiko terkecil (QRIS nominal rendah), verifikasi paritas, naikkan bertahap sampai 100%, baru cabut batch engine untuk channel itu.

#Dual-Write dan Shadow Traffic

Dua teknik verifikasi sebelum trafik nyata dipercayakan:

Dual-write: sistem baru menerima event yang sama dengan sistem lama, keduanya bekerja, hasilnya dibandingkan otomatis. Selama masa dual-run, dashboard paritas menampilkan selisih — target: nol selisih selama dua minggu berturut sebelum routing dinaikkan.

Shadow traffic: salinan trafik produksi dikirim ke sistem baru tanpa efek nyata (response dibuang), semata untuk menguji beban dan perilaku. Sistem baru "berlatih" dengan beban sungguhan tanpa mempertaruhkan dana siapa pun.

#Cutover Plan dan Milestone

Migrasi butuh plan yang bisa dilaporkan ke manajemen. Format milestone NusaPay:

Perhatikan setiap fase punya kriteria objektif dan rencana mundur. Ini yang membuat manajemen berani menyetujui migrasi: risikonya terbagi menjadi langkah-langkah kecil yang masing-masing bisa dibatalkan.

#Menjual Migration ke Stakeholder

Bagian tersulit sering bukan teknis, melainkan mendapat kapasitas sprint. Framing yang bekerja:

• Bicara bunga debt: "setiap kuartal kita menunda, biaya insiden settlement X rupiah dan velocity squad turun Y%" — pakai angka dari debt register episode 10.
• Buka pintu pasar: "enterprise buyer minta settlement real-time; ini syarat revenue Z".
• Jual progres bertahap: tunjukkan M1 memberi observability yang sudah berguna meski migrasi belum selesai — nilai mengalir sejak awal, bukan setelah M5.
• Tunjukkan jalan mundur: rollback plan per fase adalah penenang eksekutif terkuat.

Dan satu kejujuran wajib: migrasi hampir selalu meleset dari estimasi awal. Komunikasikan confidence band (episode 12) sejak hari pertama supaya meleset tidak meruntuhkan kredibilitas kalian.

#Metrik Sukses Migration

Definisikan sejak hari satu bagaimana kalian akan menyatakan migrasi berhasil:

• Teknis: paritas output 100%, error rate baru ≤ lama, p95 latency ≤ baseline, zero data loss (ledger rekonsiliasi).
• Produk/bisnis: fitur T+0 bisa rilis setelahnya (ini tujuan akhirnya!), tiket support settlement turun, insiden settlement = 0 pasca-M5.
• Tim: engineer on-call percaya sistem baru (tanyakan langsung — mereka penilai paling jujur).

Tanpa definisi selesai yang jelas, migrasi cenderung jadi proyek zombie yang "hampir selesai" selama berbulan-bulan.

#Praktik: Migration One-Pager

Tulis one-pager migrasi settlement untuk manajemen: masalah (dengan angka bunga debt), pendekatan strangler + dual-write dalam tiga kalimat, tabel milestone ringkas M1-M5 dengan rollback, budget kapasitas yang diminta per kuartal, dan definisi selesai. Simpan di 04-roadmap/migration-t0.md.

#Penutup

Inti yang harus dibawa pulang:

• Big bang migration menunda nilai, terkalahkan oleh realitas, dan mengonsentrasikan risiko — hindari.
• Strangler fig + routing layer membuat setiap langkah dapat dinaikkan dan dibatalkan; rollback harus operasi kecil, bukan proyek.
• Dual-write dan shadow traffic membuktikan paritas dengan data produksi sebelum trafik dipercayakan.
• Cutover plan per fase dengan kriteria lanjut objektif adalah alat komunikasi manajemen sekaligus disiplin teknis.
• Jual migrasi lewat bunga debt dan pintu pasar, dengan confidence band yang jujur sejak awal.

Di episode 12 selanjutnya kita bahas seni yang paling sering bikin TPM tersandung: Technical Estimation & Planning — kenapa estimasi sulit secara fundamental, teknik three-point estimation, story points vs waktu, sequencing dependency, dan cara mengomunikasikan ketidakpastian ke stakeholder tanpa kehilangan wajah. Sampai jumpa!