สวัสดีปีใหม่ 2569 รายงานตัวประจำวันพฤหัสบดีที่ 1 มกราคม 2569 ครับ ขอต้อนรับเข้าสู่ศักราชใหม่ และขอต้อนรับสู่ ตอนที่ 21 อย่างเป็นทางการครับ! ในปีที่ผ่านมา (Ep.20) เราได้เห็นบทบาทใหม่ของ สสท.ทร. ที่ผันตัวเป็น “ผู้กำกับดูแล” (Regulator) ไปแล้ว
แต่การจะสร้างนวัตกรรมระดับเปลี่ยนโลก (หรือเปลี่ยนกองทัพ) ลำพังแค่คนคุมกฎกับคนทำงานแยกกันอยู่คนละตึก มันไม่พอครับ วันนี้ AdminTee จะพาไปดูโมเดลการทำงานแบบใหม่ที่เรียกว่า Cross-Functional Team หรือการจับเอา “เทพ” จากต่างสาขา มานั่งสุมหัวอยู่ในห้องเดียวกันเหมือนทีม Avengers เพื่อพิชิตภารกิจสร้าง Open ERP ให้สำเร็จ มันจะว้าวแค่ไหน? และจะแก้ปัญหา “คุยกันไม่รู้เรื่อง” ได้อย่างไร? มาเปิดศักราชใหม่ไปด้วยกันครับ
บทที่ 3: ยุทธศาสตร์การพัฒนาแบบมีส่วนร่วม (Co-Creation Strategy)
จุดประสงค์: แก้ปัญหา Bias และดึงเจ้าของงาน (Users) มาเป็นผู้ร่วมสร้าง
ตอนที่ 21/80: การจัดตั้งคณะทำงานร่วม (Cross-Functional Team): IT + Business Units
ในอดีต การพัฒนาระบบมักทำแบบ “วิ่งผลัด” (Relay Race) คือ ฝ่ายยุทธการเขียนโจทย์ -> ส่งไม้ต่อให้ไอทีไปทำ -> ไอทีทำเสร็จส่งกลับมา -> ยุทธการบอกว่าผิด -> ส่งกลับไปแก้วนไปวนมา เสียเวลาเป็นปี
โมเดลใหม่ที่เราจะใช้คือ “รักบี้” (Scrum Team) ครับ คือทุกคนทั้งฝ่ายไอทีและเจ้าของงาน วิ่งไปพร้อมกัน รุมแย่งลูก (แก้ปัญหา) ด้วยกันในสนาม (War Room) เดียวกัน
1. ส่วนผสมของทีม Avengers (The Dream Team Composition)
- เจ้าของเรื่อง (Business Owner/Domain Expert): คือนายทหารจากหน่วยงานนั้นๆ (เช่น กรมพลาธิการ) ผู้รู้ลึกรู้จริงว่า “กระสุนปืนใหญ่เบิกอย่างไร?” หรือ “ระเบียบจ่ายเงินเป็นอย่างไร?” คนนี้คือ “สมอง” ของทีม
- พ่อมดไอที (Tech Wizard/Developer): คือทีม Dev จาก กสทจ.สปช.ทร. หรือ Citizen Developer ประจำหน่วย ผู้รู้ว่าจะเสก Odoo ให้ทำงานตามที่สมองสั่งได้อย่างไร คนนี้คือ “แขนขา” ของทีม
- ล่ามแปลภาษา (Facilitator/Business Analyst): คนกลางที่ช่วยแปลภาษาทหารเป็นภาษาคอมพิวเตอร์ และคอยไกล่เกลี่ยเมื่อความต้องการของ User ขัดแย้งกับข้อจำกัดทางเทคนิค
2. ตัวอย่างสถานการณ์จริง: ปฏิบัติการสร้าง “ระบบเบิกจ่ายน้ำมันเชื้อเพลิง”
- แบบเดิม (แยกกันทำ): จ่าเอกฝ่ายน้ำมัน เขียนความต้องการ 10 หน้ากระดาษส่งให้โปรแกรมเมอร์ อีก 3 เดือนโปรแกรมเมอร์ส่งระบบมาให้ จ่าเอกลองใช้แล้วบอกว่า “ไม่ใช่แบบนี้ครับ ขั้นตอนการตวงวัดมันผิด”
- แบบ Cross-Functional:
- จ่าเอกฝ่ายน้ำมัน นั่งข้างๆ โปรแกรมเมอร์ ในห้อง War Room
- จ่าเอก: “ปกติผมต้องเช็คค่าความถ่วงจำเพาะก่อนเซ็นรับนะ”
- โปรแกรมเมอร์: “งั้นผมเพิ่มช่อง ‘ค่าความถ่วงจำเพาะ’ ให้เลยครับ แบบนี้ถูกไหม?” (หันหน้าจอให้ดูทันที)
- จ่าเอก: “ใช่เลย! แต่ขอตัวหนังสือใหญ่กว่านี้หน่อย”
- ผลลัพธ์: งานที่เคยใช้เวลาแก้ 3 เดือน เสร็จภายใน 3 นาที เพราะ Feedback Loop สั้นที่สุด
3. ข้อจำกัดและอุปสรรค (The Silo Wall)
- กำแพงสังกัด: วัฒนธรรมทหารเรายึดติดกับ “สังกัด” การจะขอยืมตัวนายทหารจากกรมอื่นมานั่งทำงานข้ามกรม เป็นเรื่องยากในทางธุรการ (คำสั่งช่วยราชการ)
- เวลาไม่ตรงกัน: ฝ่าย Business (เจ้าของงาน) มักมีภารกิจประจำที่รัดตัว (เข้าเวร, ประชุม, ออกราชการ) ทำให้หาเวลามานั่งกับฝ่าย IT ยาก
4. ข้อแนะนำและข้อเสนอแนะ (Recommendations)
- ตั้ง War Room (เฉพาะกิจ): ควรมีห้องปฏิบัติการกลาง (Physical หรือ Virtual) ที่ให้ทีม Cross-Functional มาเจอกันอย่างน้อยสัปดาห์ละ 2 วัน (Co-Location) เพื่อเร่งงานสำคัญ
- เป้าหมายร่วม (Shared OKRs): ต้องตั้งเป้าหมายความสำเร็จร่วมกัน ไม่ใช่ “ไอทีส่งงานแล้วจบ” แต่ต้องเป็น “ไอทีและ User ทำอย่างไรให้การเบิกน้ำมันลดเวลาลง 50%” ถ้าทำไม่ได้ถือว่า “ตก” ทั้งคู่
- อำนาจการตัดสินใจ: หัวหน้าทีม Cross-Functional ต้องได้รับดาบอาญาสิทธิ์จากผู้บังคับบัญชา ให้ตัดสินใจหน้างานได้เลย ไม่ต้องรอทำหนังสือขออนุมัติทุกขั้นตอน
บทสรุป
การจัดตั้ง Cross-Functional Team คือหัวใจสำคัญของการทำ Co-Creation ครับ มันคือการทลายกำแพงที่มองไม่เห็นระหว่าง “คนไอที” และ “คนทำงาน”
เมื่อเรานำความเชี่ยวชาญทางทหาร (Military Expertise) มาผสานกับความเชี่ยวชาญทางเทคโนโลยี (Digital Expertise) อย่างแนบแน่น ผลลัพธ์ที่ได้จะไม่ใช่แค่ซอฟต์แวร์ Odoo ธรรมดา แต่จะเป็น “อาวุธทางปัญญา” ที่ทรงประสิทธิภาพ ที่ถูกสร้างขึ้นมาเพื่อทหารเรือ โดยทหารเรือ และเพื่อภารกิจของกองทัพเรืออย่างแท้จริงครับ
(อ้างอิง: หลักการ Agile Scrum Team และ คู่มือการบริหารจัดการภาครัฐแนวใหม่)
คำถามชวนคิด
- ท่านเคยต้องรอฝ่ายไอทีแก้โปรแกรม แล้วรู้สึกว่า “ถ้าฉันทำเองได้ ฉันแก้เสร็จไปนานแล้ว” หรือไม่?
- ท่านคิดว่าในหน่วยงานของท่าน มีใครที่เป็น “กูรู” รู้ลึกรู้จริงในงานนั้นๆ ที่ควรถูกส่งตัวมาเป็นตัวแทนในทีมพัฒนามากที่สุด?
- ถ้ามีการจัดตั้งทีมเฉพาะกิจแบบนี้ ท่านพร้อมจะสละเวลาสัปดาห์ละ 2 วัน เพื่อมาร่วมสร้างระบบที่จะทำให้ชีวิตท่านสบายขึ้นในอนาคตหรือไม่?
ติดตามตอนต่อไป
เมื่อทีมพร้อม คนพร้อม แต่ถ้าวิธีการทำงานยัง “อืดอาด” เหมือนเดิม งานก็ไม่เดิน ในโลกยุคใหม่ “ปลาเร็วกินปลาช้า” ครับ! ในตอนหน้า Ep.22/80 “Agile Methodology ในบริบททหาร: ปรับตัวเร็ว ส่งมอบไว แก้ไขทันที” เราจะมาดูว่า วิธีการทำงานแบบ Agile ที่สตาร์ทอัพทั่วโลกใช้ จะเอามาปรับใช้ในองค์กรทหารที่เคร่งครัดระเบียบวินัยได้อย่างไร? ห้ามพลาดครับ!
ขอให้พลังสถิตอยู่กับท่าน
May the Force be with you