เมื่อ Product Owner สวมบทบาทนักสืบ: ศาสตร์และศิลป์ของการเป็น Business Analyst ในทีม Scrum

ในโลกของ Agile ที่เปี่ยมไปด้วยการเปลี่ยนแปลงอย่างต่อเนื่อง ทีม Scrum ที่มีขนาดเล็กและคล่องตัวมักจะไม่มี Business Analyst (BA) ในทีมทำให้ Product Owner (PO) ต้องรับผิดชอบหน้าที่นี้เพิ่มเติม โดยเปรียบเสมือนนักสืบที่ต้องไขปริศนาแห่งความต้องการของลูกค้า พร้อมทั้งวางแผนการสร้างสรรค์ผลิตภัณฑ์ที่ตอบโจทย์และนำไปสู่ความสำเร็จของ Product

จาก PO สู่ “โคนัน” แห่งโลกของ Agile Product Development

ลองจินตนาการถึง PO ท่านหนึ่งชื่อ “สมชาย” ซึ่งกำลังรับผิดชอบโครงการพัฒนาแอปพลิเคชันสำหรับการจองตั๋วเครื่องบิน สมชายต้องทำหน้าที่ทั้ง PO และ BA ในเวลาเดียวกัน เขาจึงต้องสวมบทบาทนักสืบโคนัน เพื่อทำความเข้าใจความต้องการที่แท้จริงของลูกค้าและผู้มีส่วนได้ส่วนเสีย

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

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

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

สมชายนำข้อมูลที่ได้มาจัดลำดับความสำคัญและแปลงเป็น User Story ที่ชัดเจนและสามารถนำไปพัฒนาต่อได้ เขาทำงานร่วมกับทีมพัฒนาเพื่อประเมินความเป็นไปได้ทางเทคนิคและความคุ้มค่าทางธุรกิจของแต่ละ User Story สมชายใช้เครื่องมือต่างๆ เช่น Impact Mapping และ Story Mapping เพื่อช่วยในการวางแผนและจัดลำดับความสำคัญของงาน

แนวทางปฏิบัติสู่ความสำเร็จ

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

1. สวมบทบาทนักสืบ: สัมภาษณ์ผู้ใช้งาน สังเกตพฤติกรรม และเก็บรวบรวมข้อมูลให้ได้มากที่สุด เพื่อทำความเข้าใจความต้องการที่แท้จริงของลูกค้า ใช้เทคนิคต่างๆ เช่น การสัมภาษณ์เชิงลึก การทำแบบสอบถาม การจัดกลุ่มสนทนา และการสังเกตการณ์ภาคสนาม
2. แปลงข้อมูลเป็น User Story: นำข้อมูลที่ได้มาวิเคราะห์และสังเคราะห์ แปลงเป็น User Story ที่ชัดเจนและสามารถนำไปพัฒนาต่อได้ User Story ควรมีรูปแบบที่เข้าใจง่าย เช่น “ในฐานะ… ฉันต้องการ… เพื่อ…”
3. จัดลำดับความสำคัญ: ทำงานร่วมกับทีมพัฒนาและผู้มีส่วนได้ส่วนเสียเพื่อจัดลำดับความสำคัญของ User Story โดยคำนึงถึงคุณค่าทางธุรกิจและความเป็นไปได้ทางเทคนิค ใช้เครื่องมือต่างๆ เช่น MoSCoW method หรือ Kano model เพื่อช่วยในการจัดลำดับความสำคัญ
4. สื่อสารอย่างต่อเนื่อง: สื่อสารกับทีมพัฒนาและผู้มีส่วนได้ส่วนเสียอย่างสม่ำเสมอ เพื่อให้ทุกคนมีความเข้าใจตรงกันและทำงานร่วมกันได้อย่างราบรื่น ใช้ช่องทางการสื่อสารที่หลากหลาย เช่น การประชุม การพูดคุยแบบตัวต่อตัว การส่งอีเมล และการใช้เครื่องมือการจัดการโครงการ
5. เรียนรู้อย่างไม่หยุดนิ่ง: พัฒนาความรู้และทักษะในการวิเคราะห์ธุรกิจและการจัดการความต้องการอยู่เสมอ เข้าร่วมอบรม สัมมนา อ่านหนังสือ และติดตามข่าวสารในวงการธุรกิจและเทคโนโลยี

เครื่องมือและเทคนิคสำหรับ PO นักสืบ

• Impact Mapping: เครื่องมือที่ช่วยให้ PO มองเห็นภาพรวมของโครงการและความสัมพันธ์ระหว่างเป้าหมาย ผลลัพธ์ กิจกรรม และตัวชี้วัด
• Story Mapping: เครื่องมือที่ช่วยในการจัดระเบียบ User Story และวางแผนการพัฒนาผลิตภัณฑ์
• MoSCoW method: เทคนิคการจัดลำดับความสำคัญของ User Story โดยแบ่งเป็น Must have, Should have, Could have, และ Won’t have
• Kano model: เทคนิคการวิเคราะห์ความต้องการของลูกค้า โดยแบ่งเป็น Basic needs, Performance needs, และ Excitement needs
• User Persona: การสร้างตัวแทนผู้ใช้งาน (Persona) เพื่อให้เข้าใจความต้องการและพฤติกรรมของผู้ใช้งานได้ดียิ่งขึ้น

กรณีศึกษา: PO นักสืบไขคดีความต้องการของลูกค้า

สมมติว่าคุณเป็น PO ของทีม Scrum ที่พัฒนาแอปพลิเคชันสำหรับการสั่งอาหาร คุณได้รับ Feedback จากลูกค้าว่าต้องการฟีเจอร์ใหม่ในการค้นหาร้านอาหารตามเมนูอาหาร

1. สวมบทบาทนักสืบ: คุณสัมภาษณ์ลูกค้าเพื่อทำความเข้าใจว่าทำไมพวกเขาถึงต้องการฟีเจอร์นี้ พวกเขาค้นหาเมนูอาหารอย่างไรในปัจจุบัน และพวกเขาคาดหวังว่าฟีเจอร์นี้จะช่วยแก้ปัญหาอะไร คุณยังทำแบบสอบถามออนไลน์เพื่อเก็บข้อมูลจากผู้ใช้งานจำนวนมากขึ้น
2. แปลงข้อมูลเป็น User Story: คุณสรุปความต้องการของลูกค้าเป็น User Story ดังนี้: “ในฐานะผู้ใช้ ฉันต้องการค้นหาร้านอาหารตามเมนูอาหาร เพื่อให้ฉันสามารถหาร้านอาหารที่เสิร์ฟอาหารที่ฉันอยากกินได้ง่ายขึ้น”
3. จัดลำดับความสำคัญ: คุณทำงานร่วมกับทีมพัฒนาเพื่อประเมินความเป็นไปได้ทางเทคนิคและความคุ้มค่าทางธุรกิจของฟีเจอร์นี้ คุณใช้ MoSCoW method และ Kano model เพื่อจัดลำดับความสำคัญของฟีเจอร์นี้เทียบกับฟีเจอร์อื่นๆ ใน Backlog
4. สื่อสารอย่างต่อเนื่อง: คุณจัดประชุมกับทีมพัฒนาเพื่ออธิบายความต้องการของลูกค้าและรายละเอียดของฟีเจอร์ คุณใช้เครื่องมือการจัดการโครงการเพื่อติดตามความคืบหน้าของการพัฒนาและสื่อสารกับผู้มีส่วนได้ส่วนเสีย
5. เรียนรู้อย่างไม่หยุดนิ่ง: คุณศึกษาเพิ่มเติมเกี่ยวกับเทคนิคการค้นหาข้อมูลและการจัดการฐานข้อมูลเมนูอาหาร เพื่อนำมาปรับปรุงฟีเจอร์นี้ในอนาคต

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

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