23-5 · Bab 23 · 4 menit baca

Bicara ke Engineer, Manager, dan Bisnis dengan Bahasa Mereka

Setelah dependency terpetakan, kita perlu mengomunikasikan temuan ini kepada berbagai pihak dengan cara yang sesuai dengan bahasa mereka. Ini adalah titik di mana banyak arsitek gagal, bukan karena an

23.5 Bicara ke Engineer, Manager, dan Bisnis dengan Bahasa Mereka

Diagram berikut merangkum perbedaan kebutuhan setiap audiens dan bagaimana arsitek dapat menyusun ulang informasi yang sama.

flowchart TD A[Peta Dependency] --> B[Engineer] A --> C[Manager] A --> D[Bisnis] B --> B1[Pertanyaan: Bagaimana cara kerja?] B1 --> B2[Detail: Interface, protokol, skema data] B2 --> B3[Format: Diagram teknis, endpoint] C --> C1[Pertanyaan: Berapa lama & risiko?] C1 --> C2[Detail: Jadwal, sumber daya, hambatan] C2 --> C3[Format: Timeline, risk register] D --> D1[Pertanyaan: Berapa biaya & value?] D1 --> D2[Detail: Biaya, ROI, manfaat bisnis] D2 --> D3[Format: Cost estimate, value projection]

Bayangkan Anda baru saja menyelesaikan pemetaan dependency untuk tiga opsi solusi. Anda tahu persis mana yang punya risiko integrasi tinggi, mana yang butuh perubahan database, dan mana yang bergantung pada tim lain yang sedang sibuk. Lalu Anda masuk ke ruang meeting dan mulai menjelaskan semuanya dengan detail teknis yang sama untuk semua orang. Hasilnya? Engineer merasa dibombardir informasi yang sudah mereka tahu. Manager mulai melihat jam tangan. Dan orang bisnis diam saja karena tidak mengerti apa yang Anda bicarakan.

Setiap audiens datang dengan pertanyaan yang berbeda. Engineer ingin tahu bagaimana cara kerjanya secara teknis. Mereka butuh detail tentang interface, protokol, skema data, dan konsekuensi arsitektural dari setiap opsi. Jika Anda hanya bilang "opsi A lebih sederhana", mereka akan bertanya "sederhana dalam hal apa? Berapa banyak service yang berubah? Apakah ada breaking change?" Anda harus siap dengan jawaban teknis yang konkret.

Manager datang dengan pertanyaan yang berbeda. Mereka peduli pada jadwal, sumber daya, dan risiko. Seorang manager ingin tahu: opsi mana yang bisa selesai lebih cepat? Tim mana yang perlu dilibatkan? Apa yang bisa menghambat? Apakah ada dependency yang bisa membuat proyek molor? Jika Anda bicara teknis terlalu dalam, mereka akan kehilangan konteks. Yang mereka butuhkan adalah peta risiko dan timeline, bukan detail kode.

Orang bisnis, entah itu product manager atau eksekutif, punya pertanyaan paling berbeda. Mereka tidak peduli apakah Anda pakai REST atau GraphQL. Mereka tidak peduli apakah database Anda pakai PostgreSQL atau MongoDB. Yang mereka ingin tahu: berapa biayanya? Berapa lama? Apa value yang didapat? Apakah ini sepadan dengan investasi yang dikeluarkan? Jika Anda tidak bisa menjelaskan trade-off dalam bahasa biaya dan manfaat, mereka akan mengambil keputusan berdasarkan intuisi, bukan berdasarkan informasi yang Anda berikan.

Inilah yang disebut komunikasi arsitektural. Bukan sekadar menyampaikan informasi, tetapi menyusun ulang informasi yang sama untuk audiens yang berbeda. Anda tetap membawa dependency map yang sama, tetapi cara Anda menyajikannya berubah. Untuk engineer, Anda tunjukkan diagram teknis dengan detail endpoint dan skema data. Untuk manager, Anda ubah dependency itu menjadi timeline dan risk register. Untuk bisnis, Anda terjemahkan menjadi cost estimate dan value projection.

Misalnya, Anda ingin mengomunikasikan opsi dashboard baru. Begini tiga versi pesannya:

# Ke Engineer
"Kita perlu integrasi REST API ke ERP dengan retry policy 3x dan circuit breaker.
Endpoint: POST /api/v2/dashboard/sync. Skema data: { userId, metric, timestamp }.
Tidak ada breaking change di service existing."

# Ke Manager
"Estimasi 2 sprint, butuh 1 backend engineer. Risiko utama: dependency ke tim ERP yang
sedang sibuk. Mitigasi: mulai prototyping sekarang, integrasi di sprint 2."

# Ke Bisnis
"Dashboard siap dalam 2 minggu. Biaya rendah (1 engineer). Risiko rendah.
Value: monitoring real-time tanpa delay 24 jam. ROI positif dalam 3 bulan."

Kuncinya adalah audiens mapping sebelum Anda bicara. Tanyakan pada diri sendiri: siapa yang akan mendengarkan? Apa yang mereka butuhkan untuk mengambil keputusan? Bahasa apa yang mereka pahami? Jika Anda bisa menjawab tiga pertanyaan itu, Anda sudah setengah jalan.

Ketika Anda mulai bicara dalam bahasa yang sesuai, sesuatu yang menarik terjadi. Engineer merasa dihargai karena Anda memberikan detail yang mereka butuhkan. Manager merasa terbantu karena Anda sudah memikirkan risiko dan jadwal. Orang bisnis merasa percaya karena Anda bisa menjelaskan value dengan jelas. Semua pihak merasa Anda memahami posisi mereka.

Ini bukan tentang manipulasi atau menjilat. Ini tentang menghormati waktu dan prioritas setiap audiens. Anda tidak perlu menjadi ahli di semua bidang, tetapi Anda perlu cukup peka untuk menyesuaikan cara bicara. Seorang arsitek yang baik tidak hanya pintar secara teknis, tetapi juga luwes secara komunikasi.

Setelah Anda bisa bicara dengan bahasa yang sesuai, langkah selanjutnya adalah memastikan visualisasi yang Anda pakai juga membantu, bukan sekadar memperindah slide. Diagram yang tepat bisa membuat penjelasan Anda semakin kuat, tetapi diagram yang salah bisa membingungkan semua orang. Bagian berikutnya membuka persoalan tersebut.