วิธีเลือกบริษัท Software Development ในไทย: Checklist 10 ข้อที่องค์กรต้องดูก่อนเซ็นสัญญา

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

บทความนี้สำหรับ IT Manager ผู้บริหาร และฝ่ายจัดซื้อที่ได้รับ proposal จากหลายบริษัทแล้วและต้องเลือก หากยังอยู่ในขั้นเตรียมโจทย์ก่อนขอราคา อ่าน Checklist เตรียมข้อมูลก่อนขอใบเสนอราคาพัฒนาซอฟต์แวร์ ก่อน

ทำไมการเลือกบริษัท Software Development ถึงยากกว่าที่คิด?

เพราะทุกรายนำเสนอตัวเองได้ดีบนกระดาษ แต่ผลลัพธ์จริงขึ้นกับทีม กระบวนการ และเงื่อนไขสัญญา ซึ่งมองไม่เห็นจากสไลด์ วิธีลดความเสี่ยงคือถามคำถามที่ตรวจสอบได้และเทียบข้อเสนอในหัวข้อเดียวกัน

ตลาด รับพัฒนาซอฟต์แวร์ ในไทยมีตั้งแต่ freelancer เดี่ยวไปจนถึงบริษัทขนาดใหญ่ ความเสี่ยงที่ควรตรวจก่อนเซ็นสัญญา ได้แก่:

• ทีมที่ pitch ≠ ทีมที่ทำงานจริง
• Requirement เปลี่ยนนิดเดียวแต่ราคาพุ่งทันที
• ส่งงานแล้ว vendor หายไป ไม่มี support
• Source code ไม่ได้รับหลังจบโปรเจกต์

ต้องตรวจอะไรบ้างก่อนเลือกบริษัทรับทำซอฟต์แวร์ไทย?

ตรวจ 10 เรื่อง ได้แก่ portfolio ที่อ้างอิงได้ ทีมที่ทำงานจริง กระบวนการรับมือ requirement change, SLA หลัง go-live, มาตรฐานที่ได้รับรอง ความเป็นเจ้าของ source code การสื่อสาร ราคาที่ต่ำผิดสังเกต กระบวนการ QA และ escalation path แต่ละข้อด้านล่างมีคำถามที่ใช้ถาม vendor ได้ทันที

ข้อ 1: มี Portfolio จริงในอุตสาหกรรมเดียวกันไหม?

ระบบแต่ละอุตสาหกรรมมีข้อกำหนดต่างกัน เช่น ระบบการเงินต้องคำนึงถึง compliance, audit trail และ transaction integrity จึงควรถามว่า vendor เคยรับมือข้อกำหนดแบบไหนมาแล้ว และขอดู case study ที่อ้างอิงได้จริง ไม่ใช่แค่ logo บนสไลด์ หากเปิดเผยชื่อลูกค้าไม่ได้ ให้ขอคุยภายใต้ NDA หรือขอผู้ติดต่อสำหรับ reference check

ถามว่า: "ขอดูโปรเจกต์ที่ใกล้เคียงกับ use case เราได้ไหม และมีผู้ติดต่อที่เราสามารถ reference check ได้หรือเปล่า?"

ข้อ 2: ทีมที่ Pitch กับทีมที่ทำงานจริงคือคนเดียวกันไหม?

นี่คือกับดักคลาสสิก — senior engineer มา present แล้วส่งงานให้ทีมอื่นทำ หรือ subcontract ออกไปอีกทอดโดยลูกค้าไม่รู้ เมื่อคนที่เข้าใจ context อยู่กับโปรเจกต์ต่อเนื่อง ความเสี่ยงที่ requirement ตกหล่นระหว่างส่งต่อก็ลดลง ให้ระบุ lead และสัดส่วนเวลาไว้ใน proposal

ถามว่า: "ใครจะเป็น lead ในโปรเจกต์นี้? ทีมที่นั่ง present วันนี้จะ involve กี่ % ตลอดโปรเจกต์? มีการใช้ subcontractor ส่วนไหนบ้าง?"

ข้อ 3: มีกระบวนการรับมือ Requirement Change อย่างไร?

Requirement เปลี่ยนเป็นเรื่องปกติในโปรเจกต์ซอฟต์แวร์ ปัญหาไม่ได้อยู่ที่การเปลี่ยน แต่อยู่ที่ไม่มี process รับมือ vendor ที่ดีต้องมี change request process ที่โปร่งใส ประเมิน impact ต่อขอบเขต งบ และเวลาได้ และตกลงกันก่อนเริ่มงานเพิ่ม โดยแยกจากการแก้ข้อบกพร่องตามเกณฑ์รับมอบ

ถามว่า: "ถ้า scope เปลี่ยนระหว่างโปรเจกต์ กระบวนการ approve และ price adjustment เป็นอย่างไร? มี change log ไหม? อัตราคิดค่างานเพิ่มคำนวณจากอะไร?"

ข้อ 4: SLA หลัง Go-Live เป็นอย่างไร?

ระยะและขอบเขตการรับประกันต่างกันมากในแต่ละข้อเสนอ บางฉบับระบุแค่ระยะเวลาโดยไม่บอกว่าครอบคลุมอะไร บางฉบับอาจไม่ระบุ SLA เลย ระบบ mission-critical ต้องการ managed support ที่ชัดเจนว่า response time คือกี่ชั่วโมง และ escalation ทำได้อย่างไร รายละเอียดการเขียนสัญญาดูแลระบบอ่านต่อได้ใน Checklist สัญญา MA และ SLA

ถามว่า: "ระยะรับประกันกี่วันและครอบคลุมอะไร? หลังหมดรับประกันมี SLA กี่ระดับ? critical bug fix ใช้เวลากี่ชั่วโมง? มี on-call team ไหม?"

ข้อ 5: บริษัทได้รับการรับรองมาตรฐานอะไร เช่น ISO 9001 หรือ ISO/IEC 29110?

การรับรอง ISO 9001 (ระบบบริหารคุณภาพ) และ ISO/IEC 29110 (lifecycle profile ด้านวิศวกรรมซอฟต์แวร์) บ่งบอกว่าบริษัทมี process ที่ผ่านการตรวจจากหน่วยรับรองภายนอก แต่เป็นมาตรฐานด้านกระบวนการ ไม่ได้แทนข้อกำหนดเฉพาะของอุตสาหกรรม เช่น ของหน่วยงานกำกับธนาคารหรือภาครัฐ ซึ่งต้องตรวจแยก ISO/IEC 29110 พัฒนาขึ้นสำหรับ Very Small Entities ซึ่ง Laporte และ O'Connor อ้างนิยามว่าเป็นองค์กร แผนก หรือโปรเจกต์ที่มีคนไม่เกิน 25 คน ด้านความมั่นคงปลอดภัยสารสนเทศให้ถามถึง ISO/IEC 27001 และทุกมาตรฐานให้ตรวจชื่อหน่วยรับรอง ขอบเขต (scope) และวันหมดอายุ

ถามว่า: "บริษัทมีการรับรองมาตรฐานอะไรบ้าง? ใครเป็นผู้ออกใบรับรอง ขอบเขตครอบคลุมงานพัฒนาซอฟต์แวร์หรือไม่? Certificate ยังมีผลอยู่ไหม? audit ล่าสุดเมื่อไร?"

ข้อ 6: Source Code เป็นของใครหลังจบโปรเจกต์?

ถ้าไม่ตรวจจุดนี้ก่อนลงนาม อาจพบภายหลังว่าไม่ได้รับ codebase หรือไม่มีสิทธิ์แก้ไขเอง ทำให้ต้องพึ่ง vendor เดิมทุกครั้ง พระราชบัญญัติลิขสิทธิ์ พ.ศ. 2537 มาตรา 10 (ตามตัวบทฉบับเดิมที่แปลเป็นภาษาอังกฤษบน WIPO Lex) กำหนดว่าลิขสิทธิ์ในงานที่สร้างขึ้นโดยการว่าจ้างเป็นของผู้ว่าจ้าง เว้นแต่ผู้สร้างสรรค์และผู้ว่าจ้างตกลงกันไว้เป็นอย่างอื่น สัญญาจึงกำหนดต่างจากหลักทั่วไปได้ ต้องเขียนให้ชัด ทั้งนี้ พ.ร.บ. ฉบับนี้มีการแก้ไขเพิ่มเติมแล้วหลายครั้ง ล่าสุดถึงฉบับที่ 5 พ.ศ. 2565 (WIPO Lex ฉบับปรับปรุง) จึงควรให้ฝ่ายกฎหมายตรวจกับตัวบทฉบับปัจจุบัน

แยก 3 ส่วนให้ชัด: โค้ดที่พัฒนาเฉพาะโปรเจกต์นี้ ส่วนประกอบที่ vendor มีอยู่ก่อนแล้วนำมาใช้ซ้ำ และ third-party / open-source library ที่ใช้ตาม license ของเจ้าของเดิม

ถามว่า: "สัญญาระบุไหมว่าโค้ดที่พัฒนาเฉพาะและเอกสารเป็นของใคร? ส่วนที่ vendor มีอยู่ก่อนเราได้สิทธิ์ใช้แบบไหน? มี dependency ที่ license จำกัดการใช้งานไหม?"

ข้อ 7: วิธีสื่อสารและรายงานความคืบหน้าเป็นอย่างไร?

โปรเจกต์ที่ไม่มีรายงานสม่ำเสมอมักซ่อนปัญหาไว้จนสายเกินแก้ vendor ที่ดีต้องมี sprint review, progress report หรืออย่างน้อย weekly status update ที่ลูกค้าตรวจสอบได้จริง ไม่ใช่แค่ตอบ chat เป็นครั้งคราว

ถามว่า: "คุณใช้ project management tool อะไร? ลูกค้าสามารถดู progress real-time ได้ไหม? มีช่องทาง escalate ถ้า PM ไม่ตอบ?"

ข้อ 8: ราคาต่ำผิดสังเกต — มีความเสี่ยงอะไรบ้าง?

ถ้า quote ฉบับหนึ่งต่ำกว่าฉบับอื่นอย่างเห็นได้ชัด ให้หาคำตอบก่อนว่าทำไม ความต่างอาจมาจากขอบเขตที่เข้าใจไม่ตรงกัน การตัด QA หรือ documentation ออก การใช้ทีมที่ประสบการณ์น้อยกว่า หรือการตั้งราคาต่ำเพื่อชนะงานแล้วคิดเพิ่มผ่าน change request ภายหลัง วิธีตรวจที่ได้ผลคือวางทุกข้อเสนอลงตารางเปรียบเทียบในหัวข้อถัดไป

ถามว่า: "ราคานี้ครอบคลุมอะไรบ้าง? QA, DevOps, documentation และ training รวมอยู่ด้วยไหม? ถ้า scope เดิมไม่เปลี่ยน ราคาสุดท้ายจะใกล้เคียงกับ quote นี้ไหม?"

ข้อ 9: มีประกันคุณภาพ (QA) อยู่ใน Process หรือเปล่า?

QA ที่ดีไม่ใช่แค่การ test ก่อน deploy แต่ต้องฝังอยู่ตลอด development cycle ตั้งแต่ unit test, integration test ไปจนถึง UAT

ด้านความปลอดภัย NIST SP 800-218 (SSDF) ระบุว่าเป็น "common vocabulary" ที่ช่วยผู้ซื้อสื่อสารกับ supplier ในกระบวนการจัดหา ใช้เป็นกรอบถามเรื่อง code review และการจัดการช่องโหว่ใน dependency ได้

ถามว่า: "ทีม QA แยกจาก developer ไหม? มีเกณฑ์ test coverage ขั้นต่ำไหม? bug tracking ใช้ tool อะไร? ตรวจช่องโหว่ของ library ที่ใช้อย่างไร?"

ข้อ 10: ถ้าโปรเจกต์มีปัญหา Escalation Path คืออะไร?

เมื่อโปรเจกต์ล่าช้าหรือมีข้อพิพาท ต้องรู้ว่าจะคุยกับใครถ้า PM ตอบไม่ได้ vendor ที่จริงจังควรมี escalation path ที่ชัดเจน พร้อมผู้รับผิดชอบแต่ละระดับ

ถามว่า: "ถ้าเราไม่พอใจผลงานหรือ timeline ล่าช้า เราต้องพูดกับใคร? มี SLA สำหรับการตอบรับ escalation ไหม?"

เปรียบเทียบ Proposal จากหลายบริษัทอย่างไรให้ยุติธรรม?

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

ตารางด้านล่างคือ 9 หัวข้อที่ควรเห็นในทุก proposal นำไปทำ spreadsheet โดยเพิ่มคอลัมน์ละหนึ่ง vendor

ทำให้ราคาเทียบกันได้

• เติมช่องว่าง: งานที่ฉบับหนึ่งไม่รวม ให้ขอราคาเป็น option หรือประเมินเองแล้วบวกเข้าไป
• ปรับสมมติฐานให้ตรงกัน: เช่น ใครเตรียม server ใครย้ายข้อมูล
• รวมต้นทุนหลังส่งมอบ: ระยะรับประกันและค่า MA ทำให้ต้นทุนตลอดอายุระบบต่างกัน
• ถามเป็นลายลักษณ์อักษร: ส่งคำถามชุดเดียวกันให้ทุกราย และเก็บคำตอบแนบสัญญา

ตัวอย่าง: ข้อเสนอที่ถูกกว่า ถูกกว่าจริงหรือไม่?

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

สมมติองค์กรได้รับ proposal 2 ฉบับสำหรับระบบเดียวกัน ฉบับ A เสนอ 1,200,000 บาท ฉบับ B เสนอ 1,500,000 บาท ต่างกัน 300,000 บาท เมื่อวางลงตาราง 9 หัวข้อ พบว่าฉบับ A ระบุใน exclusions ว่าไม่รวมการย้ายข้อมูลจากระบบเดิม และไม่รวมการตั้งค่า deploy บน production ขณะที่ฉบับ B รวมทั้งสองงาน

• องค์กรขอราคา option จาก vendor A: งานย้ายข้อมูล 180,000 บาท และงานตั้งค่า deploy 80,000 บาท
• ราคาฉบับ A บนขอบเขตเดียวกัน = 1,200,000 + 180,000 + 80,000 = 1,460,000 บาท
• ส่วนต่างจริงกับฉบับ B = 1,500,000 − 1,460,000 = 40,000 บาท จากเดิมที่ดูเหมือนต่าง 300,000 บาท

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

Red Flags อะไรบ้างที่ควรหยุดก่อนเซ็นสัญญา?

หยุดและถามต่อเมื่อพบ 5 สัญญาณนี้: portfolio ตรวจสอบไม่ได้ ทีม pitch มีแต่ฝ่ายขาย สัญญาไม่ระบุ IP QA วัดผลไม่ได้ และราคาเปลี่ยนหลังชนะงาน สัญญาณเหล่านี้ไม่ได้แปลว่า vendor ไม่ดีเสมอไป แต่เป็นจุดที่ต้องได้คำตอบชัดก่อนลงนาม

• ไม่มี portfolio จริงที่ verify ได้ — มีแต่ logo บนสไลด์ ไม่มีรายละเอียดโปรเจกต์ ไม่มี contact ให้ reference check
• ทีม pitch มาจาก sales ล้วน — ไม่มี technical lead ร่วม present หรือตอบคำถาม technical ไม่ได้
• สัญญาไม่ระบุ IP ownership ชัดเจน — ไม่ระบุว่าใครได้ source code เอกสาร และสิทธิ์ในส่วนที่ vendor มีอยู่ก่อน
• ไม่มีกระบวนการ QA ที่วัดได้ — ตอบแค่ว่า "เราเทสให้ครบ" โดยไม่มี test plan, bug tracker หรือ acceptance criteria
• ราคา quote เปลี่ยนหลังชนะงาน — โดยอ้าง "ข้อมูลที่ได้รับมาไม่ครบ" ทั้งที่ RFP ระบุครบแล้ว หรือมีข้อความ "อาจมีค่าใช้จ่ายเพิ่มเติม" โดยไม่ระบุเงื่อนไข

สัญญาณเตือนหลังเซ็นสัญญาแล้วว่างบกำลังบาน ดู5 สัญญาณเตือนงบบานปลาย

ควรถามอะไรตอน RFP หรือ Demo?

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

• "ให้เล่าโปรเจกต์ที่ล้มเหลวหรือมีปัญหาสักหนึ่งครั้ง และคุณแก้อย่างไร?"
• "ถ้า requirement เปลี่ยน 20% กลางโปรเจกต์ กระบวนการเป็นอย่างไร?"
• "ทีมที่จะทำงานกับเรามีกี่คน และ seniority level เป็นอย่างไร?"
• "คุณจะ handover documentation, runbook และ source code ให้เราตอนไหน และในรูปแบบอะไร?" — รายการส่งมอบที่ควรขอดูได้ใน Checklist รับมอบงานจาก vendor

ถ้าโจทย์คือปรับปรุงระบบเดิม ให้ถามว่า vendor จะประเมินระบบเดิมอย่างไรก่อนเสนอแนวทาง ดู ทางเลือก Legacy System Modernization

ก่อนเซ็นสัญญาต้องเช็กอะไรเป็นขั้นสุดท้าย?

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

• ตรวจ 10 ข้อกับทุก vendor ที่เข้ารอบ วางลงตาราง 9 หัวข้อ และเก็บคำตอบเป็นลายลักษณ์อักษร
• ทำ reference check กับ vendor รอบสุดท้าย
• ให้ฝ่ายกฎหมายตรวจข้อ IP และ license ของ third-party
• ระบุ lead และทีมหลักในสัญญาหรือภาคผนวก
• ผูกงวดชำระกับผลงานที่มีเกณฑ์ตรวจรับ แยกรับประกัน MA และ change request ให้ชัด

สรุป: เลือก vendor อย่างไรให้ลดความเสี่ยง?

ใช้ checklist 10 ข้อคัดกรองบริษัท แล้วใช้ตาราง 9 หัวข้อเปรียบเทียบข้อเสนอบนขอบเขตเดียวกัน การเลือก บริษัทรับทำซอฟต์แวร์ไทย ที่เหมาะสมไม่ได้ขึ้นกับราคาอย่างเดียว แต่ขึ้นกับ process ความโปร่งใส และการที่ทีมที่นั่ง present คือทีมที่จะส่งมอบงานจริง

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

หากองค์กรของคุณกำลังมองหาพาร์ทเนอร์ด้าน outsource software development thailand UNIXDEV ให้บริการ Custom Software Development ภายใต้กระบวนการตามมาตรฐาน ISO/IEC 29110 (รายละเอียดใบรับรองดูได้ที่หน้า เกี่ยวกับเรา) มีประสบการณ์ราว 308 โปรเจกต์กับราว 71 องค์กรตลอด 12 ปี ครอบคลุมภาครัฐ การเงินและธนาคาร โทรคมนาคม สื่อ และองค์กรขนาดใหญ่ ส่งรายละเอียดโปรเจกต์มาเพื่อรับข้อเสนอที่ระบุขอบเขต สมมติฐาน และสิ่งที่ไม่รวมไว้ชัดเจน

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

• WIPO Lex — Copyright Act B.E. 2537 (1994), Thailand (ตัวบทฉบับเดิม): มาตรา 10 ว่าด้วยลิขสิทธิ์ในงานที่สร้างโดยการว่าจ้าง
• WIPO Lex — Copyright Act B.E. 2537 (1994), amended up to Copyright Act (No. 5) B.E. 2565 (2022): ฉบับปรับปรุงล่าสุดที่ควรให้ฝ่ายกฎหมายใช้ตรวจ
• Laporte & O'Connor — Systems and Software Engineering Standards for Very Small Entities: ที่มาและนิยาม VSE ของ ISO/IEC 29110
• NIST SP 800-218 — Secure Software Development Framework (SSDF) v1.1: แนวปฏิบัติการพัฒนาซอฟต์แวร์อย่างปลอดภัย และการใช้เป็นภาษากลางระหว่างผู้ซื้อกับ supplier
• Checklist เตรียมข้อมูลก่อนขอใบเสนอราคาพัฒนาซอฟต์แวร์
• Checklist รับมอบงานจาก vendor ซอฟต์แวร์
• Checklist สัญญา MA และ SLA สำหรับระบบ IT
• Managed Services vs In-house IT
• Web Development vs Custom Software Development
• บทความทั้งหมดจาก UNIXDEV

บทความโดย UNIXDEV Team · unixdev.co.th · ปรับปรุง 23 ตุลาคม 2026