Bagaimana Anda mengatasi ketidaksepakatan arsitektur di tim Anda?

Question

Accepted Answer

Insinyur cerdas akan tidak setuju tentang arsitektur, itu sehat. Pekerjaan TL adalah mengubah ketidaksepakatan menjadi **keputusan yang baik dan tim yang berkomitmen**, bukan memenangkan argumen. Sebagian besar perselisihan hilang setelah semua orang setuju pada kriterianya.

## Proses untuk menyelesaikannya

```text
1. AGREE on the criteria first — what are we optimizing for?
   (scale, simplicity, time-to-ship, team familiarity)
2. Let each side make its STRONGEST case — steelman, don't strawman
3. Look for DATA — spike it, benchmark it, prototype it
4. If still tied — the TL decides, and explains why
5. DISAGREE AND COMMIT — once decided, everyone rows together
```

## Contoh konkret

Dua insinyur berdebat microservices vs. monolith. Anda mereformulasi: "Apa yang kami optimalkan tahun depan?" Jawabannya, mengirim dengan cepat dengan tim kecil, membuat monolith menjadi keputusan yang jelas. Argumen itu sebenarnya tentang tujuan yang tidak dinyatakan.

## Kapan memutuskan vs. menunda

Untuk keputusan yang dapat dibalik, pilih satu dengan cepat dan lanjutkan, biaya membuat keputusan yang salah adalah kecil. Untuk pintu satu arah, perlambat dan kumpulkan data. Mencocokkan pertimbangan dengan reversibilitas menghindari bikeshedding dan keputusan sembrono.

## Sebuah perangkap

Jangan biarkan senioritas Anda membungkam perdebatan, atau biarkan perdebatan berlangsung selamanya. Keduanya membunuh tim: yang satu menimbulkan resentimen, yang lain menimbulkan kelumpuhan.

## Mengapa ini penting

Perkelahian arsitektur yang tidak terselesaikan memudar dan membagi tim menjadi kubu.

Seorang TL yang memfasilitasi secara adil, kemudian memutuskan, mendapatkan desain yang solid dan tim yang memilikinya bersama, bahkan mereka yang berdebat di sisi lain.