ใบเสนอราคาสามใบวางอยู่บนโต๊ะ ราคาต่างกันสามเท่า ทุกเจ้าบอกว่าทำได้ และทุกเจ้ามีผลงานสวย ๆ ให้ดู การตัดสินใจแบบนี้ยากเพราะสิ่งที่ซื้อยังไม่มีตัวตน สิ่งที่ประเมินได้จริงมีแค่คนที่จะทำและวิธีที่เขาทำงาน บทความนี้รวมคำถามที่ช่วยให้เห็นสองอย่างนั้นก่อนเซ็นสัญญา เราเองก็เป็นหนึ่งในตัวเลือกที่ถูกเทียบแบบนี้ คำถามข้างล่างจึงเป็นคำถามที่เราอยากให้ลูกค้าถามเราด้วย
เรื่องราคาว่าตัวเลขมาจากไหนและทำไมต่างกันมาก อยู่ในบทความค่าจ้างเขียนโปรแกรมเท่าไหร่ ส่วนเรื่องหลังส่งมอบอยู่ในค่าดูแลระบบหลังส่งมอบ บทความนี้จะโฟกัสที่ตัวบริษัทและสัญญาพัฒนา
สัญญาณแรกอยู่ในการคุยครั้งแรก
ให้สังเกตว่าใครเป็นฝ่ายถามมากกว่ากัน บริษัทที่จะทำงานได้ดีมักถามเรื่องงานของคุณก่อนเรื่องระบบ ตอนนี้ทำยังไง ใครทำ ติดตรงไหน ถ้าไม่มีระบบนี้จะเสียอะไร ส่วนบริษัทที่รีบพูดถึงฟีเจอร์ เทคโนโลยี หรือราคาตั้งแต่สิบนาทีแรก มักกำลังจับโจทย์ของคุณใส่ของที่เขามีอยู่แล้ว
สัญญาณที่ดีอีกอย่างคือเขากล้าแย้ง ถ้าคุณขอฟีเจอร์ที่ไม่คุ้ม ทีมที่มีประสบการณ์จะบอกตรง ๆ ว่าไม่ควรทำในเฟสแรก หรือมีวิธีที่ถูกกว่า การรับปากทุกข้อฟังดูดีตอนขาย แต่มักแปลว่ายังไม่ได้คิดว่าจะทำยังไง
ดูผลงานให้ถูกจุด
ภาพหน้าจอสวย ๆ บอกได้ว่าทีมออกแบบเก่ง แต่บอกไม่ได้ว่าระบบใช้งานได้จริงหรือยังมีคนใช้อยู่ไหม คำถามที่ให้ข้อมูลมากกว่าคือ
- เคยทำงานที่โจทย์คล้ายกันไหม ไม่จำเป็นต้องเป็นอุตสาหกรรมเดียวกัน แต่ควรเป็นปัญหาแบบเดียวกัน เช่น ต้องเชื่อมกับระบบเดิม หรือมีผู้ใช้หลายบทบาท
- ระบบนั้นยังใช้งานอยู่ไหม และหลังส่งมอบแล้วใครดูแล
- งานนั้นมีอะไรที่ไม่เป็นไปตามแผน และแก้ยังไง
- ขอดูระบบจริง หรือขอคุยกับลูกค้าเดิมสักรายได้ไหม
ข้อที่สามสำคัญที่สุด ทุกโปรเจกต์มีเรื่องที่ไม่เป็นตามแผน บริษัทที่ตอบว่าไม่เคยมีปัญหาเลย แปลว่ายังไม่อยากเล่า ส่วนบริษัทที่เล่าได้ว่าพลาดอะไรและแก้ยังไง กำลังบอกว่าจะรับมือกับปัญหาของคุณยังไงด้วย เราเปิดผลงานพร้อมขอบเขตและช่วงราคาไว้ให้ดูเทียบได้ เช่นงานอัปเกรดแอป React Native ที่เล่าทั้งสิ่งที่เจอและวิธีทดสอบก่อนปล่อยจริง
ใครเป็นคนทำงานจริง
คนที่คุยตอนขายกับคนที่เขียนโค้ดมักเป็นคนละคน นั่นเป็นเรื่องปกติ แต่คุณควรรู้ว่าใครจะอยู่กับโปรเจกต์ของคุณจริง
- ใครเป็นคนประสานงานหลัก และติดต่อได้ช่องทางไหน
- ขอคุยกับหัวหน้าทีมพัฒนาก่อนเซ็นได้ไหม ไม่ใช่แค่ฝ่ายขาย
- งานทั้งหมดทำในทีมเอง หรือมีส่วนไหนส่งต่อให้ผู้รับเหมาช่วง
- ถ้าคนหลักในโปรเจกต์ลาออกกลางทาง จะมีใครรับช่วงต่อ
ข้อสุดท้ายใช้ได้กับบริษัททุกขนาด บริษัทใหญ่อาจส่งทีมที่คุณไม่เคยเจอมาทำ ส่วนบริษัทเล็กอาจมีความรู้ทั้งระบบอยู่ในหัวคนคนเดียว คำตอบที่ดีคือโค้ดและเอกสารอยู่ในที่ที่คนอื่นในทีมเข้าไปอ่านต่อได้ ไม่ได้อยู่ในเครื่องของใครคนเดียว
ระหว่างทาง คุณจะเห็นอะไรบ้าง
โปรเจกต์ที่พังส่วนใหญ่ไม่ได้พังตอนส่งมอบ แต่พังเงียบ ๆ ตั้งแต่เดือนที่สอง แล้วมีคนรู้ตัวตอนเดือนที่ห้า ถามให้ชัดว่าระหว่างทางคุณจะเห็นอะไร
- ได้เห็นระบบที่ใช้ได้จริงทุกกี่สัปดาห์ ทุกหนึ่งถึงสองสัปดาห์คือจังหวะที่ยังแก้ทิศทางทัน ถ้าได้เห็นครั้งแรกตอนใกล้ส่งมอบ ถือว่าช้าเกินไป
- ซอร์สโค้ดเก็บอยู่ที่ไหน และคุณเข้าไปดูได้ตั้งแต่วันแรกไหม ไม่ใช่ได้เป็นไฟล์ zip ตอนจบ
- ทดสอบยังไง มีช่วงให้ผู้ใช้จริงลองก่อนขึ้นระบบหรือเปล่า
- ถ้าอยากเปลี่ยนอะไรกลางทาง ขั้นตอนคืออะไร ใครประเมินผลกระทบ และตกลงราคากันตอนไหน
ข้อสุดท้ายต้องมีคำตอบเสมอ เพราะการเปลี่ยนใจกลางทางเกิดขึ้นทุกโปรเจกต์ ไม่ใช่ความผิดของใคร เพราะความชัดส่วนใหญ่เกิดตอนได้เห็นของจริง ปัญหาอยู่ที่การไม่มีวิธีจัดการที่ตกลงกันไว้ จนต้องอาศัยความเกรงใจ
สิ่งที่ต้องอยู่ในสัญญาพัฒนา
ใบเสนอราคาบอกว่าจะได้อะไร สัญญาบอกว่าถ้าไม่ได้ตามนั้นจะเกิดอะไรขึ้น ข้อต่อไปนี้ควรเขียนไว้เป็นลายลักษณ์อักษร ไม่ใช่แค่ตกลงกันปากเปล่า
- ขอบเขตงานแนบท้าย รวมรายการที่ไม่รวมอยู่ในงานนี้ด้วย ขอบเขตที่มีแค่ชื่อฟีเจอร์ เช่น "ระบบสมาชิก" บรรทัดเดียว ตีความได้กว้างจนเถียงกันได้ทุกข้อ
- เกณฑ์ตรวจรับของแต่ละงวด ว่าต้องทำอะไรได้ถึงจะถือว่าผ่าน
- งวดเงินผูกกับงานที่ตรวจรับได้จริง ไม่ใช่ผูกกับวันที่อย่างเดียว
- กรรมสิทธิ์ในซอร์สโค้ดหลังชำระเงินครบ และถ้าบริษัทใช้ชิ้นส่วนที่เขาพัฒนาไว้ก่อนแล้ว ส่วนนั้นคุณได้สิทธิ์ใช้ต่อแบบไหน
- บัญชีเซิร์ฟเวอร์ โดเมน และบัญชีร้านแอป เปิดในชื่อใคร
- ระยะประกันนับจากวันไหน วันส่งมอบไฟล์หรือวันที่ระบบขึ้นใช้งานจริง
- ถ้าต้องยกเลิกกลางทาง จ่ายเท่าไหร่ และได้อะไรกลับไปบ้าง
สัญญาที่มูลค่าสูงควรให้ฝ่ายกฎหมายขององค์กรอ่านก่อนเซ็นเสมอ รายการข้างบนไม่ได้แทนคำแนะนำทางกฎหมาย แต่ช่วยให้รู้ว่าต้องถามหาอะไร
สัญญาณเตือนที่ควรหยุดคิดก่อนเซ็น
- ตอบราคาได้ทันทีโดยยังไม่ถามอะไรเกี่ยวกับงานของคุณเลย
- รับปากทุกข้อ ไม่มีข้อไหนที่บอกว่าไม่ควรทำหรือยังไม่แน่ใจ
- ขอเงินส่วนใหญ่ก่อนที่คุณจะได้เห็นงานชิ้นแรก
- ไม่ยอมเขียนเรื่องกรรมสิทธิ์ซอร์สโค้ดลงในสัญญา
- ไม่ให้เห็นระบบระหว่างทาง บอกให้รอดูทีเดียวตอนเสร็จ
- ใบเสนอราคาไม่พูดถึงค่าเซิร์ฟเวอร์ ค่าบริการภายนอก หรือค่าดูแลหลังส่งมอบเลย
ข้อเดียวไม่ได้แปลว่าต้องตัดทิ้งเสมอไป แต่ถ้าเจอหลายข้อพร้อมกัน ราคาที่ถูกกว่ามักไม่ได้ถูกจริงเมื่อนับรวมสิ่งที่ต้องจ่ายตามมาทีหลัง
เทียบใบเสนอราคาหลายเจ้าให้เป็นธรรม
ใบเสนอราคาที่ได้มาจากการเล่าโจทย์คนละแบบ เทียบกันไม่ได้ตั้งแต่ต้น วิธีที่ช่วยได้คือ
- ส่งเอกสารสรุปโจทย์ชุดเดียวกันให้ทุกเจ้า ไม่ต้องเป็นสเปกละเอียด แค่ว่าใครใช้ ทำอะไร และต้องเชื่อมกับระบบไหน
- ขอให้แต่ละเจ้าเขียนสมมติฐานที่ใช้คิดราคา และสิ่งที่ไม่รวมไว้ในใบเสนอราคา
- เทียบต้นทุนรวมสามปี คือค่าพัฒนา บวกค่าเซิร์ฟเวอร์และบริการภายนอก บวกค่าดูแล ไม่ใช่เทียบแค่ค่าพัฒนา
- ถ้าราคาห่างกันมาก ให้ถามเจ้าที่ถูกว่าตัดอะไรออก และถามเจ้าที่แพงว่าเผื่ออะไรไว้
ข้อสุดท้ายมักได้คำตอบที่มีประโยชน์ที่สุด บางครั้งเจ้าที่แพงเผื่อความเสี่ยงที่คุณไม่รู้ว่ามี บางครั้งเจ้าที่ถูกเห็นทางที่ง่ายกว่าจริง ทั้งสองแบบช่วยให้คุณเข้าใจโจทย์ของตัวเองมากขึ้น
คำถามที่เอาไปถามได้เลย
- เคยทำงานที่มีโจทย์คล้ายกันไหม ระบบนั้นยังใช้อยู่หรือเปล่า
- งานที่ผ่านมามีอะไรไม่เป็นตามแผน และแก้ยังไง
- ใครเป็นคนทำงานจริง และขอคุยกับหัวหน้าทีมพัฒนาก่อนได้ไหม
- ถ้าคนหลักลาออกกลางทาง ใครรับช่วงต่อ
- จะได้เห็นระบบที่ใช้ได้จริงทุกกี่สัปดาห์
- ซอร์สโค้ดเก็บที่ไหน และเข้าไปดูได้ตั้งแต่เมื่อไหร่
- ถ้าอยากเปลี่ยนอะไรกลางทาง ขั้นตอนและการคิดราคาเป็นยังไง
- กรรมสิทธิ์ในซอร์สโค้ดเป็นของใครหลังจ่ายครบ
- ประกันกี่เดือน นับจากวันไหน
- ถ้ายกเลิกกลางทาง จ่ายเท่าไหร่และได้อะไรกลับไป
บริษัทที่ดีจะตอบได้ทุกข้อโดยไม่อึดอัด และหลายข้ออาจพูดถึงก่อนที่คุณจะถามด้วยซ้ำ ของเราส่งมอบซอร์สโค้ดพร้อมเอกสารและสิทธิ์เข้าถึง repository ให้ครบ ประกันงาน 6 เดือนถึง 1 ปีขึ้นกับขอบเขต และการคุยโจทย์ครั้งแรกไม่มีค่าใช้จ่าย ถ้าอยากลองเอาคำถามชุดนี้มาถามเรา นัดคุยได้ที่นี่
คำถามที่พบบ่อย
- ควรขอใบเสนอราคากี่เจ้า
- สองถึงสามเจ้ากำลังดี น้อยกว่านั้นไม่มีอะไรให้เทียบ มากกว่านั้นเวลาที่ใช้เล่าโจทย์ซ้ำและเทียบเอกสารจะเริ่มคุ้มน้อยลง สิ่งที่ทำให้เทียบได้จริงคือการส่งโจทย์ชุดเดียวกันให้ทุกเจ้า ไม่ใช่จำนวนเจ้า
- จ้างฟรีแลนซ์หรือบริษัทดีกว่ากัน
- ขึ้นกับขนาดงานและความเสี่ยงที่รับได้ ฟรีแลนซ์มักถูกกว่าและเหมาะกับงานเล็กที่ขอบเขตชัด ความเสี่ยงคืองานทั้งหมดขึ้นกับคนคนเดียว ถ้าระบบต้องใช้งานต่อหลายปีหรือหยุดไม่ได้ ควรถามให้ชัดว่าถ้าคนนั้นไม่ว่าง ใครจะดูแลแทน
- บริษัทใหญ่ปลอดภัยกว่าบริษัทเล็กไหม
- ไม่เสมอไป บริษัทใหญ่มีความต่อเนื่องมากกว่า แต่โปรเจกต์ขนาดกลางอาจได้ทีมที่มีประสบการณ์น้อยและได้ความสนใจไม่มาก บริษัทเล็กอาจใส่ใจมากกว่าแต่มีความเสี่ยงเรื่องคนหลัก สิ่งที่ควรดูคือใครจะทำงานของคุณจริง ไม่ใช่ขนาดบริษัท
- ถ้าโจทย์ยังไม่ชัด ควรจ้างออกแบบก่อนแยกจากงานพัฒนาไหม
- เป็นทางที่ลดความเสี่ยงได้ดี โดยเฉพาะงานใหญ่ การทำงานออกแบบและเก็บความต้องการเป็นสัญญาเล็กก่อน ทำให้ได้หน้าจอและขอบเขตที่ชัดพอจะเอาไปขอราคาพัฒนาจากหลายเจ้าได้อย่างเป็นธรรม และได้ลองทำงานกับทีมนั้นก่อนตัดสินใจก้อนใหญ่
อยากให้ช่วยดูเคสของคุณโดยเฉพาะไหม
เล่าโจทย์มาคร่าว ๆ ได้เลย เราตีกรอบงบและระยะเวลาให้ฟรีตั้งแต่คุยครั้งแรก