ก่อนจ้างพัฒนาระบบ ประเมินความเสี่ยงที่ vendor จะหายไปอย่างไร

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

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

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

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

ความเป็นเจ้าของโค้ด กับการเปิดโค้ดได้จริง เป็นคนละเรื่อง

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

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

จากฝั่งปฏิบัติ สิ่งที่เราเห็นว่าสำคัญไม่แพ้กันคือ ความเป็นเจ้าของบนกระดาษใช้ได้จริงก็ต่อเมื่อองค์กรเปิดโค้ดนั้นได้ สัญญาที่ให้ส่งมอบ source code ตอนปิดโครงการปกป้ององค์กรในวันที่โครงการจบตามแผน แต่ไม่ช่วยอะไรในวันที่ vendor หายไประหว่างทาง เพราะวันส่งมอบนั้นไม่เคยมาถึง

ความเสี่ยงจริงอยู่ที่ช่วงกลางโครงการ

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

ถ้าจำเป็นต้องให้ repository หลักอยู่ฝั่ง vendor ทางออกที่ตรวจได้คือให้มีสำเนาแบบ mirror อยู่ในที่ที่องค์กรควบคุม เอกสารของ Git อธิบายว่าโหมด --mirror ไม่ได้ map แค่ branch แต่ map ทุก ref ของต้นทาง รวมถึง remote-tracking branch และ notes และตั้งค่าให้ ref เหล่านั้นถูกเขียนทับทุกครั้งที่สั่งอัปเดต สำเนาแบบนี้เก็บประวัติการแก้ไขไว้ครบ ซึ่งเราเห็นว่ามีค่ากว่าไฟล์ zip ชุดสุดท้าย เพราะประวัติบอกได้ว่าโค้ดแต่ละส่วนถูกแก้เมื่อไรและพร้อมกับงานชิ้นไหน

Key-person risk: บริษัทยังอยู่ แต่คนที่รู้ระบบอาจไม่อยู่

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

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

สัญญาณที่ถามได้โดยไม่ล่วงเกินใคร มีอยู่ไม่กี่ข้อ

• ขอรายชื่อบทบาทหลักที่จะทำงานในโครงการจริง พร้อมคนสำรองของแต่ละบทบาท ไม่ใช่แค่รายชื่อทีมที่มานำเสนอ

• ถามว่าโค้ดทุกชิ้นผ่านการ review โดยคนที่ไม่ใช่ผู้เขียนหรือไม่ ถ้าใช่ แปลว่ามีอย่างน้อยสองคนที่เคยอ่านทุกส่วนของระบบ

• ขอคุยกับทีมที่จะลงมือทำจริงสักครั้งก่อนตัดสินใจ

• ถามว่าเคยมีสมาชิกทีมลาออกกลางโครงการหรือไม่ และตอนนั้นส่งต่องานกันอย่างไร โดยถามถึงกระบวนการ ไม่ต้องถามชื่อคน

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

Source code escrow คืออะไร และคุ้มเมื่อไร

Code escrow คือการฝาก source code ไว้กับคนกลาง แนวปฏิบัติด้านจัดซื้อของกระทรวงกลาโหมสหรัฐฯ ใน DFARS PGI 227.7203-2 อธิบายว่าฝ่ายรัฐกับผู้รับจ้างตกลงเลือก escrow agent ที่เป็นบุคคลที่สาม ให้เก็บซอฟต์แวร์ที่ระบุไว้จนกว่าจะเกิดเงื่อนไขที่เขียนไว้ในสัญญา เมื่อเงื่อนไขนั้นเกิดขึ้น ฝ่ายรัฐจึงขอรับของที่ฝากไว้ได้ และสัญญาต้องระบุด้วยว่าฝ่ายรัฐมีสิทธิ์ใช้ของที่ฝากนั้นแค่ไหน

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

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

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

ความเสี่ยงชนิดนี้ต่างจากการผูกกับ cloud provider รายเดียว ซึ่งเราแยกเขียนไว้ใน กรอบตัดสินใจเรื่อง Cloud รายเดียวหรือหลายราย

อ่านสัญญาณความต่อเนื่องของ vendor โดยไม่ต้องขอเกินควร

ข้อมูลบางส่วนองค์กรตรวจเองได้โดยไม่ต้องขอจาก vendor เลย กรมพัฒนาธุรกิจการค้าเปิดบริการ DBD DataWarehouse+ ให้ค้นข้อมูลนิติบุคคลและงบการเงิน และระบุว่าข้อมูลนี้ใช้ประกอบการพิจารณาการลงทุนและเช็คสถานะความมีตัวตนของนิติบุคคลได้ การดูสถานะของบริษัทและข้อมูลงบการเงินที่ยื่นไว้ เป็นการตรวจที่ไม่ต้องรบกวนใคร

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

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

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

สิ่งที่ควรได้รับระหว่างทาง ไม่ใช่แค่วันส่งมอบ

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

• โค้ดพร้อมประวัติการแก้ไข ใน repository ที่องค์กรอ่านได้ ตามที่กล่าวไว้ข้างต้น

• ขั้นตอน build และ deploy ที่เขียนเป็น pipeline หรือ script อยู่ใน repository ไม่ใช่ขั้นตอนที่อยู่ในเครื่องหรือในความจำของคนคนเดียว

• ชุดทดสอบอัตโนมัติที่คนนอกทีมสั่งรันได้ และอ่านผลได้เองว่าผ่านหรือไม่ผ่าน

• backlog และรายการ bug ที่รู้แล้วแต่ยังไม่ได้แก้ ในระบบที่องค์กรเปิดดูได้ เพราะรายการนี้คือสิ่งแรกที่ทีมใหม่ต้องรู้

• ค่าตั้งต้นของแต่ละ environment ที่แยกความลับออกไปเก็บต่างหากแล้ว

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

จุดที่ติดคือจุดที่ความรู้ยังอยู่ในหัวคน

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

ข้อจำกัดของเกณฑ์เหล่านี้

ข้อเสียที่ต้องพูดให้ชัดคือ เกณฑ์เรื่อง key-person ทำให้ vendor ทีมเล็กเสียคะแนน ทั้งที่ทีมสี่ห้าคนที่มีประสบการณ์ตรงกับโจทย์ อาจทำงานได้ดีกว่าทีมใหญ่ที่หมุนคนเข้าออก ถ้าคุณตัดทีมเล็กออกเพราะจำนวนคนอย่างเดียว องค์กรอาจเสียตัวเลือกที่เหมาะกับงานไป คำแนะนำของเราในกรณีนั้นคือให้น้ำหนักกับการเข้าถึง repository และการซ้อมรับช่วงมากกว่าจำนวนคน เพราะสองข้อนี้ลดความเสี่ยงได้โดยไม่ขึ้นกับขนาดของทีม

ข้อโต้แย้งที่ได้ยินบ่อย

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

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

จะเริ่มตรงไหน

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

• องค์กรจะอ่าน repository ได้ตั้งแต่เมื่อไร และโค้ดเข้าไปบ่อยแค่ไหน

• บทบาทหลักในโครงการมีใครบ้าง และใครสำรองแต่ละบทบาท

• ยินดีให้ซ้อมรับช่วงกลางโครงการหรือไม่

• มีส่วนไหนของระบบที่ใช้ซอฟต์แวร์ซึ่ง vendor เป็นเจ้าของและไม่เปิดโค้ด ถ้ามี จะเสนอทางคุ้มครองอะไร

ระหว่างนั้นให้ฝ่ายกฎหมายอ่านข้อความเรื่องสิทธิ์ใน source code ในร่างสัญญาของแต่ละราย ส่วนเงื่อนไขการดูแลระบบหลังส่งมอบเป็นอีกสัญญาหนึ่ง ซึ่งเราแยกไว้ใน ก่อนเซ็นสัญญาดูแลระบบรายปี

สรุป

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

หากองค์กรของคุณกำลังร่างเกณฑ์คัดเลือกผู้พัฒนาระบบ และอยากให้มีคนช่วยอ่านทบทวน ติดต่อ Superdev ได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ ไม่มีกำหนดเวลาบังคับ และถ้าคุยแล้วคุณอยากถามคำถามในบทความนี้กับเราด้วย เรายินดีตอบทุกข้อ