การศึกษา

วิทยาศาสตรมหาบัณฑิต (ระบบสารสนเทศ)
คณะสื่อสารมวลชลและสารสนเทศวีคิมวี มหาวิทยาลัยเทคโนโลยีนันยาง
สิงคโปร์
ปี 2558

วิทยาศาสตรบัณฑิต (วิทยาการคอมพิวเตอร์)
สถาบันเทคโนโลยีนานาชาติสิรินธร มหาวิทยาลัยธรรมศาสตร์
ประเทศไทย
ปี 2555

ประสบการณ์

ผู้นำทีมเทคนิคอล, ผู้จัดการโครงการ
Moolahgo, Irvins, Secretlab
สิงคโปร์
ปี 2561 - ปัจจุบัน

ที่ปรึกษาด้านเทคโนโลยีอิสระ
ฟรีแลนซ์
สิงคโปร์, กรุงเทพ
ปี 2567 - ปัจจุบัน

วิศวกรซอฟต์แวร์
Mobads, BuzzCity, DST
สิงคโปร์, กรุงเทพ
ปี 2555 - ปี 2560

ในฐานะ Scrum Master ผมมุ่งเน้นไปที่การปรับปรุงประสิทธิภาพการทำงานร่วมกันในทีม การขจัดอุปสรรคเชิงระบบ และการขยายขีดความสามารถของทีมข้ามสายงาน ในฐานะ Product Owner ผมดูแลให้มั่นใจว่าเราได้เพิ่มมูลค่าสูงสุดให้กับผลิตภัณฑ์ในทุก ๆ Sprint และเมื่อสวมหมวก Project Manager ผมจะบริหารสมดุลของสามเหลี่ยมการบริหารโครงการ (Project Management Triangle) โดยจัดสรรขอบเขต เวลา และต้นทุนให้สอดคล้องกัน เพื่อส่งมอบผลลัพธ์ที่คาดการณ์ได้ให้แก่ผู้มีส่วนได้ส่วนเสีย วิศวกร และลูกค้า ผมเชื่อมั่นอย่างยิ่งว่าผลงานที่ยอดเยี่ยมไม่ควรต้องแลกมาด้วยความยั่งยืนของทีม ผมจึงเข้ามาจัดการขอบเขตของงานอย่างจริงจังเพื่อป้องกันปัญหาขอบเขตงานขยายวงกว้าง (Scope Creep) และขจัดความเร่งรีบที่ไม่มีอยู่จริง เป้าหมายสูงสุดของผมคือการสร้างสภาพแวดล้อมที่ทีมสามารถส่งมอบผลิตภัณฑ์ที่สร้างผลกระทบสูงได้อย่างสม่ำเสมอ โดยปราศจากภาวะหมดไฟ (Burnout)

กรณีศึกษา

  1  

จากความโกลาหลสู่ความชัดเจน – การวางระบบธรรมาภิบาลแบบ Agile

ความท้าทาย

องค์กรต้องเผชิญกับอุปสรรคในการส่งมอบงานอย่างรุนแรง ซึ่งมีสาเหตุมาจากการขาดการจัดตารางเวลาที่เป็นระบบและการเริ่มโครงการก่อนเวลาอันควร ยิ่งไปกว่านั้น การที่ข้อกำหนดของงาน (Requirements) ไม่นิ่ง ทำให้ทีมต้องปรับเปลี่ยนแผนงานกลางคันอยู่ตลอดเวลาระหว่างทำ Sprint นำไปสู่ปัญหาขอบเขตงานขยายวงกว้างเรื้อรัง (Scope Creep) และพลาดเป้าหมายสำคัญ และเนื่องจากข้อบกพร่องเชิงโครงสร้างเหล่านี้ไม่ถูกมองเห็น เหล่านักพัฒนาจึงตกเป็นแพะรับบาปสำหรับความล่าช้าในการส่งมอบงานที่เป็นปัญหาเชิงระบบ ซึ่งทำลายขวัญและกำลังใจของทีมเป็นอย่างมาก

แนวทางการแก้ไข

• วางระบบธรรมาภิบาลที่มีโครงสร้างชัดเจน: นำลำดับขั้นตอนที่เข้มงวดของ Scrum Events เข้ามาใช้เพื่อจัดระเบียบและสร้างความเสถียรให้กับ Delivery Pipeline สร้างตารางเวลาที่คาดการณ์ได้ และขจัดความคลุมเครือในแต่ละวันให้หมดไป
• บ่มเพาะความรับผิดชอบในงานวิศวกรรม: ขับเคลื่อนการเปลี่ยนแปลงโดยยึดหลักคุณค่าหลักของ Scrum (Scrum Values) ได้แก่ Commitment, Openness, Focus, Respect และ Courage โดยเปลี่ยนวัฒนธรรมของทีมจากการทำงานตามสั่งแบบตั้งรับ (Passive) ไปสู่การเป็นเจ้าของงานร่วมกันอย่างแท้จริง (True Ownership)
• จัดการขอบเขตงานอย่างจริงจัง: บังคับใช้กรอบการเจรจาต่อรองที่เข้มงวดเมื่อมีข้อกำหนดใหม่ ๆ เข้ามา โดยฟีเจอร์ใหม่ ๆ จะได้รับการต้อนรับเข้าสู่ Product Backlog แต่จะถูกสั่งห้ามไม่ให้รบกวน Sprint Goals ที่กำลังดำเนินอยู่โดยเด็ดขาด เว้นแต่จะมีการแลกเปลี่ยนและเอาขอบเขตงานเดิมที่เท่ากันออกไปก่อน

ผลลัพธ์ที่เกิดขึ้น

• ขจัดความคลุมเครือในการทำงาน: นักพัฒนามีความชัดเจน 100% ในลำดับความสำคัญของงานที่จะเกิดขึ้น ซึ่งช่วยลดการสลับบริบทการทำงาน (Context-switching) และลดความอึดอัดใจในการปฏิบัติงานลงได้อย่างมหาศาล
• สร้างความเสถียรให้กับ Delivery Pipeline: เปลี่ยนปัญหาขอบเขตงานงอก (Scope Creep) จากความเสี่ยงที่สร้างความเสียหาย ให้กลายเป็นกระบวนการเจรจาต่อรองที่โปร่งใสและจัดการได้ ซึ่งช่วยปกป้องความสมบูรณ์ของรอบการ Release งาน
• บรรลุความเร็วที่คาดการณ์ได้ (Predictable Velocity): ด้วยการปกป้อง Sprint Goals จากความผันผวนภายนอก ทีมงานจึงสามารถส่งมอบงานได้ตามกำหนดอย่างสม่ำเสมอและทำให้ไทม์ไลน์ของโครงการมีความเสถียร

  2  

สยบข้อกำหนดที่ซับซ้อน – การจัดสถาปัตยกรรมและการปรับต้นทุนให้เหมาะสม

ความท้าทาย

แพลตฟอร์มประสบปัญหาประสิทธิภาพลดลงอย่างรุนแรงและระบบล่มรายวัน ซึ่งเกิดจากความไม่สอดคล้องกันระหว่างความต้องการทางธุรกิจและข้อจำกัดทางเทคนิค ผู้มีส่วนได้ส่วนเสียฝั่งที่ไม่ใช่เทคนิค (Non-technical stakeholders) มักจะร้องขอฟีเจอร์แบบเรียลไทม์ (Synchronous Real-time) ที่ไม่สามารถทำได้จริงในทางปฏิบัติ ซึ่งเข้าไปกลืนกินทรัพยากรของระบบ การทำงานหนักเกินไปเชิงโครงสร้างนี้ส่งผลให้ระบบไม่เสถียรเรื้อรัง กระทบต่อการดำเนินงานที่สำคัญของคลังสินค้า และทำให้ค่าใช้จ่ายด้านโครงสร้างพื้นฐานเซิร์ฟเวอร์พุ่งสูงขึ้นอย่างรวดเร็วเนื่องจากรูปแบบการประมวลผลที่ไม่มีประสิทธิภาพ

แนวทางการแก้ไข

• ออกแบบสถาปัตยกรรมแบบ Async Decoupling: เป็นผู้นำในการปรับโครงสร้างสถาปัตยกรรมระบบ (Refactoring) โดยตัดการพึ่งพาแบบซิงโครนัสเรียลไทม์ที่ไม่จำเป็นออกไป และบังคับใช้การประมวลผลแบบอะซิงโครนัส (Asynchronous Processing) สำหรับการทำงานที่กินทรัพยากรสูง
• ปรับปรุงอัลกอริทึมหลักให้มีประสิทธิภาพสูงสุด: กำกับดูแลการแก้ไขทางวิศวกรรมอย่างตรงจุดเพื่อปรับปรุงโครงสร้างข้อมูลระบบเดิม (Legacy Data Structures) และอัลกอริทึมการประมวลผล ซึ่งช่วยยกระดับ System Throughput, Scalability และความเสถียรขั้นพื้นฐานของระบบได้อย่างแท้จริง
• วางระบบธรรมาภิบาลร่วมกันข้ามสายงาน: นำกรอบการทบทวนข้อกำหนดอย่างต่อเนื่องร่วมกับทีมธุรกิจมาใช้ เพื่อให้ความรู้แก่ผู้มีส่วนได้ส่วนเสียเกี่ยวกับขอบเขตทางเทคนิค และดูแลให้มั่นใจว่าการขอฟีเจอร์ทั้งหมดขับเคลื่อนด้วยมูลค่าทางธุรกิจและมีความเป็นไปได้ในเชิงสถาปัตยกรรม
• ดำเนินการคัดแยกและแก้ไขปัญหาแบบตรงจุด (Targeted Triage): สร้างความเสถียรให้กับระบบโปรดักชันอย่างเร่งด่วน โดยการนำวิธีการคัดแยกปัญหาแบบเดี่ยว (Single-issue Triage) ที่เข้มงวดมาใช้ เพื่อกำจัดจุดที่ระบบล้มเหลวอย่างเป็นระบบโดยไม่เพิ่มความเสี่ยงให้ระบบถดถอย (Regression Risks)

ผลลัพธ์ที่เกิดขึ้น

• กู้คืนความสมบูรณ์ของระบบ: เปลี่ยนสภาพแวดล้อมที่ผันผวนให้กลายเป็นโครงสร้างพื้นฐานที่มีความเสถียรสูง ขจัดปัญหาระบบล่มรายวันได้อย่างสิ้นเชิง และเพิ่มความเร็วของแพลตฟอร์มได้อย่างมหาศาล
• ลดค่าใช้จ่ายโครงสร้างพื้นฐานลงครึ่งหนึ่ง: ลดต้นทุนการดำเนินงานของเซิร์ฟเวอร์ลงได้ถึง 50% ส่งผลให้บริษัทประหยัดค่าใช้จ่ายได้อย่างรวดเร็วและต่อเนื่องในระยะยาว
• เพิ่มความเร็วในการดำเนินงาน: ยกระดับความพึงพอใจของผู้ใช้ปลายทางได้อย่างดีเยี่ยมด้วยการปรับปรุงแพลตฟอร์มให้คล่องตัว ซึ่งช่วยให้ระบบโลจิสติกส์ในคลังสินค้าทำงานได้รวดเร็วและไร้แรงเสียดทานโดยตรง

  3  

ปรับปรุงโครงสร้างพื้นฐานเพื่อการรองรับที่แท้จริง – ทลายกำแพงการสื่อสารข้ามสายงาน

ความท้าทาย

การขาดการเชื่อมต่อด้านการสื่อสารที่สำคัญระหว่างทีม Business Intelligence (BI) และทีมวิศวกรรม นำไปสู่ความล้มเหลวครั้งใหญ่ของระบบโปรดักชันในระหว่างการเปิดตัวผลิตภัณฑ์ที่มีชื่อเสียง ข้อมูลการตลาดเกี่ยวกับยอดทราฟฟิกมหาศาลที่กำลังจะเกิดขึ้น (ซึ่งขับเคลื่อนโดยแคมเปญแฟรนไชส์ขนาดใหญ่) ไม่เคยถูกส่งต่อให้กับทีมเทคนิคเลย ส่งผลให้ทีมวิศวกรรมมุ่งเน้นการปรับแต่งประสิทธิภาพ (Optimize) เฉพาะในระดับซอร์สโค้ดเท่านั้น โดยไม่ได้ขยายโครงสร้างพื้นฐาน (Infrastructure) รองรับ เมื่อเปิดตัวจริง ทราฟฟิกของผู้ใช้ที่เข้ามาพร้อมกันเป็นประวัติการณ์ได้ทะลักเข้าท่วมเครือข่าย ส่งผลให้เซิร์ฟเวอร์ล่มอย่างต่อเนื่อง แม้ว่าโค้ดจะประมวลผลได้อย่างมีประสิทธิภาพสูงก็ตาม

แนวทางการแก้ไข

• วางสถาปัตยกรรม Cloud Auto-Scaling: เป็นผู้นำในการยกระดับสถาปัตยกรรมการ Deployment ให้ทันสมัย โดยนำ AWS Elastic Beanstalk มาใช้เพื่อจัดการกับความผันผวนของทราฟฟิกสูงแบบไดนามิก และรับประกันความพร้อมใช้งานสูง (High Availability) สำหรับแอปพลิเคชันฝั่งที่ลูกค้าใช้งาน
• แยกสภาพแวดล้อมของระบบออกจากกัน (Decoupled Environments): ลดความเสี่ยงเชิงสถาปัตยกรรมโดยการแยกส่วนระบบปฏิบัติการภายในไว้บน Amazon EC2 อินสแตนซ์ที่กำหนดไว้โดยเฉพาะ เพื่อให้มั่นใจว่าฟังก์ชันทางธุรกิจหลักจะไม่ได้รับผลกระทบจากยอดทราฟฟิกภายนอกที่พุ่งสูงขึ้นในส่วนหน้าบ้าน
• วางระบบ DevOps Governance เฉพาะด้าน: ดึงผู้เชี่ยวชาญด้านวิศวกรรมโครงสร้างพื้นฐานเข้ามาออกแบบระบบตรวจสอบเชิงรุก (Proactive Monitoring), การวางแผนกำลังการรองรับ (Capacity Planning) และแบบจำลองแนวโน้มภาระงานของระบบล่วงหน้า (Predictive System-load Trending)
• ให้ความรู้แก่ผู้มีส่วนได้ส่วนเสียระดับบริหาร: ใช้การวิเคราะห์หลังเกิดเหตุ (Post-mortem Analysis) เพื่อชี้ให้เห็นถึงความเชื่อมโยงที่สำคัญระหว่างการลงทุนในโครงสร้างพื้นฐานและความต่อเนื่องของธุรกิจ จนสามารถได้รับการอนุมัติและงบประมาณระยะยาวสำหรับโครงสร้างพื้นฐานคลาวด์จากผู้บริหารได้สำเร็จ

ผลลัพธ์ที่เกิดขึ้น

• ขจัดจุดที่ทำให้ระบบล่มทั้งระบบ (Single Points of Failure): ประสบความสำเร็จในการป้องกันไม่ให้เกิดปัญหาระบบล่มจากทราฟฟิกซ้ำอีก สร้างประสบการณ์ดิจิทัลที่ราบรื่นและเชื่อถือได้ให้กับผู้ใช้ปลายทาง
• ระบบจัดการความผันผวนแบบยืดหยุ่นอัตโนมัติ: ช่วยให้แพลตฟอร์มสามารถขยายทรัพยากรการคำนวณ (Compute Resources) ได้โดยอัตโนมัติล่วงหน้าก่อนที่ทราฟฟิกจะพุ่งสูง ช่วยลดความเสี่ยงจากการจัดแคมเปญในอนาคต
• ได้รับความไว้วางใจเชิงกลยุทธ์ในโครงสร้างพื้นฐาน: พลิกโฉมวัฒนธรรมองค์กรโดยการปิดช่องว่างระหว่างการวางแผนการตลาดและการเตรียมพร้อมทางวิศวกรรมอย่างถาวร เพื่อให้มั่นใจว่าการเปิดตัวผลิตภัณฑ์ทั้งหมดในอนาคตจะได้รับการสนับสนุนจากการวางแผนกำลังการรองรับที่สอดคล้องกัน

การเสริมสร้างศักยภาพของทีมเพื่อความเป็นเลิศที่ยั่งยืน

ผู้นำที่แท้จริงคือการปลดล็อกศักยภาพผ่านการปูรากฐานระบบที่ดี ในฐานะผู้จัดการโครงการ ผมบริหารงานด้วย Project Management Triangle เข้าใจ และดูแลข้อจำกัดต่างๆ ทั้งในเรื่องของเวลา ทรัพยากร และขอบเขตงาน เพื่อสร้างสภาพแวดล้อมทางวิศวกรรมที่คาดการณ์ผลลัพธ์ได้ ในฐานะ Scrum Master ผมปกป้องโฟกัสของทีม ขจัดอุปสรรคเชิงระบบ และสนับสนุนหลักการ Agile เพื่อเพิ่มความเร็วในการส่งมอบงานอย่างมั่นคง ในขณะเดียวกัน ในฐานะ Product Owner ผมเพิ่มมูลค่าผลิตภัณฑ์สูงสุดในแต่ละ Sprint โดยดูแลให้เหล่านักพัฒนาทำงานบนความชัดเจนสูงสุดของข้อกำหนด (Requirements) เป้าหมายสูงสุดของผมคือการลดแรงเสียดทานและบ่มเพาะทีมที่มีความยืดหยุ่นและสามารถจัดการตนเองได้ (Self-organizing) เพื่อส่งมอบความเป็นเลิศทางวิศวกรรมที่สร้างผลกระทบเชิงบวกในวงกว้าง