[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-faqs-vendor-continuity-due-diligence-th":3,"blog-post-vendor-continuity-due-diligence-th":28},[4,8,12,16,20,24],{"answer":5,"id":6,"question":7},"Code escrow คือการฝาก source code ไว้กับคนกลาง และองค์กรขอรับได้เมื่อเกิดเงื่อนไขที่เขียนไว้ในสัญญาเท่านั้น ส่วนการเข้าถึง repository ระหว่างโครงการ ทำให้องค์กรเห็นโค้ดพร้อมประวัติการแก้ไขตั้งแต่ sprint แรกโดยไม่ต้องรอเงื่อนไขใด เราเห็นว่าถ้าได้อย่างหลังอยู่แล้ว escrow สำหรับโค้ดที่จ้างเขียนใหม่จะเพิ่มความคุ้มครองได้น้อย","z06l7ar9remipy8","Code escrow ต่างจากการให้องค์กรเข้าถึง repository ระหว่างโครงการอย่างไร",{"answer":9,"id":10,"question":11},"ไม่จำเป็นเสมอไป แนวปฏิบัติด้านจัดซื้อของกระทรวงกลาโหมสหรัฐฯ (DFARS PGI 227.7203-2) ระบุว่า escrow ไม่ใช่ทางที่เหมาะในทุกกรณี แต่อาจมีประโยชน์เมื่อการส่งมอบหรือการเข้าถึงระหว่างสัญญาทำไม่ได้หรือไม่คุ้ม กรณีที่เราเห็นว่าควรพิจารณาคือส่วนที่ระบบพึ่งซอฟต์แวร์ที่ vendor เป็นเจ้าของเองและไม่เปิดโค้ด","5n0l5x9scbf0cx1","ระบบที่จ้างพัฒนาขึ้นใหม่ทั้งหมด จำเป็นต้องทำ code escrow ไหม",{"answer":13,"id":14,"question":15},"คำตอบขึ้นกับทั้งตัวบทกฎหมายลิขสิทธิ์และข้อความในสัญญาจ้าง เราไม่ใช่ที่ปรึกษากฎหมาย จึงแนะนำให้ฝ่ายกฎหมายขององค์กรตรวจข้อนี้ในร่างสัญญาของผู้เสนอแต่ละราย รวมถึงถามให้ชัดว่าองค์กรได้สิทธิ์อะไรในส่วนประกอบที่ vendor ไม่ได้เขียนขึ้นใหม่ เช่น library โอเพนซอร์สหรือ framework ของ vendor เอง","pnhkkz2jqbqnq8c","เมื่อจ้างบริษัทภายนอกพัฒนาระบบ ใครเป็นเจ้าของ source code",{"answer":17,"id":18,"question":19},"ถามเรื่องโครงสร้างทีม ไม่ใช่เรื่องตัวบุคคล เช่น บทบาทหลักในโครงการมีใครและใครเป็นคนสำรอง โค้ดทุกชิ้นผ่านการ review โดยคนที่ไม่ใช่ผู้เขียนหรือไม่ และเคยส่งต่องานกลางโครงการอย่างไร คำถามแบบนี้ vendor ตอบได้โดยไม่ต้องเปิดเผยข้อมูลภายในที่ไม่เกี่ยวกับโครงการ","wf8deygd9yv5548","จะประเมิน key-person risk ในทีมของ vendor ได้อย่างไรโดยไม่เสียความสัมพันธ์",{"answer":21,"id":22,"question":23},"บริการ DBD DataWarehouse+ ของกรมพัฒนาธุรกิจการค้า ให้ค้นข้อมูลนิติบุคคลและงบการเงิน และระบุว่าใช้ตรวจสถานะความมีตัวตนของนิติบุคคลได้ องค์กรจึงดูข้อมูลส่วนนี้เองได้โดยไม่ต้องขอเอกสารเพิ่มจาก vendor","yjxsl82w0n29ay4","ตรวจสถานะบริษัทของ vendor เองได้จากที่ไหน",{"answer":25,"id":26,"question":27},"คือการให้คนที่ไม่เคยแตะโครงการ จากทีมขององค์กรหรือทีมที่สาม ลอง build และ deploy ระบบขึ้น environment ทดสอบจากสิ่งที่อยู่ใน repository เพียงอย่างเดียว จุดที่ติดคือจุดที่ความรู้ยังอยู่ในหัวคน การซ้อมกลางโครงการทำให้ยังแก้จุดเหล่านั้นได้ทันก่อนส่งมอบ","96wm7r6h2nmx5yj","การซ้อมรับช่วงระบบกลางโครงการคืออะไร",{"id":29,"parentId":30,"title":31,"excerpt":32,"content":33,"image":34,"date":35,"isoDate":36,"views":37,"tag":38,"categorySlug":39,"slug":40,"to":41,"readTime":42,"isHighlight":43,"sortOrder":44,"video":45,"video_id":45,"keywords":46},"y602cupghzhthkn","aw7tyg35q14i5te","ก่อนจ้างพัฒนาระบบ ประเมินความเสี่ยงที่ vendor จะหายไปอย่างไร","ก่อนจ้างพัฒนาระบบ ควรถามอะไรเรื่องความต่อเนื่องของ vendor ตั้งแต่การเข้าถึง repository ระหว่างโครงการ key-person risk ไปจนถึง source code escrow ว่าคุ้มเมื่อไร","\u003Cp>ตอนกรรมการคัดเลือกผู้พัฒนาระบบนั่งเทียบข้อเสนอจากหลายราย คำถามหลักบนโต๊ะคือใครทำได้ตรงขอบเขตงานและส่งมอบทันกำหนด คำถามที่ควรถามคู่กันคือ ถ้าบริษัทนี้หรือคนหลักในทีมนี้ไม่อยู่แล้วในปีที่สาม องค์กรของคุณจะเหลืออะไรอยู่ในมือ\u003C\u002Fp>\u003Cp>คำถามนี้ไม่ได้มาจากความไม่ไว้ใจ บริษัทซอฟต์แวร์ปิดตัวหรือถูกควบรวมได้ด้วยเหตุผลที่ไม่เกี่ยวกับฝีมือของทีมเลย และคนเก่งในทีมก็ย้ายงานได้เสมอ\u003C\u002Fp>\u003Cp>เราเองก็เป็นผู้พัฒนาระบบที่องค์กรต้องประเมินเหมือนกัน บทความนี้จึงเขียนเป็นคำถามที่เราคิดว่าองค์กรควรถามผู้เสนอทุกราย รวมถึงถามเราด้วย ไม่ได้เขียนเพื่อบอกว่าควรเลือกใคร\u003C\u002Fp>\u003Cp>เงื่อนไขที่ควรเขียนลง TOR ตั้งแต่ต้น ตั้งแต่เอกสารสถาปัตยกรรมไปจนถึงบัญชีคลาวด์ในนามองค์กร เราเขียนไว้แล้วใน \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fblogs\u002Ftor-conditions-for-a-maintainable-system\">เขียน TOR ระบบอย่างไรให้ได้ระบบที่ดูแลต่อได้\u003C\u002Fa> บทความนี้ว่าด้วยขั้นถัดมา คือการอ่านผู้เสนอแต่ละรายในรอบคัดเลือก ก่อนเซ็นสัญญา\u003C\u002Fp>\u003Ch2>ความเป็นเจ้าของโค้ด กับการเปิดโค้ดได้จริง เป็นคนละเรื่อง\u003C\u002Fh2>\u003Cp>คำถามแรกที่องค์กรนึกถึงคือ ใครเป็นเจ้าของ source code ที่จ้างทำ คำตอบทางกฎหมายขึ้นกับทั้งตัวบทกฎหมายลิขสิทธิ์และข้อความในสัญญาที่สองฝ่ายตกลงกัน เราไม่ใช่ที่ปรึกษากฎหมาย จึงแนะนำให้ฝ่ายกฎหมายขององค์กรอ่านข้อนี้ในร่างสัญญาของผู้เสนอแต่ละรายโดยตรง\u003C\u002Fp>\u003Cp>ประเด็นที่ควรฝากฝ่ายกฎหมายดูด้วยคือส่วนประกอบที่ vendor ไม่ได้เขียนขึ้นใหม่สำหรับโครงการของคุณ เช่น library โอเพนซอร์ส หรือ framework ที่ vendor พัฒนาไว้ใช้กับหลายโครงการ ส่วนเหล่านี้มีเงื่อนไขการใช้งานของเจ้าของเดิมกำกับอยู่ จึงควรถามให้ชัดว่าองค์กรได้สิทธิ์อะไรในส่วนนั้นเมื่อสัญญาจบ\u003C\u002Fp>\u003Cp>จากฝั่งปฏิบัติ สิ่งที่เราเห็นว่าสำคัญไม่แพ้กันคือ ความเป็นเจ้าของบนกระดาษใช้ได้จริงก็ต่อเมื่อองค์กรเปิดโค้ดนั้นได้ สัญญาที่ให้ส่งมอบ source code ตอนปิดโครงการปกป้ององค์กรในวันที่โครงการจบตามแผน แต่ไม่ช่วยอะไรในวันที่ vendor หายไประหว่างทาง เพราะวันส่งมอบนั้นไม่เคยมาถึง\u003C\u002Fp>\u003Cp>ความเสี่ยงจริงอยู่ที่ช่วงกลางโครงการ\u003C\u002Fp>\u003Cp>คำถามที่ควรถามผู้เสนอทุกรายตั้งแต่รอบคัดเลือกจึงเป็นว่า ทีมขององค์กรจะอ่าน repository ได้ตั้งแต่ sprint แรกหรือไม่ และโค้ดจะถูก push เข้าไปทุกวันทำงาน หรือรวบส่งเป็นก้อนตอนตรวจรับงวดงาน รายที่ขอเก็บโค้ดไว้ในระบบของตัวเองก่อน ควรอธิบายได้ว่าองค์กรจะได้สำเนาที่อัปเดตบ่อยแค่ไหน\u003C\u002Fp>\u003Cp>ถ้าจำเป็นต้องให้ repository หลักอยู่ฝั่ง vendor ทางออกที่ตรวจได้คือให้มีสำเนาแบบ mirror อยู่ในที่ที่องค์กรควบคุม เอกสารของ Git อธิบายว่าโหมด \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fgit-scm.com\u002Fdocs\u002Fgit-clone\">--mirror\u003C\u002Fa> ไม่ได้ map แค่ branch แต่ map ทุก ref ของต้นทาง รวมถึง remote-tracking branch และ notes และตั้งค่าให้ ref เหล่านั้นถูกเขียนทับทุกครั้งที่สั่งอัปเดต สำเนาแบบนี้เก็บประวัติการแก้ไขไว้ครบ ซึ่งเราเห็นว่ามีค่ากว่าไฟล์ zip ชุดสุดท้าย เพราะประวัติบอกได้ว่าโค้ดแต่ละส่วนถูกแก้เมื่อไรและพร้อมกับงานชิ้นไหน\u003C\u002Fp>\u003Ch2>Key-person risk: บริษัทยังอยู่ แต่คนที่รู้ระบบอาจไม่อยู่\u003C\u002Fh2>\u003Cp>vendor ที่มั่นคงในระดับบริษัท ยังมีความเสี่ยงอีกชั้นหนึ่งที่มองจากงบการเงินไม่เห็น คือความรู้เรื่องระบบของคุณอาจไปกองอยู่กับคนหนึ่งหรือสองคนในทีม\u003C\u002Fp>\u003Cp>ลองนึกภาพว่า tech lead ที่ออกแบบโครงสร้างข้อมูลทั้งหมดลาออกในเดือนที่เจ็ดของโครงการ บริษัทยังอยู่ครบและยังส่งคนใหม่มาแทน แต่คนใหม่ต้องอ่านย้อนเองว่าทำไมระบบถึงออกมาเป็นแบบนี้ ระหว่างนั้นงานของคุณเดินช้าลงโดยไม่มีใครผิดสัญญา\u003C\u002Fp>\u003Cp>สัญญาณที่ถามได้โดยไม่ล่วงเกินใคร มีอยู่ไม่กี่ข้อ\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>ขอรายชื่อบทบาทหลักที่จะทำงานในโครงการจริง พร้อมคนสำรองของแต่ละบทบาท ไม่ใช่แค่รายชื่อทีมที่มานำเสนอ\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ถามว่าโค้ดทุกชิ้นผ่านการ review โดยคนที่ไม่ใช่ผู้เขียนหรือไม่ ถ้าใช่ แปลว่ามีอย่างน้อยสองคนที่เคยอ่านทุกส่วนของระบบ\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ขอคุยกับทีมที่จะลงมือทำจริงสักครั้งก่อนตัดสินใจ\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ถามว่าเคยมีสมาชิกทีมลาออกกลางโครงการหรือไม่ และตอนนั้นส่งต่องานกันอย่างไร โดยถามถึงกระบวนการ ไม่ต้องถามชื่อคน\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>คำตอบที่ดีไม่จำเป็นต้องบอกว่าไม่เคยมีใครลาออก คำตอบที่มีประโยชน์กว่าคือเล่าได้ว่าส่งต่องานอย่างไร และใช้เวลานานเท่าไรกว่าคนใหม่จะทำงานต่อได้\u003C\u002Fp>\u003Ch2>Source code escrow คืออะไร และคุ้มเมื่อไร\u003C\u002Fh2>\u003Cp>Code escrow คือการฝาก source code ไว้กับคนกลาง แนวปฏิบัติด้านจัดซื้อของกระทรวงกลาโหมสหรัฐฯ ใน \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.acquisition.gov\u002Fdfarspgi\u002Fpgi-227.7203-2-acquisition-other-commercial-computer-software-and-computer-software-documentation-and-associated-rights.\">DFARS PGI 227.7203-2\u003C\u002Fa> อธิบายว่าฝ่ายรัฐกับผู้รับจ้างตกลงเลือก escrow agent ที่เป็นบุคคลที่สาม ให้เก็บซอฟต์แวร์ที่ระบุไว้จนกว่าจะเกิดเงื่อนไขที่เขียนไว้ในสัญญา เมื่อเงื่อนไขนั้นเกิดขึ้น ฝ่ายรัฐจึงขอรับของที่ฝากไว้ได้ และสัญญาต้องระบุด้วยว่าฝ่ายรัฐมีสิทธิ์ใช้ของที่ฝากนั้นแค่ไหน\u003C\u002Fp>\u003Cp>เอกสารเดียวกันเขียนไว้ด้วยว่า escrow ไม่ใช่ทางที่เหมาะในทุกกรณี แต่อาจมีประโยชน์เมื่อการส่งมอบหรือการเข้าถึงระหว่างสัญญาทำไม่ได้หรือไม่คุ้ม เราเห็นว่าประโยคนี้คือหัวใจของการตัดสินใจ ถ้าองค์กรอ่าน repository ได้ตลอดโครงการอยู่แล้ว escrow สำหรับโค้ดที่จ้างเขียนขึ้นใหม่จะเพิ่มความคุ้มครองได้น้อย\u003C\u002Fp>\u003Cp>กรณีที่เราเห็นว่า escrow ยังควรพิจารณา คือเมื่อระบบของคุณพึ่งซอฟต์แวร์ที่ vendor เป็นเจ้าของเองและให้ใช้แบบไม่เปิดโค้ด เช่น แพลตฟอร์มของ vendor ที่ระบบทั้งระบบวางอยู่บนนั้น ส่วนนี้องค์กรไม่ได้โค้ดมาตั้งแต่แรก ถ้า vendor หายไป โค้ดที่ฝากไว้กับคนกลางคือสิ่งที่ทำให้ยังมีทางแก้ไขต่อ\u003C\u002Fp>\u003Cp>จากมุมของเรา escrow มีข้อจำกัดที่ควรรู้ก่อนเซ็น ของที่ฝากไว้อาจไม่ใช่เวอร์ชันล่าสุดหรือ build ไม่ผ่าน ถ้าไม่มีใครรับหน้าที่ตรวจเป็นระยะ และต่อให้ของที่ฝากไว้สมบูรณ์ โค้ดที่ได้มาโดยไม่มีคนอธิบาย ยังต้องใช้เวลาอีกนานกว่าทีมใหม่จะดูแลได้ escrow จึงช่วยเรื่องการเข้าถึง แต่ไม่ได้แก้เรื่องคน\u003C\u002Fp>\u003Cp>ความเสี่ยงชนิดนี้ต่างจากการผูกกับ cloud provider รายเดียว ซึ่งเราแยกเขียนไว้ใน \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fblogs\u002Fmulti-cloud-vs-vendor-lockin-decision\">กรอบตัดสินใจเรื่อง Cloud รายเดียวหรือหลายราย\u003C\u002Fa>\u003C\u002Fp>\u003Ch2>อ่านสัญญาณความต่อเนื่องของ vendor โดยไม่ต้องขอเกินควร\u003C\u002Fh2>\u003Cp>ข้อมูลบางส่วนองค์กรตรวจเองได้โดยไม่ต้องขอจาก vendor เลย กรมพัฒนาธุรกิจการค้าเปิดบริการ \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fdatawarehouse.dbd.go.th\u002F\">DBD DataWarehouse+\u003C\u002Fa> ให้ค้นข้อมูลนิติบุคคลและงบการเงิน และระบุว่าข้อมูลนี้ใช้ประกอบการพิจารณาการลงทุนและเช็คสถานะความมีตัวตนของนิติบุคคลได้ การดูสถานะของบริษัทและข้อมูลงบการเงินที่ยื่นไว้ เป็นการตรวจที่ไม่ต้องรบกวนใคร\u003C\u002Fp>\u003Cp>สิ่งที่เราเห็นว่าเกินควร คือการขอเอกสารภายในที่ vendor ไม่มีเหตุต้องเปิดเผย เช่น รายชื่อผู้ว่าจ้างรายอื่นพร้อมมูลค่าสัญญา การขอแบบนี้ไม่ได้ทำให้ความเสี่ยงของคุณลดลง และทำให้ vendor ที่รักษาความลับของผู้ว่าจ้างรายอื่นกลายเป็นฝ่ายเสียเปรียบ\u003C\u002Fp>\u003Cp>คำถามที่ได้ข้อมูลมากกว่าคือ ระบบที่ vendor เคยสร้างไว้หลายปีก่อน ยังมีตัวไหนเปิดใช้งานอยู่ และเจ้าของระบบยินดีให้คุณโทรคุยหรือไม่ ถ้ามี ให้ถามเจ้าของระบบว่าตอนที่คนในทีม vendor เปลี่ยน งานสะดุดแค่ไหน และถ้าวันหนึ่งต้องย้ายไปให้ทีมอื่นดูแล เขาคิดว่าทำได้จริงหรือไม่\u003C\u002Fp>\u003Cp>อีกคำขอที่สมเหตุสมผลคือขอดูตัวอย่างชุดส่งมอบจากโครงการเก่า ถ้าติดข้อตกลงรักษาความลับ แค่สารบัญหรือ template ก็พอบอกได้ว่า vendor คิดเรื่องการส่งต่องานไว้ละเอียดแค่ไหน\u003C\u002Fp>\u003Ch2>สิ่งที่ควรได้รับระหว่างทาง ไม่ใช่แค่วันส่งมอบ\u003C\u002Fh2>\u003Cp>เป้าหมายของทุกข้อข้างต้นคือให้ทีมอื่นรับช่วงต่อได้ถ้าวันหนึ่งจำเป็น การรับช่วงต่อทำได้จริงเมื่อองค์กรได้ของบางอย่างสะสมมาตลอดทาง ไม่ใช่ได้ทั้งหมดในสัปดาห์สุดท้าย รายการที่เราเห็นว่าควรถามผู้เสนอทุกรายว่าจะส่งอย่างไรและบ่อยแค่ไหน มีดังนี้\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>โค้ดพร้อมประวัติการแก้ไข ใน repository ที่องค์กรอ่านได้ ตามที่กล่าวไว้ข้างต้น\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ขั้นตอน build และ deploy ที่เขียนเป็น pipeline หรือ script อยู่ใน repository ไม่ใช่ขั้นตอนที่อยู่ในเครื่องหรือในความจำของคนคนเดียว\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ชุดทดสอบอัตโนมัติที่คนนอกทีมสั่งรันได้ และอ่านผลได้เองว่าผ่านหรือไม่ผ่าน\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>backlog และรายการ bug ที่รู้แล้วแต่ยังไม่ได้แก้ ในระบบที่องค์กรเปิดดูได้ เพราะรายการนี้คือสิ่งแรกที่ทีมใหม่ต้องรู้\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ค่าตั้งต้นของแต่ละ environment ที่แยกความลับออกไปเก็บต่างหากแล้ว\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>วิธีตรวจว่ารายการเหล่านี้ใช้ได้จริงที่เราแนะนำ คือนัดซ้อมรับช่วงสักครั้งกลางโครงการ ให้คนจากทีมขององค์กรหรือทีมที่สามซึ่งไม่เคยแตะโครงการนี้ build และ deploy ระบบขึ้น environment ทดสอบ จากสิ่งที่อยู่ใน repository เพียงอย่างเดียว\u003C\u002Fp>\u003Cp>จุดที่ติดคือจุดที่ความรู้ยังอยู่ในหัวคน\u003C\u002Fp>\u003Cp>กลางโครงการคือช่วงที่ยังแก้จุดเหล่านั้นได้ทัน ในรอบคัดเลือก ให้ถามผู้เสนอว่ายินดีให้ซ้อมแบบนี้หรือไม่ และถ้ายินดี จะเขียนเป็นส่วนหนึ่งของงวดงานได้หรือไม่\u003C\u002Fp>\u003Ch2>ข้อจำกัดของเกณฑ์เหล่านี้\u003C\u002Fh2>\u003Cp>ข้อเสียที่ต้องพูดให้ชัดคือ เกณฑ์เรื่อง key-person ทำให้ vendor ทีมเล็กเสียคะแนน ทั้งที่ทีมสี่ห้าคนที่มีประสบการณ์ตรงกับโจทย์ อาจทำงานได้ดีกว่าทีมใหญ่ที่หมุนคนเข้าออก ถ้าคุณตัดทีมเล็กออกเพราะจำนวนคนอย่างเดียว องค์กรอาจเสียตัวเลือกที่เหมาะกับงานไป คำแนะนำของเราในกรณีนั้นคือให้น้ำหนักกับการเข้าถึง repository และการซ้อมรับช่วงมากกว่าจำนวนคน เพราะสองข้อนี้ลดความเสี่ยงได้โดยไม่ขึ้นกับขนาดของทีม\u003C\u002Fp>\u003Ch2>ข้อโต้แย้งที่ได้ยินบ่อย\u003C\u002Fh2>\u003Cp>ข้อโต้แย้งที่ได้ยินบ่อยคือ vendor รายนี้เป็นบริษัทใหญ่ มีพนักงานหลายร้อยคน ไม่มีทางหายไปง่าย ๆ ข้อนี้มีเหตุผล โอกาสที่บริษัทใหญ่จะปิดตัวอาจต่ำกว่าจริง แต่ความต่อเนื่องที่องค์กรต้องการไม่ใช่ความต่อเนื่องของบริษัท เป็นความต่อเนื่องของระบบที่คุณจ้างทำ\u003C\u002Fp>\u003Cp>บริษัทขนาดไหนก็ย้ายทีมไปรับโครงการอื่น หรือเลิกทำผลิตภัณฑ์บางตัวได้ตามเหตุผลทางธุรกิจของตัวเอง คำถามในบทความนี้จึงใช้กับ vendor ทุกขนาด และคำตอบของบริษัทใหญ่ก็ควรผ่านเกณฑ์เดียวกัน\u003C\u002Fp>\u003Ch2>จะเริ่มตรงไหน\u003C\u002Fh2>\u003Cp>ถ้ากำลังจะเปิดรับข้อเสนอรอบถัดไป จุดเริ่มที่ทำได้ทันทีคือเพิ่มคำถามลงในเกณฑ์ประเมินผู้เสนอราคา และให้ทุกรายตอบเป็นลายลักษณ์อักษรในรูปแบบเดียวกัน\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>องค์กรจะอ่าน repository ได้ตั้งแต่เมื่อไร และโค้ดเข้าไปบ่อยแค่ไหน\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>บทบาทหลักในโครงการมีใครบ้าง และใครสำรองแต่ละบทบาท\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ยินดีให้ซ้อมรับช่วงกลางโครงการหรือไม่\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>มีส่วนไหนของระบบที่ใช้ซอฟต์แวร์ซึ่ง vendor เป็นเจ้าของและไม่เปิดโค้ด ถ้ามี จะเสนอทางคุ้มครองอะไร\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>ระหว่างนั้นให้ฝ่ายกฎหมายอ่านข้อความเรื่องสิทธิ์ใน source code ในร่างสัญญาของแต่ละราย ส่วนเงื่อนไขการดูแลระบบหลังส่งมอบเป็นอีกสัญญาหนึ่ง ซึ่งเราแยกไว้ใน \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fblogs\u002Fma-sla-contract-checklist-before-signing\">ก่อนเซ็นสัญญาดูแลระบบรายปี\u003C\u002Fa>\u003C\u002Fp>\u003Cdiv data-type=\"horizontalRule\">\u003Chr>\u003C\u002Fdiv>\u003Ch2>สรุป\u003C\u002Fh2>\u003Cp>ถ้าจะหยิบไปใช้อย่างเดียวจากบทความนี้ ให้ถามผู้เสนอทุกรายว่าองค์กรจะเปิด repository ได้ตั้งแต่ sprint แรกหรือไม่ ความเป็นเจ้าของโค้ดที่เขียนไว้ในสัญญา มีค่าเท่ากับสิ่งที่องค์กรเปิดดูได้จริงในวันที่ต้องใช้\u003C\u002Fp>\u003Cp>หากองค์กรของคุณกำลังร่างเกณฑ์คัดเลือกผู้พัฒนาระบบ และอยากให้มีคนช่วยอ่านทบทวน ติดต่อ \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002F\">Superdev\u003C\u002Fa> ได้ที่ 088-983-9386 หรืออีเมล contact@superdev.tech สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ ไม่มีกำหนดเวลาบังคับ และถ้าคุยแล้วคุณอยากถามคำถามในบทความนี้กับเราด้วย เรายินดีตอบทุกข้อ\u003C\u002Fp>","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fpbc_2128795511\u002Fy602cupghzhthkn\u002Fcover_cover_p7ocz2qhiy.webp","30 กันยายน 2569","2026-09-30 06:19:23.369Z",118,"Enterprise","enterprise","vendor-continuity-due-diligence","\u002Fblogs\u002Fvendor-continuity-due-diligence",2,false,0,"",[47,48,49,50,51,52],"จ้างพัฒนาระบบ","สัญญาจ้างพัฒนาระบบ","source code escrow","code escrow","เจ้าของ source code","key-person risk"]