หลายคนคงเคยได้ยินวิธีการยอดฮิตที่นิยมใช้ในการทำงาน
อย่าง Waterfall และ Agile ที่ควบคู่กันมากับกับคำว่า “Scrum”
ซึ่งในแต่ละองค์กร ก็ต่างมีวิธีการนำไปปรับใช้ที่แตกต่างกันให้เหมาะสมกับบริบทองค์กรนั้นๆ
วันนี้ ผู้เขียนจะพาทุกคนไปเรียนรู้ร่วมกันผ่านบทสัมภาษณ์ของ “คุณท็อป” Product Owner ที่มีประสบการณ์การทำงานแบบ Scrum ที่ผสมผสานกับความเป็น Waterfall ที่ LINE BK
คุณท็อป เป็น Product Owner อยู่ที่ KBank ทำโปรเจกต์ LINE BK ที่เป็นการร่วมทุนระหว่าง KBank กับ LINE ซึ่ง LINE BK เป็นบริษัทลูกที่เป็น Startup แต่มีความเป็น Corporate เพราะบริษัทแม่ทั้งสองมีความเป็น Corporate อยู่แล้วในตัว โดยทำงานกับ LINE BK มาตั้งแต่แรกจนถึงปัจจุบันรวมได้ 3 ปีแล้ว ทำให้สัมผัสอยู่กับทีมนี้ในหลายบริบท ทั้งตอนที่ยังเป็น Waterfall และ Scrum
Table of Contents
จุดเริ่มต้นของการนำแนวคิด Agile มาใช้ในองค์กรคืออะไร?
เริ่มจาก Waterfall Framework
Framework การทำงานแบบหนึ่งที่มีมานานและยังใช้กันอยู่ในปัจจุบัน โดยเฉพาะองค์กรขนาดใหญ่ คือ Waterfall framework มีลักษณะการทำงานเป็นขั้นเป็นตอน
ทีมหนึ่งทำงานเสร็จก่อนจึงส่งต่อให้ทีมถัดไป ต้องรู้ Plan ก่อน ถึงเตรียม Requirement แล้วนำ Requirement ที่ Solid แล้ว ส่งไปให้ Designer ตั้ง Wireframe ว่า Product หน้าตาประมาณไหน แล้วส่งให้ Developer เพื่อ Develop แล้วจึงส่งให้ Tester (หรือ QA Engineer) ทำการ Test จากนั้นค่อยขึ้นระบบจริง
สาเหตุที่ตัดสินใจเริ่มนำ Agile มาใช้
ในความเป็นจริงแล้ว แทนที่งานจะไหลจากทีม 1 ไป 2 ไป 3 แบบที่คิดไว้ บางทีทีมท้าย ๆ มาเจอทีหลังว่า Requirement ที่ตั้งมา ไม่สามารถทำได้จริง ดังนั้น Waterfall จึงเป็น Framework ที่อาจไม่ได้รวดเร็ว และไม่ Flexible จึงเกิดแนวคิด Agile ขึ้นมา ให้มีการ reiterate ไปเรื่อยๆ
แทนที่จะกำหนดภาพใหญ่ไปเลย เปลี่ยนเป็นตั้ง Goal ย่อยลงมา
เช่น จะสร้าง Feature อันหนึ่ง ก็นำมาดูว่า Feature นี้แตกย่อยเป็นอะไรบ้าง
แล้วในแต่ละ Sprint จะต้องทำอะไรให้เสร็จ เราจะใช้ Sprint เป็นตัวครอบว่า ในแต่ละ 1 สัปดาห์ หรือ 2 สัปดาห์ จะ Deliver อะไรออกมาบ้าง กล่าวคือการนำ Agile เข้ามาประยุกต์ใช้ในการวางแผน การกำหนดเป้าหมาย เป็นการเปลี่ยนเป้าหมายระยะยาว ให้เป็นเป้าหมายระยะสั้น เพื่อให้ทีมเจอปัญหาได้เร็วขึ้น แก้ไขปัญหาได้ง่ายขึ้นนั่นเอง
Scrum มีวิธีการและขั้นตอนอย่างไร?
Scrum เป็น Framework ที่ใช้แนวคิด Agile ในการแบ่งเป้าหมายใหญ่ให้กลายเป็น Task ย่อย ๆ โดยระยะเวลาในการทำแต่ละ Task จะเรียกว่า Sprint
Sprint เป็น Timeframe ตั้งร่วมกันกับทีมว่า จะกลับมา Revisit งานนั้น ๆ ทุกระยะเวลาเท่าใด ในช่วงระยะเวลานั้น แต่ละทีมต้องบอกได้ว่าทำอะไรมา Accomplish อะไรบ้าง เมื่อจบ Sprint จะสามารถประเมินได้ว่าสิ่งที่ตั้งไว้ตอนแรก สามารถทำได้หรือไม่
บทบาทของ Product Owner ในการทำ Scrum ที่ LINE BK คืออะไร?
บทบาท (Role) ใน Scrum team จะมีอยู่ 3 กลุ่มใหญ่ ๆ ด้วยกัน
#1 – Scrum Master
เป็นคนที่ทำให้ทีมเข้าใจ Scrum framework คอยช่วยให้ทีมสามารถทำงานต่อไปได้อย่างไหลลื่น คอย check ว่าทีมเจอปัญหาอะไรหรือไม่ในระหว่างทำงาน เพื่อให้มั่นใจว่า Sprint goal จะสำเร็จได้ทันเวลาและมีประสิทธิภาพ
คนที่เป็น Scrum Master ไม่จำเป็นต้องเป็น Product Owner/ Product Manager มาก่อน แต่ต้องรู้และเข้าใจใน Scrum framework เพราะต้องเป็นคนที่ดูภาพใหญ่ได้
เข้าใจการทำงานของ Scrum
เข้าใจว่าแต่ละทีมต้องทำอะไร
รู้ว่าการทำงานแบบ Sprint หน้าตาเป็นแบบไหน
ต้อง Concern อะไรบ้าง
หน้าที่ของ Scrum Master ที่ LINE BK คือต้องคอยดูเสมอว่าทุกสิ่งที่ทำอยู่ใน Sprint นั้น ๆ ยังคง On plan และสามารถ Lead ไปจนบรรลุเป้าหมายได้
ในเมื่อ Scrum Master เป็นผู้ที่คอยช่วยเหลือคนอื่นในทีม ฉะนั้นถ้าสามารถประเมินล่วงหน้าได้ว่า Requirement ออกมาเป็นแบบนี้ น่าจะเกิดปัญหาที่ตรงไหน ถึงแม้ทีมที่อาจเกิดปัญหาจะยังไม่มีใครรู้ถึง Concern ตรงนี้ก็ตาม Scrum Master ก็จะสามารถเข้าไปช่วยป้องกันปัญหาก่อนได้ (ซึ่งจริงๆ แล้วแต่บริษัท แต่อย่างที่ LINE BK จะมี Scrum Master ที่ช่วยดูตรงนี้ด้วยอีกคนนึง)
เช่น ถ้าสมมติว่าเคยทำใน Development team มาก่อน พอมาเป็น Scrum Master ก็จะสามารถประเมินได้ว่า Requirement หน้าตาแบบนี้ Developer น่าจะใช้เวลาในการทำเท่าไร
Scrum Master ที่ดีจะต้องเป็นคนที่สามารถ Align Expectation ของทั้งทีมได้ สามารถสื่อสารให้ทีมเข้าใจได้ว่าทุกคนกำลังทำอะไรอยู่
สำหรับตำแหน่งที่ใกล้เคียงกับ Scrum Master ใน Framework อื่น อาจจะเป็น Project Manager, Project Management Officer ที่คอยดูว่า Project นั้น Deliver ได้ไหม ทำได้ On plan ไหม ทำได้ใน Budget ที่กำหนดหรือไม่ จะเหมือนกันตรงที่เป็นคนที่ Ensure ว่างานสามารถทำได้สำเร็จผล และ ถูก Launch ออกไปหาลูกค้าได้
#2 – Product Owner
จะดูในเรื่องของ Requirement กับ User story เป็นหลัก คอยประเมินว่า value ของงานแต่ละชิ้นตอบโจทย์ความต้องการของลูกค้าและตลาดหรือไม่ และต้องสามารถจัด Priority ของงานได้
เช่น มี User story มา 20 อัน ซึ่งไม่สามารถทำพร้อมกันทั้งหมด จึงจะต้องบอกได้ด้วยว่าจะทำอันไหนก่อนหลัง เพราะอะไร
โดยปกติใน Scrum framework เมื่อแบ่งตาม Task/ Responsibility จะเป็นตำแหน่ง Product Owner แต่ถ้าไม่มีก็สามารถเป็น Product Manager แทนได้
แต่ถ้าในบริษัทมีทั้ง Product Owner และ Product Manager คนที่อยู่ใกล้เคียงกับ Development team จะเป็น Product Owner ส่วน Product Manager จะอยู่ใกล้กับฝั่ง Customer/ User facing เป็นคนที่ออกไปคุยกับลูกค้า ทำ Customer Research และ Market Research เพื่อ Set ภาพ Direction ส่งให้กับ Product Owner แล้ว Product Owner ตั้ง Requirement ให้ Deliver ต่อไปให้ Development team
เมื่อ Develop & Test จบพร้อมที่จะ Launch feature ตอนที่จะทำ Go-to-market strategy และ Marketing communication ต่อนั้น Product Manager จะกลับมา Take lead อีกครั้ง
อย่างไรก็ตามแต่ละบริษัทก็จะแบ่ง Role หรือ Responsibility แตกต่างกันออกไปตามบริบทของบริษัท, Project และ ทีมต่าง ๆ เช่น บริษัทที่เป็น B2B ก็อาจไม่ต้องทำ Go to market strategy แบบ B2C
#3 – Development Team หรือ Scrum Team
จริงๆ แล้วทีมนี้จะเป็นทีมที่รวบรวมคนจากหลาย ๆ ทีมเอาไว้ ไม่ได้มีกำหนดตายตัว แต่ขึ้นอยู่กับเนื้องานของ Product นั้นๆ โดยทั่วไปก็จะมึ Developer, UX/UI Designer, Tester และอาจรวมถึง Operation Team
เมื่อ Product Owner กำหนด Requirement หรือ User story โดยที่เรียง Priority มาแล้ว Development Team จะเข้ามาช่วยกันดูว่าแต่ละทีมมี Feedback อย่างไร
เช่น
Tester คิดว่าสามารถ test ได้ไหม ใช้เวลาเท่าไร
ส่วนของ Operation Team คิดว่าการขึ้น Feature นี้ มีผลกระทบอะไรกับ Operation หน้าบ้านหรือหลังบ้านไหม
ยกตัวอย่างเหตุการณ์ เช่น การเปลี่ยนจำนวนปุ่มกดจากปุ่มเดียวเป็น 5 ปุ่ม ต้องสื่อสาร Message อะไรออกไปไหมให้ลูกค้า Aware ว่ากำลังจะมีปุ่มเพิ่มขึ้นมาจากเดิม และมันต่างกันอย่างไร
เคยใช้ Scrum แล้วเจอ Challenge อะไรบ้าง?
ที่เคยเจอคงเป็นเรื่องของ Sprint period ความยากคือ เราจะรู้ได้ยังไงว่า Objective ที่ตั้งมา มันจะสำเร็จได้ในระยะเวลาที่กำหนด หรือว่าจะต้องกำหนดระยะเวลาเป็นเท่าไร
Case Study: Mobile Application
ตอนทำ Sprint planning กับทีม เราจะมีการ Set ไว้กับทีมแล้วว่าจะทำอะไรบ้าง ซึ่งจริงๆ ใน Task ของเราที่เป็น Product Owner เอง จะต้องมีไปคุยกับทีมกฎหมายเพื่อที่จะปิด Concept ของ Feature หนึ่งให้ได้ มี Timeframe ที่ชัดเจนแล้วว่า Sprint หนึ่งคือ 2 สัปดาห์
ตอนแรก เรา Target ว่าจะต้องทำให้เสร็จใน 1 Sprint แต่พอทำจริง พบว่ามี Blocker แจ้งปัญหากับ Product Manager และทีมอื่นๆ ก็แล้ว แต่งานก็ยังไม่เสร็จ จึง Target ใหม่ว่าจะปิดงานใน sprint ที่ 2 สุดท้ายก็ยังไม่เสร็จ และเลื่อนไปอีก 1 สัปดาห์
ซึ่งงานตรงนี้เป็นแค่ของทีม Product Owner เท่านั้น ไม่รวมถึง Development Team ซึ่งพอทาง Development Team ที่วางแผนไว้ใน Sprint ที่ 2 ว่าจะเริ่มเข้ามารีวิว Requirement ก็ไม่สามารถเข้ามาดูได้ เพราะหลายอย่างยังคลุมเครือ
จึงกลายเป็นความท้าทายของ Product Owner อย่างเราว่าการที่มี Sprint planning แล้วจะ Set goal ให้แต่ละทีมทำต่อกันได้อย่างลื่นไหล จะต้องประเมินเวลายังไงให้ใกล้เคียงกับเวลาที่ใช้จริงที่สุด จะบอกทีมตอนไหนว่า Task นี้ไม่สามารถส่งต่อได้ตาม Goal ที่ตั้งไว้
ซึ่งสิ่งเหล่านี้จะมีทำกันใน Scrum framework อยู่แล้วเรียกว่า Sprint review และ Retrospective เพื่อให้ทีมช่วยกันเข้ามาดูว่า Sprint ที่ผ่านมาทำอะไรไปบ้าง เจอปัญหา หรือ challenge อะไร แล้วจะแก้ไขต่อไปได้อย่างไร
ซึ่งใน Case Study นี้พบว่า เพราะ Product Owner มี Challenge ที่ยากกว่าที่คิด คือ Task ที่ต้องคุยกับทีมกฎหมาย จึงตัดสินใจแยก Task นี้ออกมา แล้ว Concept ใดก็ตามที่เกี่ยวข้องกับส่วนนี้ ก็แบ่งย่อยลงไปอีกอยู่ใต้ Task นี้ กล่าวคือ แยกงานที่เกี่ยวกับกฎหมายออกไปจากงานส่วนอื่น ๆ เลย แล้วทำงานส่วนที่เหลือไปก่อนได้ โดยที่ยังไม่ต้องสนใจงานส่วนที่ยัง Pending
ผลที่ออกมาก็คือทั้งทีมสามารถเดินต่อได้ โดยมี Delay แค่ส่วนที่เกี่ยวกับกฎหมายเท่านั้น
คิดว่า Scrum เหมาะและไม่เหมาะกับองค์กรแบบไหน?
ส่วนตัวคิดว่า Scrum เหมาะกับองค์กรขนาดเล็ก เพราะ การทำ Scrum คือการที่ Product Owner สามารถส่ง Requirement เข้าไปที่ Development Team ได้โดยตรง ซึ่งเป็น Working team ที่รวมคนจากหลายฝ่าย หมายความว่าคนจะเยอะประมาณหนึ่งในทีม
ยิ่งมีหลายคนเข้ามารุมงานพร้อมกันก็จะมีความวุ่นวาย เลยคิดว่าควรใช้ Scrum ในองค์กรที่มีคนไม่เยอะ และมีการสื่อสารที่ทั่วถึง เพราะการที่จะทำอะไรให้เร็ว การสื่อสารระหว่างคนจะมีผลมาก หากเป็นองค์กรใหญ่ก็ควรมีการออกแบบการสื่อสารระหว่างทีมที่ดี
ตัวอย่างปัญหาที่เป็นไปได้ว่าจะเจอหากขาดการสื่อสารที่ทั่วถึง เช่น Designer คนที่ 1 คุยกับ Developer ว่าอยากจะแก้อะไร แต่ Designer คนที่ 2 ไม่รู้ เนื่องจากอาจจะ Sync กันช้า จึงคิดอีกแบบไปคุยกับ Developer เกิดเป็นการออกแบบ 2 อันซ้อนกัน
จะเห็นว่า ถ้าในแต่ละทีมยิ่งมีคนเยอะ ก็จะยิ่งเกิด Micro conversation เวลาที่ทำอะไรผ่านไปเร็ว Requirement อาจจะถูกเปลี่ยนไป สามารถเกิดความเข้าใจที่คลาดเคลื่อนได้
ปรับตัวใช้ Scrum ผสมผสานกับ Waterfall
อาจเพราะด้วยตัว Industry ที่เป็น Banking เอง ส่วนมากงานที่ทำต้องการความชัดเจนจากฝั่ง Requirement ประมาณหนึ่ง เพราะมีเรื่องของกฎหมาย หรือกฎเกณฑ์เป็นองค์ประกอบด้วย เป็นเหมือน Hard rule ที่ถ้าเกิดทำไม่ตรง ก็ไม่สามารถ Launch สู่ตลาดได้
ถ้าขา Requirement ยังไม่ Solid สามารถให้ทีมอื่นเข้ามาดูและเรียนรู้ได้ แต่ก็ไม่สามารถเดินต่อได้ Flexible ขนาดนั้น จึงไม่สามารถทำได้เร็วแบบที่ Scrum ควรจะเป็นในช่วงแรกอยู่ดี
อยากฝากอะไรถึงการทำงานร่วมกับทีมโดยใช้ Scrum บ้าง?
หัวใจของการทำงานแบบ Scrum ในการแบ่งทีม เพื่อทำของออกมาได้ เป็นเรื่องของ “การสื่อสาร”
จุดที่สำคัญที่สุด คือ Sprint objective จะต้อง Align กับทุก Stakeholders ว่าสิ่งที่เราอยากทำคืออะไร และจะมีสิ่งที่เรียกว่า Definition of Done (DoD) อยู่ภายใต้ Objective ต้องทำให้ Clear ว่างานแต่ละงานที่ต้องทำให้เสร็จ คำว่าเสร็จคืออะไร
เช่น ภายใน sprint นี้ Tester จะสามารถตั้ง Test Scope ได้ประมาณไหน เมื่อ Link กลับมาที่ Sprint goal จะเห็นว่า Sprint objective เป็นส่วนไหนของภาพนั้น เพื่อให้ทุกคนสามารถ aware ได้ว่างานนั้น ๆ มี Value กับ Sprint goal ยังไง ถ้าทำไม่เสร็จ จะไปติดที่ตรงไหน blocker ที่ใครหรือไม่ หากทีมมีการสื่อสารที่ดีก็จะทำให้สามารถ Deliver งานออกมาได้รวดเร็ว และมีประสิทธิภาพ
ในส่วนของ Scrum Master ต้องสามารถสื่อสารให้ทุกคนรู้ว่า ถ้าใครมีปัญหาอะไรต้องรีบบอก ไม่อย่างนั้นทั้งทีมจะเดินต่อไม่ได้ ทางฝั่งของ Product Owner จะต้องสื่อสารความสำคัญของรายละเอียดงานแต่ละงานใน backlog ว่าทำไมถึงต้องทำงานนี้ ทำไมถึงเรียง priority แบบนี้ แต่ถ้าเห็นว่า Idea ของคนในทีมน่าสนใจ ก็สามารถ Shuffle priority ได้
และแน่นอนว่า Product Owner/ Product Manager ต้องคอย Ensure ว่าสิ่งที่จะ Deliver ออกไปมี Value กับลูกค้าจริง ๆ และสามารถตอบโจทย์ลูกค้า หรือ Goal ของ Direction ที่ทีมตั้งใจเอาไว้
สำหรับใครที่อยากศึกษาเพิ่มเติมเกี่ยวกับ Scrum สามารถศึกษาได้จากแหล่งข้อมูลต่างๆ มากมาย อย่างเช่น AWS Amazon ก็มีการอธิบายเนื้อหาไว้เช่นเดียวกัน
สุดท้ายนี้ ขอขอบคุณพี่เซปที่มอบพื้นที่ให้ผู้เขียนได้แลกเปลี่ยนความรู้และประสบการณ์ร่วมกันกับผู้ที่มีความสนใจทางด้าน Product Management ใน Community ของ PM Corner นะคะ 🙂
และหากคุณชอบคอนเทนท์นี้ อย่าลืมกดไลก์ กดแบ่งปันให้เพื่อนๆ หรือคอมเมนต์กับพวกเรา และสามารถติดตาม content update ใหม่ๆ จาก PM Corner ได้จาก Facebook Page: PM Corner Thailand หรือทาง PM Corner Library ได้เลย!
