Scrum Guide | 7. ข้อผิดพลาดที่พบบ่อยที่สุดของ Product Owner

ในโพสต์ของวันนี้ เราจะเน้นที่ความท้าทายที่พบบ่อยที่สุดที่เจ้าของผลิตภัณฑ์ต้องเผชิญ นอกจากนี้เรายังจะบอกคุณถึงวิธีเตรียมตัวสำหรับสถานการณ์ที่ความผิดพลาดของ Product Owner เกิดขึ้นบ่อยที่สุด

ข้อผิดพลาดของเจ้าของผลิตภัณฑ์ – สารบัญ:

1. สิ่งที่อาจผิดพลาดระหว่างเจ้าของผลิตภัณฑ์และลูกค้า
2. ความท้าทายที่ Product Owner ต้องเผชิญเกี่ยวกับทีม Scrum ที่เหลือ
3. สรุป

สิ่งที่อาจผิดพลาดระหว่างเจ้าของผลิตภัณฑ์และลูกค้า

เจ้าของผลิตภัณฑ์คือบุคคลที่ รับผิดชอบความล้มเหลวของทีม Scrum เป็นการส่วนตัว เนื่องจากตำแหน่งนี้อยู่นอกเหนือกิจกรรมของทีมจึงถือว่า Product Owner เป็น คอบิดตัวเดียว กล่าวอีกนัยหนึ่งคือ Product Owner ที่ทุกข์ทรมานมากที่สุดเมื่อ Scrum Team ผิดพลาด แล้วจะจัดการกับสถานการณ์ที่ลำบากเมื่อปรากฏหรือดีกว่าแต่ป้องกันไม่ให้เกิดขึ้นตั้งแต่แรก?

ในการตอบประเด็นนั้น เราได้จัดเตรียมการวิเคราะห์ข้อผิดพลาดที่สำคัญบางประการของเจ้าของผลิตภัณฑ์และลูกค้าในเชิงลึกไว้อย่างชัดเจนและในตารางต่อไปนี้พร้อมกับคำอธิบายโดยละเอียดของแต่ละรายการ

ไม่สามารถจัดลำดับความสำคัญได้

ความผิดพลาดที่ไม่รู้ว่าจะจัดลำดับความสำคัญอย่างไรคือความหายนะของเจ้าของผลิตภัณฑ์หลายราย เหตุใดการจัดลำดับความสำคัญของงานจึงเป็นความสามารถหลัก เพราะเมื่อทุกอย่างมีความสำคัญเท่าเทียมกัน Product Goal ก็จะหายไป นั่นคือผลที่ตั้งใจไว้ของกิจกรรม Scrum Team

ปัญหาเริ่มต้นขึ้นแล้วในระหว่างการสนทนาครั้งแรกกับลูกค้าเกี่ยวกับ Product Objective ลูกค้ามักต้องการให้ความคิดทั้งหมดของเขาเป็นจริงอย่างรวดเร็วและถูกที่สุด งานของ Product Owner คือการสร้างรายการลำดับความสำคัญ งานของเขาคือสร้างรายการความคาดหวังที่ชัดเจนและเป็นไปได้โดยจัดลำดับจากมากไปหาน้อยที่สำคัญที่สุด โดย พิจารณาจากความคาดหวังของลูกค้าที่ไม่มีโครงสร้าง

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

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

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

เจ้าของผลิตภัณฑ์ขาดความแน่วแน่

ปัญหาที่เกี่ยวข้องอย่างใกล้ชิดกับการไม่สามารถจัดลำดับความสำคัญคือการขาดความแน่วแน่ ส่งผลให้มีการจัดคิวงานที่ไม่เหมาะสมและนำไปสู่การปิดกั้นการบรรลุเป้าหมายผลิตภัณฑ์โดยการทบต้นกับงานที่มากเกินไป ดังนั้น ความสามารถในการปฏิเสธลูกค้าจึงเป็นสิ่งสำคัญ

ความแน่วแน่ของเจ้าของผลิตภัณฑ์ควรอยู่บนสามเสาหลัก:

• ความรู้ความสามารถของทีม
• ความรู้เกี่ยวกับโซลูชั่นที่ใช้และพัฒนาโดยทีมงาน
• การตระหนักรู้ถึงบทบาทและคุณค่าของพวกเขาตามตำแหน่งของพวกเขาในทีม Scrum

ดังนั้น วิธีที่สำคัญที่สุดวิธีหนึ่งในการป้องกันปัญหาความกล้าแสดงออกคือการให้ Product Owner ทำงานร่วมกับ Scrum Team ทุกวัน สิ่งนี้จะช่วยให้เขาสร้างความเชื่อที่เป็นจริงเกี่ยวกับเวลาและความสามารถในการนำความคิดของลูกค้าไปใช้

ทักษะทางธุรกิจไม่เพียงพอ

ข้อผิดพลาดต่อไปที่เราอยากจะพูดถึงคือการขาดคุณสมบัติทางธุรกิจที่เหมาะสม จุดแข็งของเจ้าของผลิตภัณฑ์เหล่านี้มักเป็นคุณสมบัติเฉพาะทาง ความสามารถของพวกเขามีความเกี่ยวข้องอย่างใกล้ชิดกับพื้นที่ของทีมพัฒนามากกว่าธุรกิจ ดังนั้นจึงขาดความรู้เชิงปฏิบัติเกี่ยวกับการแข่งขัน กฎเกณฑ์ของตลาด และลูกค้าขั้นสุดท้ายของผลิตภัณฑ์ที่สร้างขึ้นโดยทีม Scrum

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

ความท้าทายที่ Product Owner ต้องเผชิญเกี่ยวกับทีม Scrum ที่เหลือ

ความสามารถในการจัดลำดับความสำคัญของงาน ความกล้าแสดงออกของ Product Owner และทักษะทางธุรกิจที่สูงเป็นข้อกำหนดเบื้องต้นที่จำเป็นสำหรับการสร้าง Product Backlog ที่เป็นแบบอย่าง ซึ่งเป็นรากฐานระยะยาวของทีม Scrum หาก Backlog ไม่ได้รับการสรุปอย่างสอดคล้องและถูกต้อง ปัญหาในความสัมพันธ์ Product Owner-Client จะขยายไปสู่ความสัมพันธ์ระหว่าง Product Owner กับสมาชิก Scrum Team คนอื่นๆ และในทางกลับกันก็ส่งผลโดยตรงต่อประสิทธิภาพของ Scrum Team มีข้อผิดพลาดอะไรอีกบ้างที่รอเจ้าของผลิตภัณฑ์ในความสัมพันธ์ของเขากับสมาชิกทีม Scrum คนอื่นๆ

เพื่อให้ง่ายขึ้น เราได้นำเสนอปัญหาระหว่าง Product Owner และ Scrum Team ในตาราง ด้านล่างนี้ คุณจะพบคำอธิบายโดยละเอียดเกี่ยวกับปัญหาแต่ละข้อและคำแนะนำสำหรับวิธีแก้ไข

เสน่ห์ที่น่าสงสาร

งานของเจ้าของผลิตภัณฑ์ในแต่ละวันคือการประสานแนวทางของลูกค้ากับวิธีที่ทีมพัฒนานำไปปฏิบัติ ไม่ต้องสงสัยเลยว่าสิ่งนี้ต้องการ อำนาจที่เหมาะสม ทักษะการฟัง และความสามารถพิเศษ

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

ทักษะเฉพาะทางไม่เพียงพอ

ตามที่เราเขียนไว้ในบทความเพื่อตอบคำถามเรื่อง Who is a Product Owner? บทบาทของ Product Owner ไม่ใช่เรื่องทางเทคนิคอย่างเคร่งครัด อย่างไรก็ตาม การ รู้พื้นฐานของทักษะเฉพาะทางของสมาชิกทีมพัฒนา สามารถเพิ่มอำนาจของเจ้าของผลิตภัณฑ์ได้อย่างมาก คุณสมบัติไม่เพียงพอในพื้นที่ความเชี่ยวชาญของทีมไม่เพียงแต่สร้างปัญหากับความสามารถพิเศษและอำนาจของเจ้าของผลิตภัณฑ์ ความผิดพลาดที่ไม่สนใจในสิ่งที่สมาชิกของทีมพัฒนาเชี่ยวชาญและพื้นฐานของความสามารถของพวกเขา สามารถสร้างสถานการณ์ที่ตลกขบขันได้ แต่ยังรวมถึง สถานการณ์ที่ส่งผลเสียต่อธุรกิจ และ ความสัมพันธ์ระหว่างบุคคลด้วย

ดังนั้น เพื่อให้ Scrum Team นำเสนอผลิตภัณฑ์ที่มีคุณภาพดีที่สุด Product Owner จึงต้องมีความเข้าใจในผลิตภัณฑ์อย่างถี่ถ้วน การได้รับคุณสมบัติที่เหมาะสมไม่ใช่เรื่องยาก เนื่องจาก Product Owner เป็นส่วนหนึ่งของทีมงานมืออาชีพ พวกเขาสามารถให้คำอธิบายไม่เพียงเท่านั้น แต่ยังให้คำแนะนำเกี่ยวกับสถานที่ที่จะได้รับความรู้เกี่ยวกับสาขาของตน

อิสรภาพ

เจ้าของผลิตภัณฑ์จะต้องสามารถ ตัดสินใจได้อย่างอิสระ แน่นอน ประเด็นสำคัญคือการรู้เงื่อนไข Scrum Team และสื่อสารกับทีมพัฒนาอย่างต่อเนื่อง อย่างไรก็ตาม เจ้าของผลิตภัณฑ์เป็นผู้รับผิดชอบในประสิทธิภาพของการกระทำของตน ด้วยเหตุนี้ เจ้าของผลิตภัณฑ์จึงต้อง สร้างอำนาจหน้าที่ และรับผิดชอบต่อการตัดสินใจที่พวกเขาทำ การเรียกร้องครั้งสุดท้ายเกี่ยวกับทิศทางของทีม การจัดลำดับความสำคัญ และการยอมรับงานเป็นของพวกเขา

สรุป

เราได้ค้นพบข้อผิดพลาดที่พบบ่อยที่สุดของ Product Owner บทบาทของเจ้าของผลิตภัณฑ์ไม่ใช่เรื่องง่าย นั่นเป็นเหตุผลที่เมื่อรับมันคุณควรเตรียมตัวสำหรับปัญหาที่คนอื่นพบบนเส้นทางของพวกเขา

ปัญหาความสัมพันธ์กับลูกค้า มักเกิดจากการขาดความแน่วแน่ ไม่สามารถจัดลำดับความสำคัญ และทักษะทางธุรกิจไม่เพียงพอ

ข้อผิดพลาดของ Product Owner ที่เกิดขึ้น ระหว่างทำงานกับ Scrum Team ที่เหลือ เป็น ผลมาจากการขาดความเป็นอิสระและเสน่ห์ที่ไม่เพียงพอของบุคคลที่รับบทบาท Product Owner อีกสาเหตุหนึ่งอาจเกี่ยวข้องกับการขาดทักษะเฉพาะทางและไม่เต็มใจหรือไม่มีเวลาขยายความรู้

หากคุณชอบเนื้อหาของเรา เข้าร่วมชุมชนผึ้งที่วุ่นวายบน Facebook, Linkedin และ Twitter

ผู้เขียน: แคโรไลน์ เบ็คเกอร์

ในฐานะผู้จัดการโครงการ Caroline เป็นผู้เชี่ยวชาญในการค้นหาวิธีการใหม่ๆ เพื่อออกแบบเวิร์กโฟลว์ที่ดีที่สุดและเพิ่มประสิทธิภาพกระบวนการ ทักษะในการจัดองค์กรและความสามารถในการทำงานภายใต้แรงกดดันของเวลาทำให้เธอเป็นคนที่ดีที่สุดในการเปลี่ยนโครงการที่ซับซ้อนให้กลายเป็นจริง

ดูกระทู้ทั้งหมด

คู่มือการต่อสู้:

1. อภิธานศัพท์ของคำศัพท์พื้นฐาน บทบาท และแนวคิด
2. Scrum คืออะไร?
3. ค่าการต่อสู้
4. วิธีใช้งาน Scrum ในบริษัทของคุณ
5. Scrum Team - มันคืออะไรและทำงานอย่างไร?
6. เจ้าของผลิตภัณฑ์คือใคร?
7. ข้อผิดพลาดที่พบบ่อยที่สุดของ Product Owner
8. Scrum Master คือใคร?
9. ลักษณะของ Scrum Master ที่ดี
10. ข้อผิดพลาดที่พบบ่อยที่สุดของ Scrum Master
11. สถิติและตัวชี้วัดใดที่ Scrum Master ควรติดตาม
12. ความร่วมมือระหว่าง Product Owner และ Scrum Master
13. ทีมพัฒนาใน Scrum
14. ข้อผิดพลาดที่พบบ่อยที่สุดของ Developers
15. สิ่งประดิษฐ์การต่อสู้
16. สเกลการต่อสู้
17. Sprint Backlog
18. Backlog สินค้าคืออะไร?
19. เรื่องราวของผู้ใช้คืออะไร?
20. สร้าง User Story ที่ดีที่สุดกับ INVEST
21. ข้อผิดพลาด User Story ที่พบบ่อยที่สุด
22. เกณฑ์การยอมรับเรื่องราวของผู้ใช้
23. การประมาณค่าและจุดเรื่องราวใน Scrum
24. การวางแผนโป๊กเกอร์
25. เกมประเมินทีม
26. กำหนดส่วนเพิ่ม
27. เหตุการณ์การต่อสู้
28. Sprint ใน Scrum คืออะไร?
29. ความมุ่งมั่นของทีม Scrum - เป้าหมายผลิตภัณฑ์ เป้าหมาย Sprint และคำจำกัดความของความสำเร็จ
30. แผนภูมิ Burndown คืออะไร?
31. จะสร้างและตีความแผนภูมิเบิร์นดาวน์ได้อย่างไร?
32. ข้อดีและข้อเสียของแผนภูมิการเบิร์นดาวน์
33. กระดาน Kanban ใน Scrum และ Scruban
34. Velocity in Scrum - ความเร็วของทีมพัฒนา
35. การต่อสู้รายวัน
36. การวางแผนการวิ่ง
37. Sprint Review
38. Sprint Retrospective คืออะไร?
39. ข้อผิดพลาดทั่วไประหว่าง Sprint Retrospective
40. บำรุง Backlog สินค้า