คู่มือจัดซื้อจัดจ้างยุคใหม่: ทำไมต้องระบุ "ISO 29110" ใน TOR เพื่อคัดกรองผู้พัฒนาซอฟต์แวร์

ในโลกของการบริหารโครงการภาครัฐและองค์กรขนาดใหญ่ "ความล้มเหลว" ของโครงการซอฟต์แวร์มักไม่ได้เริ่มตอนเขียนโค้ด แต่เริ่มตั้งแต่ขั้นตอน จัดซื้อจัดจ้างภาครัฐ หรือการร่างสัญญา ปัญหาคลาสสิกที่ Procurement Committee (กรรมการตรวจรับ) ต้องเผชิญคือ การได้ผู้ชนะการประมูลที่เสนอราคาต่ำที่สุดแต่ขาดศักยภาพ (Low Bidder Dilemma) ส่งผลให้งานล่าช้า ทิ้งงาน หรือส่งมอบระบบที่เต็มไปด้วยข้อผิดพลาด

เพื่อปิดช่องโหว่ดังกล่าว การนำมาตรฐานวิศวกรรมซอฟต์แวร์ระดับโลกอย่าง ISO 29110 มาใช้เป็นเกณฑ์สำคัญใน TOR (Terms of Reference) จึงไม่ใช่ทางเลือก แต่เป็น "ทางรอด" ที่จะช่วยการันตีความสำเร็จของโครงการและความปลอดภัยของผู้ตรวจรับ

พลิกโฉมการเขียน TOR: ใช้มาตรฐานคัดกรอง "ตัวจริง"

หัวใจสำคัญของการ เขียน TOR จ้างทำซอฟต์แวร์ ที่ดี คือการกำหนด คุณสมบัติผู้ยื่นซอง (Vendor Qualification) ให้รัดกุม การระบุว่า "ผู้ยื่นข้อเสนอต้องได้รับการรับรองมาตรฐาน ISO 29110" เปรียบเสมือนการติดตั้งเครื่องกรองประสิทธิภาพสูง

มาตรฐานนี้จะคัดแยกผู้รับเหมาทั่วไปที่ทำงานแบบลูกทุ่ง ออกจาก Software House มืออาชีพที่มีระบบการจัดการ การทำเช่นนี้ช่วยลดความเสี่ยงที่จะเจอผู้พัฒนาที่ "เก่งแต่ปาก" แต่ไม่มีกระบวนการทำงานจริง ซึ่งเป็นสาเหตุหลักของการทิ้งงาน

‍

‍

กรรมการตรวจรับทำงานง่าย: ตรวจสอบได้ทุกขั้นตอน (Audit Trail)

ความกังวลที่สุดของคณะกรรมการตรวจรับพัสดุหรือซอฟต์แวร์ คือการถูกตรวจสอบภายหลังว่า "ตรวจรับงานผ่านไปได้อย่างไรทั้งที่งานไม่สมบูรณ์" มาตรฐาน ISO 29110 เข้ามาแก้ปัญหานี้ด้วยการสร้าง Audit Trail (การตรวจสอบย้อนกลับ)

ในกระบวนการของ ISO 29110 ทุกฟีเจอร์ที่พัฒนาจะต้องมีเอกสารอ้างอิง ตั้งแต่ SRS (Requirement), Design Document, ไปจนถึง Test Result กรรมการสามารถใช้เอกสารเหล่านี้เป็น Acceptance Criteria (เกณฑ์การตรวจรับงาน) ได้อย่างชัดเจน ไม่ต้องใช้ความรู้สึกส่วนตัวตัดสิน ว่างานเสร็จหรือไม่เสร็จ ทุกอย่างมีหลักฐานยืนยันความถูกต้อง (Compliance) ตามมาตรฐานสากล

แก้ปม "ราคากลางซอฟต์แวร์" และกับดักของถูก

การกำหนด ราคากลางซอฟต์แวร์ มักเป็นเรื่องปวดหัว เพราะซอฟต์แวร์เป็นสินทรัพย์ไม่มีตัวตน (Intangible Asset) หลายครั้งที่หน่วยงานเลือกเจ้าที่ราคาถูกที่สุดแล้วต้องมาเสียใจภายหลัง

การมีเกณฑ์ ISO 29110 ช่วยให้หน่วยงานสามารถอธิบายได้ว่า ทำไมโครงการนี้ถึงต้องใช้งบประมาณระดับนี้ เพราะเราไม่ได้จ่ายแค่ค่าเขียนโค้ด แต่เราจ่ายค่า "กระบวนการบริหารจัดการความเสี่ยง" และ "เอกสารทางวิศวกรรม" ที่จะทำให้ระบบอยู่รอดได้ในระยะยาว เป็นการเปลี่ยนมุมมองจากการซื้อของถูก เป็นการลงทุนที่คุ้มค่า (Value for Money)

‍

‍

ลดภาระการดูแลรักษาในอนาคต

บ่อยครั้งที่โครงการจบแต่ปัญหาไม่จบ เพราะผู้พัฒนาเดิมไม่ทำคู่มือ หรือโค้ดเขียนไว้ยุ่งเหยิงจนคนใหม่แก้ไม่ได้ แต่หากระบุใน TOR ว่าต้องดำเนินงานตาม ISO 29110 ผู้พัฒนาจะต้องส่งมอบชุดเอกสารทางเทคนิคที่ครบถ้วนเป็นมาตรฐาน

สิ่งนี้คือหลักประกันว่า ทรัพย์สินทางปัญญาและระบบที่จ้างพัฒนา จะเป็นขององค์กรอย่างแท้จริง สามารถจ้างทีมใหม่มาดูแลรักษา (Maintenance) ต่อได้ทันทีโดยไม่ต้องรื้อระบบทิ้ง

บทสรุป

การใส่ข้อกำหนด ISO 29110 ลงใน TOR ไม่ใช่การกีดกันทางการค้า แต่คือการยกระดับมาตรฐานอุตสาหกรรมซอฟต์แวร์ไทย และเป็นการสร้างเกราะป้องกันให้กับหน่วยงานเจ้าของโครงการ

สำหรับผู้บริหารและฝ่ายจัดซื้อ การเลือกผู้พัฒนาที่มีมาตรฐาน คือการเลือก "ความสบายใจ" และ "ความโปร่งใส" ซึ่งเป็นหัวใจสำคัญของการบริหารจัดการโครงการในยุค Digital Transformation ที่ความผิดพลาดเพียงเล็กน้อยอาจหมายถึงความเสียหายมหาศาล

References:

• "Software Procurement: The Importance of Standards" - IEEE Software
• "ISO/IEC 29110 and Government Procurement Policies" - ISO Focus
• Comptroller General's Department Regulations on Public Procurement (Guidelines for IT Projects)

ทางรอดของคณะกรรมการตรวจรับ! เจาะลึกเหตุผลที่ทำไมการระบุมาตรฐาน ISO 29110 ใน TOR ถึงเป็น "เกราะป้องกัน" ชั้นดีที่ช่วยลดความเสี่ยงจากการถูกตรวจสอบย้อนหลัง เปลี่ยนการตรวจรับงานจากความรู้สึก ให้เป็นระบบที่ตรวจสอบได้ (Audit Trail) ทุกขั้นตอน

‍