Business, Design & Tech Sprint

จากการที่ได้ร่วมงานกับ FINNOMENA มาประมาณ 2 ปี มีโอกาสได้เรียนรู้วิธีการทำงาน แบบ Agile Software Development คือการทำทีละน้อย ซึ่งดูจะให้ผลลัพธ์ที่ดีกว่าการพัฒนาซอฟท์แวร์แบบเดิม ๆ ที่ต้องมีการทำ Manual, User Requirement ทีละมาก ๆ จึงค่อยส่งให้ทีม Tech พัฒนา บทความนี้จะพาไปลงรายละเอียดถึงการใช้แนวคิดแบบ Agile เข้าไปใช้ในกระบวนการพัฒนาระบบฟินเทค ตามแบบฉบับของ FINNOMENA ครับ

Agile Software Development
Agile Software Development คือแนวทางในการพัฒนาซอฟท์แวร์ ที่ตลอดกระบวนการจะมีการประสานงานกันแบบ project based ที่ทุกฝ่าย ซึ่งในกรณีของฟินโนมีนา คือฝ่าย Business ฝ่าย Design และฝ่าย Technology ร่วมกันพัฒนาตลอดกระบวนการ โดยเอา Customer Journey เป็นแกนกลาง การประชุมหารือจะได้ผลลัพธ์ออกมาเป็น “การ์ด” สำหรับทีม Tech เพื่อนำไปลงมือ dev (เขียนโปรแกรม) จริง ซึ่งที่ฟินโนมีนาใช้ Jira เป็นโปรแกรมหลักในการทำ Sprint Planning

Scrum และ Sprint Planning
Scrum เป็นวิธีการพัฒนาแบบ Agile Software Development ที่ออกแบบสำหรับนักพัฒนาทีมละ 3 – 9 คน โดยมีการแตกงานออกเป็นชิ้น ๆ (ในที่นี้คือ Jira Card) และพัฒนาให้เสร็จภายในรอบระยะเวลาที่กำหนด ซึ่งที่ฟินโนมีนาใช้ช่วงเวลา 2 สัปดาห์ต่อ 1 Sprint เท่ากับว่าปีหนึ่ง ๆ จะมีกระบวนการนี้เกิดขึ้น 26 รอบ โดยแต่ละทีมจะมีสิทธิ์เบ็ดเสร็จเด็ดขาดในการบริหารจัดการตัวเองให้บรรลุเป้าหมายในแต่ละรอบ Sprint Planning

การทำ Sprint Planning คือการกำหนด Backlog คือ Jira Card ที่พร้อมเข้าสู่กระบวนการพัฒนา การกำหนดความยากง่าย และลำดับความสำคัญของงานแต่ละชิ้น และการกำหนดสิ่งที่จะลงมือทำให้สำเร็จจริงในแต่ละรอบของ Sprint Planning

ชีวิตจริงตอนที่ 1: ปัญหา Jira Card ไม่พอ
หลังจากที่ทีมงานได้ตัดสินใจใช้แนวทาง Scrum และ Sprint Planning ไปซักระยะ เกิดปัญหา Jira Card ที่พร้อมจะทำการพัฒนาไม่เพียงพอ ซึ่งถือว่าเป็นปัญหาใหญ่ทีเดียว เพราะเท่ากับว่าทีม Developer มีงานน้อย capacity ที่มีในแต่ละรอบ 2 สัปดาห์ของการทำ Sprint Planning

สิ่งที่ได้ทำไปคือการ reengineer ขั้นตอนการทำงานเป็น สูตร “B -> B&D -> T” ซึ่งในที่นี้ B = Business Team, D = Design Team (UX) และ T = Tech Team (Developer) โดยขั้นตอนดังนี้
1. B - ทีม Business จะมีการประชุมกันทุกสัปดาห์ เพื่อกำหนด feature ที่ต้องการในเวบ และแอพของฟินโนมีนา
2. B&D - จากนั้นจัดประชุมทีม Business ร่วมกับทีม Design เพื่อทำความเข้าใจ feature ที่ต้องการและนำไปออกแบบประสบการณ์ผู้ใช้ (UX) และส่วนต่อประสานกับผู้ใช้ คือหน้าจอที่ผู้บริโภคสัมผัสจริง (UI)
3. T - จากนั้นนำผลที่ได้ไปสร้างเป็น Jira Card สำหรับนำไปใช้ในการประชุม Sprint Planning เพื่อให้ทีม Developer มี Backlog งานเพื่อนำไปพัฒนาเขียนโปรแกรมต่อไป

หลังจากทำตามสูตร “B -> B&D -> T” ไปได้ 1 ไตรมาส ผลที่ได้รับคือมีงานจำนวนมากที่ส่งไปให้ทีม Tech พัฒนา เท่ากับว่าการแก้ปัญหา Jira Card ไม่พอได้ถูกแก้ไปอย่างเบ็ดเสร็จ

ชีวิตจริงตอนที่ 2: ปัญหาการขาดความเข้าใจที่ตรงกัน
หลังจากแก้ปัญหาตามวิธีในตอนที่ 1 ได้สำเร็จ เกิดปัญหาใหม่ที่หนักไม่แพ้กันตามมา คือการที่ Jira Card ที่สร้างมาบางครั้งยังไม่สมบูรณ์พอ เมื่อ dev ออกมาเสร็จไม่สามารถ roll out ออกไปใช้งานได้ รวมถึงปัญหาที่ทีม Developer แต่ละคนไม่เข้าใจเป้าประสงค์ หรือ UX ของสิ่งที่ตัวเองกำลัง dev โดยสมบูรณ์ สิ่งที่เกิดขึ้นคือ “ความอึดอัดใจ” ครับ ทางทีม Developer ก็มึน ๆ กับสิ่งที่ตัวเองกำลังทำ และสิ่งที่ทำออกมาหลายครั้งก็ไม่ได้นำไปใช้จริง ยิ่งทำให้ morale ของทีมโดยรวมตกลงไปอีก

เราจึงได้ทำการ reengineer อีกครั้งเป็น สูตร “B -> B&D&T -> V -> T” ซึ่งในที่นี้เพิ่มตัว “V = Validation” โดยขั้นตอนใหม่เป็นดังนี้
1. B - เหมือนเดิมคือทีม Business ประชุมกันทุกสัปดาห์เพื่อกำหนด feature ที่ต้องการ
2. B&D&T - จากเดิมที่มีเฉพาะทีม Business กับ Design ตัดสินใจเพิ่มทีม Tech เข้าร่วมประชุมด้วยเลย เพื่อทำการ POC (Proof of Concept) ว่าในทางเทคนิคสามารถนำไปพัฒนาได้จริงหรือไม่ ตรงนี้จะช่วยเพิ่ม “อารมณ์ร่วม” ให้กับ Developer ที่จะรับทราบความสำคัญของแต่ละชิ้นงานไปในตัว
3. V หรือ Validation - ก่อนที่จะส่งต่อไปพัฒนาจริง โดยทำการสรุปสุดท้ายถึงลำดับความสำคัญ (Priority) และระดับของ effort ที่ต้องใช้ในการพัฒนาโปรแกรม ถ้าผ่านขั้นตอนนี้จะได้ Jira Card ที่พร้อมต่อการเริ่ม coding กันได้เลย
4. T – นำ Jira Card ไปใช้ในการประชุม Sprint Planning ต่อไป

สรุปคือกระบวนการ Business, Design & Tech Sprint Planning นั้นไม่มีสูตรตายตัว การปรับเปลี่ยนกระบวนการจะให้ผลที่แตกต่างกัน สำคัญคือการเรียนรู้ข้อดี ข้อเสียของแต่ละแบบของกระบวนการที่ทำ และทำการเรียนรู้ซึ่งกันและกัน จากนั้นก็ค่อย ๆ ทยอยพัฒนากระบวนการทำงานให้ดียิ่ง ๆ ขึ้นไป ทั้งหมดก็เป็นกรณีศึกษาแนวคิดการพัฒนาซอฟท์แวร์ของ Tech Startup ที่ผู้เขียนได้เรียนรู้ในตลอดกว่า 2 ปีที่ผ่านมา

FundTalk รายงาน