จ้างพัฒนาซอฟต์แวร์องค์กร: เตรียมข้อมูลอะไรให้ได้ราคาประเมินที่ตรงโจทย์

ลองนึกภาพองค์กรหนึ่งส่งอีเมลสั้น ๆ ไปหา vendor สามรายว่า "อยากได้ระบบรับคำสั่งซื้อออนไลน์ที่เชื่อมกับ ERP" สองสัปดาห์ต่อมาได้ใบเสนอราคากลับมาสามฉบับที่ราคาต่างกันหลายเท่า ระยะเวลาไม่ตรงกัน และแต่ละฉบับเขียนขอบเขตคนละแบบ ฝ่ายจัดซื้อเปรียบเทียบไม่ได้ ผู้บริหารเริ่มสงสัยว่ารายไหนตั้งราคาเกินจริง

ปัญหานี้ส่วนใหญ่ไม่ได้อยู่ที่ vendor แต่อยู่ที่โจทย์ที่ยังไม่ชัด บทความนี้สรุปว่าองค์กรควรเตรียมข้อมูลอะไรก่อนขอใบเสนอราคาพัฒนาซอฟต์แวร์ ตั้งแต่โจทย์ธุรกิจ ผู้ใช้ ขอบเขต การเชื่อมระบบ ความต้องการด้านความปลอดภัยและ PDPA เกณฑ์ตรวจรับ ไปจนถึงรูปแบบสัญญา พร้อมแม่แบบ brief หนึ่งหน้าที่นำไปใช้ได้ทันที สำหรับเรื่องการคัดเลือกและตรวจสอบ vendor อ่านต่อได้ที่ วิธีเลือกบริษัท Software Development ในไทย

ทำไมใบเสนอราคาพัฒนาซอฟต์แวร์จากแต่ละเจ้าถึงต่างกันหลายเท่า?

ใบเสนอราคาจากแต่ละรายต่างกันหลายเท่า เพราะเมื่อ brief ไม่ระบุรายละเอียด vendor แต่ละรายต้องเติมช่องว่างด้วยสมมติฐานของตัวเอง รายหนึ่งอาจคิดว่าแค่นำเข้าไฟล์ อีกรายคิดว่าต้องเชื่อม API แบบ real-time ราคาจึงต่างกันตามสมมติฐาน ไม่ใช่ตามความสามารถเพียงอย่างเดียว

Steve McConnell อธิบายไว้ใน Software Development's Cone of Uncertainty (Construx) ว่าช่วงต้นโครงการ ความต้องการ แนวทางแก้ปัญหา แผนงาน และทีมยังไม่ชัด ความไม่แน่นอนนี้จึงไหลเข้าไปในราคาประเมิน เขาระบุว่าการประเมิน ณ ช่วง Initial Concept ค่าจริงอาจสูงกว่าที่ประเมินได้ถึง 4 เท่า หรือต่ำได้ถึง 0.25 เท่า รวมเป็นช่วงกว้าง 16 เท่า และช่วงนี้แคบลงเมื่อผ่านจุดสำคัญ เช่น ได้นิยามผลิตภัณฑ์ที่อนุมัติแล้ว เก็บความต้องการครบ และออกแบบหน้าจอเสร็จ

ประเด็นที่ผู้ซื้อควรจำมีสามข้อจากเอกสารเดียวกัน:

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

ภาพด้านบนไล่จุดสำคัญตามเอกสารต้นฉบับ จาก Initial Concept ถึง Software Complete ตัวเลขในกรวยมาจากความคลาดเคลื่อนที่พบในการประเมินของผู้ประเมินที่มีทักษะตามที่ McConnell อธิบาย ไม่ได้หมายความว่าทุกโครงการในไทยจะคลาดเคลื่อนเท่านี้ แต่อธิบายได้ดีว่าทำไม brief ที่ดีจึงสำคัญกว่าการต่อราคา

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

ต้องเตรียมข้อมูลอะไรบ้างก่อนขอใบเสนอราคา?

เตรียมสิ่งที่ทำให้ vendor ทุกรายประเมินบนสมมติฐานเดียวกัน ได้แก่ โจทย์และผลลัพธ์ที่ต้องการ ผู้ใช้และบทบาท กระบวนการปัจจุบัน ขอบเขตที่ต้องมีกับที่มีก็ดี ระบบที่ต้องเชื่อมและข้อมูลที่ต้องย้าย ความต้องการที่ไม่ใช่ฟังก์ชัน (non-functional) เกณฑ์ตรวจรับ เรื่องกรรมสิทธิ์และ hosting การดูแลหลังส่งมอบ และงบกับกรอบเวลา ไม่จำเป็นต้องละเอียดระดับสเปกเทคนิค แต่ต้องชัดพอให้เปรียบเทียบกันได้

แนวทางช่วง Discovery ของ GOV.UK Service Manual ใช้เป็นโครงได้ดี โดยให้หาคำตอบเรื่องผู้ใช้และบริบท ข้อจำกัด เช่น กฎหมาย สัญญา เทคโนโลยีเดิม และกระบวนการที่มีอยู่ โอกาสในการปรับปรุง และวิธีวัดความสำเร็จ

โจทย์ธุรกิจ ผู้ใช้ และกระบวนการปัจจุบัน

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

แยกสิ่งที่ต้องมีออกจากสิ่งที่มีก็ดี

จัดลำดับความต้องการเป็นอย่างน้อยสองกลุ่ม คือ must-have ที่ระบบรุ่นแรกขาดไม่ได้ และ nice-to-have ที่รอรุ่นถัดไปได้ หรือจะใช้ MoSCoW (Must, Should, Could, Won't) ที่แบ่งละเอียดกว่าก็ได้ เขียนแต่ละข้อเป็น user story ตามรูปแบบของ GOV.UK คือ "ในฐานะ [ผู้ใช้] ฉันต้องการ [ทำอะไร] เพื่อ [เหตุผล]" รูปแบบนี้บังคับให้ระบุว่าใครได้ประโยชน์ ช่วยให้ตัดฟีเจอร์ที่ไม่มีเจ้าของออกได้ง่าย

การเชื่อมระบบและการย้ายข้อมูล

การเชื่อมระบบเป็นจุดที่ราคาประเมินแกว่งมากที่สุด เพราะ vendor มองไม่เห็นระบบปลายทางจนกว่าจะได้ลงมือ ให้ระบุชื่อระบบ เวอร์ชันถ้ารู้ ช่องทางเชื่อมต่อที่มี เช่น API ที่มีเอกสาร การ export ไฟล์ หรือฐานข้อมูลตรง ทิศทางของข้อมูล และความถี่ เช่น real-time หรือวันละครั้ง สำหรับการย้ายข้อมูล ให้ระบุปริมาณ ช่วงปีที่ต้องย้าย และคุณภาพข้อมูลเท่าที่รู้ หากต้องย้ายจากระบบเก่าที่ซับซ้อน ดูแนวทางเพิ่มใน การ Modernize ระบบเก่า

ความปลอดภัย ความเร็ว และความพร้อมใช้งาน ต้องเขียนใน brief แค่ไหน?

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

โมเดลคุณภาพซอฟต์แวร์ ISO/IEC 25010:2023 ซึ่ง iso25000.com สรุปไว้ (เป็นเว็บไซต์อธิบายมาตรฐาน ไม่ใช่ ISO โดยตรง) แบ่งคุณภาพเป็นเก้าคุณลักษณะ ได้แก่ Functional Suitability, Performance Efficiency, Compatibility, Interaction Capability, Reliability, Security, Maintainability, Flexibility และ Safety ใช้เป็น checklist ไม่ให้หลงลืมหัวข้อสำคัญได้

สำหรับเว็บแอปพลิเคชัน brief สามารถอ้าง OWASP Application Security Verification Standard (ASVS) ได้ ASVS เป็นโครงการ Flagship ของ OWASP ใช้ได้ทั้งเป็นเกณฑ์ทดสอบ security control และเป็นรายการข้อกำหนดให้นักพัฒนา รุ่นล่าสุดตามหน้าโครงการคือ 5.0.0 การระบุใน brief ว่างานต้องตรวจสอบตาม ASVS ช่วยให้ vendor ทุกรายประเมินงานด้านความปลอดภัยบนฐานเดียวกัน

ถ้าระบบมีข้อมูลส่วนบุคคล ต้องบอก vendor เรื่อง PDPA อะไรบ้าง?

บอกว่าระบบเก็บข้อมูลส่วนบุคคลประเภทใด ของใคร และ vendor จะเข้าถึงหรือประมวลผลข้อมูลนั้นหรือไม่ เช่น ระหว่างย้ายข้อมูล ทดสอบ หรือดูแลระบบ หากเข้าถึง ควรระบุใน brief ว่าจะทำข้อตกลงการประมวลผลข้อมูล (Data Processing Agreement) แนบกับสัญญาหลัก

ตัวอย่างหนึ่งคือ (ร่าง) ข้อตกลงการประมวลผลข้อมูล PDPA-DPA-6601 ที่เผยแพร่บนเว็บไซต์ bde.go.th ซึ่งเป็นร่างที่สำนักงานคณะกรรมการดิจิทัลเพื่อเศรษฐกิจและสังคมแห่งชาติใช้กับสัญญาบริการของตนเอง ร่างนี้ระบุว่าจัดทำเพื่อปฏิบัติตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 40 วรรคสาม และเป็นส่วนหนึ่งของสัญญาการให้บริการหลัก โดยผู้ว่าจ้างเป็นผู้ควบคุมข้อมูล และผู้ให้บริการเป็นผู้ประมวลผลข้อมูลที่ต้องปฏิบัติตามกฎหมายที่เกี่ยวข้อง

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

จะตรวจรับงานอย่างไร ต้องกำหนดตั้งแต่ตอนขอราคาไหม?

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

GOV.UK อธิบาย acceptance criteria ว่าเป็นรายการผลลัพธ์ที่ใช้เป็น checklist ยืนยันว่าระบบทำหน้าที่ได้ มักเขียนในรูป "ถือว่าเสร็จเมื่อ..." ให้เขียนเกณฑ์อย่างน้อยสำหรับ must-have ทุกข้อ ระบุผู้ตรวจรับฝั่งองค์กร และชุดข้อมูลตัวอย่างที่ใช้ทดสอบ

สำหรับเกณฑ์ภาพรวม คู่มือของ 18F (อดีตทีมดิจิทัลของ US GSA ซึ่งยุติการดำเนินงานในปี 2025 แต่คู่มือยังเผยแพร่อยู่) ระบุว่างานที่ส่งมอบต้อง complete, tested, accessible, deployed, documented และ secure โดยควบคุมผ่านแผนตรวจคุณภาพ (QASP) ของผู้ซื้อ และแนะนำอย่างชัดเจนว่าไม่ควรให้ vendor เขียนแผนตรวจคุณภาพของตัวเอง หกคำนี้ใช้เป็นจุดตั้งต้นของ checklist UAT ได้ดี

Source code, IP และ hosting ต้องตกลงอะไรก่อนขอราคา?

เรื่อง source code, IP และ hosting ควรระบุตั้งแต่ใน brief ว่าองค์กรต้องการถือกรรมสิทธิ์ source code และเอกสาร ระบบจะรันบน infrastructure ของใคร และใครจ่ายค่า cloud หรือ license เรื่องเหล่านี้เปลี่ยนราคาได้มาก ถ้าตกลงทีหลังจะเปรียบเทียบใบเสนอราคาไม่ได้

คู่มือของ 18F แนะนำให้ code ทั้งหมดส่งเข้า repository ที่ผู้ซื้อเป็นเจ้าของ และหากสัญญาจบก่อนกำหนด ผู้ซื้อต้องยังเป็นเจ้าของซอฟต์แวร์ทุกส่วนที่ส่งมอบมาแล้ว สำหรับ hosting ให้ระบุว่าจะใช้ cloud ขององค์กร ให้ vendor จัดหา หรือรันใน data center เดิม รายละเอียดการส่งมอบ code เอกสาร และสิทธิ์เข้าถึงตอนจบงาน ดูได้ใน Checklist การส่งมอบงานจาก vendor ส่วนการวางแผนย้ายระบบขึ้น cloud อ่านต่อได้ที่ คู่มือ Cloud Migration

ต้องรวมค่าดูแลระบบหลัง go-live ไว้ในงบตั้งแต่แรกไหม?

ควรรวมค่าดูแลระบบหลัง go-live ไว้ในงบตั้งแต่แรก เพราะซอฟต์แวร์ที่ใช้งานจริงต้องแก้ไข ปรับปรุง และอัปเดตความปลอดภัยต่อเนื่อง ถ้าขอราคาเฉพาะการพัฒนา จะเห็นต้นทุนรวมไม่ครบ และอาจเลือกรายที่ราคาพัฒนาต่ำแต่ค่าดูแลสูง

คู่มือด้านงบประมาณของ 18F ระบุว่า custom software ไม่เคย "เสร็จ" จึงต้องวางแผนให้ปรับปรุงต่อเนื่อง และการตั้งงบดูแลระบบเหมือนเป็นคนละกิจกรรมกับการสร้างระบบถือเป็นความผิดพลาด ใน brief ให้ขอราคาค่าดูแลแยกเป็นบรรทัด พร้อมระบุสิ่งที่คาดหวัง เช่น ช่วงเวลาให้บริการ และช่องทางแจ้งปัญหา รายละเอียดการเขียนสัญญา MA และ SLA อ่านได้ที่ Checklist สัญญา MA และ SLA ส่วนการเลือกระหว่างจ้างดูแลกับทีมภายใน อ่านได้ที่ Managed Services หรือ In-house IT

ควรบอกงบประมาณและกรอบเวลาให้ vendor รู้ไหม?

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

สำหรับกรอบเวลา ให้แยกวันที่ตายตัวจริง เช่น วันที่กฎระเบียบใหม่มีผล ออกจากวันที่อยากได้ และบอกว่าทีมองค์กรมีเวลาตอบคำถามและตรวจงานสัปดาห์ละเท่าไร เพราะมีผลต่อกำหนดส่งงานโดยตรง

Fixed price, Time & Materials หรือ Discovery ก่อน แบบไหนเหมาะกับองค์กร?

Fixed price เหมาะเมื่อขอบเขตชัดและนิ่งแล้ว Time & Materials (T&M) เหมาะเมื่อยังต้องเรียนรู้ระหว่างทาง ส่วนการแบ่งเป็น Discovery แล้วค่อยพัฒนา เหมาะกับโครงการที่ยังตอบคำถามใน brief ได้ไม่ครบ ซึ่งเป็นสถานการณ์ของหลายองค์กร

คู่มือของ 18F ให้มุมมองจากการจัดซื้อภาครัฐสหรัฐฯ ว่าสำหรับงานซอฟต์แวร์ สัญญา T&M ปกป้องผลประโยชน์ทางการเงินและผลงานของผู้ซื้อได้ดีกว่าสัญญาราคาตายตัว (firm-fixed-price) เหตุผลคือภายใต้ T&M ผู้รับจ้างเรียกเก็บเงินตามเวลาที่ใช้จริง และใบแจ้งหนี้ทุกฉบับต้องมีรายละเอียดการเรียกเก็บที่ชัดเจน ขณะที่สัญญาราคาตายตัวไม่มีการคุ้มครองแบบนี้ระหว่างที่งานดำเนินไป เพราะใบแจ้งหนี้ไม่ได้แสดงรายละเอียด คู่มือยังระบุว่าสัญญา T&M ของรัฐบาลสหรัฐฯ ต้องมีเพดานวงเงินเสมอ

นี่เป็นคำแนะนำในบริบทการจัดซื้อภาครัฐของสหรัฐฯ ไม่ใช่กฎสากล องค์กรไทยบางแห่งอาจต้องใช้ราคาตายตัวด้วยเหตุผลด้านงบประมาณหรือระเบียบ ซึ่งทำได้ หากนิยามขอบเขตจนกรวยความไม่แน่นอนแคบลงแล้ว ถ้าเลือก T&M บทความนี้แนะนำให้ตั้งเพดานงบรวมไว้ด้วย ตามตารางด้านบน

ทางสายกลางคือแบ่งเป็นช่วง GOV.UK อธิบายว่า Discovery มีไว้ทำความเข้าใจปัญหาก่อนสร้าง และไม่ควรเริ่มสร้างบริการในช่วงนี้ ส่วน ช่วง Alpha คือการลองแนวทางแก้ปัญหาด้วย prototype และควรคาดว่าจะทิ้ง code ทั้งหมด และไอเดียจำนวนมากที่ทดลองเมื่อจบช่วง

คู่มือของ 18F เองก็ระบุว่าการสร้าง prototype ของส่วนเล็ก ๆ ก่อนทำสัญญาช่วยลดความเสี่ยงได้หลายทาง ในทางปฏิบัติ องค์กรจึงอาจจ้าง Discovery แบบขอบเขตจำกัดก่อน แล้วใช้ผลลัพธ์เป็น brief ขอราคาช่วงพัฒนา

ตัวอย่างสมมติ: brief ไม่ชัดทำให้ช่วงราคากว้างได้อย่างไร?

ตัวเลขต่อไปนี้เป็นตัวเลขสมมติเพื่ออธิบายวิธีคิด ไม่ใช่ผลลัพธ์จากลูกค้า ไม่ใช่ราคาตลาด และไม่ใช่ราคาเสนอขายของ UNIXDEV

บริษัทจัดจำหน่ายสมมติแห่งหนึ่งส่ง brief บรรทัดเดียวว่า "ต้องการระบบรับคำสั่งซื้อจากตัวแทนจำหน่าย เชื่อมกับ ERP" แล้วได้ราคากลับมาสามราย:

• Vendor A: 0.8 ล้านบาท สมมติว่าเป็นเว็บอย่างเดียว ผู้ใช้หนึ่งบทบาท และส่งไฟล์ให้ ERP วันละครั้ง
• Vendor B: 2.4 ล้านบาท สมมติว่าต้องเชื่อม ERP ผ่าน API แบบ real-time มีสามบทบาท และย้ายข้อมูลลูกค้าเดิม
• Vendor C: 4.5 ล้านบาท สมมติว่าต้องมี mobile app ย้ายประวัติสั่งซื้อย้อนหลังทั้งหมด และพัฒนา API ฝั่ง ERP เพิ่มเอง

ช่วงราคากว้างกว่าห้าเท่า แต่ทั้งสามรายอาจประเมินถูกต้องตามสมมติฐานของตัวเอง หลังจากองค์กรใช้เวลาเตรียม brief หนึ่งหน้า โดยระบุว่ารุ่นแรกเป็นเว็บที่ใช้บนมือถือได้ มีสามบทบาท ERP มี API พร้อมเอกสาร ย้ายเฉพาะลูกค้าที่ยังมีการสั่งซื้อ และ mobile app เป็น nice-to-have ราคาจากรอบใหม่สมมติอยู่ที่ 1.7 ถึง 2.3 ล้านบาท ซึ่งเปรียบเทียบกันได้ และส่วนต่างที่เหลือสะท้อนวิธีทำงานของแต่ละรายแทนที่จะสะท้อนการเดาโจทย์

ราคาที่ใกล้กันในรอบที่สองหมายความว่า vendor ทุกรายประเมินบนสมมติฐานชุดเดียวกัน ไม่ได้หมายความว่าต้นทุนสุดท้ายแน่นอนแล้ว ตามกรวยของ McConnell ต้นทุนยังเปลี่ยนได้จนกว่าความต้องการและการออกแบบหน้าจอจะนิ่ง องค์กรจึงควรกันงบสำรองไว้ หรือใช้สัญญาแบบแบ่งช่วง หรือ T&M ที่มีเพดานงบ

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

brief ขอใบเสนอราคาพัฒนาซอฟต์แวร์หนึ่งหน้าควรมีหัวข้ออะไรบ้าง?

brief ขอใบเสนอราคาที่ดีไม่ต้องยาว หนึ่งหน้าที่ตอบครบสิบหัวข้อด้านล่างมีประโยชน์กว่าเอกสารยาวที่ขาดสิ่งที่ vendor ต้องรู้ ส่วนที่ยังไม่รู้ให้เขียนว่า "ยังไม่ทราบ" ตรง ๆ เพื่อให้ vendor เสนอวิธีหาคำตอบแทนการเดา

1. โจทย์และผลลัพธ์: ปัญหาที่เกิดวันนี้ และตัวชี้วัดที่อยากให้เปลี่ยน
2. ผู้ใช้และบทบาท: กลุ่มผู้ใช้ จำนวนโดยประมาณ และสิทธิ์ของแต่ละบทบาท
3. กระบวนการปัจจุบัน: แผนผังขั้นตอน แบบฟอร์ม และข้อยกเว้นที่พบบ่อย
4. ขอบเขต: รายการ must-have และ nice-to-have เขียนเป็น user story
5. การเชื่อมระบบและย้ายข้อมูล: ระบบปลายทาง ช่องทางเชื่อมต่อ ปริมาณและช่วงปีของข้อมูล
6. ความต้องการที่ไม่ใช่ฟังก์ชัน: ความเร็ว ความพร้อมใช้งาน ระดับความปลอดภัย และข้อมูลส่วนบุคคลที่เกี่ยวข้อง
7. เกณฑ์ตรวจรับ: "ถือว่าเสร็จเมื่อ..." สำหรับ must-have และผู้ตรวจรับฝั่งองค์กร
8. กรรมสิทธิ์และ hosting: repository ของใคร ระบบรันที่ไหน ใครจ่ายค่า cloud และ license
9. การดูแลหลังส่งมอบ: ระยะเวลาและระดับบริการที่คาดหวัง ขอราคาแยกบรรทัด
10. งบและกรอบเวลา: ช่วงงบ วันที่ตายตัว และเวลาที่ทีมองค์กรให้ได้ต่อสัปดาห์

ก่อนส่ง brief ให้ vendor ต้องตรวจอะไรบ้าง?

ก่อนส่ง brief ให้ตรวจว่าตอบครบทุกหัวข้อ มีผู้ตัดสินใจฝั่งองค์กร ส่งฉบับเดียวกันให้ทุกราย และขอให้ทุกรายแยกราคาเป็นบรรทัดพร้อมแนบสมมติฐาน ใช้รายการด้านล่างตรวจทีละข้อ

• มีเจ้าของโครงการฝั่งธุรกิจหนึ่งคนที่ตัดสินใจเรื่องขอบเขตได้
• ส่ง brief ฉบับเดียวกันให้ทุกราย และตอบคำถามของรายหนึ่งให้ทุกรายเห็น
• แยก must-have กับ nice-to-have แล้ว และ must-have ทุกข้อมีเกณฑ์ตรวจรับ
• ระบุระบบที่ต้องเชื่อมพร้อมช่องทางเชื่อมต่อ หรือเขียนว่ายังไม่ทราบ
• ระบุว่ามีข้อมูลส่วนบุคคลหรือไม่ และ vendor จะเข้าถึงข้อมูลหรือไม่
• ระบุกรรมสิทธิ์ source code และสภาพแวดล้อม hosting ที่ต้องการ
• ขอให้แยกราคาพัฒนา ค่าดูแลรายปี และค่า infrastructure เป็นบรรทัด
• ขอให้แนบรายการสมมติฐาน สิ่งที่ไม่รวมในราคา และความเสี่ยงที่ vendor เห็น
• บอกช่วงงบและวันที่ตายตัว และเปิดทางให้เสนอแบบแบ่งช่วงหรือ Discovery ก่อน

เริ่มจาก brief ที่ชัด แล้วราคาจะเปรียบเทียบได้

ใบเสนอราคาที่ดีที่สุดไม่ใช่ใบที่ถูกที่สุด แต่เป็นใบที่สมมติฐานตรงกับโจทย์จริงขององค์กร การลงแรงเตรียม brief ก่อนขอราคาจึงคุ้มกว่าการต่อรองหลังได้ราคามาแล้ว หากองค์กรกำลังวางโครงการพัฒนาระบบและยังตอบบางหัวข้อใน brief ไม่ได้ ทีม UNIXDEV ช่วยไล่โจทย์ ขอบเขต และสมมติฐานร่วมกันได้ผ่านบริการ Custom Software Development โดยเสนอแบบแบ่งช่วงได้เมื่อยังมีคำถามสำคัญที่ต้องหาคำตอบก่อน

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

• Steve McConnell, Construx — Software Development's Cone of Uncertainty (2010): ความไม่แน่นอนของการประเมินตามระยะของโครงการ
• 18F — Buying custom software development services: รูปแบบสัญญา กรรมสิทธิ์ code และการตรวจคุณภาพงาน
• 18F — Budgeting and overseeing tech projects: การตั้งงบดูแลระบบต่อเนื่อง
• GOV.UK Service Manual — How the discovery phase works
• GOV.UK Service Manual — How the alpha phase works
• GOV.UK Service Manual — Writing user stories: รูปแบบ user story และ acceptance criteria
• iso25000.com — ISO/IEC 25010:2023 product quality model (เว็บไซต์อธิบายมาตรฐาน)
• OWASP — Application Security Verification Standard (ASVS)
• (ร่าง) ข้อตกลงการประมวลผลข้อมูล PDPA-DPA-6601
• บทความที่เกี่ยวข้อง: วิธีเลือกบริษัท Software Development ในไทย
• บทความที่เกี่ยวข้อง: Checklist การส่งมอบงานจาก vendor
• บทความที่เกี่ยวข้อง: Checklist สัญญา MA และ SLA

บทความโดย UNIXDEV Team · 23 ตุลาคม 2026 · ตัวอย่างราคาเป็นตัวเลขสมมติ และสรุปข้อกฎหมายเพื่อประกอบการวางแผน ไม่ใช่คำแนะนำทางกฎหมาย