คุณออกแบบโครงสร้างองค์กรและทีมอย่างไร

Question

Accepted Answer

การออกแบบองค์กรเกี่ยวข้องกับ **การวาดเส้นขอบเขตของทีมเพื่อให้งานที่เปลี่ยนแปลงด้วยกันอยู่ด้วยกัน** — ลดความเป็นอิสระระหว่างทีมสำหรับสิ่งที่เคลื่อนไหวอย่างรวดเร็ว โครงสร้างควรเป็นไปตามกลยุทธ์และระบบ ไม่ใช่วิธีอื่น

## หลักการ

```text
1. TEAMS OWN OUTCOMES, not layers (a team owns a product/domain end to end)
2. MINIMIZE DEPENDENCIES — autonomous teams ship faster
3. CONWAY'S LAW — your architecture will mirror your org; design both together
4. CLEAR OWNERSHIP — every critical area has ONE owning team
5. RIGHT SIZE — ~5–9 people; two-pizza teams
6. COGNITIVE LOAD — don't give one team more domains than it can hold
```

## การคิดแบบเน้นกระแส

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

## อันตราย

- **ไซโลเชิงหน้าที่** ("ทีม QA" "ทีมด้านหน้า") ที่บังคับให้ทุกคุณสมบัติข้ามมือมากมาย
- **ไม่สนใจกฎหมายของ Conway** และแปลกใจว่าสถาปัตยกรรมสะท้อนแผนภูมิองค์กร
- **จัดระเบียบใหม่อย่างต่อเนื่อง** ซึ่งรีเซ็ตความเชื่อถือและการเป็นเจ้าของในแต่ละครั้ง
- **ความเป็นเจ้าของที่ไม่ชัดเจน** ซึ่งทุกอย่างคือ "ส่วนแบ่ง" และด้วยเหตุนี้จึงไม่มีเจ้าของ

## ทำไมมันจึงสำคัญ

โครงสร้างกำหนดความเร็วอย่างเงียบ ๆ

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

เนื่องจากกฎหมายของ Conway การออกแบบองค์กร *คือ* การออกแบบสถาปัตยกรรม

หากคุณได้รับขอบเขตของทีมผิด ไม่มีความกล้าหาญด้านวิศวกรรมใด ๆ ที่จะทำให้ระบบสะอาด