Experimental Banking Ep.3 — กว่าจะมาเป็น MAKE by KBank ในมุมของตำแหน่ง Product Owner

ในปี 2020 แอป Mobile Banking ไม่ใช่เรื่องใหม่ของวงการธนาคารและประเทศไทยอีกต่อไป ทุกวันนี้เรามักจะเห็นผู้คนใช้ Mobile Banking แทนเงินสดมากขึ้นเรื่อยๆ ไม่ว่าจะเป็นการจ่ายเงินรูปแบบใหม่ผ่าน QR Code หรือถอนเงินแบบไม่ใช้บัตร รวมไปถึงฟีเจอร์ใหม่ๆ ที่ทาง KBTG กำลังพัฒนาอย่างต่อเนื่อง ส่งมอบประสบการณ์การทำธุรกรรมทางการเงินที่ดีขึ้นโดยคำนึงถึงความสะดวกของลูกค้าเป็นหลักเสมอ

ทั้งนี้ กว่าจะคลอดออกมาเป็น MAKE by KBank แอปพลิเคชัน Mobile Banking ตัวใหม่ที่ทำขึ้นมาเพื่อประสบการณ์ที่ดีที่สุดสำหรับลูกค้าที่เป็นคนรุ่นใหม่นั้น ผู้ที่ต้องสวมหมวกเป็นคนดูแลทั้งหมดและต้องรับผิดชอบ Product ที่ออกมาก็หนีไม่พ้นคนที่เป็น Product Owner

เราพัฒนา Mobile Banking ใหม่ที่เป็น Experimental Banking ในเชิงเทคโนโลยี (Canary Deployment, A/B Test, Google Cloud Platform, etc.), User Interface/User Experience (หรือ UX/UI) และวิธีการทำงาน เพื่อที่จะค้นหาและส่งมอบประสบการณ์รูปแบบใหม่ให้ลูกค้าแบบครบวงจรและสร้างสรรค์ให้ดียิ่งขึ้น จึงอยากใช้พื้นที่ใน Ep.3 แบ่งปันประสบการณ์เบื้องหลังการสร้างแอป MAKE ในมุมของ Product Owner หน้าที่หลักๆ จะแบ่งออกเป็น 3 เฟส คือ Conceptual Phase, Plan และ Build & Test มาเริ่มกันที่ช่วงแรกกันเลย

Conceptual Phase

เฟสนี้ถือเป็นเฟสเริ่มต้น โดยส่วนมากจะมีการทำงานร่วมกับ Designer เพื่อค้นหา Pain Points ของลูกค้าอันเป็นหัวใจสำคัญของเรา เริ่มต้นจากการหาข้อมูลและกำหนดลูกค้ากลุ่มเป้าหมาย เช่น เราอยากจะตอบโจทย์คนกลุ่มไหน เป็นต้น ซึ่งการกำหนดกลุ่มเป้าหมายนี้มีความสำคัญมากในการพัฒนาแอป Mobile Banking เพราะเราต้องสร้าง Customer Value Proposition (CVP) หรือคุณค่าที่เราจะนำเสนอให้กับลูกค้าอย่างชัดเจน จากนั้น Product Owner และ Designer จะจัดทำ User Research เพื่อให้เข้าใจความต้องการ รวมทั้ง Pain Points จริงของลูกค้ากลุ่มเป้าหมาย โดยจะใช้เทคนิคต่างๆ ทำ User Research (ตามที่ได้เล่าไปก่อนหน้านี้แล้วใน EP.1) เมื่อทำ User Research เสร็จสิ้น เราจะสามารถแบ่งกลุ่มเป้าหมายให้เป็นแต่ละ Typology แยกตามแต่ละพฤติกรรมของกลุ่มเป้าหมายให้ละเอียด หลังจากนั้นจะสำรวจ Market Size หรือจำนวนกลุ่มเป้าหมายและความต้องการในตลาด เพื่อค้นหาโอกาสที่จะเกิด Product หรือประสบการณ์ใหม่ๆ

หลังจากการที่เราเข้าใจกลุ่มลูกค้าและตลาดเป้าหมายแล้ว ก็เข้าสู่ขั้นตอนการรวบรวมไอเดีย โดยจะเริ่มร่างฟีเจอร์ซึ่งเป็นผลลัพธ์จาก User Research พร้อมด้วยการออกแบบ Customer Experience ร่วมกันทีม Designer เพื่อให้ได้รูปร่างของฟีเจอร์และคอนเซ็ปต์ โดย 2 ส่วนนี้จะสร้าง Customer Journey ของการใช้ฟีเจอร์และเผยประสบการณ์ใหม่ที่ยังไม่มี Mobile Banking ใดทำ แล้วนำไปพิสูจน์ด้วยการทำ Concept Validation ทดสอบกับลูกค้าจริงว่าฟีเจอร์เหล่านี้ตอบโจทย์ความต้องการของลูกค้าหรือไม่

Plan

เมื่อเราได้ฟีเจอร์ของ Product ที่ตอบโจทย์ลูกค้าแล้ว ขั้นต่อมาคือการวางแผนและสื่อสารกับ Stakeholders ที่เกี่ยวข้องทั้งหมด ส่วนนี้จำเป็นต้องเข้าใจเนื้อหาการทำงานและความคาดหวังของบุคคลเหล่านี้ทั้งหมด รวมถึงการจัดการความคาดหวัง (Manage Expectations) ของ Stakeholders ทุกคน แบ่งคร่าวๆ ได้ดังนี้

1. Plan for Working Team — Working Team ประกอบไปด้วย Product Manager, Product Owner, Designer และ Developer โดยจะมีการประชุมและวางแผนงานกันว่าจะต้องทำงานอะไร ส่งเมื่อไหร่ เช่นเมื่อแบ่งงานเป็น Sprint ละ 2 อาทิตย์ ทาง Product Owner และ Designer จะต้องคิด User Journey ที่เป็นประสบการณ์ที่ดีที่สุดสำหรับลูกค้า แล้วร่าง Requirement Application อย่างละเอียด จากนั้นส่งให้ Designer ทำ Screen Flow ให้เสร็จ ก่อนส่งทั้งหมดให้ Developer เพื่อทำการ Dev ต่อไป ซึ่งสิ่งที่ได้เรียนรู้คือ Designer ในช่วงแรกจะออกแบบ Designer Theme & Concept ในแกน Horizontal ซึ่งคือการออกแบบภาพรวม ขนาดตัวอักษรและรูปแบบของแอปทั้งหมดให้ออกมาเป็นธีมเดียวกัน แล้วค่อยทำการออกแบบแต่ละฟีเจอร์ตามแกน Vertical หรือการแยกชิ้นให้ Designer แต่ละคนทำเพื่อให้สามารถส่งมอบตามเวลาที่กำหนดของ Sprint ได้ ซึ่งการวางแผนการทำงานนี้จำเป็นต้องหารือกับ Designer และ Developer ในเรื่องของระยะเวลาการส่งมอบงาน

2. Plan for Executives — การพัฒนา Product ให้กับธนาคารนั้นจะมี Business Unit มากมาย ดังนั้นในฐานะ Product Owner เราจึงต้องมีรายละเอียดของ Killing Feature หลักๆ ที่ต้องการพัฒนา และพร้อมตอบคำถามว่าแต่ละฟีเจอร์ทำเพื่อตอบโจทย์ลูกค้ากลุ่มใด รวมถึงกำหนดการออก Product ในแต่ Phase เพื่ออัพเดตความคืบหน้ากับผู้บริหารและทีมที่เกี่ยวข้อง

3. Plan for Customer Support Team — การจัดเตรียม Operational Support ให้กับลูกค้าที่เข้ามาใช้บริการ เริ่มต้นด้วยการติดต่อกับทีม Customer Service เพื่อทำการสื่อสารและจัดอบรมพนักงาน Call Center และพนักงานสาขาทั่วประเทศ นอกจากนี้เรายังต้องคำนึงถึงการพัฒนาเพิ่มในส่วนของ Back Office หรือระบบที่ทาง Call Center และสาขาใช้งาน ตัวระบบนี้จะต้องถูกออกแบบให้ตอบโจทย์การใช้งานของพนักงาน Call Center และสาขามากที่สุด เพื่อความรวดเร็วและถูกต้องของการให้บริการลูกค้า ซึ่งหากต้องมีการแก้ไขหรือเปลี่ยนแปลงวิธีการทำงานของ Call Center และสาขา เราก็ต้องลงรายละเอียดของกระบวนการใหม่และตรวจสอบความถูกต้องอย่างถี่ถ้วน ซึ่งกระบวนการนี้ใช้เวลาถึง 1–2 เดือนเลยทีเดียว เพื่อให้มั่นใจว่า Call Center และสาขา ซึ่งเป็น Touch Points หลักของธนาคารสามารถจัดการและรองรับลูกค้าได้อย่างท่วงทัน

4. Plan for Compliance and BOT — ถึงแม้ Customer Experience จะมีความสำคัญมากที่สุดในการทำ Mobile Banking แต่ทุกขั้นตอนของการพัฒนาเราจะทำตามนโยบายที่ถูกต้องทางกฎหมายและการจำกัดความเสี่ยงที่อาจเกิดขึ้นกับลูกค้าได้ ซึ่งเป็นหน้าที่ของ Product Owner ที่จะต้องทำงานอย่างใกล้ชิดกับทีม Compliance, Operational Risk, ทีม Legal และ ทีม IT-Security

5. Plan for Communication — ส่วนนี้จะเป็นการจัดเตรียมรายละเอียดทั้งหมดของ Product เช่น กลุ่มลูกค้าเป้าหมาย จุดประสงค์และรายละเอียดของ Product เพื่อการสื่อสารและการจัดลำดับความสำคัญสำหรับขออนุมัติ Resource กับธนาคารในพัฒนา Product ตามความเหมาะสม

Build & Test

1. Build

ขั้นตอนการสร้าง Product เป็นการทำงานระหว่าง Product Owner, Designer, Developer และ Tester การร่วมงานกันเป็น Squad เล็กๆ แบบนี้ช่วยทำให้ชิ้นงานออกมาได้อย่างรวดเร็วขึ้น โดยฟีเจอร์ที่ผ่านการทำ Concept Validation จะถูกนำมาเขียนเป็น Requirements ลงรายละเอียดมากขึ้น เช่น ลูกค้าจะเห็นข้อมูลอะไรบ้างบนหน้าจอ มีกี่ปุ่มที่ลูกค้าสามารถเลือกได้ เป็นต้น ซึ่ง Requirement เปรียบเสมือนพิมพ์เขียวของการสร้างบ้าน จึงต้องเขียนอย่างละเอียด เพื่อเป็นแบบตั้งต้นให้ทาง Developer และ Tester นำไปเพื่อไปสร้างแอป ในเวลาเดียวกันเราจะประสานงานกับ Designer ให้ทางนั้นออกแบบและส่งมอบภาพหน้าจอทั้งหมดผ่านทางระบบ Zeplin เมื่อเสร็จก็ส่ง Requirement ทั้งหมดให้กับทาง Developer ในส่วนนี้จะทำงานในรูปแบบ Agile เป็นส่วนใหญ่ แต่บางชิ้นงานในโปรเจคก็ยังมีการใช้การจัดการแบบ Waterfall อยู่เพราะได้ผลลัพธ์ออกมาดีกว่าเมื่ออยู่ในรูปแบบของ Corporate รวมทั้งถ้ามีส่วนที่เกี่ยวกับแอปอื่นของธนาคาร เราก็ต้องหารือกับทีมผู้เกี่ยวข้องนั้นๆ โปรเจคนี้เราได้สื่อสารและร่วมมือกับผู้เกี่ยวข้องกว่า 20 ทีมด้วยกัน

ในส่วนของ Requirement จะถูกส่งเป็น Sprint และมี Timeline ส่งมอบผลงาน Sprint ละ 2 อาทิตย์ ในระหว่างที่ Developer ทำงาน Product Owner และ Designer ก็จะเริ่มลงรายละเอียดสำหรับ Sprint ถัดไป หาก Developer มีข้อสงสัยหรือปัญหาที่เกี่ยวกับ Development ทาง Product Owner ก็จะสามารถตอบคำถามและหาวิธีแก้ไขไปพร้อมๆกับ Squad และผู้เกี่ยวข้องทั้งหมด อีกสิ่งที่มีความสำคัญคือการจัดประชุมเพื่ออัพเดตและแก้ไขปัญหาต่างๆ ที่พบเจอ ซึ่งทาง Product Owner จะมีการจัดประชุม Daily Scrum อัพเดตกับ Designer และประชุมรายสัปดาห์กับ Developer

ซึ่งการทำงานแบบนี้ทำให้ Product ใหม่ของเรามีความยืดหยุ่นในการรองรับภาษาได้หลากหลาย แต่ละคำในแอปจะมี Key ประจำเพื่อเพิ่ม Label เป็นภาษาไทย ภาษาอังกฤษ และภาษาที่สามอื่นๆ ได้ ก่อนที่จะปล่อย Product ใหม่นี้ออกมา จะต้องทำ Usability Testing เพื่อให้ลูกค้าทดลองประสบการณ์การใช้งานจริง และนำคำติชมมาพัฒนา Product ต่อๆไป

2. Test and Approval

เมื่อ Product ได้ถูกสร้างขึ้นมาแล้ว Product Owner มีหน้าที่อำนวยความสะดวกให้ Tester และ App Owner ต่างๆ ซึ่ง Product Owner จะเข้ามาเทสรวบรวมผลลัพธ์ทั้งหมด และแจ้งขออนุมัติแบงก์ชาติอีกครั้ง เพื่อขออนุญาตในการทำ Performance Verification Test หรือ PVT กับลูกค้าจริงหลัง Deploy โดยมีการแบ่งขั้นตอนการทำเทสดังนี้

2.1 System Integration Test หรือ SIT ทีม Tester จะเริ่มทำการเทสโดยจะมี Test Case หรือ Test Scenarios เพื่อยืนยันความถูกต้องของการทำงานของระบบ เช่น ระบบเราส่งข้อมูลให้ระบบขารับถูกต้อง ระบบบัญชีต่างๆ ลง Record หรือ Log ถูกต้อง และ Defects ที่เกิดขึ้นระหว่าง SIT จะถูก Log ลงบนระบบ Jira Software ซึ่งทาง Product Owner จะทำการแจ้ง Requirement เพิ่มเติมเพื่อให้ Developer ทำการแก้ไข Defects ทั้งหมด

2.2 User Acceptance Test หรือ UAT จาก Business Unit ที่เกี่ยวข้องกับ Product ก่อนจะนำขึ้นโปรดักชัน ทีมที่เกี่ยวข้องทั้งหมด เช่น Legal, Risk, IT, Compliance, Data Governance, Product Owner จะช่วยเทสความถูกต้องในเชิงการใช้งาน ตรวจสอบเงื่อนไข บันทึกข้อมูล และยืนยันอนุมัติ UAT ผ่าน ซึ่ง Product Owner จะคอยช่วยอำนวยความสะดวกให้ UAT ก่อนที่จะ Deploy ขึ้นโปรดักชันในส่วนถัดไป ในระหว่างนี้ Tester จะมีการทำ Regression Test เป็นการเทสวิธีเดียวกับบริษัท Google ที่จะทำการเทสทุกฟังก์ชันอีกครั้ง รวมทั้งเทสฟังก์ชันรอบๆ ด้วยว่าใช้งานได้ถูกต้องและไม่ผิดพลาด

2.3 Performance Verification Test หรือ PVT หลังจากที่ Deploy ขึ้นโปรดักชันจริงแล้ว จะมีการจำกัดวงผู้ใช้งานจำนวนหนึ่งเพื่อดู Performance ของแอปพลิเคชันก่อนออกสู่ตลาดเปิดให้ใช้งานในวงกว้าง

สำหรับแอป MAKE by KBank ที่เราได้สร้างขึ้นมานี้ เราจะมีการทำ Dogfooding หรือ Eating your own Dogfood คำนี้เป็นศัพท์ Slang ที่บริษัทเทคโนโลยีอย่าง Google และ Apple ใช้กันบ่อยครั้ง หมายถึงการทำเองและทดลองใช้งานเองภายในก่อนจะออกสู่ตลาดวงกว้างนั่นเอง โดยจะเริ่มจากเปิดให้พนักงาน KBank และ KBTG ได้ทดลองประสบการณ์ใหม่นี้พร้อมกัน เพื่อนำฟีตแบ็คไปพัฒนา Product ให้ดียิ่งขึ้นก่อนที่ส่งมอบให้กับลูกค้าจริงภายในปลายปีนี้

พอได้เรียนรู้เกี่ยวกับเบื้องหลังการออกแบบและพัฒนา MAKE กันไปบ้างแล้ว หวังว่าข้อมูลนี้จะทำให้หลายคนที่อยากทำงานด้านนี้เห็นภาพว่าเนื้องานที่ตัวเองต้องเจอเป็นแบบไหนชัดเจนขึ้น แล้วอย่าลืมรอติดตามผลงานของเราเร็วๆ นี้นะครับ ^^