การ setup domain team สำหรับบริษัท

บทความนี้เอาบันทึกในการใช้สำหรับนำไปปรับทีมในองค์กร จาก Resource pool เป็น Domain Team

Background & Problem Statement

ปัจจุบันองค์กรใช้รูปแบบ Resource Pool คือ การจัดทีมแบบ “รวมคนตาม skill” แล้ว assign ไปตาม project โดยทุกที่ทีมจะช่วยกันพัฒนา Features ต่างๆ ภายในระบบ MyOrder

Problem

• Ownership ของระบบไม่ชัดเจน
• Context switching สูง → productivity ต่ำ
• Knowledge กระจาย ไม่สะสมเป็น domain expertise
• Quality และ maintainability ลดลงในระยะยาว
• ทีมโฟกัส “ส่งงานให้เสร็จ” มากกว่า “ดูแล product ให้ดี”

ซึ่งวิธีการทำงานแบบนี้ไม่ได้ผิด แต่เหมาะกับการทำงานในบริษัทที่เป็น Software House ที่ทำจบเป็น Project ไปมากกว่า

สิ่งที่ต้องเขาใจก่อนว่า Platform business ≠ Project-based business ที่ทำแล้วจบไป แต่จำเป็นต้อง optimize เพื่อ long-term system health ไม่ใช่แค่ delivery speed ระยะสั้น

จึงจำเป็นต้องปรับให้ทีมและวิธีการพัฒนาให้เหมาะสมมากยิ่งขึ้น ซึ่งก็คือ domain team นั่นเอง

Goal / Vision

เราจะเปลี่ยนจาก:

ทีมทำตามงานที่ถูก assign

เป็น:

ทีมที่มี ownership ใน domain และ ดูแล product lifecycle แบบ end-to-end

การปรับเปลี่ยนวิธีการทำงานของทีมในครั้งนี้ เพื่อทำให้ทีมที่มี ownership และมีส่วนร่วมในการพัฒนาและดูแล product ของ MyOrder มากขึ้น ดังนี้ความรับผิดชอบและสิ่งที่ต้อง โฟกัสจะถูกขยายมากขึ้นตามไปด้วย

เพื่อให้ทุกคนเราใจภาพรวมของการจัดการโครงสร้างใหม่นี้ เราจะไปลงรายละเอียดแต่ละส่วนกัน…

Team Topologies

เป็น กรอบแนวคิด (Framework) สำหรับออกแบบโครงสร้างทีมและปฏิสัมพันธ์ภายในองค์กร เพื่อเพิ่มความเร็วในการส่งมอบงาน (Fast Flow of Value) ลดภาระทางความคิด (Cognitive Load) และ จัดการ Dependency ระหว่างทีมพัฒนาซอฟต์แวร์ และ ทีมดำเนินงาน (Operations) ให้มีประสิทธิภาพสูงสุด

โดยภาพรวมจะเป็นภาพนี้

โดยจะมีการแบ่งทีมออกเป็นดังนี้

Stream-aligned Team / Domain Team

เป็นทีมพัฒนาโดยสนใจในส่วนของการพัฒนาระบบในแต่ละ domain เราจะแบ่งออกเป็นดังนี้

• Order Domain
• Chat Experience Domain
• Shipping Domain
• อื่นๆ

Complicated Subsystem Team

เป็นสาย specialist เป็นกลุ่มผู้เชี่ยวชาญที่รับผิดชอบในการสร้างและบำรุงรักษาส่วนหนึ่งของระบบที่ต้องการความรู้เฉพาะทางขั้นสูง (เช่น อัลกอริทึมที่ซับซ้อน ตัวแปลงสัญญาณวิดีโอ ปัญญาประดิษฐ์) โดยทีมที่จะอยู่ในส่วนนี้ คือ

• AI
• Research Development

Enabling Team

กลุ่มผู้เชี่ยวชาญเฉพาะด้าน (ชั่วคราว) ที่ให้ความช่วยเหลือทีมอื่นๆ (เช่น Tech Lead / EM, SRE, Data Engineer / Data Analytic)

โดยทีมที่จะอยู่ในส่วนนี้ คือ

• Tech Lead / EM
• SRE
• Data Engineer / Data Analytic

Platform Team

มีหน้าที่รับผิดชอบในการสร้าง และ บำรุงรักษาแพลตฟอร์มพื้นฐานที่สนับสนุนการพัฒนา การติดตั้งใช้งาน และการดำเนินงานของแอปพลิเคชันซอฟต์แวร์ (เช่น แพลตฟอร์ม, การปรับปรุงให้ทันสมัย) โดยทีมที่จะอยู่ในส่วนนี้ คือ

• Modernize
• Platform

DevOps

จะไม่ใช่ทีม operations แต่จะถูกปรับเป็น responsibility จะอยู่กับทีมแทน ตามหลักของ microservice และตามนิยามของ DevOps

Dev + Operations

Interaction Model (ภาพรวม)

ในการทำงานร่วมกันของแต่ละกลุ่มจะมีการ interact ตามนี้

อธิบายการทำงานร่วมกันได้แบบนี้

1.Collaboration

ใช้เมื่อ:

• ทำ feature ใหม่
• ยังไม่ชัดว่า boundary อยู่ตรงไหน
• ต้อง design ร่วมกัน

สิ่งที่ทำร่วมกัน:

• define flow (UX + business logic)
• design API contract
• define event (OrderCreated)

Rule สำคัญ:

• ต้อง มี timebox (เช่น 1 sprint)
• ต้องมี outcome ชัด:
  • API
  • contract
  • ownership

2. X-as-a-service

ใช้เมื่อ:

• ของมัน stable แล้ว
• มี boundary ชัดแล้ว

Example:

 Chat Team → Order API → Order Team

• Chat:
  • call createOrder()
• Order:
  • รับผิดชอบ logic ทั้งหมด

 Shipping:

 Order Team → Event → Shipping Team

• OrderCreated
• OrderPaid

Rule:

• ไม่ direct access
• ใช้งานผ่าน API / Event เท่านั้น

3.Facilitating (ช่วยให้เก่งขึ้น)

ใช้เมื่อ:

• ทีมยังไม่เก่งบางเรื่อง
• ต้อง upgrade capability

Example:

 Enablement Team → Chat / Order / Shipping

ช่วยเรื่อง:

• event-driven design
• observability
• test automation
• infra, CI/CD

ลักษณะ:

• ไม่ได้ทำแทน
• แต่ สอน + coach

Anti-pattern:

• กลายเป็นทีม support ถาวร
• หรือรับงานไปทำเอง

Domain Team Responsibility

ความรับผิดชอบสำหรับ Domain Team จะมีความหลากหลายเยอะขึ้น จะไม่ใช่แค่ Develop + Deploy แล้วจบไป

โดยทีมจะมี responsibility ใน scope เหล่านี้

1. Own Roadmap (ร่วมกับ PO)

• prioritize งานใน domain ตัวเอง
• align กับ business (Goal)

2. Own Business Logic ของ Domain

• รับผิดชอบ:
  • เป็นเจ้าของความถูกต้องของ domain นั้น

3. Own System / Service

รับผิดชอบ:

• Design
• Develop
• Deploy
• Operation

You build it, you run it

4. Own Outcome

ไม่ใช่มองแค่ Output

รับผิดชอบ:

• conversion
• success rate
• latency
• error rate

เช่น:

Chat Team:

• response time
• chat → order conversion

5. Own Quality

รับผิดชอบ:

• Testing strategy
• Monitoring
• Alerting

ไม่ใช่โยนให้ QA

6. Own API / Contract

• Expose API ให้ domain อื่นใช้
• Define contract ให้ชัด
• ไม่ใช่ Expose DB / internal logic

7. Collaborate กับ Domain อื่น

รับผิดชอบ:

• การคุยกันเมื่อมีการทำงาน cross-team
• การช่วยเหลือจะต้องมีกำหนดขอบเขตชัดเจน

Core Principle สำคัญมาก

ในมุมของ core principle นั้น ให้ถือตามนี้ (จำอันนี้พอ)

1.Strong Ownership

แยก domain ให้ชัด

• เคลีย domain ให้ชัด
• ตรงไหนใครทำ (Domain Team)
• ไม่ควรถือ domain เยอะเกินไป

2.Loose Coupling

คุยกันผ่าน API / Event เท่านั้น

ไม่มีการไป query table ของ domain อื่น ผ่าน database

3.High Cohesion

การแยกส่วนที่ไม่เกี่ยวข้องออกจากกัน

4.Minimize Coordination

ถ้าหาก domain team ยังต้อง sync กันเยอะ แปลว่า อาจจะ design ผิด เพราะงานทำงานระหว่าง Domain team นั้น ส่วนใหญ่การ Sync กันในเรื่องของการ Integrate, Data Transfers เป็นหลัก

5. Collaborate

ในบาง feature จำเป็นต้อง cross-domain

วิธีการปฏิบัติ คือ การนัดทีมที่ cross-domain กัน มาคุยและวางแผนร่วมกัน (ซึ่งถ้าทำกันอย่างถูกต้อง) ก็จะได้ประมาณนี้:

• จะทำ feature อะไร ยังไง
• มีทีมที่เกี่ยวข้องกี่ทีม
• แต่ละทีมต้องทำอะไรบ้าง
• จะส่งข้อมูลกันแบบไหน
• ระยะเวลาในการทำ ช่วงไหน
• ทีมวางทำช่วงนั้นไหม
• ต้องการความช่วยเหลืออะไร

ระวังอย่าไปหลงกับหน้า ui (แยก domain กับ ui ให้ชัด)

เช่น

ถ้าเราต้องการจะเพิ่ม create order เข้าไปในหน้า chat

• Order team: เป็นคนทำ
• Chat team: จะทำ message form ของ จำแนกที่อยู่ใน chat ให้
• แต่ กดแล้ว จะส่งที่อยู่ไปที่ form ยังไง order team และ chat team จะต้องเป็นคนออกแบบร่วมกัน และทำร่วมกัน หรือ ให้อีกทีมทำเพิ่มให้ (มองในมุม front-end)
• service จำแนกที่อยู่เป็นของ shipping team ที่จะต้อง provide ให้

Advanced

• ใช้ event-driven architecture
• ใช้ contract-first design
• ใช้ async flow (ใน MyOrder ยังไม่จำเป็นต้องใช้)

Anti-pattern

ในการทำงานแบบ domain team นั้น มักมีโอกาศที่ทีจะกลับไปใช้วิธีการทำงานเดิม ดังนั้นควรทำความเข้าใจและหลีกเลี่ยงการปฏิบัติ เพื่อไม่ให้กลับไปเป็นเหมือนเดิม

ซึ่งแบ่งออกเป็นข้อๆ ได้ดังนี้

1. แบ่งตาม Layer

ในการทำงาน การแยกงานเป็น Frontend, Backend มักมีปัญหาในการรอ integrate เพราะบางช่วงบางเวลา backend งานเยอะกว่า บางเวลา frontend งานเยอะกว่า เลยเกิดการรอขึ้น ซึ่งโดยทั่วไปแล้วสมาชิกในทีมมักไม่รอ และไปหยิบงานชิ้นอื่นมาทำแทน ซึ่งนำมาซึ่งปัญหาอื่นๆ ที่ตามมา จนมักนำกลับไปเป็น resource pool ได้ด้วย

2. Cross-domain logic กระจาย

การที่ให้ทีมอื่นเข้ามาเพิ่ม/แก้ไข domain ตัวเอง เช่น

• Chat ไปเขียน order logic เอง
• Shipping ไปแก้ order status

การทำแบบนี้เป็นการพัง domain team ในระยะยาว

แต่ถ้า Domain Team มีการออกแบบไว้แล้ว และขอให้ Cross-team Help Team มาช่วยได้ แต่ต้องมี scope และกรอบเวลาที่ชัดเจน (1-2 สัปดาห์)

3.ไม่มี clear ownership

ปัญหาหนึ่งของ MyOrder คือ ไม่มี ownership ใครก็แก้ได้

สุดท้าย = ไม่มีใครรับผิดชอบ

ดังนั้น Domain / Features ส่วนใหญ่จะต้องมีทีมรับผิดชอบเสมอ และ ไม่ควรมี Domain ที่ไม่มีทีมเป็น Ownership

ยกเว้น บ้าง features ที่เป็น system กลางที่หลายๆ domain team ใช้งานร่วมกัน ส่วนนี้จำเป็นต้องดูแลร่วมกัน และการ develop ตัว code ควรแยก business domain ชัดเจน

Team ว่าง ทำไง?

เมื่อเราดูแล Domain ของใครของมัน ถ้าหากช่วงนั้น ไม่มีการ priority หรือ ไม่มี features ใหม่ๆ ให้ develop แล้ว ทีมจะมีงานอื่นๆ ให้ทำ เช่น

1. Internal Improvement: การปรับปรุงระบบให้ดีขึ้น เช่น refactor code, improve test coverage, tech debt, improve CI/CD
2. Cross-team Help: เข้าร่วมทีม ในรูปแบบของ temporary collaboration ที่ทำงานขนาดเล็กที่จบได้ภายใน 1-2 สัปดาห์
3. Platform Contribution: การเข้าไป contribute feature, improve developer experience ของ platform team
4. Innovation / Experiment: ทำการ research หรือ ทดลอง แนวคิด หรือ เครื่องมือ เพื่อนำมาใช้กับ domain เช่น AI agent, new architecture, performance experiment
5. Backlog สำคัญที่ไม่ urgent: หยิบงานอื่นๆ มาทำ เช่น observability, monitoring, alerting, security hardening, analytics
6. Skill Upgrade: เรียนรู้ และ อัพเดททักษะของคนในทีม ที่เกี่ยวข้องกับ learning domain, cross-skill

จากทั้งหมดที่กล่าวมา แสดงว่าที่จะต้องมีการเก็บสิ่งที่ต้องทำไว้ด้วย รวมถึง technical dept ที่จำเป็นต้องแก้ในภายหลัง เมื่อมีเวลา ถึงกลับมาแก้ไขสิ่งเหล่านี้

Cross-team Help

โดยปกติแล้ว ปริมาณงานของแต่ละทีมที่รับผิดชอบนั้น มักจะ priority ไม่เท่ากันในแต่ละปี ซึ่งหากทีมไม่มีงานใน domain ที่ต้องทำแล้ว (อาจไม่จำเป็นต้องใช้ครบทุกคน)

แต่ละทีมสามารถให้คนในทีมมาร่วม Cross-team Help ได้ โดยทีมนี้จะเน้นเข้าไปช่วยแก้ปัญหาบางอย่าง แต่ไม่ใช่การ take full feature / domain โดยทีมจะยังเป็นคนออกแบบระบบอยู่ / เพราะจะต้องคุม Standard, Quality ของทีม

การทำงานของ Cross-team

การเข้าร่วมของ cross-team จะเป็นการส่งคนใน domain team เข้าร่วมกลุ่ม cross-team โดยจะจัดให้แต่ละคนอยู่ใน cross-team แค่ช่วงสั้นๆ (2 week = 1 sprint) เพื่อไม่ใช้ cross-team ถืองานนอก domain ของตัวเองนานเกินไป

Cross-team เข้ามาช่วยอะไรได้บ้าง

1. ช่วย แก้ปัญหา Incident Support: ในกรณีที่มีต้องการคนช่วยเหลือและแก้ไขปัญหา Incident ที่เข้ามา สามารถร้องขอให้ Cross-team เข้ามาช่วยเหลือได้โดยเคสที่เข้ามาช่วยเหลือ ควรเป็น เคสที่มีเอกสารในการแก้ไขปัญหาแล้ว Cross-team จะได้สามารถแก้ปัญหาได้ทันทีแต่ถ้าหากเป็น case แนะนำให้ cross team เข้าไปแก้ไขปัญหาในระดับ workaround, และถ้ามีเวลาเพียงพอสามารถหา root cause ออกเป็นเอกสาร ให้ domain team ได้

2. ช่วย develop ของให้ domain team: โดย develop ตาม Adept-Blueprint ที่ทางทีมออกแบบไว้แล้ว ไม่ควรยกทั้ง feature ให้ทีมอื่นทำ เพราะจะทำให้ domain team พัง และกลับไปสู่ resource pool ได้

การขอ Support จาก Cross-team

แต่ละ Domain team สามารถร้องขอ Cross-team เข้าช่วยเหลือได้ โดยเงื่อนไข / Signal ที่บอกว่าเราควรขอความช่วยเหลือจาก Cross-team

เช่น

• เวลาในการ develop มากกว่า เวลาที่กำหนดไว้ (Lead Time > threshold)
• เจอ Incident ซ้ำๆ (มีเอกสารวิธีแก้แล้ว)
• MTTR (Mean Time To Repair หรือ Mean Time To Recovery) คือ เวลาเฉลี่ยที่ใช้ในการซ่อมแซมหรือกู้คืนระบบให้กลับมาใช้งานได้ตามปกติหลังจากเกิดความเสียหาย ซึ่งเป็นตัวชี้วัด (KPI) ด้านประสิทธิภาพการบำรุงรักษา ยิ่งค่าน้อยยิ่งดี เพราะหมายถึงการหยุดทำงาน (Downtime) น้อยลง
• Dependency สูง (>20–30%)

การขอ request ให้คุยกับทาง Engineer Manager เพื่อให้จัดสรรในส่วนนี้

การ Exit จาก Support เคส

ทุกครั้งหลังจากจบการช่วยเหลือ Cross-team จะต้องทำ Knowledge Transfer/Documents ให้แก่ domain team เช่น

• demo solution
• explain root cause
• update runbook