การบริหาร Backlog สำหรับ Domain Team: จากการจัดประเภทงานถึงการจัดลำดับความสำคัญ

Domain team หรือ ทีมที่จัดตามขอบเขตธุรกิจ (bounded context) และเป็นเจ้าของ domain ของตัวเองตั้งแต่ต้นจนจบ มักเจอโจทย์ที่ต่างจากทีมทั่วไปตรงที่งานไหลเข้ามาจากหลายทิศพร้อมกัน

ทั้งฟีเจอร์ feature จากฝั่ง product งานปรับปรุงระบบ technical debt ที่สะสม การ migrate ระบบที่ผูกกับทีมอื่น และ bug ที่อยู่ก็โผล่มา

ถ้าปล่อยให้ทุกอย่างไหลปนกันโดยไม่มีระบบ สุดท้ายงานประเภทใดประเภทหนึ่งจะกลืนทีมไปจนงานอื่นไม่ได้ทำ

บทความนี้เป็นการวางกรอบการบริหาร backlog ที่ใช้ได้จริงสำหรับ domain team ภายในบริษัท MyOrder ที่ผมทำงานอยู่ โดยเริ่มจากการจัดประเภทงานให้ถูก ต่อด้วยหลักการบริหาร backlog ในภาพรวม แล้วจบด้วยการจัดลำดับความสำคัญ เมื่องานแต่ละประเภทมีธรรมชาติต่างกันคนละแบบ

จัดประเภทงานให้ถูกก่อน: แยก "ประเภท" ออกจาก "ที่มา"

ก่อนจะบริหารอะไรได้ ต้องรู้ก่อนว่ากำลังบริหารงานประเภทไหนบ้าง ประเภทงานที่ครอบคลุมและแบ่งได้สะอาดสำหรับ domain team มีอยู่ 5 แบบ

1. Features: การสร้าง capability ใหม่ที่ผู้ใช้ หรือ business value
2. Improvement: การยกระดับของเดิมที่มีอยู่แล้วให้ดีขึ้น ไม่ว่าจะด้าน performance ความเสถียร ประสบการณ์ผู้ใช้ หรือ observability โดยที่ผู้ใช้ หรือ ทีม ops รู้สึกได้
3. Technical Debt: การหนี้ที่ทีมต้องจ่าย เป็นการจัดการงานภายในที่ผู้ใช้ไม่เห็นผลตรงๆ แต่ช่วยลด friction ในการพัฒนาต่อ เช่น การลด coupling ปรับ domain model หรือ refactor
4. Migration: การย้าย หรือ เปลี่ยนของ ซึ่งมักมาพร้อม dependency และ deadline จากภายนอก
5. Bugs/Defects: การแก้สิ่งที่ควรทำงานได้แต่พัง เป็นงานเชิงแก้ไข
6. Research/Explore: เป็นงานประเภทที่ต้องใช้เวลาศึกษา หรือ ทดลอง โดยงานจะมาพร้อมกรอบเวลา

จุดที่ต้องระวังตั้งแต่ต้น คือ อย่าสับสนระหว่าง "ประเภทของงาน (Types)" กับ "ใครเป็นคนขอ (Owner)"

2 มิตินี้ไม่ได้ผูกกันตายตัว ฝ่าย SRE อาจขอฟีเจอร์ได้ Product Owner อาจหยิบยกเรื่อง technical debt ที่กระทบธุรกิจได้

ถ้าเราไป fixed ว่า "งานจากคนนี้ต้องเป็นของตำแหน่งนี้เสมอ" สักพักจะเจองานที่ยัดหมวดไม่ลง หรือ ถูกจัดผิด เพราะดูจากคนขอแทนที่จะดูจากเนื้องาน

เส้นแบ่งที่มักเถียงกัน

การแบ่งประเภทของงงานออกมาแบบนี้ ในทางปฏิบัติมีเส้นแบ่งอยู่ 2-3 คู่ที่ทีมมักถกเถียงทุกครั้งที่มีงานเข้า

ทางแก้ที่เราใช้ คือ ตกลงนิยามไว้ล่วงหน้า

Improvement กับ Technical Debt
คู่ที่เบลอที่สุดของการแบ่งประเภทแบบนี้ คือ Improvement กับ Technical Debt

เกณฑ์ที่ใช้ตัดสินได้จริง คือ ถามว่า...

ผลลัพธ์มีคนนอกทีมพัฒนาเห็นไหม?

ถ้าเห็น เช่น ระบบเร็วขึ้น หรือ เสถียรขึ้นในสายตาผู้ใช้ หรือ operations มันจะเป็น Improvement

ถ้าไม่มีใครนอกทีมเห็นผลตรงๆ ทว่าทำให้ทีมพัฒนาต่อง่ายขึ้น มันจะเป็น Technical Debt

Improvement กับ Feature
ถามว่าเป็น capability ที่ยังไม่เคยมี หรือ ของเดิมที่ทำได้ดีขึ้น ของใหม่ คือ Feature ถ้าทำให้ ของเดิมยกระดับ คือ Improvement

Bug กับ Improvement
ถามว่ามันเคยทำงานถูกแล้วพัง หรือ มันไม่เคยดีพอ พังจากที่เคยถูก มันคือ Bug ส่วนไม่เคยดีพอตั้งแต่แรก มันคือ Improvement

งานที่มักตกหล่น

ถ้าจะใช้แค่ 6 ประเภทนี้ล้วนๆ มีงานอีกกลุ่มที่บางทีมชอบมองข้าม คือ งาน operational หรือ keep-the-lights-on พวกงานประจำที่ไม่ใช่ฟีเจอร์ ไม่ใช่ bug และไม่ใช่หนี้ เช่น การอัปเวอร์ชัน dependency ตามรอบ การต่ออายุ certificate หรือ การตอบ ad-hoc request จากทีมอื่น งานประเภทนี้ถ้ามีเยอะและซ่อนอยู่ จะทำให้การประเมิน capacity เพี้ยน (โดยปกติผมจะให้ทีมหักงานประเภท meeting, sync, update status ออกไปจาก capacity อยู่แล้ว

ดังนั้น

ถ้ามีน้อย ยัดไว้ใน Improvement หรือ Tech Debt ก็พอ เพราะจำนวนหมวดยิ่งน้อยยิ่งจัดการง่าย ตราบใดที่ทุกคนแยกออกว่าอันไหนคืออันไหน

แต่ถ้ามีเยอะและซ่อนอยู่ อาจจะพิจารณาแยกเป็นหมวด "Operational" หรือ "Chore" ต่างหาก ก็ได้ เพื่อให้เห็นงานประเภทนี้ และจัดการลดมันให้น้อยที่สุด

หลักการบริหาร Backlog ในภาพรวม

เมื่อจัดประเภทงานได้แล้ว โครงของการบริหาร backlog ที่ทำให้ domain team คุมงานอยู่ประกอบด้วยหลายส่วนที่ทำงานร่วมกัน

จัดการจุดเข้าของงานทางเดียว backlog เดียว

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

การแบ่งชั้นตามความใกล้

ต่อมา คือ การแบ่งงานตามความใกล้ คือ โดยปกติแล้ว เราจะมีงานปริมาณที่เยอะกองไว้ที่ backlog การที่เราจะ refinement ทั้งหมดเลย คงเป็นไปไม่ได้

สิ่งที่เราควรทำ คือ การจัดลำดับความสำคัญแบบคร่าวๆ แบ่งเป็น 2 ระยะง่ายๆ คือ

• ระยะใกล้: เป็นงานที่กำลังจะทำในช่วง 1-2 เดือนข้างหน้า
• ระยะไกล: งานที่วางแผนว่าจะทำใน quarter หน้า หรือ ครึ่งปีหลัง

เมื่อแบ่งแบบนี้ เราจะสามารถแยกเป็นชั้นของที่จะทำใน 2-3 sprint ข้างหน้าได้ แล้วค่อยหยิบมา refinement ให้ละเอียด มี acceptance criteria ผ่าน Definition of Ready ส่วนของที่ไกลออกไปเก็บเป็น epic หรือ theme หยาบๆ ก็พอ เพราะ domain เปลี่ยนเร็ว การ refine ของที่อาจไม่ได้ทำในอีกหกเดือน คือ การเสียเวลาเปล่า

Refinement เป็นกิจวัตร

ควรจัดสม่ำเสมอโดยมี PO, tech lead และ สมาชิกทีมร่วมกัน เพื่อแตก epic ใหญ่ให้เป็น story ที่จบได้ใน sprint เดียวและเคลียร์ความไม่ชัดเจนก่อนเอางานเข้า sprint สำหรับ domain team ควรใช้ช่วงนี้ตรวจด้วยว่างานยังอยู่ในขอบเขต domain ที่ทีมเป็นเจ้าของหรือไม่ หรือ ควรส่งต่อผ่าน contract ให้ domain อื่น

นอกจากนี้ทุก item ควร trace กลับไปเป้าหมายของ domain ได้ ผูก backlog เข้ากับ OKR หรือ outcome ถ้ามี item ที่ตอบไม่ได้ว่ามันตอบโจทย์เป้าอะไร นั่นคือ สัญญาณให้ตั้งคำถามว่าควรอยู่ใน backlog ไหม พร้อมกับมีรอบ review เป็นระยะเพื่อ archive ของที่ค้างนานเกินและไม่มีใครแตะ เพื่อกันไม่ให้ backlog กลายเป็นถังขยะ และสุดท้าย dependency ระหว่าง domain ต้องทำให้มองเห็นและประสานล่วงหน้า ซึ่งเป็นหน้าที่ของ domain team ที่เป็น owner ของงานนั้นอยู่แล้ว อย่าปล่อยให้กลายเป็น surprise ตอน sprint กำลังจะจบ

การจัดลำดับความสำคัญ

กับดักใหญ่ที่สุดของการจัดลำดับงานใน domain team คือ ความเชื่อว่าจะใช้เกณฑ์เดียวเรียงงานทุกประเภทได้

ความจริง คือ ทำไม่ได้ เพราะงาน 6 ประเภทมีธรรมชาติต่างกันคนละแบบเลย Feature ตัดสินด้วย value แต่ Migration ตัดสินด้วย deadline เอามาเรียงใน lists เดียวด้วยไม้บรรทัดวัดแบบเดียวกันไม่ได้ ทางที่ใช้ได้จริง คือ คิดเป็น 3 ชั้น

ชั้นที่ 1: จัดสรร Capacity ก่อน แล้วค่อยจัดลำดับ

การจัดลำดับที่ดีสำหรับ domain team ไม่ได้ เริ่มจากการเรียงงานทั้งหมดเป็นเส้นเดียว แต่เริ่มจากการกันเวลาให้แต่ละประเภทก่อน

ตัวอย่าง เช่น

domain team ตกลงกันว่า แต่ละ sprint จะกัน Capacity ให้:

• Feature: 50%
• Tech Debt & Improvement: 25%
• Bug กับงาน operational: 15%
• Migration: 10% หรือ ปรับตาม deadline

เหตุผลที่ต้องทำแบบนี้ คือ ถ้าเรียงทุกงานปนกันด้วยเกณฑ์เดียว Feature จะชนะ Tech Debt เกือบทุกครั้ง เพราะเห็น value ชัดกว่าเสมอในระยะสั้น ผล คือ หนี้สะสมจนระบบพัฒนาต่อไม่ไหว

การกันโควตาก่อน คือ การตัดสินใจว่าจะลงทุนกับแต่ละด้านแค่ไหน แล้วค่อยจัดลำดับภายในแต่ละถังต่างหาก นี่ คือ กลไกที่ป้องกัน 2 อาการที่ domain team เป็นบ่อย

1. ฟีเจอร์กินพื้นที่จนหนี้ท่วม
2. incident ดูดทีมไปหมดจนงานที่วางแผนไว้ไม่ได้ทำ

ชั้นที่ 2: จัดลำดับภายในแต่ละประเภทด้วยเกณฑ์ที่เหมาะ

เมื่อกันถังไว้แล้ว การเรียงงานภายในแต่ละถังต้องใช้เกณฑ์ที่ตรงกับธรรมชาติของงานประเภทนั้น

จุดที่ต้องเน้นเป็นพิเศษ คือ Technical Debt ไม่ควรจัดลำดับด้วย value เพราะมันจะแพ้เสมอ ให้จัดด้วยคำถามว่าหนี้ก้อนนี้อยู่ในเส้นทางของงานที่กำลังจะทำหรือไม่ และทำให้ทีมช้าลงจริงแค่ไหน หนี้ใน code ที่ไม่มีใครแตะปล่อยไว้ได้ แต่หนี้ในส่วนที่แก้ทุกสัปดาห์ต้องจัดการก่อน

WSJF: https://www.nutshell.work/what-is-wsjf/

ชั้นที่ 3: เกณฑ์ที่ Override ทุกอย่าง

มีบางเงื่อนไขที่ดึงงานขึ้นหัวคิวได้ทันทีโดยไม่ต้องผ่านการคำนวณ ควรตกลงกันไว้ล่วงหน้าว่ามีอะไรบ้าง

1. Incident รุนแรงระดับ P1 หรือ P2: ที่ต้องแทรกทันทีผ่าน fast lane ไม่รอคิวและไม่รอ refinement
2. Deadline จากภายนอกที่พลาดไม่ได้ เช่น 3rd party จะ deprecate API เก่าในวันที่กำหนด พลาดแล้วระบบล่ม กรณีนี้ชนะฟีเจอร์ที่ value สูงกว่าเสมอ เพราะ cost of delay เป็น infinity
3. blocker ของ domain อื่น: ถ้างานเราค้างอยู่แล้วมีอีกทีมรอเราทั้งทีม การปลดล็อกให้เขามักคุ้มกว่าเก็บงานไว้ทำเอง เพราะคิด cost รวมทั้งองค์กรแล้วถูกกว่า

เรื่อง Bug ควรเสริมด้วยว่าต้องมี fast lane แยกชัดเจน อย่าให้ bug รุนแรงต้องรอ refinement วางนโยบายไว้เลยว่า P1 หรือ P2 แทรกได้ทันทีตามเกณฑ์

ส่วน bug เล็กเข้า backlog ปกติเพื่อจัดลำดับร่วม การมี fast lane ที่ชัดช่วยไม่ให้งานด่วนจริงติดคิว และไม่ให้ทุกอย่างถูกอ้างว่าด่วนจนทำ lane พัง เช่นเดียวกับ Migration ที่มาจาก 3rd party หรือ domain อื่น ควรแยกว่าเป็น dependency-driven เพื่อไม่ให้พลาดเส้นตายที่ทีมคุมไม่ได้

กระบวนการที่ร้อยทุกชั้นเข้าด้วยกัน

ในทางปฏิบัติ เวลาจะจัดลำดับงาน ลำดับการคิด คือ

เริ่มจากถามว่ามี override ไหม — incident deadline หรือ blocker คนอื่น จัดการก่อน

จากนั้นดูว่า capacity แต่ละถังเหลือเท่าไหร่ แล้วดูว่าในถังนั้นมีอะไรอยู่บนสุดของคิวตามเกณฑ์เฉพาะประเภท

สุดท้ายเช็ค dependency ว่างานที่อยู่บนสุดของคิวติดอะไรที่ยังไม่พร้อมหรือไม่ ถ้าติดก็ข้ามไปตัวถัดไป

สิ่งที่ทำให้ระบบนี้อยู่รอด

การจัดลำดับไม่ใช่ทำครั้งเดียวจบ ควร review สัดส่วน capacity เป็นระยะเพราะสถานการณ์เปลี่ยน ช่วงใกล้ปล่อยของใหญ่อาจดัน Feature ขึ้นเป็น 70% ช่วงหลัง incident หนักอาจต้องเทให้ Tech Debt มากขึ้นชั่วคราว การมีตัวเลขให้เห็นทำให้การปรับกลายเป็นการคุยด้วยข้อมูล ไม่ใช่ลางสังหรณ์

สิ่งที่สำคัญที่สุด คือ การทำให้เหตุผลของลำดับโปร่งใส เมื่อ stakeholder เห็นว่าทำไมงานของเขาอยู่ลำดับนี้ ไม่ว่าจะเพราะถังเต็ม หรือ เพราะมี deadline อื่นแซง การต่อรองจะกลายเป็นการคุยเรื่อง trade-off แทนการกดดันด้วยเสียงดัง นี่คือประโยชน์ที่แท้จริงของการมีกรอบชัด มันเปลี่ยนการเมืองในทีมให้กลายเป็นการตัดสินใจร่วมบนข้อมูลเดียวกัน

สรุป

การบริหาร backlog ของ domain team ที่ได้ผลตั้งอยู่บนโครงไม่กี่อย่าง เริ่มจากจัดประเภทงานให้ถูกโดยแยกประเภทออกจากที่มา ตกลงนิยามเส้นแบ่งที่มักเถียงกันไว้ล่วงหน้า จากนั้นให้ทุกงานไหลผ่านจุดเข้าเดียวและมองเห็นร่วมกัน แล้วบริหารการจัดลำดับเป็นสามชั้น — กัน capacity ตามประเภทก่อน จัดลำดับภายในแต่ละถังด้วยเกณฑ์ที่เหมาะกับธรรมชาติของงาน และมี override สำหรับ incident deadline และ blocker ของทีมอื่น ปิดท้ายด้วยการ review สัดส่วนเป็นระยะและทำเหตุผลของทุกลำดับให้โปร่งใส

หัวใจที่ต้องจำ คือ งานแต่ละประเภทตัดสินด้วยไม้บรรทัดคนละอัน การพยายามเรียงทุกอย่างด้วยเกณฑ์เดียว คือ ต้นตอที่ทำให้ technical debt สะสมและงานสำคัญบางประเภทไม่เคยได้คิว เมื่อวางกรอบนี้ไว้ครบ domain team จะคุม backlog ได้โดยไม่โดนงานประเภทใดประเภทหนึ่งกลืน