- ผู้รับทำเว็บไซต์และแอปในไทยมีสามแบบ ฟรีแลนซ์ เอเจนซีขนาดเล็ก และ Software House แต่ละแบบเหมาะกับงานคนละขนาด
- วัดทุกรายด้วยคำถามชุดเดียวกัน 5 หมวด หลักฐาน กระบวนการ สัญญา ความเหมาะสม และสัญญาณเตือน
- สามเรื่องที่ควรถามก่อน ใครเขียนโค้ดจริง โค้ดกับบัญชีทุกใบเป็นของใคร และคุณเห็นงานจริงบ่อยแค่ไหน
- เจอสัญญาณเตือนข้อใดข้อหนึ่ง ให้พักรายนั้นไว้ก่อน แม้คะแนนรวมจะสูง
ผู้รับงานสามแบบ และวิธีเทียบที่ยุติธรรมกับทุกราย
การเลือกบริษัทรับทำเว็บไซต์คล้ายการเลือกอู่ซ่อมรถประจำ คุณอยากเห็นรถที่อู่เคยซ่อมแล้วยังวิ่งดี รู้ว่าช่างคนไหนลงมือ ได้ใบประเมินที่เขียนชัด และเก็บเล่มทะเบียนรถไว้เอง งานซอฟต์แวร์ก็เหมือนกัน เล่มทะเบียนในที่นี้คือ Source Code โดเมน และบัญชีระบบทุกใบ
ในตลาดไทยมีผู้รับงานสามแบบ ฟรีแลนซ์ทำงานคนเดียวหรือสองคน เหมาะกับงานเล็กที่ขอบเขตชัด เอเจนซีขนาดเล็กมักเด่นด้านออกแบบและการตลาด ทำเว็บไซต์บริษัทหรือร้านค้าออนไลน์บนระบบสำเร็จรูปได้เร็ว Software House มีทีมวิศวกรประจำ มีขั้นตอนทดสอบและดูแลหลังส่งมอบ เหมาะกับระบบที่ต่อกับข้อมูลภายในหรือต้องใช้ไปอีกหลายปี ทุกแบบมีรายที่ดีและรายที่ควรเลี่ยง บทนี้จึงไม่จัดอันดับบริษัท มีแต่คำถามที่ใช้วัดได้ทุกราย รวมถึงเรา
หมวด 1 หลักฐาน ผลงานที่เปิดใช้ได้ และคนที่เขียนโค้ดจริง
ผลงานที่ดีคือผลงานที่คุณเปิดใช้เองได้ ขอลิงก์เว็บไซต์ที่ยังออนไลน์หรือชื่อแอปในสโตร์ แล้วลองบนมือถือของคุณ ดูความเร็วและหน้าจอภาษาไทย ภาพหน้าจอในสไลด์บอกได้แค่ว่าเคยมีงานนั้น แล้วขอเบอร์ลูกค้าเก่าสองราย ถามว่างานเสร็จตามกำหนดไหม หลังส่งมอบมีปัญหาแล้วได้คำตอบเร็วแค่ไหน และจะจ้างอีกหรือเปล่า
คำถามที่คนมักลืมคือใครเขียนโค้ดจริง คนที่มาเสนองานมักเป็นฝ่ายขาย ขอพบวิศวกรที่จะทำงานของคุณสักครั้งก่อนเซ็นสัญญา ถามตรง ๆ ว่างานส่วนไหนส่งต่อให้คนนอกบริษัท และถ้าคนหลักลาออกกลางทาง ใครรับช่วง ผู้รับงานที่มีทีมของตัวเองตอบได้ทันที
หมวด 2 กระบวนการ ต้นแบบ เดโม การทดสอบ และคนตรวจโค้ด
กระบวนการที่ดีมีสี่จุดที่คุณสังเกตได้จากข้างนอก จุดแรกคือ Prototype หน้าจอที่กดได้ก่อนเขียนโค้ดจริง แก้ภาพร่างถูกกว่าแก้ระบบที่สร้างเสร็จแล้วมาก จุดที่สองคือจังหวะเดโม คุณจะได้เห็นงานจริงทุกสัปดาห์ หรือเห็นครั้งแรกตอนส่งมอบ ช่วงห่างระหว่างเดโมคือช่วงที่ความเข้าใจผิดสะสมโดยไม่มีใครเห็น
จุดที่สามคือการทดสอบ ใครทดสอบ และมี Staging ระบบทดลองที่แยกจากของจริงให้ทีมคุณลองก่อนเปิดใช้หรือเปล่า ถ้าระบบเก็บข้อมูลลูกค้า ดูรายการตรวจใน Cybersecurity ของแอปยุค Vibe Code จุดที่สี่คือ Code Review ถามว่า “โค้ดที่เขียนเสร็จ ใครตรวจก่อนขึ้นระบบจริง” คำตอบที่ดีคือชื่อวิศวกรอาวุโส
หมวด 3 สัญญา ขอบเขต ราคา งวดจ่าย Source Code และบัญชีทุกใบ
สัญญาที่ดีเริ่มจาก Scope ที่เขียนเป็นรายการ ว่าระบบทำอะไร อะไรไม่รวม และขอเพิ่มกลางทางคิดอย่างไร ราคาคงที่ตามขอบเขตเหมาะเมื่อโจทย์ชัด ราคาตามเวลาที่ใช้เหมาะกับงานที่ยังหาคำตอบอยู่ ใช้ได้ทั้งคู่ ขอให้สัญญาบอกชัดว่าแบบไหน และผูกงวดจ่ายกับงานที่ตรวจรับแล้วตาม Acceptance Criteria มากกว่าวันที่ในปฏิทิน
ข้อที่ต้องอ่านช้า ๆ คือ Source Code Ownership สัญญาควรระบุว่าเมื่อจ่ายครบ Source Code ฐานข้อมูล เอกสารระบบ และงานออกแบบเป็นของบริษัทคุณ และนำไปให้ทีมอื่นพัฒนาต่อได้ ถ้าผู้รับงานใช้ชิ้นส่วนที่เป็นลิขสิทธิ์ของเขาเอง ต้องระบุว่าคุณใช้ต่อได้ภายใต้เงื่อนไขใด
อีกเรื่องที่ดูเล็กคือบัญชีต่าง ๆ โดเมน โฮสติ้ง บัญชีคลาวด์ บัญชีนักพัฒนาของ App Store และ Google Play บัญชี LINE OA และบัญชีโฆษณา ทุกบัญชีควรเปิดในชื่อบริษัทคุณ จ่ายด้วยบัตรของบริษัท แล้วให้สิทธิ์ผู้รับงานเข้าไปทำงาน บัญชีในชื่อผู้รับงานจะโอนยากในวันที่คุณอยากเปลี่ยนผู้ดูแล นี่คือ Vendor Lock-in ที่อยู่นอกโค้ด
อีกสี่ข้อในหมวดนี้ ระยะรับประกัน ว่าแก้ข้อบกพร่องให้กี่เดือน แผนดูแลหลังหมดประกันพร้อมเวลาตอบกลับที่เขียนเป็น SLA ข้อสัญญาตาม PDPA ว่าผู้รับงานเข้าถึงข้อมูลลูกค้าของคุณได้แค่ไหนและลบเมื่อไหร่หลังจบงาน และเอกสารภาษี ผู้รับงานที่จดทะเบียนภาษีมูลค่าเพิ่มออกใบกำกับภาษีได้ บางรายออกเป็น e-Tax Invoice ส่วนฟรีแลนซ์ที่ไม่ได้จดทะเบียนออกได้เพียงใบเสร็จรับเงิน สถานะนิติบุคคลตรวจได้จากกรมพัฒนาธุรกิจการค้า
หมวด 4 ความเหมาะสม ขนาดทีม ภาษา อุตสาหกรรม และการกล้าปฏิเสธ
ขนาดทีมควรพอดีกับงาน ถามว่างานของคุณมีกี่คน และแต่ละคนดูแลงานอื่นพร้อมกันอีกกี่งาน ส่วนภาษา ถ้าผู้ใช้คือพนักงานไทย หน้าจอและคู่มือต้องเป็นภาษาไทยที่อ่านรู้เรื่อง ถ้าผู้บริหารหรือบริษัทแม่อยู่ต่างประเทศ เอกสารระบบและรายงานความคืบหน้าควรมีภาษาอังกฤษ ถามว่าใครในทีมสื่อสารได้ทั้งสองภาษา และใครจะตอบคุณในแต่ละวัน
ถ้าเขาไม่เคยทำธุรกิจแบบคุณ ดูว่าถามลึกพอหรือเปล่าในการประชุมครั้งแรก ข้อสุดท้ายคือการกล้าปฏิเสธ ผู้รับงานที่ดีบอกคุณเมื่อฟีเจอร์ที่ขอยังไม่ควรทำ หรือเมื่อระบบสำเร็จรูปคุ้มกว่าการสร้างเอง รายที่รับทุกข้อในการประชุมแรก มักกลับมาคิดราคาส่วนเพิ่มทีหลัง
| หมวด | สิ่งที่ถาม | คำตอบที่ดี | สัญญาณเตือน |
|---|---|---|---|
| หลักฐาน | ขอลิงก์ผลงานที่ยังใช้งานอยู่ | ส่งลิงก์หรือชื่อแอปให้ลองเอง | มีแต่ภาพในสไลด์ |
| หลักฐาน | ใครเขียนโค้ดงานนี้ | นัดพบวิศวกรก่อนเซ็น บอกชัดว่าส่วนไหนทำเอง | ตอบว่า “ทีมเรา” โดยไม่มีชื่อคน |
| กระบวนการ | จะได้เห็นงานจริงบ่อยแค่ไหน ใครตรวจโค้ด | เดโมทุกรอบมีวันที่แน่นอน คนอาวุโสตรวจโค้ด | เห็นครั้งแรกตอนส่งมอบ |
| สัญญา | Source Code เป็นของใครเมื่อจ่ายครบ | ของบริษัทคุณ เขียนไว้ในสัญญา | “ค่อยคุยกันตอนจบงาน” |
| สัญญา | โดเมนและบัญชีสโตร์เปิดในชื่อใคร | ชื่อบริษัทคุณ ผู้รับงานได้สิทธิ์เข้าทำงาน | ชื่อผู้รับงาน |
| สัญญา | งวดจ่ายผูกกับอะไร | งานที่ตรวจรับแล้วแต่ละช่วง | จ่ายก้อนใหญ่ก่อนเริ่ม |
| ความเหมาะสม | มีอะไรในโจทย์ที่ยังไม่ควรทำ | ชี้ได้อย่างน้อยหนึ่งข้อ พร้อมเหตุผล | รับทุกข้อ |
กรณีจำลอง
โรงงานบรรจุภัณฑ์กระดาษในนครปฐม (ชื่อและรายละเอียดสมมติ) ต้องการเว็บแอปให้ลูกค้าสั่งผลิตซ้ำและดาวน์โหลดใบกำกับภาษีได้เอง สองรายเสนอราคาใกล้กัน รายแรกมีผลงานเป็นภาพในสไลด์ ส่งฝ่ายขายมาทุกครั้ง และเสนอเปิดโดเมนกับโฮสติ้งในชื่อตัวเอง “เพื่อความสะดวก” รายที่สองส่งลิงก์ระบบของลูกค้าเก่าให้ลองใช้ พาวิศวกรมาประชุม และเสนอ Prototype ให้กดก่อนเขียนโค้ด
ผู้จัดการโรงงานกับหัวหน้าบัญชีให้คะแนนแยกกันด้วยตาราง 5 หมวด รายแรกได้คะแนนดีเรื่องความเหมาะสม แต่ติดสัญญาณเตือนสองข้อ บัญชีในชื่อผู้รับงาน และเรื่อง Source Code ที่สัญญาเขียนว่า “ตามตกลง” รายแรกไม่แก้สองข้อนี้ โรงงานจึงเลือกรายที่สอง
วิธีให้คะแนน 5 หมวดในครึ่งชั่วโมง
ใช้ตารางข้างบนเป็นแบบให้คะแนน หนึ่งคอลัมน์ต่อผู้รับงานหนึ่งราย
ตารางให้คะแนน 5 หมวด
- ขั้น 1 ส่งคำถามล่วงหน้า ส่งคำถามชุดเดียวกันให้ทุกราย และขอให้ตอบพร้อมหลักฐาน
- ขั้น 2 ให้คะแนน 0 ถึง 2 0 คือตอบไม่ได้หรือตอบอ้อม 1 คือตอบได้แต่ไม่มีหลักฐาน 2 คือมีหลักฐาน เช่น ลิงก์ ชื่อคน หรือร่างสัญญา
- ขั้น 3 แยกสัญญาณเตือนออกจากคะแนน รายที่ติดข้อใดในรายการถัดไป พักไว้จนกว่าจะแก้
- ขั้น 4 ให้สองคนให้คะแนนแยกกัน แล้วคุยกันเฉพาะข้อที่คะแนนต่างกัน
- ขั้น 5 ตัดสินเมื่อคะแนนใกล้กัน เลือกรายที่คุยกับคนเขียนโค้ดจริงแล้วเข้าใจตรงกันเร็วกว่า
ถ้างานที่จ้างมีส่วน AI คำถามเรื่องโมเดล ข้อมูล และสิทธิ์ของ AI Agent อยู่ใน ก่อนจ้างบริษัทพัฒนา AI ต้องเตรียมอะไรบ้าง
หมวด 5 สัญญาณเตือนที่ควรหยุดก่อน
- เสนอราคาได้ทันทีโดยยังไม่ถามเรื่องธุรกิจของคุณ
- ขอเงินก้อนใหญ่ก่อนเริ่มงาน โดยไม่มีงวดที่ผูกกับการตรวจรับ
- ไม่ให้พบคนที่จะเขียนโค้ดจริง
- สัญญาไม่พูดถึง Source Code หรือเขียนว่าเป็นของผู้รับงาน
- ยืนยันจะเปิดโดเมน โฮสติ้ง หรือบัญชีสโตร์ในชื่อตัวเอง
- ไม่มีขอบเขตเป็นลายลักษณ์อักษร
- ตอบเรื่องดูแลหลังส่งมอบว่า “ติดต่อได้ตลอด” โดยไม่มีเวลาตอบกลับ
สำหรับทีมพัฒนา · รายการตรวจตอนรับมอบโค้ด
Repository อยู่ในบัญชีองค์กรของลูกค้าตั้งแต่วันแรก พร้อมประวัติ Commit ครบ README บอกวิธีติดตั้งบนเครื่องใหม่จนรันได้ โดยคนที่ไม่ได้เขียนโค้ดทำตามได้ มีไฟล์ .env.example ส่วนค่าลับจริงอยู่ในระบบจัดการ Secret แยกจากโค้ด สคริปต์ Migration ของฐานข้อมูลอยู่ใน Repository มี Pipeline CI/CD ที่รันการทดสอบอัตโนมัติ Dev, Staging และ Production แยกกัน Backup ตั้งเวลาไว้และเคยซ้อมกู้คืนจริง มีรายการบัญชีบริการภายนอกพร้อมชื่อเจ้าของ และรายการ License ของไลบรารี เรื่องซ้อมกู้ระบบอ่านต่อใน ระบบล่มตอนยอดขายพีค
เราตอบเช็กลิสต์นี้อย่างไร
ก่อนเสนอราคา DNA Maker ขอคุยกับคนที่จะใช้ระบบจริง ฝ่ายขาย บัญชี คลัง หรือหน้าร้าน แล้วเขียนขอบเขตเป็นรายการที่คุณอ่านแล้วเห็นภาพ พร้อมบอกตรง ๆ ว่าอะไรยังไม่ควรทำในเฟสแรก คำถามทุกข้อในตารางข้างบนถามเราได้ และเราตอบด้วยลิงก์ผลงานและร่างสัญญา
ทีมที่ทำงานให้คุณคือทีมของ DNA Maker เอง ไม่มีการจ้างช่วง คุณได้ลอง Prototype ก่อนเขียนโค้ด เห็นเดโมบนข้อมูลจริงทุกสัปดาห์ วิศวกรอาวุโสตรวจโค้ดก่อนขึ้นระบบ ขอบเขตและราคาคงที่ก่อนเริ่มงาน เราส่งมอบ Source Code และเอกสารระบบตามขอบเขต เราทำงานแบบนี้ให้ธนาคาร โรงพยาบาล และกลุ่มบริษัทขนาดใหญ่ของไทย ดูรายละเอียดที่ มาตรฐานการพัฒนาระบบระดับ Production และ รับเขียนโปรแกรมและพัฒนาซอฟต์แวร์ หรือถาม Dream ในหน้าแชต
SOFTWARE ENGINEERING GLOSSARY
คลังคำศัพท์การพัฒนาซอฟต์แวร์
| คำศัพท์ | คืออะไร | ตัวอย่างที่เข้าใจง่าย | คำถามที่ผู้บริหารควรถามทีมพัฒนา |
|---|---|---|---|
| Scope | รายการว่าระบบทำอะไร และอะไรไม่รวม | “สั่งผลิตซ้ำได้ ระบบคะแนนอยู่เฟสสอง” | ขอเพิ่มกลางทาง ราคาคิดอย่างไร |
| Prototype | หน้าจอที่กดได้ก่อนเขียนโค้ดจริง | ลูกค้าลองกดหน้าสั่งซื้อก่อนสร้างระบบ | เราได้ลองต้นแบบเมื่อไหร่ |
| Source Code Ownership | ข้อตกลงว่าโค้ดและเอกสารเป็นของใครหลังส่งมอบ | สัญญาระบุว่าเป็นของบริษัทคุณเมื่อจ่ายครบ | ส่วนไหนยังเป็นลิขสิทธิ์ของผู้รับงาน |
| Vendor Lock-in | สภาพที่เปลี่ยนผู้ดูแลไม่ได้ เพราะโค้ดหรือบัญชีผูกกับรายเดิม | โดเมนอยู่ในชื่อผู้รับงาน จึงย้ายไม่ได้ | ถ้าเราเปลี่ยนทีมพัฒนาปีหน้า มีอะไรที่ย้ายไม่ได้ |
| Handover | การส่งมอบโค้ด เอกสาร บัญชี และความรู้ให้ทีมที่ดูแลต่อ | ทีมใหม่ติดตั้งระบบจากเอกสารได้เอง | ใครทดสอบว่าติดตั้งตามเอกสารได้จริง |