ส่วนที่ 3: ยุทธศาสตร์การพัฒนาแบบมีส่วนร่วม (Co-Creation Strategy) อย่างเป็นทางการครับ!
หลังจากในส่วนที่ 1 และ 2 เราได้ปูพื้นฐานเรื่องปัญหา (Pain Points), เครื่องมือ (Odoo), และกฎกติกา (Governance) กันไปแล้ว ตอนนี้เรามี “อิฐและปูน” ชั้นดีกองอยู่เต็มไปหมด แต่คำถามสำคัญคือ “เราจะสร้างบ้านหลังนี้อย่างไรให้คนอยู่อาศัยมีความสุข?”
ในอดีต โครงการไอทีหลายร้อยล้านมักล้มเหลว ไม่ใช่เพราะเทคโนโลยีไม่ดี แต่เพราะเราติดอยู่ในกับดักที่เรียกว่า “Centralized Development” หรือการพัฒนาแบบรวมศูนย์ วันนี้ใน ตอนที่ 17 เราจะมาแฉความจริงอันเจ็บปวดว่า ทำไมวิธีการเดิมๆ ถึงทำให้เกิดประโยคยอดฮิตที่ว่า “คนออกแบบไม่เคยใช้ คนใช้ไม่เคยได้ออกแบบ” ครับ
ส่วนที่ 3: ยุทธศาสตร์การพัฒนาแบบมีส่วนร่วม (Co-Creation Strategy)
จุดประสงค์: แก้ปัญหา Bias และดึงเจ้าของงาน (Users) มาเป็นผู้ร่วมสร้าง
ตอนที่ 17/80: กับดักการพัฒนาแบบรวมศูนย์: ทำไมคนทำไม่ได้ใช้ คนใช้ไม่ได้ทำ
การพัฒนาแบบรวมศูนย์ (Centralized) เปรียบเสมือนการสั่งตัดชุดสูท โดยที่ช่างตัดเสื้อ (Programmer) นั่งเทียนตัดชุดอยู่ในห้องแอร์ โดยไม่เคยออกมาวัดตัวลูกค้า (User) ที่ยืนตากแดดอยู่ ผลลัพธ์คือได้ชุดที่สวยหรูแต่ “ใส่ไม่ได้” หรือ “คับจนหายใจไม่ออก”
1. จาะลึกสถานการณ์จริง: โศกนาฏกรรมของความหวังดี (The Tragedy of Good Intentions)
- เหตุการณ์สมมติ (ที่คุ้นเคย): กรม A ต้องการระบบลางาน จึงจ้างโปรแกรมเมอร์ (หรือให้ฝ่าย IT ส่วนกลาง) พัฒนาให้
- กระบวนการ: โปรแกรมเมอร์คิดเองว่า “การลางานก็แค่ กรอกวัน-กดส่ง-จบ” จึงสร้างระบบง่ายๆ ขึ้นมา
- ความจริงหน้างาน: ทหารเรือมี “การลา” ที่ซับซ้อนกว่านั้น เช่น ลาบวช, ลาไปต่างประเทศ, ลาพักผ่อนที่ต้องสะสมวันลาได้, การลาของนักเรียนทหาร ฯลฯ
- ผลลัพธ์: เมื่อระบบเสร็จและบังคับใช้ ผู้ใช้งานพบว่า “ไม่มีปุ่มสำหรับลาไปราชการต่างประเทศ” สุดท้ายก็ต้องกลับมาเขียนกระดาษเหมือนเดิม ระบบที่สร้างมาก็กลายเป็นขยะ
2. สาเหตุของปัญหา: กำแพง 3 ชั้น (The 3 Barriers)
- กำแพงภาษา (Language Barrier): ฝ่าย IT พูดภาษา Technical (Database, Server, API) ส่วนฝ่ายปฏิบัติการพูดภาษาทหาร (อัตรา, พรรค-เหล่า, ชั้นยศ) คุยกันเหมือนลิ้นกับฟัน ไม่เข้าใจบริบทของกันและกัน
- อคติของผู้สร้าง (Developer Bias): คนทำระบบมักคิดว่า “User น่าจะชอบแบบนี้” หรือ “ทำแบบนี้แหละง่ายดี (สำหรับคนเขียนโค้ด)” โดยลืมมองในมุมของผู้ใช้งานจริงที่อาจจะไม่ถนัดเทคโนโลยี
- ความกลัวของผู้ใช้ (User Fear): ผู้ใช้งานมักไม่กล้าแย้งผู้เชี่ยวชาญไอที หรือคิดว่า “เดี๋ยวเขาทำมาให้ก็คงดีเอง” จึงไม่ออกความเห็นตั้งแต่แรก มารู้อีกทีก็ตอนระบบเสร็จแล้ว
3. ข้อจำกัดและผลกระทบ (Constraints & Impact)
- เสียของ (Waste): งบประมาณถูกใช้ไปสร้างฟีเจอร์ที่ไม่มีใครใช้ (Over-engineering) แต่ฟีเจอร์ที่จำเป็นกลับไม่มี
- แรงต้าน (Resistance): เมื่อ User รู้สึกว่าระบบเป็นภาระและไม่ได้ช่วยงานเขาจริงๆ เขาจะต่อต้านและพยายามหาทางเลี่ยงไม่ใช้ระบบ (System Workaround)
4. ข้อแนะนำและข้อเสนอแนะ: เปลี่ยนวิธีคิด ชีวิตเปลี่ยน (Paradigm Shift)
- เลิกคิดแทน: กฎข้อแรกของ คือ “ห้ามฝ่าย IT คิดแทน User เด็ดขาด”
- ดึง User มาร่วมโต๊ะ: การพัฒนา Odoo ในครั้งนี้ เราจะไม่ให้ฝ่าย IT นั่งทำคนเดียว แต่เราจะใช้กลยุทธ์ Co-Creation คือเชิญ “เจ้าหน้าที่ตัวจริง” จากกรมกำลังพล, กรมการเงิน ฯลฯ มานั่งประกบกับ Developer ตั้งแต่วันแรกที่เริ่มเขียนโค้ด
- แปลภาษา: ต้องมีคนกลาง (Business Analyst – BA) ที่เข้าใจทั้งภาษาทหารและภาษาคอมพิวเตอร์ ทำหน้าที่เป็นล่าม เพื่อให้ความต้องการของ User ถูกแปลงเป็นระบบที่ถูกต้องแม่นยำ
บทสรุป
กับดัก Centralized Development คือหลุมพรางที่ใหญ่ที่สุดของการพัฒนาระบบราชการไทย การแก้ปัญหานี้ไม่ใช่การเปลี่ยนโปรแกรมเมอร์ให้เก่งขึ้น แต่คือการ “เปลี่ยนเจ้าของงาน (User) ให้เป็นผู้ร่วมสร้าง”
ในโครงการ Open ERP ของกองทัพเรือครั้งนี้ เราจะไม่ยอมให้เกิดเหตุการณ์ “ตัดเสื้อไม่ดูคนใส่” อีกต่อไป แต่เราจะยื่นสายวัดให้ท่านวัดตัวของท่านเอง เพื่อให้ได้ระบบที่ “พอดีตัว” และ “ตอบโจทย์ภารกิจ” ของพี่น้องชาวเรืออย่างแท้จริงครับ
(อ้างอิง: หลักการ User-Centered Design (UCD) และ The Agile Manifesto for Government)
คำถามชวนคิด (เพื่อการมีส่วนร่วม)
- ท่านเคยเจอระบบงานที่ปุ่มสำคัญๆ ซ่อนอยู่ลึกมาก หรือช่องกรอกข้อมูลบังคับให้กรอกในสิ่งที่ไม่จำเป็น จนท่านหงุดหงิดหรือไม่?
- ถ้าท่านมีโอกาสได้นั่งข้างๆ คนเขียนโปรแกรม ท่านอยากจะบอกอะไรกับเขาเป็นประโยคแรก?
- ท่านคิดว่าใครควรรู้ดีที่สุดว่าระบบควรทำงานอย่างไร? ระหว่าง “ผอ.กองสารสนเทศ” หรือ “จ่าเอกที่นั่งทำเอกสารนั้นอยู่ทุกวัน”?
ติดตามตอนต่อไป
เมื่อเรารู้แล้วว่ารวมศูนย์อำนาจการพัฒนาไว้ที่ส่วนกลางมันไม่เวิร์ค แล้วทางออกคืออะไร? ในตอนหน้า Ep.18/80 “แนวคิด Decentralized Development: กระจายอำนาจการพัฒนาสู่หน่วยเจ้าของงาน” เราจะมาดูโมเดลใหม่ที่ให้ “แต่ละกรม” เป็นเจ้าภาพในการสร้างบ้านของตัวเอง โดยมีส่วนกลางเป็นแค่พี่เลี้ยง มันจะทำได้จริงหรือ? ห้ามพลาดครับ!
Talk is cheap. Show me the code.