มีโอกาสมาร่วมงาน Agile Thailand 2023
ซึ่งครั้งนี้จัดที่ True Digital Park
โดยมีทั้งหมด 6 ห้อง แบ่งเป็น 20 นาที และ 45 นาทีอย่างละครึ่ง
ในช่วงเช้ามีหัวข้อที่น่าสนใจเยอะมาก ๆ
แต่ผมก็ไม่ค่อยรู้เรื่องเท่าไร เลยจดและสรุปจากที่ฟังไว้นิดหน่อย
ปล. หลบมาสรุปนิดหน่อย แล้วค่อยไปฟังต่อ
เริ่มจากการเข้าในหลาย ๆ ห้องสลับไปมา
พบว่ามีรูปแบบที่น่าสนใจคือ
- Fast feedback
- Learn -> Do/Try -> Feedback -> Change และ repeat วนไป
- PDCA (Plan Do Check Act)
ดังนั้นการเรียนรู้ ใช้งานจริง รับฟัง feedback
เพื่อนำมาใช้ปรับปรุงอย่างต่อเนื่อง
เพื่อช่วยปรับให้เข้ากับองค์กรต่าง ๆ
ต่อมาเจอคำที่น่าสนใจอีก คือ Innovation framework
แสดงดังรูป
ใน session นี้จะพูดเรื่องของการสร้าง persona
ซึ่งสามารถทำได้ตั้งแต่การ discovery เลย หรือ ระหว่างทางก็ได้
และสามารถทำการแก้ไขหรือเปลี่ยนแปลงได้ตลอดเวลาในทุก ๆ ขั้นตอน
ส่วนการสร้าง persona นั้นเน้นจากการทำงานร่วมกันของทุก ๆ คนที่เกี่ยวข้อง
หรือเป็นการทำงานแบบ Cross-functional team นั่นเอง
เพื่อช่วยให้เห็นมุมมองต่าง ๆ อย่างครบถ้วน
แต่ก็ขึ้นอยู่กับบริบทขององค์กรนั้น ๆ ด้วย !!
โดย persona นี้จะช่วยนำมาสร้าง Product backlog ต่าง ๆ ออกมา
จากนั้นก็ทำการส่งมอบให้ถึงมือผู้ใช้งาน
ในการสร้าง persona นั้น มักจะมีองค์ประกอบต่าง ๆ เยอะมาก
เช่น demography, Psycho เป็นต้น
แต่สิ่งที่ต้องให้ความสนใจคือ
องค์ประกอบเหล่านั้น เราใช้เพื่ออะไร รู้แล้วได้อะไร
มันจำเป็นต่อ business นั้น ๆ หรือไม่ อย่างไร
จากนั้นทำการเก็บผลและสรุป เพื่อนำมาใช้ต่อไป
เพื่อ mapping ความต้องการกับ technology ได้อย่างเหมาะสม
แต่เพียง persona ยังไม่เพียงพอ
จำเป็นต้องมีการทำ journey ด้วย
ไม่ว่าจะเป็น user หรือ customer journey ก็ตาม
จะเรียกว่า journey นั่นเอง
ใช้งาน journey เพื่อให้เห็นตามมุมมองของผู้ใช้งาน (backbone) ว่าเป็นอย่างไร
ทั้งจาก mental/emotional model และ pain point ต่าง ๆ
เพื่อทำให้เข้าใจได้ดี และนำมาวิเคราะห์ต่อไป
Session ต่อมาก่อนออกมาสรุป คือ Real PO (Product Owner)
เป้าหมายเพื่อช่วยให้เห็นว่า PO เป็นอย่างไร
ไม่ใช่บอกว่าที่ทำอยู่ไม่ถูกต้อง แต่ช่วยให้เข้าใจมากขึ้นนั่นเอง
เพื่อช่วยให้เห็นปัญหาที่อาจจะเกิดขึ้นได้รวดเร็วขึ้น
เริ่มจาก Anti-pattern ต่าง ๆ ที่มักพบเจอ
หรือรูปแบบที่ไม่ดี แต่มักได้รับความนิยม สำหรับตำแหน่ง PO
รูปแบบแรก Team Output Owner (TOO)
มีหลาย ๆ PO หรือ PO per team
พอมี PO เยอะ ก็แยก Product Backlog กันอีก
ต่างคนต่างทำ
มีการรายงาน progress ของการทำงาน
PO คือเจ้าของ product แล้วจะไป report ใคร ?
แสดงว่าต้องมีคนกลางเข้ามา ?
มีการทำงานที่ over มากไป (over-production)
ส่งผลให้ feedback ล่าช้าลงไป !!! (delay feedback)
ดูเพิ่มเติมได้ที่ How Misconceptions About the Product Owner Role Harm Your Organization and What To Do About It
ยังมีรูปแบบอื่น ๆ อีกเช่น
- Component Owner ทำให้แต่ละ component เสร็จ แต่ยังไม่ integrate กัน แสดงว่ายังไม่เสร็จ !! PO มักจะมาจาก development team
- Scribe มาจาก SA/BA มักจะทำเอกสารเยอะ ต้องทำตามที่ออกแบบไว้ มักจะพูดว่าทีมยังไม่เร็วพอ อ่านมากกว่าลงมือทำ ไม่สนใจ feedback ของทีม เพราะว่าต้องทำให้ตรงอย่างเดียว สนใจแต่ tool ทำให้ทีมสนใจหรือมีความรู็หรือเรียนรู้ business ได้น้อยลง การปรับตัวก็ยาก
- ผลแปลก ๆ ที่มักออกมาอีก เช่น ไม่ได้เป็นเจ้าของ budget ไม่สามารถตัดสินใจใด ๆ ได้ เกิด conflict ในภาพรวมขององค์กร
- มักจะมี committee เพิ่มเข้ามา แต่ไม่ได้ทำงานเป็นทีม และลงเอยด้วยการ Vote !!
ดังนั้นกลับมาที่คำว่า Real PO ?
จะประกอบด้วยคุณสมบัติดังนี้ เพื่อลดปัญหาต่าง ๆ ที่อาจจะเกิดขึ้นได้
- PO :: Can kill product ?
- PO :: No status/progress report ? ทำการพูดคุยเรื่อง value ของสิ่งที่ดีกว่าไหม
- PO :: Priority flow สามารถตัดสินใจ และจัด priority ต่าง ๆ เองได้
- PO :: Own the budget
กลับไปฟังต่อดีกว่า ....