PO ต่อ team หรือ PO ต่อ feature
ผมสรุปสิ่งที่ผมได้เรียนรู้จากบทความของ Lv Yi เรื่อง Limits to one Product Backlog — 1 นะครับ
สำหรับสกรัม product owner รับผิดชอบเรื่องความสำเร็จของทั้ง product และเป็นคนเดียวที่เป็นตัวแทนเสียงจากลูกค้าให้กับทีม ทุกอย่างง่ายและตรงไปตรงมา
แต่สำหรับ product ขนาดใหญ่ที่มีทีมมากกว่าหนึ่งทีมพัฒนาหล่ะ? ทุกอย่างจะซับซ้อนขึ้น เริ่มจากมี product owner ทำงานกับทีมหลาย ๆ ทีมพร้อมกัน แล้วทุกอย่างจะยิ่งซับซ้อนขึ้นอีก เมื่อมี product owner หลาย ๆ คน ทำงานกับทีมหลาย ๆ ทีมใน product เดียวกัน
แล้วก็จะเกิดคำถามว่า เราจะมี PO ต่อทีมดี หรือว่าเราจะมี PO ต่อ feature ดี?
PO ต่อทีม
product owner ทำงานกับทีมนั้น ๆ ทำให้เข้าขากันสุด ๆ product owner แต่ละคนก็จะดูแล part ของ product backlog
PO ต่อ feature
product owner ไม่ได้ fix ว่าจะทำงานกับทีมไหน แต่ละคนจะดูแต่ละ feature และแต่ละ sprint PO แต่ละคนก็จะทำงานกับทีมที่ทำ feature นั้น ๆ สลับผลัดเปลี่ยนหมุนเวียนกันไป แล้วแต่ว่า priority ใน product backlog ณ sprint นั้น ๆ เป็นยังไง
Lv Yi เล่าในบทความว่า เค้ามักจะแนะนำให้ทีมมี PO ต่อทีมมากกว่า PO ต่อ feature และเค้าบอกว่า PO ต่อ feature รู้สึกแปลก ๆ สำหรับเค้า และเค้าก็อธิบายความคิดเห็นเค้าไว้ด้านล่าง
ข้อดีข้อเสียของ PO ต่อ feature
มาดูข้อดีของ PO ต่อ feature ที่เรามักจะคาดหวังกันก่อน
- PO จะได้มีความรู้ความชำนาญใน feature นั้น ๆ ซึ่งมักเป็นจุดเริ่มต้นที่ง่ายกว่า
- การดูภาพรวมของ feature นั้น ๆ จะทำได้ง่าย เพราะมีคนดูคนเดียว ไม่ต้องไล่ถามหลายคน
ปัญหาที่ชัดเจนของ PO ต่อ feature คือ ถ้าทีมต้องทำงานมากกว่า 1 feature ใน 1 sprint เราจะทำยังไง?
ถ้าปล่อยให้ทีมมี PO หลายคนใน sprint นั้น ปัญหา priority สับสน, การทำงานหลายอย่างไปพร้อม ๆ กันทำให้ต้องสลับ focus ไปมาที่เราเคยเจอก่อนทำสกรัมก็จะกลับมาหมด
แต่ปัญหาด้านบนแก้ง่ายโดยการให้มี PO หลัก 1 คนในแต่ละ sprint ส่วน PO รองมีหน้าที่เจรจากับ PO หลักของ sprint นั้น ๆ เพื่อให้งานตัวเองโดนทำ
ปัญหาที่ลึกกว่าด้านบน และแก้ยากกว่ากับการวางตัว PO แบบนี้คือ
PO ต่อ feature focus อยู่ที่ feature ปัจจุบันที่ตัวเองดู
เพราะส่วนงานที่รับผิดชอบเป็น feature เป็นอัน ๆ ไป ทำให้เสียมุมมองระยะยาว การลงทุนแก้ technical debt หรือการให้ความสำคัญกับการ refine feature ในอนาคตจะไม่ได้รับความสำคัญ การแบ่ง PO ต่อ feature จะสนับสนุนกรอบความคิดแบบ short-term project
PO ต่อ feature เสีย feedback loop ในการเรียนรู้ไป
PO ต่อ feature จะไม่ค่อยได้เรียนรู้จากความผิดพลาด ไม่ว่าจะเป็นบทเรียนจากการรับปากในสิ่งที่เป็นไปไม่ได้, หรือผลกระทบระยะยาวจากการลด Definition Of Done เพื่อให้งานตอนนี้เสร็จเร็วขึ้น หรือพลาดโอกาสปรับปรุงวิธีรวบรวม requirement กับทีมที่เคยพัฒนาด้วยกันให้ดียิ่งขึ้น เพราะต้องเปลี่ยนทีมไปเรื่อย ๆ
สรุปแล้ว PO ต่อ feature มักจะเสียสมดุลย์ระหว่าง short-term กับ long-term ของ product ไป สำหรับ product owner แล้ว ความรับผิดชอบไม่ใช่แค่เพื่อความสำเร็จของ feature ใด feature หนึ่ง แต่เป็นสำหรับทั้ง product
PO ต่อทั้งทีมและ feature
ทางสายกลางที่ทำให้ PO ได้ทั้งความชำนาญของกลุ่ม feature ที่ใกล้เคียงกัน แต่ไม่แคบจนเสียมุมมองระยะยาวคือให้แบ่ง product เป็น area
product area จะต้องใหญ่จนครอบคลุมเกือบทั้ง product เพื่อให้เราไม่ลืมมองภาพ product ในระยะยาว แม้ว่ามันจะใหญ่จนต้องให้หลายทีมช่วยกันทำถึงจะไหวก็ตาม ในทางกลับกัน area ก็ยังเล็กกว่าทั้ง product ทำให้มันไม่หนักหน่วงสำหรับ product owner จนเกินไปที่จะจัดการ
area ควรจะใหญ่สำหรับทีมกี่ทีมทำดี บางคนบอกว่ามากกว่า 2 บางคนบอกว่าไม่เกิน 10 ส่วนตัว Lv Yi เค้าแนะนำว่าประมาณ 5 ทีมกำลังดี
ถ้าตาม LeSS Huge เค้าบอกว่า ถ้าเมื่อไหร่ที่เกิน 8 ทีม ให้เริ่มแบ่ง Requirement Area
