Menjadi Orang yang Dicari Saat Masih Gelap

24.8 Menjadi Orang yang Dicari Saat Masih Gelap

Ada satu momen yang membedakan arsitek yang benar-benar dibutuhkan dari arsitek yang sekadar ada di org chart. Momen itu bukan saat semua orang sudah tahu apa yang harus dikerjakan. Momen itu adalah saat tim masih bingung, belum ada yang bisa menjelaskan masalah dengan jelas, dan semua orang menunggu seseorang yang bisa membuat situasi menjadi lebih terang.

Di momen seperti itu, sebagian engineer akan menunggu tugas. Mereka terbiasa menerima user story yang sudah dipecah, acceptance criteria yang jelas, dan definisi done yang tidak perlu dipertanyakan. Tapi arsitek yang tumbuh menjadi problem shaper justru bergerak ke arah sebaliknya. Ketika masalah masih gelap, mereka datang dengan template dan checklist yang membantu organisasi melihat bentuk masalah sebelum solusi dicari.

Salah satu alat paling sederhana yang bisa Anda pakai adalah system context diagram. Bukan diagram arsitektur yang rumit, cukup gambar sederhana yang menunjukkan sistem yang sedang dibahas, siapa yang berinteraksi dengannya, dan apa batasnya. Saat tim masih debat tentang scope, Anda bisa menggambar kotak di tengah, lalu bertanya: "Siapa yang akan memakai sistem ini? Sistem lain apa yang tersentuh? Data apa yang masuk dan keluar?" Pertanyaan-pertanyaan itu mengubah perdebatan abstrak menjadi diskusi yang bisa dijawab.

Setelah batas sistem mulai terlihat, Anda perlu mendokumentasikan keputusan yang muncul. Gunakan ADR yang sederhana: konteks keputusan, opsi yang dipertimbangkan, alasan memilih satu opsi, dan konsekuensinya. Di titik ini, ADR bukan lagi teori dokumentasi; ia menjadi alat untuk membuat forum tetap bergerak tanpa mengulang diskusi yang sama.

Trade-off sendiri perlu dikelola secara eksplisit. Design trade-off matrix membantu Anda membandingkan opsi secara visual. Misalnya, tim sedang memilih antara pendekatan synchronous dan asynchronous untuk integrasi dua sistem. Anda bisa membuat matriks dengan baris berisi kriteria seperti latency, konsistensi data, kompleksitas operasional, dan biaya pengembangan. Setiap opsi diberi skor sederhana. Hasilnya bukan jawaban mutlak, tapi alat diskusi yang membuat tim bisa melihat konsekuensi setiap pilihan.

Tapi tidak semua risiko bisa dihilangkan dengan pemilihan opsi. Beberapa risiko akan tetap ada, dan Anda perlu mengklasifikasikannya. Mitigation pengelompokan membantu Anda membedakan mana risiko yang bisa dicegah, mana yang bisa dideteksi, mana yang bisa dikurangi dampaknya, dan mana yang harus diterima. Klasifikasi ini penting karena arsitek tidak bisa menghilangkan semua ketidakpastian. Yang bisa dilakukan adalah membuat organisasi tahu persis apa yang mereka hadapi dan bagaimana mereka akan merespons jika skenario buruk terjadi.

Ketika Anda membawa alat-alat ini ke dalam forum, peran Anda berubah. Anda bukan lagi orang yang menunggu tugas. Anda adalah orang yang membantu tim melihat bentuk masalah, membandingkan opsi secara terstruktur, dan membuat keputusan dengan risiko yang sudah dipetakan. Anda menjadi orang yang dicari saat masih gelap, karena Anda membawa senter, bukan hanya menunggu lampu menyala.

Berikut adalah diagram alur yang merangkum langkah-langkah menjadi problem shaper saat situasi masih gelap.

Inilah bentuk kerja yang ingin dibangun buku ini. Bukan sekadar merancang solusi, tetapi membentuk masalah sehingga organisasi bisa bergerak dengan percaya diri. Setelah pola ini terlihat, langkah selanjutnya adalah menyusun peta latihan yang konkret agar kemampuan seperti ini bisa dilatih secara bertahap.