Belajar Platform Engineer - Platform-as-a-Product Advanced
Mengelola platform seperti produk sungguhan: struktur tim produk, user research kepada developer, roadmap berbasis hasil, dan KPI platform berbasis DORA yang diukur bukan ditebak
#Pendahuluan
Di episode 2 kita mengenalkan platform mindset: developer adalah pengguna, platform adalah produk. Episode ini mengoperasionalkannya sepenuhnya: platform-as-a-product advanced — struktur tim produk, user research kepada developer, roadmap berbasis hasil, dan KPI platform berbasis DORA. Inilah yang membedakan tim platform yang berkembang dari tim infrastruktur yang sibuk.
Mengapa ini penting? Banyak tim platform hebat secara teknis tapi gagal diadopsi — karena mereka membangun "sesuatu yang keren" tanpa bertanya apa yang benar-benar dibutuhkan developer. Product management yang serius memecahkan masalah itu: platform dibangun dari kebutuhan nyata, diukur, dan diperbaiki — persis seperti produk eksternal, dengan KPI yang jelas.
#Struktur Tim Platform-as-a-Product
Platform adalah produk internal, jadi butuh fungsi produk:
| Peran | Tanggung jawab |
|---|---|
| Platform product manager | Memahami kebutuhan developer, memprioritaskan roadmap |
| Platform engineer (member) | Membangun dan mengoperasikan platform |
| Developer advocate (internal) | Sosialisasi, onboarding, umpan balik lapangan |
| Tech lead / EM | Kualitas teknis, arsitektur, dan SLO platform |
Tim yang sehat tidak "menunggu tiket" — ia proaktif mencari kebutuhan: mengunjungi tim, melihat pipeline mereka, dan menemukan pain point sebelum menjadi tiket.
#User Research: Mendengarkan Developer
Roadmap yang benar dimulai dari riset. Tiga teknik utama:
- Developer interviews — duduk dengan 3-5 tim yang workload-nya berbeda. Tanya: apa yang membuatmu lambat minggu ini? Bukan "fitur platform apa yang kamu mau?".
- Observasi langsung — menonton developer melakukan golden path; temukan langkah manual yang tak disadari siapa pun.
- Survei berkala — DX score, NPS platform, dan pertanyaan "apa satu hal yang platform bisa perbaiki".
Pola kerja yang umum: Jobs-to-be-Done (JTBD). Developer tidak "mau Terraform" — ia ingin "membuat environment staging tanpa menunggu 3 hari". Fokus pada job, bukan pada tools.
#Roadmap Berbasis Hasil
Roadmap platform menggunakan kerangka now / next / later:
| Now (kuartal ini) | Next (kuartal berikut) | Later (investigasi) |
|---|---|---|
| Perbaiki provisioning staging (target: < 15 menit) | Golden path deploy canary untuk semua tim | Platform untuk AI workloads (ep. 21) |
| User research 5 tim besar | Docs refresh + TechDocs | Migrasi service lama |
Ciri roadmap yang sehat:
- Berbasis hasil (outcome), bukan deliverables ("kurangi provisioning time 50%", bukan "buat modul X").
- Satu prioritas besar per kuartal, bukan 10 item serba penting.
- Membangun dukungan — keputusan diambil dari data riset, bukan selera anggota tim.
#KPI Platform: DORA dan Sekitarnya
KPI platform mengukur dampak ke developer, bukan aktivitas tim platform. Kerangka paling mapan: DORA metrics:
| Metrik DORA | Makna untuk platform |
|---|---|
| Deployment frequency | Seberapa sering rilis bisa terjadi (platform membuat rilis mudah?) |
| Lead time for change | Dari commit ke production (pipeline, review, provisioning) |
| Change failure rate | Seberapa sering rilis menyebabkan masalah (gate dan test yang baik) |
| MTTR (time to restore) | Seberapa cepat pulih dari failure (observability, rollback) |
Melengkapi DORA, KPI khas platform:
| KPI | Target realistis |
|---|---|
| % deploy melalui golden path | > 80% |
| Time-to-provision environment | < 15 menit |
| DX / platform NPS | Meningkat kuartal ke kuartal |
| Tiket platform per developer | Menurun |
| Adopsi catalog & self-service | > 70% layanan baru |
Aturan emas: ukur baseline sebelum membangun. Platform tanpa baseline tidak pernah bisa membuktikan dampaknya.
#Pendanaan: Cost Center → Value
Model pendanaan menentukan perilaku. Tiga model umum:
| Model | Cara kerja | Risiko |
|---|---|---|
| Cost center | Platform digaji dari budget pusat | Susah membuktikan nilai; sering dipangkas |
| Showback | Biaya diinformasikan ke tim | Kesadaran biaya, tanpa sanksi |
| Chargeback | Biaya dibebankan ke tim | Tim enggan memakai platform; jangan diterapkan di awal |
Rekomendasi umum: mulai showback (dari episode 11), lalu tunjukkan bahwa platform mengurangi total biaya (licensing, toil, downtime) melebihi biayanya.
#Common Pitfalls
- Roadmap berisi fitur, bukan hasil — sulit dibuktikan dampaknya; selalu tulis outcome yang terukur.
- Riset sekali, lalu membangun dari asumsi — kebutuhan berubah; riset adalah proses berkelanjutan.
- KPI mengukur aktivitas, bukan dampak — "jumlah modul yang dibuat" tidak bermakna tanpa "lead time turun".
- Tim platform berjarak dari developer — tanpa observasi langsung, roadmap melenceng dari kebutuhan nyata.
- Chargeback sejak awal — platform ditinggalkan sebelum membuktikan nilainya; mulailah dari showback.
Tip
Riset dulu, bangun kemudian. Aturan praktis: sebelum mengerjakan fitur platform apa pun, tanyakan tiga hal — developer mana yang mengalaminya, apa hasil yang terukur, dan apa bukti risetnya. Jika tidak ada, jangan mulai; adopsi platform bergantung pada kepercayaan, dan kepercayaan dibangun dari fitur yang memecahkan masalah nyata.
#Penutup
Inti yang harus dibawa pulang:
- Tim platform-butuh-fungsi-produk: PM, engineer, advocate, tech lead — yang proaktif, bukan menunggu tiket.
- User research (interview, observasi, survei) adalah sumber kebenaran roadmap.
- Roadmap berbasis hasil dengan kerangka now/next/later.
- KPI platform berbasis DORA + KPI adopsi; ukur baseline sebelum membangun.
- Mulai dari showback, dan buktikan platform menurunkan biaya total.
Di episode 23 selanjutnya kita memberi skor pada kemajuan platform: scorecard & maturity platform — platform maturity model, scorecards di Backstage, dan metrik adopsi yang menunjukkan apakah platform kalian benar-benar berfungsi atau hanya sekadar ada!