Technology Strategy · WHITE FORCES KNOWLEDGE
เลือก Technology Partner อย่างไรให้โครงการไม่สะดุดหลังส่งมอบ
เผยแพร่ · ตรวจทานล่าสุด · อ่านประมาณ 5 นาทีราคาและหน้าตาผลงานเป็นเพียงส่วนหนึ่ง ระบบที่อยู่กับธุรกิจหลายปีต้องมีเจ้าของ ขอบเขต และทางส่งต่อที่ชัด
อ่านขอบเขตให้เข้าใจตรงกัน
ข้อเสนอควรระบุสิ่งที่รวมและไม่รวม milestone ผู้อนุมัติ เกณฑ์รับงาน และรอบแก้ ลดความเสี่ยงจากคำกว้างอย่าง “ทำให้ครบ”
ก่อนเซ็นสัญญา ลองเล่าย้อนขอบเขตงานให้ผู้เสนอฟังด้วยคำของคุณเอง แล้วขอให้ยืนยันเป็นลายลักษณ์อักษร จุดที่มักตีความต่างกันคือจำนวนรอบแก้ การย้ายข้อมูลเก่า การอบรมทีม และงานหลังส่งมอบ หากข้อเสนอไม่ระบุ ให้ถามจนได้คำตอบชัดก่อนตกลง เพราะการเจรจาก่อนเริ่มถูกกว่าการเถียงกันกลางโครงการเสมอ
ยืนยันกรรมสิทธิ์และการเข้าถึง
ถามว่าใครเป็นเจ้าของโดเมน บัญชี cloud source code ข้อมูล และ credentials ลูกค้าควรมีสิทธิ์ที่เหมาะสมและมีขั้นตอนส่งคืนเมื่อจบสัญญา
ทำทะเบียนทรัพย์สินดิจิทัลของโครงการตั้งแต่วันแรก ระบุว่าโดเมน โฮสติ้ง ฐานข้อมูล บัญชีอีเมล และ repository อยู่ในบัญชีของใคร ใครถือสิทธิ์ระดับเจ้าของ และใครถือสิทธิ์ระดับผู้ดูแล เมื่อจบสัญญาหรือเปลี่ยนพาร์ตเนอร์ รายการนี้จะเป็นหลักฐานว่าต้องส่งมอบอะไรบ้าง ป้องกันกรณีที่ระบบยังทำงานได้แต่ธุรกิจไม่มีสิทธิ์แตะต้องอะไรเลย
ดูวิธีทดสอบและดูแลต่อ
ตรวจแผน mobile, security, backup, rollback, documentation และช่องทางแจ้งเหตุ พาร์ตเนอร์ที่ดีต้องอธิบาย trade-off และทำให้ทีมอื่นรับช่วงต่อได้
ขอดูตัวอย่างเอกสารส่งมอบจากโครงการก่อนหน้า เช่น คู่มือระบบ diagram และรายงานทดสอบ ทีมที่ทำงานเป็นระบบจะมีของเหล่านี้อยู่แล้วและยินดีให้ดู ขณะเดียวกันให้สังเกตวิธีตอบคำถามเชิงลึก ทีมที่อธิบายข้อจำกัดและ trade-off ตรงไปตรงมา น่าไว้ใจกว่าทีมที่รับปากทุกอย่างว่าทำได้หมด
ตัวอย่างสถานการณ์ที่พบบ่อย
สถานการณ์คลาสสิกคือธุรกิจจ้างทำเว็บไซต์หรือระบบไปเมื่อหลายปีก่อน วันหนึ่งต้องการแก้ข้อความหรือเพิ่มฟีเจอร์ แต่ติดต่อผู้พัฒนาเดิมไม่ได้ พอไปตรวจจึงพบว่าโดเมนจดในชื่อผู้พัฒนา โฮสติ้งอยู่ในบัญชีส่วนตัวของเขา และไม่มีใครมี source code เลย ทางเลือกที่เหลือคือเจรจาตามหาเจ้าของบัญชี หรือสร้างระบบใหม่ทั้งหมด ซึ่งทั้งสองทางมีต้นทุนสูงกว่าการตกลงเรื่องกรรมสิทธิ์ตั้งแต่วันแรกมาก
อีกกรณีคือระบบภายในที่พัฒนาโดยพนักงานหรือฟรีแลนซ์คนเดียวโดยไม่มีเอกสารประกอบ เมื่อคนนั้นออกไป ไม่มีใครกล้าแก้ระบบเพราะไม่รู้ว่าแตะแล้วอะไรจะพัง ธุรกิจจึงถูกล็อกอยู่กับซอฟต์แวร์เวอร์ชันเดิมไปเรื่อย ๆ ทั้งสองสถานการณ์ป้องกันได้ด้วยเงื่อนไขการส่งมอบและเอกสารที่ตกลงกันไว้ในสัญญา ไม่ใช่ด้วยความไว้ใจอย่างเดียว
ขั้นตอนคัดเลือกพาร์ตเนอร์
กระบวนการนี้ใช้เวลาเพิ่มไม่มาก แต่ลดความเสี่ยงระยะยาวได้อย่างมีนัยสำคัญ
- นิยามโจทย์และงบให้ชัดเขียนสิ่งที่ต้องการ ผลลัพธ์ที่คาดหวัง และกรอบงบประมาณ ก่อนคุยกับผู้เสนอรายใด
- รวบรวมตัวเลือกสองถึงสามรายดูผลงานจริงที่ยังใช้งานอยู่ ไม่ใช่แค่ภาพในพอร์ตโฟลิโอ และถามหาลูกค้าเก่าที่ติดต่อได้
- คุยเชิงลึกก่อนขอราคาทีมที่ดีจะถามกลับเรื่องเป้าหมายธุรกิจและข้อจำกัด ไม่ใช่ส่งใบเสนอราคาทันทีโดยไม่เข้าใจงาน
- ตรวจข้อเสนอและร่างสัญญาดูขอบเขต กรรมสิทธิ์ เกณฑ์รับงาน เงื่อนไขจ่ายเงิน และงานหลังส่งมอบ ให้ครบก่อนเซ็น
- เริ่มจากงานขอบเขตเล็กถ้าเป็นไปได้ ทดลองร่วมงานด้วยเฟสแรกหรือชิ้นงานเล็กก่อนผูกสัญญาระยะยาว
- ทบทวนหลังส่งมอบประเมินคุณภาพงาน การสื่อสาร และเอกสารที่ได้รับ เพื่อใช้ตัดสินใจว่าจะทำงานต่อกันระยะยาวหรือไม่
เช็กลิสต์คำถามก่อนเซ็นสัญญา
- ขอบเขตงานระบุสิ่งที่รวมและไม่รวมชัดเจนหรือไม่ มีเกณฑ์รับงานไหม
- โดเมน โฮสติ้ง และบัญชีบริการต่าง ๆ จดทะเบียนในชื่อของธุรกิจเราหรือไม่
- source code และฐานข้อมูลเป็นกรรมสิทธิ์ของใครเมื่อจ่ายเงินครบ
- มีเอกสารส่งมอบอะไรบ้าง เช่น คู่มือ diagram และรายการ credentials
- หลังส่งมอบมีประกันผลงานกี่เดือน และงานดูแลต่อคิดราคาอย่างไร
- ถ้าจะเปลี่ยนผู้ดูแลในอนาคต ขั้นตอนส่งต่อเป็นอย่างไร มีค่าใช้จ่ายไหม
- ข้อมูลลูกค้าของเราถูกเก็บที่ไหน และใครเข้าถึงได้บ้าง
สัญญาณที่ดีและสัญญาณเตือน
ใช้ตารางนี้ประกอบการประเมินระหว่างพูดคุยกับผู้เสนอแต่ละราย
| หัวข้อ | สัญญาณที่ดี | สัญญาณเตือน |
|---|---|---|
| ขอบเขตงาน | ระบุสิ่งที่รวมและไม่รวม พร้อมเกณฑ์รับงานเป็นลายลักษณ์อักษร | ใช้คำกว้าง เช่น “ทำให้ครบ” โดยไม่มีรายละเอียด |
| กรรมสิทธิ์ | โดเมนและบัญชีอยู่ในชื่อลูกค้า ระบุการส่งมอบ source code ชัด | ทรัพย์สินทั้งหมดอยู่ในบัญชีผู้พัฒนา และเลี่ยงที่จะตอบเรื่องนี้ |
| การประเมินราคา | ถามโจทย์ธุรกิจก่อน แจกแจงรายการงานและสมมติฐาน | เสนอราคาทันทีโดยไม่ถามอะไร หรือถูกผิดปกติจนไม่มีที่มา |
| การดูแลต่อ | มีแผน backup ช่องทางแจ้งเหตุ และเงื่อนไขดูแลหลังส่งมอบ | พูดถึงแต่วันส่งมอบ ไม่มีคำตอบว่าหลังจากนั้นใครดูแล |
| การสื่อสาร | อธิบายข้อจำกัดและ trade-off ตรงไปตรงมา | รับปากทุกอย่างว่าทำได้หมดในเวลาอันสั้น |
ข้อผิดพลาดที่พบบ่อย
- ตัดสินจากราคาถูกสุดอย่างเดียวราคาที่ต่ำผิดปกติมักแลกด้วยขอบเขตที่คลุมเครือ หรืองานที่ต้องจ้างแก้ใหม่ภายหลัง
- ไม่คุยเรื่องกรรมสิทธิ์ตั้งแต่แรกเรื่องโดเมน บัญชี และ source code ต้องอยู่ในสัญญา ไม่ใช่ตกลงปากเปล่า
- ข้ามการอ่านสัญญาเพราะเกรงใจสัญญาที่ดีปกป้องทั้งสองฝ่าย ผู้เสนอที่จริงจังจะยินดีอธิบายทุกข้อ
- ไม่กำหนดเกณฑ์รับงานเมื่อไม่มีนิยามว่า “เสร็จ” หมายถึงอะไร โครงการจะจบไม่ลงและความสัมพันธ์จะเสีย
- ลืมวางแผนหลังส่งมอบระบบทุกระบบต้องมีคนดูแล อัปเดต และสำรองข้อมูล ควรตกลงเรื่องนี้พร้อมงานหลัก ไม่ใช่หลังเกิดปัญหา
คำถามที่พบบ่อย
จำเป็นต้องทำสัญญาเป็นลายลักษณ์อักษรไหม
จำเป็น แม้เป็นงานขนาดเล็กหรือจ้างคนรู้จัก อย่างน้อยควรมีเอกสารสรุปขอบเขต ราคา กำหนดส่งมอบ และกรรมสิทธิ์ ที่ทั้งสองฝ่ายยืนยันเป็นหลักฐาน ข้อความในอีเมลหรือแชตที่ชัดเจนก็ยังดีกว่าการตกลงปากเปล่า
source code ควรเป็นของใคร
ขึ้นกับข้อตกลง แต่สำหรับระบบที่พัฒนาเฉพาะให้ธุรกิจคุณ ควรเจรจาให้ได้กรรมสิทธิ์หรืออย่างน้อยสิทธิ์ใช้งานถาวรพร้อมสำเนา source code เมื่อจ่ายครบ เพื่อไม่ให้ธุรกิจถูกผูกกับผู้พัฒนารายเดียวตลอดไป
ถ้าผู้พัฒนาเดิมหายไปแล้ว ควรทำอย่างไร
เริ่มจากรวบรวมสิ่งที่มี ได้แก่ สิทธิ์เข้าโดเมน โฮสติ้ง ฐานข้อมูล และไฟล์ระบบ แล้วให้ทีมใหม่ประเมินว่ากู้คืนการควบคุมได้แค่ไหน บางกรณีย้ายระบบเดิมออกมาได้ บางกรณีสร้างใหม่คุ้มกว่า สิ่งสำคัญคือรีบสำรองข้อมูลที่ยังเข้าถึงได้ก่อน
พาร์ตเนอร์รายเดียวควรทำทุกอย่างเลยไหม
ข้อดีคือการประสานงานง่าย ข้อเสียคือการพึ่งพารายเดียวสูง แนวทางที่สมดุลคือให้พาร์ตเนอร์หลักรับผิดชอบภาพรวม แต่ธุรกิจถือกรรมสิทธิ์ทรัพย์สินทั้งหมดเอง และมีเอกสารเพียงพอให้รายอื่นรับช่วงต่อได้เสมอ
แหล่งอ้างอิง
แหล่งข้อมูลสำหรับศึกษาแนวปฏิบัติเพิ่มเติม
- สำนักงานพัฒนาธุรกรรมทางอิเล็กทรอนิกส์ (ETDA) — แนวทางธุรกรรมทางอิเล็กทรอนิกส์ที่น่าเชื่อถือ
- OWASP — มาตรฐานความปลอดภัยของแอปพลิเคชันที่ควรใช้คุยกับผู้พัฒนา
- พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA)