คุณจะแก้ไขข้อขัดแย้งด้านสถาปัตยกรรมในทีมของคุณได้อย่างไร

Question

Accepted Answer

วิศวกรที่ฉลาดจะไม่เห็นด้วยในเรื่องสถาปัตยกรรม นั่นเป็นสิ่งที่ดี งานของผู้นำทีมคือการเปลี่ยนข้อขัดแย้งให้กลายเป็น **การตัดสินใจที่ดีและทีมที่มีความมุ่งมั่น** ไม่ใช่การชนะในการถกเถียง ข้อมูลส่วนใหญ่จะหายไปเมื่อทุกคนตกลงใจกับเกณฑ์ที่ใช้

## กระบวนการสำหรับการแก้ไข

```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
```

## ตัวอย่างที่เป็นรูปธรรม

วิศวกรสองคนถกเถียงเกี่ยวกับไมโครเซอร์วิสเทียบกับมโนลิท คุณปรับปรุงใหม่: "เรากำลังเพิ่มประสิทธิภาพสิ่งใดในปีถัดไป" คำตอบคือการส่งมอบอย่างรวดเร็วด้วยทีมขนาดเล็ก ซึ่งทำให้มโนลิทเป็นตัวเลือกที่ชัดเจน การถกเถียงนั้นเกี่ยวกับเป้าหมายที่ไม่ได้พูดออกมาจริงๆ

## เมื่อใดควรตัดสินใจ เทียบกับเมื่อใดควรเลื่อนไป

สำหรับการตัดสินใจที่ย้อนกลับได้ เลือกหนึ่งอย่างรวดเร็วและเดินหน้า เพราะต้นทุนของการตัดสินใจผิดนั้นน้อย สำหรับประตูแบบทางเดียว ช้าลงและรวบรวมข้อมูล การจับคู่การพิจารณากับความสามารถในการย้อนกลับนั้นหลีกเลี่ยงทั้ง bikeshedding และการโทรที่ไม่ระมัดระวัง

## ข้อเสียสำคัญ

อย่าให้ระดับอาวุโสของคุณปิดกั้นการถกเถียง หรือปล่อยให้การถกเถียงดำเนินต่อไปตลอดไป ทั้งสองอย่างนี้ฆ่าทีม: ทีมแรกสร้างความเสียใจ ส่วนทีมที่สองสร้างความเฉื่อยชา

## เหตุใดจึงมีความสำคัญ

การต่อสู้ด้านสถาปัตยกรรมที่ยังไม่ได้รับการแก้ไขนั้นเกิดการติดเชื้อและแบ่งทีมออกเป็นค่ายต่างๆ

ผู้นำทีมที่อำนวยความสะดวกอย่างยุติธรรม แล้วตัดสินใจ จะได้ทั้งการออกแบบที่ดีและทีมที่เป็นเจ้าของมันร่วมกัน แม้แต่คนที่ถกเถียงไปในแนวตรงข้าม