เลือก​ ​Software​ ​House​ ​อย่างไร​ให้​เหมาะ​กับ​โปร​เจ​กต์​เว็บไซต์​และ​ระบบ​ของ​ธุรกิจ

การ เลือก Software House ไม่ควรเริ่มและจบที่ราคา เพราะใบเสนอราคาสองฉบับอาจรวมงานคนละอย่าง สิ่งที่ต้องเทียบคือผู้รับงานเข้าใจปัญหาเพียงใด จะส่งมอบอะไร ตรวจรับอย่างไร และใครดูแลเมื่อเริ่มใช้งานจริง

เริ่มจากประเภทงานที่ต้องการ

เว็บไซต์บริษัทเน้นความชัดของเนื้อหา ประสบการณ์ใช้งาน และการติดต่อ ส่วน Web Application ต้องดูงานหลัก ข้อมูล บทบาทผู้ใช้ และการเปลี่ยนสถานะ ระบบหลังบ้านหรือ Integration ต้องเข้าใจกระบวนการเดิม ข้อยกเว้น และระบบภายนอกที่เกี่ยวข้อง ทีมที่เหมาะกับงานหนึ่งอาจไม่ใช่ทีมที่เหมาะกับอีกงาน

ภาพที่ 1: จับคู่ประสบการณ์ทีมกับงานที่ต้องส่งมอบจริง ก่อนเปรียบเทียบราคาหรือขนาดทีม

6 คำถามที่ควรถามทุกทีม

1. ทีมเข้าใจปัญหาและกลุ่มผู้ใช้อย่างไร มีอะไรที่ยังไม่ทราบ?
2. ขอบเขตที่รวมและไม่รวมในราคาเป็นอะไร โดยเฉพาะเนื้อหา ข้อมูล และระบบภายนอก?
3. จะเห็นงานระหว่างทางเมื่อไร และใครให้ความเห็นหรืออนุมัติ?
4. ทดสอบบนมือถือ สิทธิ์ผู้ใช้ ข้อมูลผิดรูปแบบ และกรณีระบบล่มอย่างไรตามประเภทงาน?
5. ส่งมอบโค้ด บัญชีบริการ เอกสาร และสิทธิ์เข้าถึงให้ใคร?
6. หลังเปิดใช้ หากมีบั๊กหรือขอเปลี่ยนงาน กระบวนการและค่าใช้จ่ายเป็นอย่างไร?

ดูหลักฐานอย่างไร

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

เตรียมโจทย์เดียวกันก่อนขอข้อเสนอ

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

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

ตัวอย่างสมมติ: เปรียบเทียบสองข้อเสนอ

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

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

เกณฑ์ประเมินที่ใช้ได้จริง

1. เข้าใจงาน: ทีมถามถึงผู้ใช้ กระบวนการเดิม และข้อยกเว้นหรือไม่
2. ขอบเขตตรวจรับได้: ผลงานแต่ละช่วงมีตัวอย่างหรือเงื่อนไขทดสอบชัดหรือไม่
3. การสื่อสาร: รู้ว่าใครรับผิดชอบงาน ใครตัดสินใจ และรายงานความคืบหน้าอย่างไร
4. การส่งมอบ: ระบุเจ้าของโค้ด บัญชีบริการ ข้อมูล คู่มือ และสิทธิ์เข้าถึงตามข้อตกลงหรือไม่
5. การดูแลต่อ: มีวิธีแจ้งบั๊ก ระยะเวลาตอบ เงื่อนไขแก้งาน และทางย้ายไปทีมอื่นหรือไม่

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

หลังเลือกทีมแล้วควรตกลงอะไร

กำหนดผู้อนุมัติเนื้อหาและขอบเขต วิธีจัดการคำขอเปลี่ยนงาน ตารางสาธิตงาน เกณฑ์ตรวจรับ ข้อมูลที่ต้องให้ทีม และเงื่อนไขส่งมอบเมื่อสิ้นสุดสัญญา ควรให้ธุรกิจถือบัญชีบริการหลักหรือมีสิทธิ์เข้าถึงตามที่ตกลง เพื่อไม่ให้การดูแลระบบผูกกับผู้รับจ้างเพียงรายเดียว แนวทางของ GOV.UK สำหรับการทำงานกับผู้รับจ้างเน้นการรักษาความรู้และวางการส่งต่องาน แม้รายละเอียดจัดซื้อของภาครัฐจะไม่ใช่กฎสำหรับธุรกิจเอกชน

ประเด็นสำหรับรายงานการจัดซื้อ

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

หากกำลังหาแนวทางสำหรับ เว็บไซต์บริษัท, Web Application หรือ ระบบหลังบ้านและ LINE/API สามารถเริ่มจาก ภาพรวม Waihaus Studio แล้วเลือกบริการที่ตรงโจทย์

แหล่งข้อมูลประกอบ

• GOV.UK Service Manual: Working with contractors and third parties — หลักการกำหนดงานและถ่ายทอดความรู้ระหว่างองค์กรกับผู้รับจ้าง
• GOV.UK Service Manual: Commercial off-the-shelf products and services — การเริ่มจากปัญหาและทางเลือกก่อนผูกกับวิธีพัฒนา