เเรงที่ลงคุ้มทุนหรือเปล่า?

หลายต่อหลายครั้งที่ทีมของเราจะต้องพัฒนาของออกมา หลายต่อหลายครั้งเราก็ทุ่มแรงไปกับของที่ไม่ได้สร้าง value ให้แก่ user หรือ stakeholder เท่าไหร่

ปัญหาในการเลือกหยิบเอาของไปพัฒนานั้นมีให้เห็นอยู่ทั่วไป ซึ่งเกิดได้ทั้งจาก Project Owner หรือ Project Manager ไม่มีทักษะนี้ หรือ บางทีอาจจะเป็นเพราะเกิดจากการแทรกแซงของเหล่าผู้มีพลังพิเศษ มันเลยทำให้บ่อยครั้งที่ ทีมพัฒนาออกของไปโดยที่ของชิ้นเหล่านั้น ไม่ได้สร้าง value ให้แก่ users และ บริษัทมากนัก

ใน scrum เลยบอกว่า ในแต่ละ Product Backlog Items จะต้องมี Value ประกอบเข้าไปด้วยเสมอ เพื่อให้ PO และทีมสามารถรู้ได้ว่าเราควรให้ความสำคัญกับ PBI ตัวไหนก่อนหลัง

เรื่อง Scrum ปล่อย แขวนลอยมันไปก่อน... เพราะบทความนี้เราจะพูดถึงเรื่อง...

Value กับ Effort

Value

"มูลค่า" หมายถึง ประโยชน์หรือผลกระทบ (benefits or impact) ที่ features มี ส่วนเราจะวัดผล (หรือ estimate) มันได้อย่างไร ก็ขึ้นอยู่กับว่าเป้าหมายทางธุรกิจของเราคืออะไร

เช่น

• มีจำนวนผู้ใช้งานเพิ่มขึ้น
• รายได้เพิ่มขึ้น
• ลด cost ลดเวลา

ดังนั้นการวัด value มันจึงมีความยืดหยุ่นพอสมควร

แล้วเราจะประมาณการ value ได้อย่างไรละ?

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

ดังนั้นลองหาวิธีการประมาณการ value กันดู เอาที่เป็นตัวเลข สามารถวัดผลได้ และก็วัดผลจากอะไร

ตัวอย่าง เช่น

หนึ่งในวิธีในการประมาณการ value ที่ผมมักจะใช้ คือ การนับจำนวนผู้ใช้ที่จะได้รับผลกระทบ (Impact) จาก Features ใหม่ เช่น มีผู้ใช้งานใหม่เพิ่มขึ้นเท่าไหร่ มียอดการกลับมาใช้งานซ้ำเพิ่มขึ้นเท่าไหร่ เป็นต้น

หรือ อีกทางเลือกหนึ่งที่ดูจะซับซ้อนขึ้นมาอีกนิด คือ การนับรายได้ที่เกิดขึ้นประจำรายเดือน (MRR) ของแต่ละคนที่ขอ features และเพิ่มเข้าไปเพื่อให้ได้ MRR สะสมของแต่ละ feature

วิธีการเหล่านี้เป็นไปตามอำเภอใจน้อยกว่าและมีการคาดเดาที่น้อยกว่าด้วย ลองเอาไปใช้กันดู

มันยังมีหลายวิธีในการกระมาณการ value เราจะต้องรู้ก่อนว่า

• เราอยากจะวัด value จากเรื่องไหน
• วิธีวัดผลคืออะไร
• value ที่จะได้เป็นจำนวนเท่าไหร่

เดี๋ยวเรื่อง value ไว้ผมจะเขียนแยกไปเป็นอีก บทความหนึ่ง (ถ้ามีเวลา และไม่ลืมไปซะก่อน 😏)

Effort

แล้ว Effort คืออะไรละ?

Effort หรือ ความพยายาม หรืออาจจะการเรียกมันด้วยชื่ออื่นๆ เช่น "ความซับซ้อน" หรือ "ต้นทุน" ("complexity" or "cost") ได้เช่นกัน

ถ้าพูดถึง Effort ให้นึกถึง ทรัพยากร บุคคลากร และเวลาที่ใช้ในการพัฒนา Features นั้นๆ

ตรงส่วนนี้คิดง่ายมาก เอาเงินเดือนพนักงาน มาตีเป็นรายได้ต่อชั่วโมง และลองประมาณการดูว่า เราใช้คนกี่คน ใช้เวลาไปเท่าไหร่ เท่านี้เราก็ได้ Effort ที่ใช้ในส่วนของเงินค่าจ้างแล้ว

นึกถึงตอนที่ outsource ทำ timesheet คิดเงินมาที่ให้เราก็ได้นะ

อีกส่วนหนึ่งก็เป็น ทรัพยากรที่ใช้ เช่น โน๊ตบุ๊ค, software, license เป็นต้น ซึ่งตรงนี้จะยากหน่อย

ในส่วนของทรัพยากรนั้น อาจจะคำนวนยากและซับซ้อนไปซักหน่อย เราอาจจะละส่วนนี้ไว้ก่อน หรือเอาไปรวมกับค่า operation cost ก็ได้ อาจไม่เอามาคิด effort

ดังนั้นถ้าเรารู้ทั้ง Value กับ Effort ที่ใช้แล้ว เราก็จะตัดสินใจได้ง่ายขึ้นว่าจะลงทุนกับ Feature ไหน ถ้าใน scrum ก็จะลงทุนใน PBI ตัวไหน

Value vs. Effort Matrix

เมทริกซ์คุณค่า vs. ความพยายาม (หรืออาจจะเรียกอีกอย่างว่า Value vs. Complexity Matrix หรือ the Impact vs. Effort model) มันเป็นเครื่องมือที่ช่วยให้เราสามารถตัดสินใจในการจัดลำดับความสำคัญของ features ต่างๆ ตามมูลค่าที่เป็นไปได้ กับ แรงที่ลงไปในการทำให้แต่ละ features นั้นเสร็จสมบูรณ์

ภาพที่ออกมาก็จะประมาณนี้

ถ้าเราจัด Features ออกมาเป็นกลุ่มๆ แล้ว เราก็จะได้ออกมาเป็น 4 กลุ่มดังนี้

• High-value, low-effort: ถ้า features ไหนอยู่ในกลุ่มนี้ให้เอามาทำก่อนเลย เพราะมันทำได้ง่าย และมี value ที่สูง
• High-value, high-effort: สิ่งที่อยู่ในกลุ่มนี้ มันเรียกอีกอย่างว่า "การเดิมพัน" (Big Bets) หรือ "ความคิดริเริ่มเชิงกลยุทธ์" (Strategic Initiatives) ซึ่งมันเป็นเหมือน project ขนาดใหญ่ที่เราคิดว่าจะได้ผลตอบแทนด้วยมูลค่ามหาศาล อาจจะเป็น Feature ตัวใหม่ที่แตกต่างไปจากเดิมของ product หรืออาจรวมถึงการเปลี่ยนแปลง UI ครั้งใหญ่ หรือฟังก์ชันการทำงานใหม่
• Low-value, low-effort: ภาษาอังกฤษ "Fill-ins" (การกรอกข้อมูล) หรือ "maybes" (บางที) project หรือ features ที่อยู่เหล่านี้อาจมีมูลค่าไม่มากนัก แต่อย่างน้อยมันก็ทำได้ง่าย (ตัวนี้มันมีความลับของมันอยู่ เดี๋ยวจะบอกในตอนท้าย)
• Low-value, high-effort: ชื่อเล่นในกลุ่มนี้มีอยู่ 2 ตัว คือ "Time Sinks" หรือ "Money Pit" ถ้า features หรือ project ใน มาตกลงที่กลุ่มนี้ก็อย่าไปทำมันเลย เพราะว่ามันทั้งเปลืองเงินและเวลา บางครั้งเราก็เรียกมันว่า Thankless tasks (งานที่ไม่เห็นคุณค่า)

ถ้าเรามาเรียงลำดับว่าจะหยิบอะไรไปทำก่อนหลัง ก็จะเป็น

• Quick wins
• Big Bets
• Fill-ins
• Time Sinks

ความลับ

สุดท้ายความลับที่ว่า คือ ตัว Low-value, low-effort หรือชื่อเล่น "Fill-ins" หรือ "maybes" เนี่ยมันคือ Incremental ในการทำงานเป็นรอบๆ นั่นเอง

ดังนั้นถ้าเราเอาแนวคิดของ Incremental มาใช้ ก็จะบอกได้ว่า

Fill-ins หรือ Maybes: มันมีไว้เพื่อหาข้อมูลเพิ่มว่าสิ่งที่คิดไว้ (Feature / Project / Business Model) มันใช่หรือไม่ใช่ ไปถูกหรือผิดทาง สร้าง value ได้จริงๆ หรือเปล่า

แปลว่า อะไรก็ตามที่ใช้ effort และ value เยอะ หรืออาจจะยังไม่เห็น value ชัดเจนเท่าไหร่ (High-value, high-effort กับ Low-value, high-effort)

โดยเฉพาะ Low-value, high-effort ถ้าเราอยากจะทำมันจริงๆ ให้เราย่อยมันลงมาให้เล็กลง แล้วทำแค่เฉพาะส่วนไปก่อน เพื่อไปทดลองกับ users หรือ ตลาด ว่าที่เราคิดไว้มันทำได้จริง และมี value กับเขาจริงๆ สามารถสร้างผลตอบแทนให้แก่บริษัทได้จริงๆ นะ

ซึ่งถ้ามันทำแล้ว พบว่ามันมี value มากกว่าที่คิดไว้ มากๆ ปล่อยไปแล้ว users ชอบ user ใช้ มีรายได้เข้ามา มันก็จะกลายเป็น Quick wins ไปโดยปริยาย

หากทำแล้วปรากฏว่าไม่ใช่ user ไม่ใช่ รายได้ไม่เพิ่ม เราก็จะได้ไม่ต้องไปลงทุนกับมันต่อในส่วนที่เหลือที่ยังไม่ได้พัฒนา

ส่วน High-value, high-effort ตัวนี้ เราพยายามย่อยมันลงมาเพื่อให้มันสามารถปล่อย feature ได้เร็วขึ้น จนมันเกิด Quick Wins นั่นเอง