Belajar Technical Product Manager - Requirements & Specs Teknis

#Pendahuluan

Setelah di episode 4 kita melatih system thinking — membaca arsitektur NusaPay, mengenali trade-off dan constraint — episode ini membahas artefak tempat semua pemahaman itu dikristalkan: spesifikasi. PRD teknis adalah kontrak pemahaman antara produk dan engineering; kalau salah tulis, seluruh sprint yang mahal akan membangun hal yang tidak diminta.

Mengapa spesifikasi jadi titik gagal favorit tim produk? Karena dua kegagalan berbeda menyamar sebagai satu kata "requirement": requirement yang ambigu (dua engineer membaca, dua pemahaman) dan requirement yang terlalu presisi solusinya (PM menulis desain tanpa sadar). Episode ini memberi kalian alat untuk menghindari keduanya.

#Anatomi PRD Teknis

PRD teknis berbeda dari PRD biasa karena ia harus cukup presisi untuk dibangun. Struktur yang kita pakai sepanjang series:

# PRD: Settlement T+0 (Opsi Batch Siang)
1. Latar belakang        : masalah + bukti (tiket support, churn data)
2. Goal & non-goal       : apa yang diselesaikan, apa yang sengaja tidak
3. User & use case       : siapa, skenario utama, frekuensi
4. Functional requirements: perilaku sistem per skenario (tertestable)
5. Non-functional reqs   : latency, availability, security, auditability
6. Trade-off & opsi      : opsi yang ditolak dan alasannya
7. Metrik sukses         : angka target + cara pengukuran
8. Rollout plan          : fase rilis, flag, rollback
9. Open questions        : belum diputuskan, dengan owner & deadline

Bagian 2 (non-goal) dan 9 (open questions) adalah pembeda PRD matang: keduanya mencegah scope creep dan menampung ketidakpastian secara jujur daripada menyembunyikannya.

#Non-Functional Requirements Harus Terukur

NFR sering ditulis malas — "sistem harus cepat dan aman" — lalu diperdebatkan saat UAT karena tidak ada definisi lolos-gagal. Aturan emas: setiap NFR punya angka, kondisi, dan metode ukur.

Sistem harus cepat.
Settlement harus reliable.
Dashboard tidak boleh lambat.

p95 latency create-settlement request <= 800 ms pada load 200 rps.
Availability settlement API >= 99.9% per bulan (error budget 43 menit).
Semua aksi admin settlement tercatat di audit log dalam <= 5 detik.

Perhatikan tiga unsur pada versi baik: persentil (p95, bukan rata-rata — ekor distribusi yang menyakitkan user), kondisi beban (pada 200 rps), dan satuan waktu yang konkret. Cara menentukan angkanya? Ambil dari data saat ini (baseline), permintaan bisnis (SLA enterprise), atau biaya (setiap penurunan latency berarti infrastruktur lebih mahal — topik episode 16).

#Acceptance Criteria: Given-When-Then

Functional requirement menjadi testable lewat format Gherkin. Untuk fitur settlement T+0:

Scenario: Settlement batch siang hanya mencakup transaksi final
  Given transaksi A berstatus "settled" pukul 11.30 WIB
  When batch settlement T+0 berjalan pukul 12.00 WIB
  Then dana transaksi A masuk daftar payout siang
 
Scenario: Transaksi disputed tidak ikut batch
  Given transaksi B berstatus "disputed" pukul 11.55 WIB
  When batch settlement T+0 berjalan pukul 12.00 WIB
  Then transaksi B ditunda ke batch berikutnya
  And merchant menerima event "settlement.deferred"

Kekuatan format ini bukan pada sintaksnya, melainkan pada disiplin berpikirnya: setiap scenario memaksa kalian mendefinisikan kondisi awal, aksi, dan hasil yang dapat diverifikasi. Engineer langsung bisa menerjemahkannya menjadi test case — dan QA tidak perlu menebak maksud kalian.

#Jebakan Umum Penulisan Requirement

Empat jebakan yang paling sering merusak sprint:

1. Solusi menyamar jadi requirement: "tambahkan tabel rekap di dashboard" bukan requirement — requirement-nya adalah "finance team butuh melihat ringkasan harian tanpa export CSV". Solusinya boleh didiskusikan bersama engineering; mungkin ada cara yang lebih murah.
2. Kata ambigu: "cepat", "user-friendly", "beberapa", "mendukung". Ganti semua dengan angka atau contoh konkret.
3. Requirement siluman lintas tim: fitur settlement ternyata menuntut perubahan di ledger milik squad lain. Deteksi ini di awal lewat review lintas squad, bukan di minggu ketiga sprint.
4. Tidak ada definisi gagal: PRD hanya menjelaskan sukses. Tulis juga apa yang terjadi saat dependency down, input aneh, atau load melonjak.

#Dari PRD ke Tiket

PRD adalah dokumen strategis; tiket adalah unit kerja. Alur pemecahan yang sehat: PRD → epik → story → task, dengan acceptance criteria terdistribusi ke story terkait. Jangan pernah menulis tiket yang isinya "implementasikan PRD" — pecah sampai tiap tiket punya criteria sendiri dan muat dalam beberapa hari kerja. Mekanika prioritas dan kolaborasinya kita bedah di episode 8.

#Praktik: Tulis PRD Settlement T+0

Latihan episode ini: lengkapi PRD satu halaman untuk opsi batch siang menggunakan struktur di atas. Minimal tiga functional scenarios Gherkin, empat NFR terukur dengan baseline, dan satu open question dengan owner. Simpan di 03-specs/ workspace kalian.

#Penutup

Inti yang harus dibawa pulang:

• PRD teknis punya sembilan bagian; non-goal dan open questions sama pentingnya dengan requirement.
• NFR wajib punya angka, kondisi beban, dan metode ukur — pakai persentil, bukan rata-rata.
• Acceptance criteria Given-When-Then membuat requirement testable dan memaksa disiplin berpikir.
• Waspadai empat jebakan: solusi menyamar jadi requirement, kata ambigu, dependency siluman, dan definisi gagal yang hilang.

Di episode 6 selanjutnya kita masuk wilayah paling khas TPM: APIs & Platform Products — bagaimana mengelola API sebagai produk dengan developer sebagai user, prinsip desain endpoint, idempotency untuk pembayaran, kebijakan breaking change, hingga platform economics. Sampai jumpa!