จ้างทำซอฟต์แวร์ไม่ให้งบบานปลาย: คุมขอบเขตและบริหารแบบ Agile

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

บทความนี้เขียนสำหรับผู้บริหาร เจ้าของโครงการ และทีมจัดซื้อที่กำลังจ้าง Software House ทำระบบหรือโปรเจกต์ Digital Transformation (DX) รวมถึงหน่วยงานรัฐที่จ้างผ่านระบบ e-GP เนื้อหาเน้นการคุมงบระหว่างโครงการ ส่วนการเตรียม brief เพื่อขอราคาอยู่ในบทความเตรียมข้อมูลขอราคาพัฒนาซอฟต์แวร์ และการเลือกบริษัทอยู่ในวิธีเลือกบริษัท Software Development: checklist 10 ข้อ มาตรฐานและตัวบทที่อ้างถึงตรวจจากต้นฉบับ ณ วันที่ 3 พฤศจิกายน 2026 ตามลิงก์ท้ายบทความ

งบบานปลายในโปรเจกต์ซอฟต์แวร์เกิดจากอะไร?

งบบานปลาย (cost overrun) คือต้นทุนจริงของโครงการสูงกว่างบที่อนุมัติไว้ ในงานจ้างทำซอฟต์แวร์ ต้นเหตุที่เราเห็นบ่อยมีสี่ทาง: ขอบเขตที่เขียนกว้างจนแต่ละฝ่ายตีความต่างกัน งานที่เพิ่มเข้ามาทีละนิดโดยไม่มีใครประเมินว่ากระทบงบและเวลาเท่าไร งานที่ต้องทำซ้ำเพราะผู้ใช้เพิ่งเห็นระบบจริงตอนตรวจรับ และช่องโหว่ความปลอดภัยที่พบตอนท้ายจนต้องรื้อแก้

ตัวเลขที่มักถูกอ้างถึงเรื่องนี้มีหลายชุด แต่ชุดที่เราตรวจต้นฉบับได้คืองานของ Flyvbjerg และ Budzier ใน Harvard Business Review ปี 2011 (Why Your IT Project Might Be Riskier Than You Think) ซึ่งวิเคราะห์โครงการ IT 1,471 โครงการ พบว่างบเกินเฉลี่ย 27% แต่ค่าเฉลี่ยนี้บังความเสี่ยงที่หนักกว่า คือหนึ่งในหกโครงการเป็น "Black Swan" ที่งบเกินเฉลี่ย 200% และเวลาเกินเกือบ 70% ผู้เขียนสรุปว่าการดูแต่ค่าเฉลี่ยทำให้มองข้ามความเสี่ยงจริงของงาน IT ตัวเลขชุดนี้เป็นกลุ่มตัวอย่างของงานศึกษานั้น ไม่ใช่สถิติของโครงการในไทย แต่ข้อสรุปใช้ได้ตรง ๆ: การคุมงบคือการตัดโอกาสที่โครงการจะหลุดไปเป็นกรณีสุดโต่ง ไม่ใช่การบีบราคาตั้งต้นให้ต่ำ

ในโครงการภาครัฐ สาเหตุเชิงกระบวนการ เช่น spec ไม่ชัด การตัดสินด้วยราคาเป็นหลัก และการทดสอบเพื่อตรวจรับโดยผู้ใช้ (User Acceptance Testing หรือ UAT) ที่ผู้ใช้จริงไม่ได้ร่วม สรุปไว้แล้วในทำไมโปรเจกต์ IT ภาครัฐถึงล้มเหลว บทความนี้ต่อจากตรงนั้น: เมื่อโครงการเริ่มแล้ว จะคุมงบอย่างไร

ต้องเขียนขอบเขตหรือ TOR อย่างไรให้คุมงบได้?

เขียนให้แต่ละข้อตรวจรับได้ และบอกลำดับความสำคัญ ขอบเขตที่คุมงบได้ไม่จำเป็นต้องยาว แต่ต้องตอบได้ว่างานไหนต้องมีก่อน งานไหนรอได้ และแต่ละข้อถือว่าเสร็จเมื่อไร สามเรื่องที่ควรอยู่ในเอกสารขอบเขตหรือ TOR:

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

รูปแบบสัญญาแบบราคาคงที่ (Fixed price) แบบตามเวลาจริง (Time & Materials) หรือเริ่มจาก Discovery ก่อน มีผลต่อการคุมงบโดยตรง ตารางเปรียบเทียบอยู่ในบทความเตรียมข้อมูลขอราคาพัฒนาซอฟต์แวร์ สำหรับหน่วยงานรัฐ หัวข้อ TOR งานพัฒนาระบบและวิธีจัดซื้ออยู่ในคู่มือจ้างพัฒนาระบบ IT ภาครัฐ และถ้าเป็นงานดูแลระบบเดิม ดูTOR จ้างดูแลระบบเดิม

เลือก Software House อย่างไรไม่ให้เสี่ยงงบบานปลาย?

ดูหลักฐานว่าผู้รับจ้างคุมขอบเขตอย่างไรในงานจริง ไม่ใช่แค่ดูราคาหรือ portfolio รายการตรวจ 10 ข้อและตารางเทียบ proposal อยู่ในวิธีเลือกบริษัท Software Development ในมุมของงบ ให้ขอดูของเหล่านี้เพิ่ม:

• ตัวอย่าง Product Backlog ที่เคยใช้ (ปิดชื่อลูกค้าได้) ว่าเรียงลำดับอย่างไร และใครเป็นคนเรียง
• ตัวอย่างบันทึก Change Request ที่มีผลกระทบด้านงานและเวลา และผลการอนุมัติ
• Definition of Done ที่ทีมใช้ เช่น ผ่าน code review มี automated test อยู่ใน repository ของลูกค้า และ deploy ขึ้นสภาพแวดล้อมทดสอบแล้ว
• รายชื่อบทบาทของทีมที่จะทำงานจริง และข้อตกลงว่าถ้าจะเปลี่ยนคนในบทบาทหลักต้องแจ้งและได้รับความเห็นชอบก่อน เพราะการเปลี่ยนคนกลางทางมีต้นทุนเรียนรู้ระบบใหม่เสมอ

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

ทำไมความสามารถด้านความปลอดภัยของผู้รับจ้างจึงเป็นเรื่องงบประมาณ?

เพราะช่องโหว่ที่พบตอนท้ายโครงการกลายเป็นงานแก้ที่ไม่ได้อยู่ในแผน ถ้าระบบออกแบบการควบคุมสิทธิ์ผิดตั้งแต่ต้น การแก้ตอนตรวจรับอาจต้องรื้อหลายส่วนพร้อมกัน แล้วตามมาด้วยคำถามว่าใครจ่าย การกำหนดเกณฑ์ความปลอดภัยที่ตรวจได้ไว้ตั้งแต่ใน TOR หรือสัญญา ทำให้ปัญหาถูกพบและแก้ในรอบที่ยังเล็ก

ควรขอหลักฐานด้านความปลอดภัยอะไรบ้าง?

ASVS เป็นกรอบข้อกำหนดความปลอดภัยสำหรับออกแบบ พัฒนา และทดสอบเว็บแอปพลิเคชันและเว็บเซอร์วิส เวอร์ชันล่าสุดคือ 5.0.0 เผยแพร่ 30 พฤษภาคม 2025 เอกสาร ASVS 5.0 เองเขียนไว้ว่าใช้เป็นกรอบในการจัดซื้อได้: ผู้ซื้อกำหนดได้ว่าซอฟต์แวร์ต้องพัฒนาตาม ASVS ระดับใด และขอให้ผู้ขายพิสูจน์ว่าซอฟต์แวร์ผ่านระดับนั้น ระดับมีสามขั้น ตามคำอธิบายของ ASVS 5.0

• Level 1: ข้อกำหนดขั้นต่ำ ราว 20% ของข้อกำหนดทั้งหมด
• Level 2: ระดับที่แอปพลิเคชันส่วนใหญ่ควรตั้งเป้า (รวม Level 1 และ 2 ราว 70%)
• Level 3: ระบบที่ต้องแสดงความปลอดภัยระดับสูงสุด

เมื่อปรับ ASVS มาใช้กับองค์กร เอกสารแนะนำให้เริ่มจาก Level 1 เป็นฐานแล้วขยับขึ้นตามความเสี่ยงของระบบ

เอกสารระบุด้วยว่า Level 1 ไม่จำเป็นต้องทดสอบได้ครบจากภายนอกโดยไม่เห็นเอกสารหรือ code หลักฐานที่ขอจึงควรรวมการตรวจ code หรือเอกสารการออกแบบ ไม่ใช่รายงานสแกนจากภายนอกอย่างเดียว

OWASP Top 10 ฉบับล่าสุดคือ ฉบับปี 2025 OWASP เรียกเอกสารนี้ว่าเอกสารสร้างความตระหนัก (awareness document) จึงเหมาะใช้เช็กว่ารายงานทดสอบครอบคลุมความเสี่ยงที่พบบ่อย เช่น A01 Broken Access Control, A03 Software Supply Chain Failures และ A06 Insecure Design ส่วนรายการข้อกำหนดที่ตรวจรับได้ให้ใช้ ASVS วิธีทดสอบอ้างอิงได้จาก OWASP Web Security Testing Guide (WSTG) ซึ่งฉบับเสถียรปัจจุบันคือ v4.2

SSDF คือ NIST SP 800-218 Version 1.1 (กุมภาพันธ์ 2022) แบ่งแนวปฏิบัติเป็นสี่กลุ่ม คือ Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) และ Respond to Vulnerabilities (RV) กลุ่มที่ควรถามผู้รับจ้างโดยตรงคือ RV: เมื่อมีคนพบช่องโหว่ในระบบที่ส่งมอบแล้ว จะรับแจ้งทางไหน ประเมินความรุนแรงอย่างไร และแก้ภายใต้สัญญาส่วนใด ถ้าต้องการวัดความพร้อมของกระบวนการทั้งองค์กรของผู้รับจ้าง อีกกรอบที่ใช้กันคือ OWASP Software Assurance Maturity Model (SAMM) เวอร์ชัน 2.2.0

ช่องทางรับแจ้งช่องโหว่ที่เผยแพร่ เช่นไฟล์ security.txt ตาม RFC 9116 เป็นสัญญาณง่าย ๆ ว่าผู้รับจ้างคิดเรื่องการรับแจ้งช่องโหว่ไว้แล้ว RFC นี้เขียนขึ้นเพราะเมื่อนักวิจัยพบช่องโหว่ มักไม่มีช่องทางแจ้งที่เหมาะสม

บริหารแบบ Agile ช่วยคุมงบได้อย่างไร?

Agile ช่วยคุมงบเมื่อใช้เพื่อให้เห็นของจริงเร็วและตัดสินใจเรื่องขอบเขตบ่อย ไม่ใช่ใช้เป็นเหตุผลให้เปลี่ยนอะไรก็ได้ตลอดเวลา หลักที่ใช้ได้กับการบริหารโปรเจกต์ DX ส่วนใหญ่มีห้าข้อ

ล็อกงบ แล้วให้ขอบเขตเป็นตัวที่ปรับ

แนวคิด fixed budget, variable scope คือกำหนดงบและกรอบเวลาไว้ แล้วตัดสินว่าจะได้งานแค่ไหนจากลำดับความสำคัญ เมื่อมีงานใหม่ที่สำคัญกว่า ให้สลับเข้าแทนงานลำดับท้ายที่ยังไม่เริ่ม ไม่ใช่เพิ่มต่อท้ายแล้วหวังว่างบจะพอ งานที่หลุดเส้นงบไม่ได้หายไป แต่รอรอบถัดไปหรืองบปีถัดไป

Product Backlog ที่เรียงลำดับ และมีเจ้าของคนเดียว

Scrum Guide (ฉบับพฤศจิกายน 2020) นิยาม Product Backlog ว่าเป็นรายการสิ่งที่ต้องทำเพื่อปรับปรุงผลิตภัณฑ์ที่เรียงลำดับและเปลี่ยนไปตามสิ่งที่เรียนรู้ และให้ Product Owner เป็นผู้รับผิดชอบการเรียงลำดับนั้น ในงานจ้าง ผู้เรียงควรเป็นคนฝั่งผู้ว่าจ้างที่ตัดสินใจได้จริง ถ้าทุกคนในองค์กรสั่งงานผู้รับจ้างได้ งบจะบานจากงานที่ไม่มีใครเรียงลำดับ

Sprint Review ที่เห็นซอฟต์แวร์ใช้งานได้

Scrum Guide กำหนดให้ Sprint ยาวไม่เกินหนึ่งเดือน และให้ Sprint Review ตรวจผลลัพธ์ของรอบนั้นเพื่อตัดสินว่าจะปรับอะไรต่อ สิ่งที่ตรวจคือ Increment ซึ่ง Scrum Guide เรียกว่าก้าวที่จับต้องได้สู่เป้าหมายของผลิตภัณฑ์ ไม่ใช่สไลด์หรือภาพหน้าจอ ตรงกับหนึ่งในค่านิยมของ Agile Manifesto ที่ว่า "Working software over comprehensive documentation" ทุกรอบที่ผู้ใช้ได้ลองของจริง คือโอกาสพบความเข้าใจผิดตอนที่ยังแก้ได้ด้วยต้นทุนต่ำ

Definition of Done ที่ตกลงกันไว้ก่อนเริ่ม

DoD คือคำอธิบายอย่างเป็นทางการว่า Increment ต้องอยู่ในสภาพใดจึงถือว่าผ่านเกณฑ์คุณภาพที่กำหนด Scrum Guide ระบุว่างานที่ยังไม่ผ่าน DoD จะ release หรือแม้แต่นำมาแสดงใน Sprint Review ไม่ได้ และต้องกลับไปอยู่ใน Product Backlog ผลทางงบคือ ความคืบหน้าจะนับจากงานที่เสร็จจริง ไม่ใช่งานที่ "เสร็จ 90%" หลายสิบชิ้น DoD ในงานจ้างควรรวมการทดสอบอัตโนมัติ code review การตรวจความปลอดภัยตามระดับที่ตกลง และ code ที่อยู่ใน repository ของผู้ว่าจ้าง

ขั้นตอน Change Request ที่มีบันทึกและประเมินผลกระทบ

ทุกงานที่ไม่อยู่ใน Product Backlog ที่ตกลงไว้ ควรเข้าบันทึก CR ที่ระบุว่าใครขอ เพราะอะไร กระทบงาน เวลา และงบเท่าไร จะสลับกับงานใด และใครอนุมัติ Scrum Guide เองระบุว่าระหว่าง Sprint ห้ามเปลี่ยนสิ่งที่ทำให้ Sprint Goal เสี่ยง แต่ขอบเขตสามารถทำให้ชัดและต่อรองใหม่กับ Product Owner ได้เมื่อเรียนรู้มากขึ้น บันทึก CR คือสิ่งที่ทำให้การต่อรองนั้นตรวจย้อนได้

สำหรับโครงการใหญ่ หลักที่ใช้ได้ทั่วไปคือแบ่งให้เล็กลง คู่มือของหน่วยงาน 18F ของรัฐบาลสหรัฐฯ (ปัจจุบันเก็บเป็นเอกสารถาวรแล้ว) แนะนำให้ตั้งงบและพัฒนาแบบค่อยเป็นค่อยไป และแบ่งโครงการใหญ่เป็นหลายโครงการเล็กที่ตั้งงบทีละส่วน รายละเอียดด้านสัญญาของคู่มือนั้นเป็นของสหรัฐฯ และใช้กับการจัดซื้อของไทยตรง ๆ ไม่ได้ แต่หลักการเริ่มเล็กใช้ได้กับการวางแผน Digital Transformation ทุกขนาด และกับการทยอยปรับระบบเดิมทีละส่วน ดูปรับระบบเก่าสู่ Cloud-Native

โครงการภาครัฐที่จ้างแบบราคาคงที่ ใช้ Agile ได้ไหม?

ใช้ได้ในรูปแบบการส่งมอบทีละส่วน แต่ต้องออกแบบไว้ใน TOR ก่อนลงนาม เพราะหลังลงนามแล้วแก้สัญญาได้จำกัด ข้อเท็จจริงทางกฎหมายที่ต้องรู้มีสามข้อ (ตัวบทตามที่ประกาศในราชกิจจานุเบกษา ไม่ใช่คำแนะนำทางกฎหมาย)

• แก้สัญญาได้เฉพาะบางกรณี พ.ร.บ. การจัดซื้อจัดจ้างและการบริหารพัสดุภาครัฐ พ.ศ. 2560 มาตรา 97 กำหนดว่าสัญญาที่ลงนามแล้วแก้ไขไม่ได้ เว้นแต่เข้ากรณีใน (1) ถึง (4) และอยู่ในดุลพินิจของผู้มีอำนาจ ถ้าต้องเพิ่มหรือลดวงเงินหรือระยะเวลา ให้ตกลงไปพร้อมกัน
• การแก้ต้องอยู่ในวัตถุประสงค์เดิม ระเบียบกระทรวงการคลังว่าด้วยการจัดซื้อจัดจ้างและการบริหารพัสดุภาครัฐ พ.ศ. 2560 ข้อ 165 กำหนดว่าการแก้ไขตามมาตรา 97 ต้องอยู่ภายในขอบข่ายแห่งวัตถุประสงค์เดิมของสัญญา และหน่วยงานต้องเปรียบเทียบคุณภาพ รายละเอียดของงาน และราคาก่อนแก้ CR จึงเปลี่ยนโครงการเป็นอีกโครงการหนึ่งไม่ได้
• ตรวจรับตามหลักฐานที่ตกลงกันไว้ มาตรา 100 ให้คณะกรรมการตรวจรับพัสดุรับผิดชอบทั้งการบริหารสัญญาและการตรวจรับ และระเบียบฯ ข้อ 175 (2) ให้ตรวจรับให้ถูกต้องครบถ้วนตามหลักฐานที่ตกลงกันไว้ โดยเชิญผู้ชำนาญการมาให้คำปรึกษาได้ถ้าต้องตรวจทางเทคนิค เกณฑ์ตรวจรับแต่ละงวดจึงต้องอยู่ใน TOR และสัญญาตั้งแต่แรก

เมื่อรวมสามข้อนี้ แนวทางที่เราแนะนำให้หน่วยงานพิจารณาร่วมกับหน่วยพัสดุคือ:

1. ให้แต่ละงวดเป็นซอฟต์แวร์ที่ทำงานได้ แทนการแบ่งงวดเป็น "ส่งเอกสารออกแบบ" "ส่งระบบ" และ "ฝึกอบรม" ให้แต่ละงวดส่งชุดฟังก์ชันที่ผู้ใช้ทดลองได้บนสภาพแวดล้อมทดสอบ การแบ่งงวดเป็นเรื่องที่ผู้ร่าง TOR ออกแบบได้ และเท่าที่เราตรวจ ยังไม่พบข้อในระเบียบที่บังคับรูปแบบงวดของงานจ้างทั่วไปที่ไม่ใช่งานก่อสร้างหรืองานจ้างที่ปรึกษา
2. เขียนหลักฐานตรวจรับแต่ละงวดไว้ชัด เช่น การสาธิตต่อกรรมการตามสถานการณ์ที่กำหนด ผลทดสอบอัตโนมัติ code ใน repository ของหน่วยงาน และรายงานทดสอบความปลอดภัยเทียบกับระดับ ASVS ที่ระบุ ซึ่งเป็น "หลักฐานที่ตกลงกันไว้" ที่กรรมการใช้ตัดสินได้ตรงกัน
3. เรียงลำดับความต้องการใน TOR ให้งวดแรก ๆ ส่งงานที่ต้องมีก่อน ถ้าโครงการมีปัญหากลางทาง หน่วยงานยังได้ส่วนที่ใช้งานได้
4. แยกการทำให้ชัดออกจากการเพิ่มงาน การลงรายละเอียดหน้าจอหรือขั้นตอนภายในข้อกำหนดเดิมเป็นงานปกติของการพัฒนา แต่การเพิ่มข้อกำหนดใหม่เป็นการเปลี่ยนแปลงที่อาจต้องแก้สัญญาตามมาตรา 97 เส้นแบ่งนี้ควรเขียนไว้ใน TOR และให้หน่วยพัสดุยืนยันก่อนประกาศ

ข้อจำกัดที่ต้องพูดตรง ๆ คือ หน่วยงานรัฐจะเปลี่ยนขอบเขตของสัญญาที่ลงนามแล้วอย่างอิสระแบบโครงการเอกชนไม่ได้ ความยืดหยุ่นแบบ Agile ในงานรัฐจึงอยู่ที่ลำดับการส่งมอบ การตรวจของจริงทุกงวด และการพบปัญหาเร็ว มากกว่าการเปลี่ยนขอบเขต งานที่อยู่นอกวัตถุประสงค์เดิมควรเป็นโครงการหรืองบรอบถัดไป ข้อที่อ้างจากระเบียบฯ เป็นตัวบทฉบับ พ.ศ. 2560 ก่อนใช้งานจริงให้ยืนยันฉบับล่าสุดกับหน่วยพัสดุหรือกรมบัญชีกลาง

ถ้าระบบต้องเชื่อมข้อมูลกับหน่วยงานอื่น ข้อมูลที่ควรเตรียมก่อนร่าง TOR เพื่อให้ผู้ยื่นข้อเสนอประเมินงานเชื่อมต่อได้ ดูตัวอย่างในระบบสารสนเทศสวัสดิการ: เชื่อมฐานข้อมูลภาครัฐผ่าน GDX ตาม PDPA

Checklist: 5 สัญญาณเตือนว่าโปรเจกต์ IT กำลังจะงบบานปลาย

สัญญาณเหล่านี้เป็นสิ่งที่เห็นได้ระหว่างโครงการ ไม่ใช่ก่อนเซ็นสัญญา (สัญญาณก่อนเซ็นอยู่ในบทความเลือกบริษัท Software Development) ยิ่งเห็นเร็ว ทางเลือกยิ่งเหลือมาก

1. Sprint Review หรือการรายงานงวดมีแต่สไลด์และภาพหน้าจอ ไม่มีซอฟต์แวร์ที่ผู้ใช้ลองได้ ความคืบหน้าที่ไม่ผ่าน DoD ยังไม่ใช่ความคืบหน้า ทำอย่างไร: ขอให้ทุกรอบสาธิตบนสภาพแวดล้อมทดสอบ และนับเฉพาะงานที่ผ่าน DoD
2. มีงานเพิ่มเข้ามาแต่ไม่มีบันทึก Change Request หรือมีบันทึกแต่ไม่มีการประเมินผลกระทบด้านงบและเวลา ทำอย่างไร: หยุดรับงานเพิ่มชั่วคราว รวบรวมคำขอที่ค้างทั้งหมดลงบันทึก CR แล้วตัดสินทีละรายการว่าจะสลับกับงานใด
3. งบที่ใช้ไปโตเร็วกว่างานที่เสร็จจริง เช่น ใช้งบหรือเวลาไปครึ่งหนึ่ง แต่งานที่ต้องมีผ่าน DoD ไม่ถึงครึ่ง ทำอย่างไร: เรียง Product Backlog ใหม่ให้งานที่ต้องมีอยู่ในงบที่เหลือ และตกลงตอนนี้ว่างานใดจะเลื่อนออกไป
4. เกณฑ์ตรวจรับถูกต่อรองใหม่ตอน UAT หรือตอนตรวจรับงวด แปลว่าเกณฑ์ไม่ชัดตั้งแต่ต้น และจะมีงานทำซ้ำตามมา ทำอย่างไร: เขียนเกณฑ์ตรวจรับของงานที่เหลือให้ชัดก่อนเริ่มทำ และให้ผู้ตรวจรับเห็นงานตั้งแต่ Sprint Review ไม่ใช่ครั้งแรกตอนตรวจรับ
5. การทดสอบความปลอดภัยถูกเลื่อนไปไว้ท้ายโครงการ ช่องโหว่ที่พบตอนท้ายมักแก้ด้วยการรื้อ ทำอย่างไร: ใส่การตรวจตามระดับ ASVS ที่ตกลงไว้ใน DoD ของทุกรอบ และขอรายงานผลทดสอบตั้งแต่งวดแรก

อีกสัญญาณที่ควรจับตาคือคนในบทบาทหลักของผู้รับจ้างเปลี่ยนโดยไม่แจ้ง เช่น technical lead ที่นำเสนอไม่ได้อยู่ในการประชุมอีกเลย ให้ถามตรง ๆ และอ้างข้อตกลงเรื่องทีมในสัญญา

ประเมินขอบเขตและความเสี่ยงงบก่อนเริ่มโครงการ

งบที่คุมได้เริ่มจากขอบเขตที่เรียงลำดับและเกณฑ์ตรวจรับที่ชัด ถ้าองค์กรหรือหน่วยงานมีร่างขอบเขต ร่าง TOR หรือโครงการที่เริ่มแล้วแต่เห็นสัญญาณข้างต้น การประเมินตอนนี้จะบอกได้ว่างานใดต้องมี งานใดรอได้ และจุดใดเสี่ยงงบบานปลาย

งานพัฒนาซอฟต์แวร์เฉพาะองค์กรของ UNIXDEV ใช้กระบวนการที่ผ่านการรับรอง ISO/IEC 29110-4-1:2018 จาก SGS Thailand (ใบรับรองเลขที่ TH25/00001024) ซึ่งประกอบด้วยรอบ sprint ที่สม่ำเสมอ code review การทดสอบอัตโนมัติ การทบทวนหลังจบรอบ (retrospective) และทะเบียนความเสี่ยง (risk log) บริษัทได้รับการรับรอง ISO 9001:2015 และ ISO/IEC 27001:2022 (ดูรายละเอียดการรับรอง) และลงทะเบียนเป็นผู้ค้าในระบบ e-GP แล้ว สำหรับงานภาครัฐ เราทำงานตาม TOR และส่งมอบ source code พร้อมเอกสาร ถ้าหน่วยงานต้องการให้เราประเมินร่าง TOR และให้เรายื่นข้อเสนอในโครงการเดียวกันด้วย ควรสอบถามหน่วยพัสดุก่อนว่ามีข้อจำกัดหรือไม่ ความเห็นต่อร่าง TOR ที่เผยแพร่แล้วส่งได้ในขั้นรับฟังความคิดเห็น

ส่งร่างขอบเขต รายการความต้องการ หรือสถานะโครงการเท่าที่มีผ่านแบบฟอร์มส่งโจทย์ เป้าหมายของทีมคือตอบกลับภายใน 2 วันทำการ

แหล่งอ้างอิงและอ่านต่อ

• Flyvbjerg, B. and Budzier, A. Why Your IT Project Might Be Riskier Than You Think: Harvard Business Review, Vol. 89 (2011), No. 9, pp. 23–25 (ฉบับผู้เขียนบน arXiv)
• OWASP Application Security Verification Standard (ASVS) 5.0.0 · ASVS 5.0: What is the ASVS (ระดับและการใช้ในการจัดซื้อ)
• OWASP Top 10:2025
• OWASP Web Security Testing Guide (WSTG)
• OWASP Software Assurance Maturity Model (SAMM)
• NIST Secure Software Development Framework (SSDF), SP 800-218 Version 1.1
• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure
• The Scrum Guide (November 2020) · Manifesto for Agile Software Development
• 18F: Buying development services (เอกสารถาวร แนวปฏิบัติของสหรัฐฯ)
• พ.ร.บ. การจัดซื้อจัดจ้างและการบริหารพัสดุภาครัฐ พ.ศ. 2560: ราชกิจจานุเบกษา เล่ม 134 ตอนที่ 24 ก วันที่ 24 กุมภาพันธ์ 2560 (มาตรา 97, 100)
• ระเบียบกระทรวงการคลังว่าด้วยการจัดซื้อจัดจ้างและการบริหารพัสดุภาครัฐ พ.ศ. 2560: ราชกิจจานุเบกษา เล่ม 134 ตอนพิเศษ 210 ง วันที่ 23 สิงหาคม 2560 (ข้อ 165, 175) · สำเนาที่กรมบัญชีกลางเผยแพร่
• บทความที่เกี่ยวข้อง: ทำไมโปรเจกต์ IT ภาครัฐถึงล้มเหลว
• บทความที่เกี่ยวข้อง: ระบบสารสนเทศสวัสดิการ เชื่อมฐานข้อมูลภาครัฐ
• บทความที่เกี่ยวข้อง: ปรับระบบเก่าสู่ Cloud-Native
• บทความที่เกี่ยวข้อง: วิธีเลือกบริษัท Software Development ในไทย
• บทความที่เกี่ยวข้อง: เตรียมข้อมูลอะไรให้ได้ราคาประเมินที่ตรงโจทย์
• บทความที่เกี่ยวข้อง: จ้างพัฒนาระบบ IT ภาครัฐ วิธีจัดซื้อ e-GP TOR และงบ MA
• บทความที่เกี่ยวข้อง: TOR จ้างดูแลระบบเดิม
• บทความที่เกี่ยวข้อง: สัญญา MA และ SLA ดูแลระบบ
• บทความที่เกี่ยวข้อง: เปลี่ยนผู้รับจ้างดูแลระบบ ต้องรับมอบอะไรบ้าง
• บทความทั้งหมดในหมวดพัฒนาซอฟต์แวร์องค์กร

บทความโดย UNIXDEV Team · 3 พฤศจิกายน 2026 · สรุปเพื่อประกอบการวางแผน ไม่ใช่คำแนะนำทางกฎหมาย