Belajar Solution Architect - Stakeholder Communication

#Pendahuluan

Setelah di episode 10 kalian bisa membungkus desain dalam SDD yang benar-benar dibaca, diagram C4 yang tepat zoom-nya, dan handoff yang membuat tim mandiri — kini kita beralih ke skill yang menentukan apakah semua itu disetujui dan didukung: komunikasi dengan stakeholder. Banyak solusi secara teknis sempurna mati di ruang rapat, bukan karena desainnya buruk, melainkan karena architect-nya gagal membuat orang tepat paham dan yakin.

Fakta yang perlu diterima sejak awal: sebagai SA, separuh waktu kerja kalian adalah komunikasi — interview requirement, presentasi, negosiasi scope, melapor progres. Skill teknis membuat kalian dihormati engineer; skill komunikasi membuat solusi kalian terbangun. Keduanya wajib.

#Memetakan Stakeholder

Langkah pertama sebelum satu slide pun dibuat: tahu siapa yang harus diyakinkan dan apa kepentingan masing-masing. Alat sederhana yang efektif adalah matriks pengaruh × minat:

Dari tabel itu lahir aturan emas: pesan yang sama tidak dikirim sama rata. Sponsor butuh jawaban "berapa biaya, apa risikonya, kapan jadi"; engineer butuh "kenapa pola ini, apa konsekuensinya"; compliance butuh "data siapa yang disimpan di mana". Satu materi inti, tiga pembungkus.

#Menerjemahkan Teknis ke Bahasa Bisnis

Kemampuan inti SA adalah penerjemahan dua arah. Tiga teknik yang bisa langsung dipakai:

#1. Konversi Istilah → Dampak

Setiap istilah teknis harus dilengkapi dampak bisnisnya:

"Multi-AZ"            -> kalau satu datacenter mati, aplikasi tetap jalan;
                         downtime turun dari jam ke menit
"Circuit breaker"     -> kalau payment gateway macet, checkout kita tetap
                         hidup, antrean diproses begitu mereka pulih
"Autoscaling + spot"  -> kita hanya bayar kapasitas saat sale; tagihan
                         hari biasa tetap rendah
"RPO 5 menit"         -> data transaksi maksimal hilang 5 menit saat
                         bencana; setara maksimal X transaksi

Bangun tabel ini sendiri untuk proyek kalian dan rawat terus — ia menjadi kamus pribadi yang membuat kalian konsisten antar-pertemuan.

#2. Analogi yang Akurat

Analogi mempercepat pemahaman asal dipilih yang tidak menyesatkan:

• Availability zone = cabang bank: satu cabang tutup mendadak, nasabah dilayani cabang lain.
• Queue = antrean teller saat lebaran: pelanggan tetap dilayani urut meski loket sibuk, tanpa ada yang diusir.
• Idempotency = mesin ATM yang error di tengah proses tidak akan mengeluarkan uang dua kali.

Hindari analogi yang klaim lebih dari kenyataan ("cloud itu seperti listrik PLN") — stakeholder akan mengingat kesimpulan salah lebih lama daripada penjelasan kalian.

#3. Angka Sebagai Jangkar

Manajemen mengingat angka, bukan istilah. Selalu bawa tiga jenis angka: biaya (Rp per tiket), risiko (jam downtime setara Rp), dan waktu (minggu sampai launch). Kalimat paling persuasif di rapat solusi biasanya berbentuk: "Opsi A hemat Rp 8 juta/bulan tapi menambah 3 minggu dan risiko single-region; Opsi B lebih mahal tapi launch 90 hari aman. Rekomendasi kami B karena window sale tak bisa mundur."

#Menyusun Presentasi Solusi

Struktur presentasi solusi 15 menit yang terbukti bekerja:

1. Masalah & tujuan (2 menit) — ulangi requirement dengan bahasa audiens; pastikan semua sepakat masalahnya sebelum bahas solusinya.
2. Opsi yang dipertimbangkan (4 menit) — minimal dua-tiga opsi termasuk yang ditolak; menampilkan alternatif meningkatkan kredibilitas drastis.
3. Rekomendasi & alasan (5 menit) — diagram C1/C2 sederhana, keputusan utama beserta trade-off-nya, bukti (PoC, benchmark).
4. Biaya, risiko, timeline (3 menit) — angka dari SDD; risiko selalu disertai mitigasi dan owner.
5. Keputusan yang diminta (1 menit) — akhiri eksplisit: "hari ini kami minta persetujuan budget fase 1". Rapat tanpa permintaan konkret = rapat tanpa hasil.

Aturan slide: satu pesan per slide, diagram lebih baik dari teks, font terbaca dari belakang ruangan. Slide kalian adalah pendukung cerita — bukan naskah yang kalian bacakan.

#Mengelola Pertanyaan Sulit dan Konflik

Beberapa situasi yang pasti kalian hadapi, plus cara menanganinya:

• "Kenapa tidak pakai [teknologi tren]?" — jawab dengan framework episode 4: tunjukkan bobot kriteria dan skor opsi tersebut di konteks kita. Jujur jika skor itu bagus untuk kasus lain; tegas bahwa konteks kita berbeda.
• Permintaan fitur mendadak di tengah desain — jangan langsung ya/tidak; tanyakan dampaknya pada timeline/biaya, hitung cepat bersama, serahkan pilihan ke sponsor: "bisa, dengan geser launch 2 minggu atau tambah 1 engineer. Mana yang Anda pilih?" Mengubah keputusan menjadi pertukaran eksplisit adalah inti negosiasi sehat.
• Konflik antar-departemen (marketing mau fitur cepat, finance mau hemat) — posisikan diri sebagai pemegang data, bukan pihak: tampilkan trade-off kedua opsi, minta mereka memutuskan prioritasnya. SA yang memihak terlalu dini kehilangan peran mediatornya.
• Kalian tidak tahu jawabannya — katakan jujur plus komitmen: "belum ada datanya, saya kirimkan hasil PoC Kamis depan." Kredibilitas dibangun oleh kejujuran kecil berulang, bukan keberanian menebak.

#Komunikasi Asynchronous yang Rapi

Tidak semua komunikasi terjadi di rapat. Kebiasaan async yang menjaga kepercayaan:

• Status update mingguan singkat: progres, keputusan yang dibutuhkan, risiko baru — format tetap, panjang maksimal setengah halaman.
• Catatan keputusan segera setelah rapat penting: siapa memutuskan apa, dikirim ke semua peserta. Ini pencegah "saya kan bilang kemarin".
• Thread keputusan tertulis untuk topik sensitif: percakapan verbal tentang scope/biaya wajib diringkas tertulis dalam 24 jam.

#Penutup

Inti yang harus dibawa pulang:

• Petakan stakeholder dengan kuadran pengaruh × minat; pesan yang sama dibungkus berbeda untuk tiap kelompok.
• Terjemahkan istilah teknis ke dampak bisnis, gunakan analogi yang akurat, dan jangkar angka: biaya, risiko, waktu.
• Struktur presentasi solusi 15 menit: masalah → opsi → rekomendasi → biaya/risiko/timeline → keputusan yang diminta.
• Kelola pertanyaan sulit dengan data (scoring matrix), ubah permintaan mendadak menjadi pertukaran eksplisit, dan jaga netralitas saat konflik.
• Keputusan penting selalu diringkas tertulis dalam 24 jam — memori manusia bukan sistem rekam yang andal.

Di episode 12 selanjutnya kita masuk Fase 3 dengan hybrid & migration solutions — strategi 6R untuk migrasi ke cloud, merancang solusi hybrid yang menyambungkan data center lama dengan platform baru, serta pola modernization yang realistis untuk sistem legacy. Sampai jumpa di episode 12!