ใบเสนอราคาที่ถูกที่สุดมักไม่ใช่ใบที่ถูกที่สุดเมื่อจบโปรเจกต์ ส่วนต่างไม่ได้มาจากตัวเลขในใบเสนอราคา แต่มาจากสิ่งที่ไม่ได้เขียนไว้ เมื่อขอบเขตงานไม่ชัด ทุกการเปลี่ยนแปลงจะกลายเป็นการต่อรองเรื่องเงิน และเมื่อไม่ได้เขียนเรื่องการรับประกัน บั๊กหลังส่งมอบก็กลายเป็นงานใหม่ที่ต้องจ่ายเพิ่ม
ก่อนเซ็น ลองไล่ดูว่าใบเสนอราคาที่อยู่ในมือมีครบ 9 ข้อนี้หรือเปล่า
- 1 ใบเสนอราคาที่ถูกกว่า ขอบเขตงานมีบรรทัดเดียว ทุกการเปลี่ยนแปลงระหว่างทำจึงกลายเป็นบิลใหม่
- 2 รับประกันแค่ 30 วัน บั๊กที่เจอหลังส่งมอบกลายเป็นงานใหม่ที่ต้องจ่ายเพิ่ม
- 3 ใบเสนอราคาที่เขียนครบ ตอนเซ็นราคาสูงกว่า แต่งานเพิ่มมีราคาให้ดูก่อนลงมือ และบั๊กในขอบเขตงานแก้ให้ภายใต้การรับประกัน
- สิ่งที่ใบเสนอราคาไม่ได้เขียนไว้ ส่วนต่างที่ต้องจ่ายเมื่อจบงาน
1. ขอบเขตงานเป็นรายฟีเจอร์ ไม่ใช่ชื่อระบบ
“ระบบ HR ครบวงจร” ไม่ใช่ขอบเขตงาน ขอบเขตงานที่ดีบอกทีละข้อว่าทำอะไรได้ ใครเป็นคนใช้ และเงื่อนไขสำคัญคืออะไร เช่น “พนักงานยื่นใบลาได้ หัวหน้าอนุมัติผ่าน LINE วันลาคงเหลือลดลงอัตโนมัติ” ถ้าอ่านแล้วนึกภาพการใช้งานไม่ออก ตอนตรวจรับก็จะเถียงกันไม่จบ
2. สิ่งที่ไม่รวมในราคา
ใบเสนอราคาที่ดีบอกด้วยว่าอะไรไม่ได้รวมไว้ เช่น การย้ายข้อมูลจากระบบเก่า ค่าเซิร์ฟเวอร์ หรือการอบรมผู้ใช้ สิ่งที่ไม่ได้เขียนไว้ คือสิ่งที่จะมาเจอกันตอนท้าย
3. สิ่งที่ต้องได้จากฝั่งคุณ และภายในวันไหน
งานพัฒนาระบบมักติดที่ฝั่งผู้ว่าจ้างไม่น้อยกว่าฝั่งเวนเดอร์ ทั้งการอนุมัติจากฝ่าย IT ไฟล์ข้อมูลตัวอย่าง หรือการให้ผู้ใช้จริงมาลองระบบ ถ้าเขียนไว้ตั้งแต่ต้น ทั้งสองฝ่ายจะรู้ว่าความล่าช้าเกิดจากตรงไหน
4. งวดงานที่ผูกกับเดโมจริง
การแบ่งจ่ายตามงวดงานปกป้องทั้งสองฝ่าย แต่งวดงานควรผูกกับสิ่งที่คุณได้เห็นและได้ลองจริง ไม่ใช่ผูกกับวันที่ในปฏิทิน และไม่ควรจ่ายล่วงหน้าเกินครึ่งก่อนเห็นงาน
- 1 จ่ายตามงานที่เห็น เช่น 40% เมื่อเซ็นสัญญา 40% หลังสาธิตครั้งแรก และ 20% หลังสาธิตครั้งสุดท้าย
- 2 จ่ายตามวันที่ในปฏิทิน เงินส่วนใหญ่ถึงกำหนดก่อนมีการสาธิต ผูกกับวันที่ ไม่ใช่ผลงาน
- จ่ายเกินครึ่งก่อนเห็นงาน ถ้าแผนการจ่ายเข้ามาอยู่ในพื้นที่นี้ ให้ถามเหตุผล
5. วิธีจัดการเมื่อมีการเปลี่ยนแปลง
ความต้องการเปลี่ยนเป็นเรื่องปกติ สิ่งที่ต้องรู้คือเปลี่ยนแล้วคิดเงินอย่างไร ทางที่ดีที่สุดคือประเมินราคาและตกลงกันก่อนลงมือทำทุกครั้ง ไม่ใช่มารู้ยอดตอนส่งบิล
6. การรับประกัน: นานแค่ไหน และครอบคลุมอะไร
ระบบที่เพิ่งขึ้นใช้งานจริงจะเจอบั๊กที่ไม่เคยเจอตอนทดสอบเสมอ ดูว่ารับประกันกี่เดือน และครอบคลุมบั๊กในทุกอย่างที่อยู่ในขอบเขตงานหรือไม่ การรับประกัน 30 วันสำหรับระบบที่ใช้งานทุกวัน แทบไม่ต่างจากไม่มี
7. ใครเป็นเจ้าของโค้ดและบัญชีต่างๆ
ซอร์สโค้ดควรอยู่ใน repository ขององค์กรคุณตั้งแต่วันแรก และบัญชีต่างๆ ทั้งโดเมน คลาวด์ และ App Store ควรเปิดในชื่อคุณ ถ้าใบเสนอราคาเขียนว่า “ส่งมอบซอร์สโค้ดเมื่อร้องขอ” ให้ถามต่อทันทีว่าทำไม
8. สิ่งที่ได้รับตอนส่งมอบ
นอกจากระบบที่ใช้งานได้ ควรมีเอกสารแผนผังระบบ วิธี deploy วิธีกู้คืนข้อมูลสำรอง และคู่มือการใช้งาน เอกสารเหล่านี้คือสิ่งที่ทำให้คุณเปลี่ยนเวนเดอร์ได้ ถ้าวันหนึ่งจำเป็นต้องเปลี่ยน
9. ค่าดูแลหลังขึ้นระบบ
ถามราคาค่าดูแลระบบตั้งแต่ตอนนี้ ไม่ใช่หลังขึ้นระบบ ซึ่งเป็นช่วงที่คุณต่อรองได้น้อยที่สุด ใบเสนอราคาที่ดีบอกว่าดูแลอะไร ตอบกลับเร็วแค่ไหน และราคาเท่าไร
5 สัญญาณที่ควรถามต่อ
- ขอบเขตงานมีแค่บรรทัดเดียว
- ขอจ่ายล่วงหน้าเกิน 50% ก่อนเห็นงาน
- ไม่มีชื่อคนที่จะลงมือทำจริง
- ราคาออกมาภายในวันเดียว โดยไม่ได้ถามอะไรคุณเลย
- ไม่พูดถึงการทดสอบเลยสักคำ
ทำไมเราไม่ให้ราคาเหมาตั้งแต่วันแรก
- 1 ราคาในวันแรก ยังไม่มีใครลิสต์งานได้ ราคาจึงต้องเผื่อไว้สูง หรือมาเก็บเพิ่มทีหลัง
- 2 Blueprint 2–3 สัปดาห์ เขียนทุกข้อในเช็กลิสต์นี้ให้ครบ
- 3 ราคาเหมาราคาเดียว เสนอจากขอบเขตงานที่เขียนไว้ เอกสารเป็นของคุณไม่ว่าจะจ้างต่อหรือไม่
เพราะยังไม่มีใครรู้ว่าต้องทำอะไรบ้าง ราคาที่ออกมาเร็วแบบนั้น ถ้าไม่เผื่อไว้สูงมาก ก็ต้องไปเก็บเพิ่มทีหลัง งานส่วนใหญ่ของเราจึงเริ่มด้วย Blueprint ใช้เวลา 2–3 สัปดาห์ เพื่อเขียนทุกข้อด้านบนให้ครบก่อน แล้วจึงเสนอราคาเหมาหนึ่งราคา ถ้าโจทย์ชัดจนลิสต์ฟีเจอร์ได้ครบตั้งแต่ตอนนัดคุย เราเสนอราคาเหมาให้ได้เลย (ขั้นตอนและการคิดเงินทั้งหมด) ถ้าคุณไม่ได้จ้างเราต่อ เอกสารทั้งหมดก็ยังเป็นของคุณ และนำไปให้เวนเดอร์รายอื่นเสนอราคาได้ ดูตัวอย่างใบเสนอราคาและเอกสารอื่นๆ