ธุรกิจและงบประมาณอ่าน 17 นาที

เลือกบริษัทรับทำซอฟต์แวร์ยังไง คำถามที่ควรถามก่อนเซ็นสัญญา

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

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

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

สัญญาณแรกอยู่ในการคุยครั้งแรก

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

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

ดูผลงานให้ถูกจุด

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

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

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

ใครเป็นคนทำงานจริง

คนที่คุยตอนขายกับคนที่เขียนโค้ดมักเป็นคนละคน นั่นเป็นเรื่องปกติ แต่คุณควรรู้ว่าใครจะอยู่กับโปรเจกต์ของคุณจริง

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

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

ระหว่างทาง คุณจะเห็นอะไรบ้าง

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

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

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

สิ่งที่ต้องอยู่ในสัญญาพัฒนา

ใบเสนอราคาบอกว่าจะได้อะไร สัญญาบอกว่าถ้าไม่ได้ตามนั้นจะเกิดอะไรขึ้น ข้อต่อไปนี้ควรเขียนไว้เป็นลายลักษณ์อักษร ไม่ใช่แค่ตกลงกันปากเปล่า

  1. ขอบเขตงานแนบท้าย รวมรายการที่ไม่รวมอยู่ในงานนี้ด้วย ขอบเขตที่มีแค่ชื่อฟีเจอร์ เช่น "ระบบสมาชิก" บรรทัดเดียว ตีความได้กว้างจนเถียงกันได้ทุกข้อ
  2. เกณฑ์ตรวจรับของแต่ละงวด ว่าต้องทำอะไรได้ถึงจะถือว่าผ่าน
  3. งวดเงินผูกกับงานที่ตรวจรับได้จริง ไม่ใช่ผูกกับวันที่อย่างเดียว
  4. กรรมสิทธิ์ในซอร์สโค้ดหลังชำระเงินครบ และถ้าบริษัทใช้ชิ้นส่วนที่เขาพัฒนาไว้ก่อนแล้ว ส่วนนั้นคุณได้สิทธิ์ใช้ต่อแบบไหน
  5. บัญชีเซิร์ฟเวอร์ โดเมน และบัญชีร้านแอป เปิดในชื่อใคร
  6. ระยะประกันนับจากวันไหน วันส่งมอบไฟล์หรือวันที่ระบบขึ้นใช้งานจริง
  7. ถ้าต้องยกเลิกกลางทาง จ่ายเท่าไหร่ และได้อะไรกลับไปบ้าง

สัญญาที่มูลค่าสูงควรให้ฝ่ายกฎหมายขององค์กรอ่านก่อนเซ็นเสมอ รายการข้างบนไม่ได้แทนคำแนะนำทางกฎหมาย แต่ช่วยให้รู้ว่าต้องถามหาอะไร

สัญญาณเตือนที่ควรหยุดคิดก่อนเซ็น

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

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

เทียบใบเสนอราคาหลายเจ้าให้เป็นธรรม

ใบเสนอราคาที่ได้มาจากการเล่าโจทย์คนละแบบ เทียบกันไม่ได้ตั้งแต่ต้น วิธีที่ช่วยได้คือ

  1. ส่งเอกสารสรุปโจทย์ชุดเดียวกันให้ทุกเจ้า ไม่ต้องเป็นสเปกละเอียด แค่ว่าใครใช้ ทำอะไร และต้องเชื่อมกับระบบไหน
  2. ขอให้แต่ละเจ้าเขียนสมมติฐานที่ใช้คิดราคา และสิ่งที่ไม่รวมไว้ในใบเสนอราคา
  3. เทียบต้นทุนรวมสามปี คือค่าพัฒนา บวกค่าเซิร์ฟเวอร์และบริการภายนอก บวกค่าดูแล ไม่ใช่เทียบแค่ค่าพัฒนา
  4. ถ้าราคาห่างกันมาก ให้ถามเจ้าที่ถูกว่าตัดอะไรออก และถามเจ้าที่แพงว่าเผื่ออะไรไว้

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

คำถามที่เอาไปถามได้เลย

  1. เคยทำงานที่มีโจทย์คล้ายกันไหม ระบบนั้นยังใช้อยู่หรือเปล่า
  2. งานที่ผ่านมามีอะไรไม่เป็นตามแผน และแก้ยังไง
  3. ใครเป็นคนทำงานจริง และขอคุยกับหัวหน้าทีมพัฒนาก่อนได้ไหม
  4. ถ้าคนหลักลาออกกลางทาง ใครรับช่วงต่อ
  5. จะได้เห็นระบบที่ใช้ได้จริงทุกกี่สัปดาห์
  6. ซอร์สโค้ดเก็บที่ไหน และเข้าไปดูได้ตั้งแต่เมื่อไหร่
  7. ถ้าอยากเปลี่ยนอะไรกลางทาง ขั้นตอนและการคิดราคาเป็นยังไง
  8. กรรมสิทธิ์ในซอร์สโค้ดเป็นของใครหลังจ่ายครบ
  9. ประกันกี่เดือน นับจากวันไหน
  10. ถ้ายกเลิกกลางทาง จ่ายเท่าไหร่และได้อะไรกลับไป

บริษัทที่ดีจะตอบได้ทุกข้อโดยไม่อึดอัด และหลายข้ออาจพูดถึงก่อนที่คุณจะถามด้วยซ้ำ ของเราส่งมอบซอร์สโค้ดพร้อมเอกสารและสิทธิ์เข้าถึง repository ให้ครบ ประกันงาน 6 เดือนถึง 1 ปีขึ้นกับขอบเขต และการคุยโจทย์ครั้งแรกไม่มีค่าใช้จ่าย ถ้าอยากลองเอาคำถามชุดนี้มาถามเรา นัดคุยได้ที่นี่

คำถามที่พบบ่อย

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

อยากให้ช่วยดูเคสของคุณโดยเฉพาะไหม

เล่าโจทย์มาคร่าว ๆ ได้เลย เราตีกรอบงบและระยะเวลาให้ฟรีตั้งแต่คุยครั้งแรก

บทความที่เกี่ยวข้อง

โน้ตบุ๊กเปิดหน้าจอโค้ดโปรแกรมวางอยู่บนโต๊ะทำงานข้างสมุดบันทึก
ธุรกิจและงบประมาณ

ค่าจ้างเขียนโปรแกรมเท่าไหร่ วิธีประเมินงบก่อนเริ่มโปรเจกต์

Day1Solution.tech

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

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

ค่าดูแลระบบหลังส่งมอบ มีอะไรบ้างและควรตั้งงบเท่าไหร่

Day1Solution.tech

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

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

ระบบเก่าที่ใช้มาสิบปี ควรเขียนใหม่หรือค่อย ๆ ปรับดี

Day1Solution.tech

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

อ่านบทความ12 นาที
ระบบเก่าที่ใช้มาสิบปี ควรเขียนใหม่หรือค่อย ๆ ปรับดี

พิมพ์เพื่อค้นหาในบริการ ผลงาน ผลิตภัณฑ์ บทความ ข่าว ทีมงาน และคำถามที่พบบ่อย