รายงานตัวประจำวันศุกร์ที่ 2 มกราคม 2569 ครับ เริ่มต้นปีใหม่มาได้ 2 วันแล้ว ไฟในการทำงานยังลุกโชนอยู่ไหมครับ? ในตอนที่แล้ว (Ep.21) เราได้จัดตั้งทีม Avengers (Cross-Functional Team) ที่รวมคนเก่งจากทุกหน่วยมารวมตัวกันแล้ว
แต่วันนี้ AdminTee มีคำถามครับ… ถ้าเรามีทีมฟุตบอลระดับโลก แต่โค้ชสั่งให้ “ห้ามส่งลูก ห้ามเลี้ยงหลบ ให้วิ่งตรงไปข้างหน้าอย่างเดียว” ทีมนั้นจะชนะไหมครับ? คงยากใช่ไหมครับ การพัฒนาระบบก็เช่นกัน ต่อให้ทีมดีแค่ไหน ถ้าใช้วิธีการทำงานแบบเดิมที่อุ้ยอ้าย (Waterfall) งานก็ไม่เดิน วันนี้เราจะมาเรียนรู้ยุทธวิธีใหม่ที่เรียกว่า Agile Methodology หรือการทำงานที่ “ปรับตัวเร็ว ส่งมอบไว แก้ไขทันที” ซึ่งเหมาะมากกับโลกยุค AI และ Odoo ของเราครับ!
บทที่ 3: ยุทธศาสตร์การพัฒนาแบบมีส่วนร่วม (Co-Creation Strategy)
จุดประสงค์: แก้ปัญหา Bias และดึงเจ้าของงาน (Users) มาเป็นผู้ร่วมสร้าง
ตอนที่ 22/80: Agile Methodology ในบริบททหาร: ปรับตัวเร็ว ส่งมอบไว แก้ไขทันที
ในวงการทหาร เราคุ้นเคยกับการวางแผนยุทธการที่รัดกุม (Military Doctrine) แต่ในโลกซอฟต์แวร์ การวางแผนยาวเหยียด 1 ปีแล้วค่อยลงมือทำ อาจหมายถึงความล้มเหลว เพราะเทคโนโลยีเปลี่ยนทุกวัน Agile จึงเปรียบเสมือนการส่ง “หน่วยรบพิเศษ” ที่เคลื่อนที่เร็ว ปรับแผนหน้างานได้ตามสถานการณ์ข้าศึก
1. เปรียบเทียบชัดๆ: ยุทธวิธีเรือบรรทุกเครื่องบิน (Waterfall) vs เรือเร็วตรวจการณ์ (Agile)
- Waterfall (แบบเดิม): วางแผน 3 เดือน -> เขียนโค้ด 6 เดือน -> ทดสอบ 3 เดือน -> ปล่อยใช้งาน (รวม 1 ปี)
- ความเสี่ยง: ถ้าทำเสร็จแล้ว User บอกว่า “ไม่ชอบ” หรือ “ไม่ตอบโจทย์” เท่ากับเสียเวลาฟรี 1 ปี แก้ไขยากเพราะสร้างเสร็จไปแล้ว
- Agile (แบบใหม่): แบ่งงานเป็นรอบสั้นๆ (Sprints) รอบละ 2 สัปดาห์
- Sprint 1: ทำฟอร์มกรอกข้อมูลเสร็จ -> ให้ User ลองกด -> User บอก “ตัวหนังสือเล็กไป” -> แก้ทันที
- Sprint 2: ทำระบบอนุมัติเสร็จ -> ให้ User ลองใช้ -> User บอก “ขั้นตอนผิด” -> แก้ทันที
- ผลลัพธ์: เราได้ซอฟต์แวร์ที่ใช้งานได้จริง (Working Software) ออกมาให้เห็นทุกๆ 2 สัปดาห์ ไม่ต้องรอนาน
1. ตัวอย่างสถานการณ์จริง: การสร้าง “ระบบจองบ้านพักข้าราชการ” ด้วย Odoo
- สัปดาห์ที่ 1-2 (MVP – Minimum Viable Product): ทีมพัฒนาสร้างระบบจองง่ายๆ แค่ “เลือกบ้าน-กดจอง” ให้กำลังพลทดลองใช้
- Feedback: กำลังพลแจ้งว่า “ดูไม่ออกว่าบ้านไหนว่าง หรือบ้านไหนซ่อมแซมอยู่”
- สัปดาห์ที่ 3-4 (Improvement): ทีมงานรีบเพิ่ม “สถานะสี” (เขียว=ว่าง, แดง=เต็ม, เหลือง=ซ่อม) ลงไปทันทีตามคำขอ
- ผลลัพธ์: ระบบถูกใจผู้ใช้งาน เพราะสร้างมาจากสิ่งที่เขาต้องการจริงๆ ไม่ใช่สิ่งที่คนสร้างนั่งเทียนคิดเอง
2. ข้อจำกัดและอุปสรรคในระบบราชการ (The Military Constraints)
- กับดัก TOR (Terms of Reference): การจัดซื้อจัดจ้างภาครัฐมักระบุสเปกละเอียดเป๊ะๆ ตั้งแต่วันแรก ห้ามเปลี่ยน แต่ Agile คือการ “ยอมรับการเปลี่ยนแปลง” ทำให้ขัดกับระเบียบพัสดุ
- ลำดับชั้นการบังคับบัญชา (Hierarchy): Agile เน้นความเท่าเทียมในทีม (Flat Team) เพื่อให้กล้าเสนอแนะ แต่ในบริบททหาร ทหารยศน้อยอาจไม่กล้าแย้งนายทหารชั้นผู้ใหญ่ในที่ประชุมสรุปงาน
3. ข้อแนะนำและข้อเสนอแนะ: ประยุกต์ใช้แบบ “กึ่งทหารกึ่งเอกชน” (Hybrid Model)
- ซอยเป้าหมายย่อย: ในเอกสารโครงการ ให้กำหนดเป้าหมายกว้างๆ แต่ในทางปฏิบัติ ให้แบ่งส่งมอบงานเป็นงวดเล็กๆ (Milestone) เพื่อให้แก้ไขได้ทันท่วงที
- Morning Brief (Stand-up Meeting): ทุกเช้า 15 นาที ให้ทีมงานยืนคุยกันหน้ากระดานงาน (Kanban Board) ว่า “เมื่อวานทำอะไร? วันนี้จะทำอะไร? ติดปัญหาอะไร?” เพื่อให้หัวหน้าทีมแก้ปัญหาให้ทันที ไม่ต้องรอประชุมประจำเดือน
- Fail Fast, Learn Faster: สร้างวัฒนธรรมว่า “การเจอข้อผิดพลาดในห้องทดลอง คือเรื่องดี” ยิ่งเจอเร็วยิ่งแก้ถูก ดีกว่าไปเจอตอนรบจริง
บทสรุป
Agile Methodology ไม่ใช่การทำงานแบบไร้ระเบียบ แต่คือการมีระเบียบวินัยในการ “ตรวจสอบและปรับปรุงตัวเอง” อย่างสม่ำเสมอ
กองทัพเรือยุคใหม่ภายใต้แนวคิด Open ERP ต้องมีความคล่องตัวเหมือนสายน้ำ เราจะไม่รอสร้างเรือรบที่สมบูรณ์แบบที่สุดในกระดาษ แต่เราจะลงมือต่อเรือ แล้วนำลงน้ำทดสอบ พัฒนา และปรับปรุงไปเรื่อยๆ จนกว่าจะได้เรือที่แข็งแกร่งที่สุดและใช้งานได้จริงในสนามรบครับ
(อ้างอิง: The Scrum Guide และ บทความ Agile in Public Sector โดย DGA)
คำถามชวนคิด (เพื่อการมีส่วนร่วม)
- ท่านเคยเจอปัญหา “โครงการไอทีที่รอกันมา 2 ปี พอได้ใช้จริงกลับล้าสมัยไปแล้ว” หรือไม่?
- ท่านชอบแบบไหนมากกว่า? ระหว่าง “รอ 1 ปี ได้ระบบเต็มรูปแบบ (แต่ไม่รู้ว่าจะถูกใจไหม)” หรือ “รอ 2 สัปดาห์ ได้ลองเล่นระบบเบื้องต้น แล้วช่วยบอกให้แก้ได้”?
- ในหน่วยงานของท่าน มีการประชุมตอนเช้าสั้นๆ (Morning Brief) เพื่ออัปเดตงานกันบ้างไหมครับ?
ติดตามตอนต่อไป
เมื่อเราทำงานเร็วขึ้น (Agile) และมีคนทำหลายกลุ่ม (Decentralized) ปัญหาใหม่ที่จะตามมาคือ “มาตรฐานโค้ดไม่เหมือนกัน” จะทำอย่างไรให้โค้ดของกรม ก. กับ กรม ข. เอามาประกอบร่างกันได้? ในตอนหน้า Ep.23/80 “การสร้าง Standard Framework: เพื่อให้ Module ของแต่ละหน่วยมาประกอบร่างกันได้” เราจะมาดู “แม่พิมพ์กลาง” ที่จะทำให้งานของทุกคนเข้าล็อกกันพอดี ห้ามพลาดครับ!
ขอให้พลังสถิตอยู่กับท่าน
May the Force be with you