Muze x Tokio Marine : พัฒนาระบบ ISA ช่วยเหลือการขายครบวงจร
เพื่อน ๆ หลายคนคงเคยได้ยินคำว่า “ประกันชีวิต” ใช่ไหมครับ? ประกันชีวิต คือประกันที่จะให้ความคุ้มครองกรณีผู้ทำประกันเสียชีวิต หรืออยู่จนอายุครบตามสัญญา ซึ่งจะได้รับเป็นเงินก้อนใหญ่กลับมาตามแผนที่เลือกทำเอาไว้
ที่เกริ่นมาอย่างนี้ก็ไม่ใช่อะไร วันนี้เราจะมาพูดถึงโปรเจกต์ ที่ Muze ได้ร่วมงานกับบริษัทที่เป็นผู้ขายประกันชีวิตเจ้าใหญ่ของประเทศไทย อย่าง Tokio Marine Life Insurance หรือโตเกียวมารีนประกันชีวิต นั่นเอง
โดยเราได้รับเกียรติจากหนึ่งในแกนหลักสำคัญของโปรเจกต์นี้อย่าง พี่เก๋-นภาศรี Head of Product Owner มาบอกเล่าเรื่องราว พร้อมแชร์ประสบการณ์ต่าง ๆ จากโปรเจกต์ Tokio Marine ให้เพื่อน ๆ ได้ฟังกันแบบเจาะลึกเน้น ๆ ไม่มีกั๊ก ถ้าใครพร้อมแล้วก็อย่ารอช้า เลื่อนลงไปอ่านด้านล่างกันได้เลย
จุดเริ่มต้นของโปรเจกต์นี้คือ การพัฒนาระบบชื่อว่า ISA มาจากระบบ Intelligent Sales Assistant ให้กับบริษัท Tokio marine Life Insurance (Thailand) PCL. ซึ่งหน้าที่ของ Muze หลัก ๆ คือ ช่วยเหลือเกี่ยวกับการขายทั้งหมด โดยสามารถอธิบายให้เข้าใจง่ายตามแต่ละฟีเจอร์ได้ ดังนี้
- ช่วยเอเจนท์ในส่วนงานขายประกันชีวิตเวลาไปขายประกันให้ง่ายขึ้น
- ช่วยคำนวณให้เอเจนท์รู้ว่าผู้มุ่งหวังที่เก็บข้อมูลมามีเปอร์เซ็นต์ความน่าจะซื้อกรมธรรม์หรือเปล่า
- ช่วยติดตามว่าผู้มุ่งหวังคนนี้มีโอกาสกลายมาเป็นลูกค้าจริง ๆ เท่าไหร่
- ช่วยเตือนเอเจนท์ว่าต้องมี activity อะไรกับลูกค้าบ้าง เช่น นัดลูกค้ากี่ครั้งแล้ว เจอกันกี่ครั้งแล้ว คุยรายละเอียดอะไรไปแล้วบ้าง
- ขอความช่วยเหลือจากหัวหน้า เพื่อขอปรึกษาหรือรับฟังคำแนะนำเพิ่มเติมในปิดการขาย
- สร้าง challenge เพื่อหา top sales กับทีมอื่น หรือในทีมตัวเอง หรือแข่งกับตัวเอง เป็นต้น
ปัจจัยหลักๆ ที่ทำให้ทาง Tokio Marine ตัดสินลุกขึ้นมาพัฒนาระบบตัวนี้ เพราะว่าบริษัทมีเป้าหมายที่จะปรับปรุงระบบเดิมที่มีอายุการใช้งานมานานกว่า 10 ปี ให้ทันสมัยมากขึ้น ปรับเปลี่ยนเป็น Tech Stack ล่าสุดขึ้น รวมทั้งต้องการปรับ UX/UI ให้ friendly กับผู้ใช้มากขึ้น และสุดท้ายคือการช่วยเหลือเอเจนท์ให้ขายประกันและหาสมาชิกเข้าร่วมทีมได้ง่ายขึ้น
งั้นเรามาเริ่มที่ Day 1 กันเลย ช่วงต้นของการเริ่มโปรเจกต์ทางพี่เก๋เล่าว่า จะต้องเข้าไปประชุมกับลูกค้า เพื่อรับฟัง requirement เก็บรายละเอียดต่าง ๆ และก็ได้เจอกับความท้าทายตั้งแต่เริ่ม นั่นก็คือบางฟีเจอร์ที่คุยกันตอนช่วงทำ proposal ว่าลูกค้าต้องการให้มีเหมือนกับระบบเดิม แต่ภายหลังมีฟีเจอร์บางอันน่าจะไม่เหมาะกับปัจจุบันแล้ว ทำให้ต้องเอาออก เลยมีการปรับเปลี่ยนฟีเจอร์ระหว่างทางบางส่วน ทำให้ส่งผลกระทบเรื่องเวลาในการทำงานตามที่ตกลงกันไว้
ซึ่งปัญหานี้ถือว่าเป็นปัญหาคลาสิค ที่พี่เก๋แชร์วิธีแก้ให้เราฟังว่า ต้องไม่พัฒนาระบบจริงไปก่อน ต้องคุย requirement ให้เห็นภาพตั้งแต่เริ่มเพื่อประเมินภาพใหญ่ และลองเอา backlog งานเข้าในแต่ละ Sprint เพื่อให้ทางลูกค้าเห็นภาพเดียวกัน ระหว่างทางหากมีการเปลี่ยนแปลงเกิดขึ้น จะได้อธิบายกับลูกค้าได้ชัดเจนว่า สามารถเอาอันนี้ออก เอาอันนี้เข้าได้ หรือเราก็ต้องมาคุยกันว่าเอาเข้าได้บางส่วน ลูกค้าช่วย prioritize ว่าอะไรที่ต้องการจริงๆ เป็น Must Have ของระบบ
เมื่อจัดการกับ Issue ที่เกี่ยวข้อง และเข้าใจ requirement ที่ลูกค้าอยากได้แล้ว ก็จะเข้าสู่ขั้นตอนการแบ่งงานให้ทีมต่าง ๆ โดยเริ่มที่ทีม PO หน้าที่หลัก ๆ เลยคือ ต้องเข้าใจโจทย์ของลูกค้า แล้วมาถ่ายทอนให้กับทีม UX/UI Designer เข้าใจ และทำการออกแบบ UX/UI ออกมาและนำไปเสนอกับลูกค้า เมื่อผ่านในส่วนของการออกแบบ UX/UI แล้ว ก็จะมาถึงคิวที่ต้องคุยกับทางทีม Development ซึ่งจะมีทั้ง Developer และ QA ต้องอธิบายให้ทุกคนในทีมเข้าใจทั้งภาพรวมของโปรเจคและรายละเอียดเงื่อนไขต่างๆ
โดยโปรเจกต์นี้ลูกค้าใช้ Project Management Tool เป็น Jira โดยทาง PO จะทำการเขียน Backlog requirement บน Jira Tool นี้ ให้กับทีม Dev โดยการอธิบายทีมงานจะทำใน Ceremony ของ Epic Review และ Backlog Grooming ก่อนเข้า sprint ทุกครั้ง
หลังจากนั้น หัวหน้าทีม Dev ก็จะเอาโจทย์ที่ได้ มาวิเคราะห์และเตรียมออกแบบในมุม technical ว่าถ้าทาง PO อยากได้งานแบบนี้ จะต้องมีฟังก์ชันอะไร ทำงานยังไง ระบบถึงจะเร็วและมีประสิทธิภาพ โดยพี่ Dev Lead จะอธิบายให้กับทีม Dev ฟังใน Ceremony ของ Sprint Planning โดยทีม Development จะทำการ Planning Poker กัน เพื่อที่จะประเมินขนาดของงานที่จะพัฒนาใน Sprint นั้นๆ ได้ จากนั้นก็จะเริ่มเขียนโปรแกรมจนกระทั่งเสร็จงานทั้งหมดใน Sprint
ทีนี้จะมาถึงหน้าที่ของทีม QA ซึ่งมีหน้าที่ตรวจสอบคุณภาพว่า ทำงานได้ตรงตามที่ PO อยากได้หรือเปล่า โจทย์ 1 2 3 4 ที่หน้าจอจะต้องแสดงผลเป็นแบบนี้หรือเปล่า อะไรแบบนี้
สำหรับโปรเจกต์ Tokio Marine ทางทีมจะดูแลทั้งส่วน UX/UI และ Development แต่ในบางโปรเจค ทางลูกค้าจะออกแบบ UX/UI เอง ทำให้เมื่อ PO get requirement แล้วก็มาบรีฟงาน เพื่อให้ designer วาดหน้าจอออกมาให้เห็นภาพว่า UI ประมาณนี้ ต้องทำเป็น flow แบบนี้ ก่อนที่จะไปคุยกับ dev แล้วก็จะวนไปแบบนี้ทุก sprint
แม้ว่าการแบ่งงานจะฟังดูเหมือนราบรื่น จนทีมได้เริ่มพัฒนาระบบไปแล้ว แต่ทีมงานก็เจอกันความท้าทายอีกครั้ง นั่นก็คือ dependency ในส่วนของ Backend ที่ทีมไม่ได้พัฒนาเอง ซึ่งในส่วนนี้ทาง Tokio Marine ช่วยพัฒนา API ในส่วนของ Backend ให้ ในบางการประชุมอาจจะมีการสื่อสารกันไม่ชัดเจน ทำให้ API บางเส้น เมื่อทำออกมาแล้ว Frontend เรียกไปแล้วพบว่า มีการส่งค่าไม่ตรงกับที่จะนำมาใช้แสดงผล ก็ต้องมาคุยกันใหม่ เพื่อแก้ไขการรับส่งข้อมูลของ API ให้ใช้งานได้ นั่นก็ทำให้ ในบาง sprint ก็มีการดีเลย์กันออกไปบ้าง
ซึ่งพี่เก๋เล่าต่อว่า โปรเจกต์นี้ใช้ระยะเวลาทำกันจริง ๆ คือทำเป็น 2 ส่วน ช่วงแรก 3 เดือนโดยประมาณ แล้วก็มาทำต่ออีกช่วง ประมาณ 3 เดือน รวมแล้วก็อยู่ที่ประมาณ 5–6 เดือน กว่าจะปิดงานทุกอย่างจนเสร็จสิ้น
หลังปิดงานเรียบร้อยพี่เก๋พูดถึงความสำเร็จของโปรเจกต์นี้ให้ฟังว่า ระหว่างการทำงาน ก็มีความไม่เข้าใจกันในบางส่วน ที่ต้องปรับจูนกันในระหว่างที่ทำงานด้วยกัน แต่เมื่อเรา Delivery งานให้ในแต่ละ Sprint ลูกค้าเองก็พอใจกับการทำงานของทีมมาก ทั้งในมุมความละเอียดของ QA ที่ทดสอบระบบก่อนส่งมอบให้กับลูกค้าไปทำ UAT ซึ่งลูกค้าเจอบั๊กน้อยมาก ความเก่งในการเขียนโค้ดของ developer และการให้คำแนะนำที่ดีมาก รวมถึงทีมงานทุกคนในโปรเจกต์ที่ทุ่มเทมาก บาง Sprint ทุกคนอยู่ทำงานจนดึก เสาร์อาทิตย์ก็มาช่วย Test เพื่อจะได้ปิดงานให้เสร็จใน Sprint ซึ่งต้องให้เครดิตกับทุกคนในเรื่องของทีมเวิร์คที่ค่อนข้างแข็งแกร่ง
นอกจากนี้สิ่งที่พี่เก๋และทีมได้เรียนรู้ก็คือ การทำงานหลาย ๆ ฝ่าย ทีมเวิร์คค่อนข้างสำคัญมาก แม้จะเจอปัญหาค่อนข้างเยอะ แต่ถ้าทุกคนพร้อมช่วยเหลือและซัพพอร์ตกัน ก็ทำให้ทุกอย่างผ่านไปได้ด้วยดี รวมถึงการช่วยเหลือต่าง ๆ จากลูกค้าเองด้วย
สุดท้ายพี่เก๋ยังเน้นย้ำให้เราฟังอีกว่า “สไตล์การทำงานของแต่ละคนอาจจะไม่เหมือนกัน บางคนชอบทำงานแบบลุยเดี่ยว บางคนก็ชอบทำงานเป็นทีม แต่ส่วนตัวของพี่เก๋รู้สึกว่า การทำงานเป็นทีมอาจจะไม่ได้เร็วเหมือนเราทำงานคนเดียว แต่มันสนุกกว่า ได้แชร์ประสบการณ์ระหว่างกัน และอาจไปปลุกศักยภาพบางอย่างขึ้นมาอีกด้วย เช่น จริง ๆ แล้วเราไม่ได้ทำได้แค่งานตาม Role ของเรา แต่เรายังสามารถทำ function อื่นๆ ในทีมได้ด้วย นั่นทำให้เวลาทำงานเป็นทีมเราจะรู้ว่าจริง ๆ ศักยภาพของเรามีมากเกินกว่าที่เราคิดไว้ไปได้อีกเยอะเลย”
และนี่คือเรื่องราวทั้งหมดของโปรเจกต์ Tokio Marine ต้องบอกว่าพี่เก๋เล่าให้เราฟังแบบละเอียดมาก ๆ ตั้งแต่วันแรกที่เริ่มงาน ความท้าทายต่าง ๆ ที่เจอในโปรเจคต์นี้ รวมถึง วิธีการแก้ปัญหา การกระจายงานให้แต่ละทีม และการทำงานเป็นทีมเวิร์คเพื่อปิดงานให้ได้ วันนี้ต้องขอขอบคุณ พี่เก๋-นภาศรี Head of Product Owner มากจริง ๆ ครับ
เพื่อน ๆ ที่อ่านมาถึงตรงนี้ เรารับรองว่าต้องได้ประโยชน์ และสามารถเอาไปปรับใช้ได้ไม่มากก็น้อยแน่ ๆ ส่วนใครที่ชอบบทความนี้ ก็อย่าลืมคอมเมนต์มาบอกกันหน่อยนะครับ แล้วเจอกันใหม่บทความหน้าครับ ^^
