เรื่อง Product Model กับ Agile
อย่างที่ทราบผู้เขียนเป็นแฟนของ Marty Cagan, เจ้าพ่อหนังสือดัง Inspired และติดตามมาหลายปี ด้วย Marty เป็นคนที่คิดแบบ “Product” ไม่ได้เอาเรื่องของแนวทางยอดฮิต แบบ Agile หรือ Software engineer ใดมาปนนัก น้อยครั้งที่เขาจะ mentioned ถึงเรื่องอื่นๆ วันนี้แกเขียนเรื่อง “The Product Model and Agile” เลยขอแปลเป็นไทยแบบตรงๆ โดยไม่เสริมเพิ่มเลยละกัน (ลองอ่านดูนะครับ ค่อนข้างตรงใจ และเป็นสิ่งที่อยู่ในใจผู้เขียนมาหลายปีแล้วครับ 🙂)
— — —
“The Product Model และ Agile” (โดย Marty Cagan, Founder, Partner — Product at SVPG)
Source : https://www.svpg.com/the-product-model-and-agile/
“คำถามหนึ่งที่ผมได้รับในรูปแบบต่างๆ คือ “อะไรคือความสัมพันธ์ระหว่าง Agile กับโมเดลการดำเนินงานผลิตภัณฑ์ (Product Operating Model)?”
มันคือสิ่งเดียวกันหรือไม่? หรือโมเดลผลิตภัณฑ์เป็นเพียงวิวัฒนาการของ Agile? หรืออย่างหนึ่งเป็นส่วนประกอบของอีกอย่างหนึ่ง? หรือในมุมมองที่ค่อนข้างเหน็บแนม The Product Model เป็นเพียงการรับรองครั้งต่อไปสำหรับ Agile coaches หรือไม่?
ในระดับหนึ่ง นี่เป็นคำถามที่ง่ายมาก Agile เป็นเพียง 1 ใน 3 เรื่องหลักของ Product Model ผมจะอธิบายแต่ละมิติเหล่านี้เพิ่มเติมเล็กน้อยต่อไป แต่หนึ่งในนั้นเกี่ยวข้องกับวิธีการที่ทีมผลิตภัณฑ์สร้าง ทดสอบ และปรับใช้ซอฟต์แวร์ของพวกเขา
แต่คำตอบนี้ง่ายเกินไป และทำให้แนวคิดสำคัญไม่ชัดในหลายประการ
เพื่อทำความเข้าใจความแตกต่างที่ละเอียดอ่อน สิ่งสำคัญคือต้องชี้แจงประเด็นบางอย่าง:
“ประการแรก” : Product Model ไม่ใช่เรื่องใหม่ มันมีมานานกว่า 20 ปีแล้ว ดังนั้นผมจึงไม่เคยโต้แย้งว่า Product Model เป็น “สิ่งใหม่ล่าสุด” เพราะผมคิดว่ามันไม่จริง
บริษัทผลิตภัณฑ์ที่แข็งแกร่งได้ปฏิบัติตามโมเดลผลิตภัณฑ์มานานหลายทศวรรษ แต่บริษัทส่วนใหญ่ทั่วโลกเพิ่งได้สัมผัสกับโมเดลนี้เมื่อไม่นานมานี้ ซึ่งเป็นเหตุผลว่าทำไมหลายคนถึงคิดว่ามันเป็นเรื่องใหม่
“ประการที่สอง” : แม้ว่าผมรู้ว่าสิ่งนี้อาจทำให้หลายคนไม่พอใจ แต่ในปัจจุบันมีคำจำกัดความที่แตกต่างกันมากเกี่ยวกับความหมายของ “Agile” บางคนมองว่า SAFe เป็น Agile ถ้านั่นคือสิ่งที่คุณคิดว่าเป็น Agile ผมก็จะบอกว่า Agile ไม่มีส่วนเกี่ยวข้องกับ Product Model เพราะ SAFe นั้นตรงกันข้ามกับ Product Model อย่างมาก
ความแตกต่างนี้มักถูกอธิบายในปัจจุบันว่าเป็น “Fake Agile” เทียบกับ “Real Agile” และเพื่อให้ชัดเจน ถ้าคุณใช้ XP, Kanban, Scrum หรือแม้แต่ไม่ได้ใช้พิธีการ Agile ใดๆ แต่คุณกำลังทำ Continuous Deployment อย่างสม่ำเสมอ อย่างน้อยเท่าที่ผมเห็น คุณกำลังใช้ “Real Agile”
“ประการที่สาม” : เราควรแยกหลักการของ Agile (ตามที่กำหนดใน Agile Manifesto) ออกจากกระบวนการต่างๆ ที่ส่วนใหญ่เกี่ยวข้องกับการจัดการโครงการที่ถูกกำหนดขึ้นรอบๆ หลักการเหล่านั้น (เช่น Scrum, Kanban, XP)
ผมคิดว่าหลายคนคงยอมรับว่าหลักการของ Agile นั้นมีคุณค่าและเกี่ยวข้อง และมันคือหลักการที่ดึงดูดพวกเราหลายคนให้มาสนใจ Agile ในตอนแรก อย่างไรก็ตาม หลักการเหล่านั้นเกี่ยวข้องกับการสร้าง ทดสอบ และปรับใช้ซอฟต์แวร์เป็นหลัก และไม่เกี่ยวข้องกับการหาว่าจะสร้างอะไร
“สุดท้าย” : สิ่งสำคัญคือต้องชี้ให้เห็นว่ามีหลักการ Agile หนึ่งข้อที่อาจดีพอสำหรับงานซอฟต์แวร์แบบที่เรากำหนดเงื่อนไขเองหรือมีสัญญาระบุ แต่ไม่เพียงพอสำหรับงานผลิตภัณฑ์เชิงพาณิชย์ นั่นคือหลักการที่ว่า “ซอฟต์แวร์ที่ทำงาน (Working Software) ได้คือตัวชี้วัดหลักของความก้าวหน้า”
บริษัทที่ใช้ Product Model รู้ดีว่า “ซอฟต์แวร์ที่ทำงานได้ (Working Software)” เป็นเพียงผลลัพธ์ (Output) และความท้าทายที่ใหญ่กว่าคือการทำให้แน่ใจว่าสิ่งที่เรากำลังสร้างนั้นแก้ไขปัญหาพื้นฐานและบรรลุผลลัพธ์ที่จำเป็น ซึ่งเรียกว่า ผลสำเร็จ (Outcomes)
เมื่อเราพูดถึงข้อควรระวังสำคัญทั้งสี่นี้แล้ว เราก็สามารถกลับมาพิจารณาคำถามเดิมได้
โมเดลผลิตภัณฑ์เกี่ยวข้องกับสามมิติหลัก คือ
คุณตัดสินใจเลือกปัญหาที่จะแก้ไขอย่างไร (กลยุทธ์ผลิตภัณฑ์ — Product Strategy)
คุณแก้ไขปัญหานั้นอย่างไร (การค้นพบผลิตภัณฑ์ — Product Discovery)
และคุณสร้าง ทดสอบ และปรับใช้โซลูชันของคุณอย่างไร (การส่งมอบผลิตภัณฑ์ — Product Delivery)
“Real Agile สามารถช่วยในมิติที่สามนี้ได้อย่างแน่นอน”
แต่ตอนนี้ก็เกิดคำถามว่า Agile coaches สามารถช่วยองค์กรในการเปลี่ยนไปใช้ Product Model ได้หรือไม่ และอย่างไร?
มี Agile coaches บางคนที่มีประสบการณ์มากพอที่สามารถประยุกต์แนวทางร่วมกับ Product Strategy หรือ Product Discovery หรือทั้งสองอย่าง และคนเหล่านั้นสามารถกลายเป็น “Product coaches” ที่มีคุณค่าอย่างมาก
แต่ Agile coaches ส่วนใหญ่ได้ “มุ่งเน้นอาชีพของพวกเขาไปที่ด้านวิศวกรรมและการสร้าง ตาม Process ที่พวกเขาถนัด” ซึ่งแน่นอนว่าไม่เป็นไร ในกรณีที่ Agile coaches มีประสบการณ์ที่เกี่ยวข้องและลงมือปฏิบัติจริงกับงานหนักของการย้ายไปสู่ Continuous Deployment การตั้งค่าอุปกรณ์ และ/หรือ monitoring ที่จำเป็น รวมถึงการเปิดใช้งานโครงสร้างพื้นฐานการปรับใช้เพื่อสนับสนุนสิ่งต่างๆ เช่น การทดสอบ A/B Agile coaches เหล่านี้ (หรือที่เรียกว่า “Delivery coaches”) สามารถช่วยในการเปลี่ยนแปลงได้มาก
แต่ถ้าคุณมี Agile coach ที่ไม่มีประสบการณ์ที่เกี่ยวข้องกับกลยุทธ์ผลิตภัณฑ์ (Product Strategy), การค้นพบผลิตภัณฑ์ (Product Discoery) หรือการส่งมอบผลิตภัณฑ์ (Product Delivery) พวกเขาอาจจะมุ่งเน้นไปที่ “กระบวนการเฉพาะ (Process) ที่สอนให้คุณปฏิบัติตาม และสิ่งเหล่านี้ จะมีความสำคัญน้อยลงอย่างมากเมื่อย้ายไปใช้ Product Model (ดูหลักการแรกของ “Principle over Process” https://www.svpg.com/principles-over-process/)
นี่คือเหตุผลที่แม้ว่าเราจะใช้เวลาส่วนใหญ่ในการสนับสนุนให้ทีม Product ย้ายไปใช้ Product Model แต่เรา “ไม่สนับสนุนหรือยอมรับการรับรองใดๆ การรับรองอาจใช้กับกระบวนการที่เป็นทางการ แต่เรากำลังมองหาประสบการณ์ที่เกี่ยวข้องที่พบในบริษัทที่ใช้ Product Model”
ขอบคุณ Josh Kerievsky สำหรับความคิดเห็นของเขาที่มีต่อร่างบทความนี้
- นี่คือเหตุผลที่ผมรู้สึกผิดหวัง แต่ไม่แปลกใจที่ได้เห็นการรวมตัวของ Agile Alliance และ Project Management Institute (PMI)
- บางคนที่สนับสนุน Agile โต้แย้งว่า “คุณสามารถใช้ Agile เพื่อหาว่าจะสร้างอะไรโดยการสร้างและดูว่ามันทำสิ่งที่คุณต้องการหรือไม่ แม้ว่าจะเป็นจริงในบางระดับ แต่นี่จะเป็นวิธีที่ช้าที่สุดและแพงที่สุดในทำ Product Discovery” ไม่ต้องพูดถึงการทำร้ายลูกค้าที่น่าสงสารของคุณ นี่คือโมเดล “พร้อม — ยิง — เล็ง” (ready-fire-aim model) ในที่สุด
หมายเหตุ : ถ้าคุณจะเข้าใจเรื่อง Product Model ที่ Marty พูดคง แนะนำให้อ่านหนังสือชื่อ “Transformed: Moving to the Product Operating Mode” นี้ก่อนครับ หาซื้อได้ตามร้านหนังสือชื่อดัง หรือ Amazon
#วันละเรื่องสองเรื่อง
