Software Projects มันไม่ได้เรียบง่าย หรือเป็นเส้นตรงสวย ๆ แบบ Product Roadmaps ที่พวกเราคุ้นชินกันหรอกนะ

สวัสดีสัปดาห์แรก ๆ ของครึ่งปีหลัง บทความเดือนนี้ จะเป็นการสรุป และแชร์มุมมองเล็กๆน้อยๆ เกี่ยวกับการทำ Product Roadmaps และการทำแผนสำหรับ Software Projects

จากบทความของคุณ Jeff Gothelf ที่ชวนคิดในหัวข้อที่ว่า ROADMAPS ARE LINEAR. SOFTWARE PROJECTS AREN’T แปลเป็นไทยในแบบฉบับของเราคือ Software Projects มันไม่ได้เรียบง่าย หรือเป็นเส้นตรงสวย ๆ แบบ Product Roadmaps ที่พวกเราคุ้นชินกันหรอกนะ ทำไมคุณ Jeff ถึงชวนคิดแบบนั้นล่ะ

รูปเปรียบเทียบ ลักษณะการวาง Roadmap ของ Software Product ที่แตกต่างจาก Software Project โดยฝั่ง Software Project จะดูยุ่งเหยิงและต้องมีแผนสำรองอยู่เสมอ

เมื่อคิดย้อนกลับไปตอนที่ทำงาน ที่เกี่ยวกับการบริหารจัดการ products (เคยสมมติตัวเองว่าเป็น Product Manager ด้วยชื่อตำแหน่งนั่นแหละ) การวาง Product Roadmaps รูปร่างหน้าตา มันก็เป็นเส้นตรงสวย ๆ แบบที่คุณ Jeff กล่าวถึงเลยล่ะ โดยเอา Timeline ตั้งก่อน แล้วเอา Features มาใส่แล้ว Map กลับไปหา KPI หรือตัวชี้วัด (Metrics)

Example of product roadmap — by Productplan ตัวอย่าง Roadmap ใน template ยอดฮิตที่หลายๆที่ใช้สื่อสารกันในองค์หร หรือสื่อสารกับลูกค้า

นั่นก็คือ จะมีการปัก Mile Stone หรือ Schedule เอาไว้ว่าช่วงไหนจะออกของ หรือ features/functions อะไรออกมาให้ลูกค้า โดยการวางแผนเหล่านั้น ใช้ข้อมูลที่ผ่านมาในอดีตมาอ้างอิง แล้วก็นำแผนนั้นไปเสนอผู้บริหาร โดยแผนงานนั้น ๆ ก็จะเชื่อโยงไปถึงเป้าหมายทางธุรกิจ ที่ Management หรือ Exclusive ในองค์กร ย่อยมาไว้ให้ทีมงาน ว่าแต่ละ Quarter หรือแต่ละปี ต้อง Achive ตัวเลขอะไรบ้าง และตัวเลขเหล่านั้น เดิมทีท่าน ๆ เหล่านั้นจะมองเพียง Level Metric : ตามความเข้าใจของเรา ก็แนวๆ ยอดขาย ที่มาจากการขายสินค้า Category ต่างๆ หรือ การให้บริการ ที่มีการสั่งซื้อมาจากช่องทางต่างๆ เพื่อให้เห็นภาพเน๊อะ

ตัวอย่างของ Level Metrics หรือตัวอย่างมุมมอง ที่ Management หรือ Exclusive ในองค์กร เคยให้ความสำคัญเป็นสิ่งแรกๆจะเห็นได้ว่า เน้นที่ ยอดขาย หรือ Revenue ในการขายสินค้าแต่ละหมวดหมู่เป็นหลัก

ภาพจาก https://www2.microstrategy.com/producthelp/Current/ReportDesigner/WebHelp/Lang_1033/Content/Level_metrics__A_practical_overview.htm

เปลี่ยนมาเป็นเริ่ม Focus ที่ Outcome หรือ Customer success หรือเรียกง่ายๆก็คือ ประโยชน์/ คุณค่าที่ลูกค้าได้รับ (ขอเขียนอีกคำ Customers’ Value — คำติดปากที่เหล่า Product Manager ใช้กัน) ทำไมนะ ? >> ผู้เขียนบทความเค้ามีขยายความไว้ในอีกบทความนึง นั่นคือ Execs care about revenue. How do we get them to care about outcomes? ที่เค้าเขียนไว้เมื่อ 2017 (เกือบๆ 6 ปีที่แล้ว) — โดยสรุปคือ ผู้ให้บริการ หรือเจ้าของสินค้า จะอยู่รอดได้ในยุคนี้ มองแค่ยอดขายอย่างเดียวมันไม่พอ!!! ต้องมองเพิ่มด้วยว่า ลูกค้าหรือว่าที่ลูกค้า เค้ามองหาอะไร เค้ากำลังเจอกับปัญหาอะไรอยู่ หรืออะไรที่ทำให้เค้าอยากซื้อซ้ำ หรือกลับมาใช้บริการอีก อะไรที่ทำให้เค้าเปลี่ยนใจไปใช้บริการ หรือซื้อจากเจ้าอื่น ๆ หรือเปลี่ยนไปใช้อย่างอื่นเลย

customer-centric behaviors known as outcomes.

ถ้ามุมมองของ Management หรือ Exclusive เปลี่ยนไป การแข่งขันที่สูงขึ้น และพฤติกรรมลูกค้าที่เปลี่ยนไปเร็วมากๆ การวางแผน (Product Roadmap) ที่จากเดิม เราวางเป็นเส้นตรง เอา Timeline ตั้ง ตามมาด้วย Features ที่จะ Release หรือบางคนเรียกแผนรายปี (Yesr Plan)ที่ค่อนข้างจะตายตัว ทั้งoนี้ผู้เขียนคุณ Jeff และคุณลุง Ken Beck เลยแนะนำ ให้ลองเปลี่ยนมุมมอง หรือวิธีการวางแผน (Product Roadmap) ให้เป็นแนว Software Projects ที่มีทั้งแผน A, B, C ที่มันต้องปรับเปลี่ยนไปตามส โดยนำ Outcome หรือ Customer success เป็นตัวตั้งต้นก่อน !!! ไม่ใช่ตั้งเวลาที่จะออก Features ก่อนโดยที่ไม่แน่ใจด้วยซ้ำว่า Values หรือ Benefits ของมันคืออะไรกันแน่นะ

คุณ Jeff เลยแนะนำ ขั้นตอนการทำ Software product roadmap หรือ software project plan เพื่อที่จะได้ลอง Draft และปรับเปลี่ยนไปตามพฤติกรรมลูกค้าหรือกระแสจากตลาด ที่เปลี่ยนไปโดยมี Step ดังนี้

1. ให้ Product Manager (PM — ชื่อตำแหน่งนี้ไม่มีใน Scrum นะ 🤓) Dev + Designer + Biz Leader (บางที่ก็ BU Owner/ Project Sponsor/ Executive แล้วแต่ชื่อตำแหน่งแล่ละที่จะเรียกกัน แต่ถ้าเป็นตัวเราเอง เราขอเรียกรวม ๆ ว่า ผู้ที่ถือ KPI หรือเป็นผู้ที่รับผิดชอบ Business Impact นั้นๆโดยตรง) แล้วให้เค้าเหล่านั้น มากางข้อมูลและวางแผนร่วมกัน ย้ำว่าร่วมกัน!!!
2. วาง Roadmap โดยเอาแกนเวลาเป๊ะๆออกไปก่อน หรือถ้ามันรู้สึกฝืน ๆ หรือกลัวว่าจะไม่มีแผนที่ประกอบไปด้วยเวลา ที่คาดว่า สิ่งที่กำลังจะทำ จะถึงมือผู้ใช้งานเมื่อไร ให้ใช้อยากมากกกกกเลย เป็น Quarter หรือ Half Year หรือ Year ไปเลย
3. ช่วยกันกำหนด วิธีประเมิน/ วัดว่า สิ่งที่เราทำไปนั้น มันมี Value ต่อ ผู้ใช้งาน/ ลูกค้าจริงๆ — คล้าย ๆ กับ ถ้าครูอยากวัดว่า ที่เราเรียนไปทั้งเทอม เราเข้าใจมั๊ยจะมี การสอบเป็นวิธีที่วัดว่า ถ้าผ่านเกณฑ์/ คะแนนถึงที่ครูกำหนด คือผ่าน ทั้ง ๆ ที่จริง ๆ แล้วเราแค่เดาถูก เราอาจจะไม่เข้าใจหรือรู้เรื่องเลยก็ได้ 🤩ผ่าม!!! (ขอให้ Focus ที่ เกณฑ์ และวิธีวัดประเมินเน๊อะ)
4. หลังจากทีม brain strom กันแล้ว เขียน Idea + วิธีวัดผล แล้วจัดกลุ่ม idea เหล่านั้นออกมา ทีมก็จะได้กลุ่มก้อนของ ideas/ features ที่ทีมคุยกันแล้ว ว่าควรทำอะไรบ้าง ที่คาดว่า จะตอบโจทย์ หรือส่งมอบสิ่งที่ลูกค้าต้องการ ตามพฤติกรรม / สถานะการณ์ของลูกค้าเหล่านั้นแล้วมา Vote กัน (บางท่าน เรียกการจัดกลุ่ม ideas เหล่านี้ว่า Affinity map )
5. ใช้ Dot voting ให้ทีมลองโหวตดู — ลองช่วยกันโหวตว่าลูกค้า หรือว่าที่ลูกค้าของเราในแต่ละกลุ่ม เราอยากให้เค้าทำอะไรได้ เพื่อแก้ปัญหา/ตอบโจทย์ลูกค้ากลุ่มนี้
6. หลังจาก โหวตกันเรียบร้อย ทีมงานที่เข้าร่วมก็จะได้ รายการที่อยากทำ และเห็นตรงกันว่า เราควรเพิ่มความสามารถเหล่านี้ เพื่อตอบสนองพฤติกรรมและความต้องการของลูกค้ากลุ่มเป้าหมาย — ยกตัวอย่างเช่น อันเดับที่ 1 ที่ได้รับการโหวต คือ …เราอยากให้ลูกค้าที่เข้ามาซื้อของกับ platform เราเดือนละ 1 ครั้ง ณ สิ้นเดือน สามารถเพิ่มจำนวนสินค้าได้ ในหน้าตะกร้าสินค้า (Cart) หรือ สามารถเพิ่มสินเค้าอื่นๆเข้าไประหว่างอยู่ในหน้าตระกร้าสินค้าได้ด้วย โดยเราสามารถวัดผลได้จาก จำนวณสินค้า และ/หรือมูลค่าการสั่งซื้อที่เพิ่มขึ้น x % และทางทีมจะวัดเกณพ์นี้เป็นระยะเวลา 1 Quarter เป็นต้น
7. Re-map features/ functions ที่ทีมเห็นว่าสามารถเพิ่มความสามารถ หรือตอบโจทย์ สิ่งที่ช่วยกันโหวต จากตัวอย่างด้านบนคือ อันเดับที่ 1 ที่ได้รับการโหวต คือ …เราอยากให้ลูกค้ากลุ่มที่มักจะเข้ามาซื้อของกับ platform เราอย่างน้อยเดือนละ 2ครั้ง สามารถเพิ่มจำนวนสินค้าได้ ในหน้าตะกร้าสินค้า (Cart) หรือ สามารถเพิ่มสินเค้าอื่นๆเข้าไประหว่างอยู่ในหน้าตระกร้าสินค้าได้ด้วย โดยเราสามารถวัดผลได้จาก จำนวณสินค้า และ/หรือมูลค่าการสั่งซื้อที่เพิ่มขึ้น x % และทางทีมจะวัดเกณพ์นี้เป็นระยะเวลา 1 Quarter เป็นต้น >> ทางทีมก็สามารถแชร์กันและนำเสนอ features/ functions ที่ตัวเองคิดมา หรือ discuss กันในทีมมาเสนอได้เลย อาจจะเป็น ให้ลูกค้าเห็นสินค้าอื่น ๆ ที่เกี่ยวข้องกับสินค้าที่ลูกค้าเพิ่ง Add-to-cart ไป และสามารถกดเพิ่มสินค้าอื่น ๆ ที่เกี่ยวข้องเหล่านั้นลงเข้าไปเพิ่มในตะกร้าได้เลย (พูดง่ายๆก็ เหมือนมี related products feed ขึ้นมาพร้อมให้กด add-to-cart ได้เลยทันที เผื่อจะขายได้เพิ่มเน๊อะ)
8. ทีนี้ เราก็จะได้ Roadmap ที่สอดคล้องกับพฤติกรรมลูกค้า หรือคว่ทต้องการของเค้า และสามารถรู้ถึงที่มาที่ไปว่า เราทำ Features/ Functions เหล่านี้กันไปทำไมนะ และเมื่อไรเราจะรู้ว่า สิ่งที่เราทำไป มันตอบโจทย์ลูกค้าจริงหรือเปล่า

ปิดท้ายจากที่คุณ Jeff ผู้เขียนบทความชวนคิด และย้ำเตือนแบบเร็ว ๆ ว่า ถ้าเราตั้งเป้าหรือเกณฑ์ ในการวัดผลไว้ แล้วผลที่เกิดขึ้นจริง มันยังไม่ถึงเกณฑ์ เราจะทำยังไงกับมันต่อ >> ส่วนตัวเรา คิดว่า เหมือนการวางแผนทำ Software Project นั่นแหละ เราต้องหา Recovery Plan มาไว้สำรอง ว่าจะ Action ยังไงต่อ ไม่ใช่ว่าทำไม่ถึงเกณฑ์ คือไม่ผ่าน ตัดจบ…

เพื่อให้เห็นภาพ ขอยกตัวอย่าง จากกรณีของ E-Commerce

เราอยากให้ลูกค้าที่เข้ามาซื้อของกับ platform เราเดือนละ 1 ครั้ง ณ สิ้นเดือน สามารถเพิ่มจำนวนสินค้าได้ ในหน้าตะกร้าสินค้า (Cart) หรือ สามารถเพิ่มสินเค้าอื่นๆเข้าไประหว่างอยู่ในหน้าตระกร้าสินค้าได้ด้วย โดยเราสามารถวัดผลได้จาก จำนวณสินค้า และ/หรือมูลค่าการสั่งซื้อที่เพิ่มขึ้น x % และทางทีมจะวัดเกณพ์นี้เป็นระยะเวลา 1 Quarter

Original Picture : https://speero.com/post/goal-tree-maps-for-experimentation-programs. และเพิ่มเติมโดยตัวเราเอง

จากการตั้งคำถาม หรือสิ่งที่อยากให้ลูกค้าทำได้เพิ่มมากขึ้น ก็จะไปสู่ measurement หรือ KPI และระยะเวลาคร่าวๆ คือ ภายในปี 2022 >> แต่ที่ทำจริงๆระยะเวลาจะสั้นกว่านี้ ส่วนใหญ่เป็น Quarter แล้วแต่ทีม/ ผู้บริหารแต่ละที่ว่า พอจะมีเวลา และกำลังทัพย์เพื่อทดลอง launch software product มาทดสอบสมมติฐานและเรียนรู้ตลาดนานแค่ไหน

กรณีถ้าไม่ถึงเป้า (KPI) ก็อาจจะมีให้แก้ตัว คือ หา Action plan มาปิด Gap เหล่านั้น และเมื่อผ่านไป 2 Quarter แล้ว Gap ยังเยอะอีก แล้วเมื่อ วิเคราะห์จากข้อมูลที่เรามีอยู่ในมือ แล้วพบว่า เรานา่จะมาผิดทาง เราก็ทำการ Kill features/ functions เหล่านั้นทิ้งซะ

แต่ถ้าเป็นกรณีที่ สามารถปิด Gap ได้ หรือเหลือ Gap ระหว่าง Actual กับ KPI น้อยมาก ๆ แล้วก็หาข้อมูลตลาด(External) และในองค์กรเอง(Internal) แล้วพบว่าเรามาถูกทาง พฤติกรรมของลูกค้าเปปลี่ยนมาทางนี้ และสอดคล้องกับ Features /Functions ที่ทีมเรานำเสนอไป ก็ได้ไปต่อ และQuarter หลัง ๆ ท้ายปี ก็จะมีการปรับ Roadmaps ไปตามสถานการณ์ อีกครั้ง ช่างสอดคล้องกับสิ่งที่พี่ๆในสยามพูดบ่อยๆ

“We PLAN to REPLAN”

โม้มานาน ถ้าสามารถหาตัวอย่างจาก Roadmap ที่ตัวเราเองเคยทำไว้ เดี๋ยวจะ binding ชื่อ Features และชื่อบริษัท มาเทียบกับสิ่งที่คุณ Jeff แนะนำ ว่าเหมือนหรือต่างกันยังไง ใน blog หน้าๆ จริงๆแล้วเราเองพยายามหาอยู่ ณ ตอนนี้ยังไม่เจอ และพยายามนึกว่าเคยทำอะไรลงไปก็จำไม่ได้ซะอย่างนั้น 🤪

สุดท้ายนี้ ไม่ว่าจะวางแผนทำ Product Roadmap หรือ Software Project ทีมงาน ควรรับรู้เป้าหมายร่วมกัน ว่าเค้า Implement นี้ไปเพื่ออะไรนะ และเค้าจะรู้ได้ยังไงว่า สิ่งที่เค้าลงแรงและให้เวลากับมันไปสร้าง Benefits ให้ลูกค้า /ผู้ใช้งานได้มากน้อยแค่ไหน เหมือนทำกาแฟออกมาแล้วลูกค้าบอกว่า อร่อย…ดื่มแล้วติดใจ สดชื่นคนชงก็ดีจายยยย 🥳😎😁