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

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

สิ่งนี้แตกต่างจากความสัมพันธ์ระหว่างผู้สั่งซื้อและผู้รับสั่งซื้อทั่วไป ยกตัวอย่างเช่น หากคุณสั่งทำสูทที่เป็นออเดอร์เมดจากร้านสูท ฝ่ายผู้สั่งซื้อ (User) จะไม่มี “ความรับผิดชอบ” ใดๆ ที่ต้องรับ “ความรับผิดชอบ” นั้นจะอยู่ที่ฝ่ายผู้รับสั่งซื้อ (Vendor) แต่เนื่องจากระบบ IT ต้องใช้แรงงานและเวลาในการทำงานมาก ฝ่ายผู้สั่งซื้อจึงต้อง “ร่วมมือ” กับฝ่ายผู้รับเหมา

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

ไม่สามารถทิ้งทุกอย่างให้กับระบบของตนเองได้

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

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

ดังนั้น ฝ่ายผู้ใช้ไม่ควร adopt ท่าทีที่ “ฉันไม่ใช่ผู้เชี่ยวชาญด้านเทคโนโลยีสารสนเทศ” แต่ควรให้ข้อมูลอย่างกระตือรือร้นเพื่อให้โปรเจคดำเนินไปอย่างราบรื่น ในทางนี้ บทบาทที่ฝ่ายผู้ใช้รับผิดชอบในโปรเจคการพัฒนาระบบจริงๆ แล้วไม่ได้เล็กน้อยเลย

หน้าที่ในการร่วมมือของผู้ใช้งานตามตัวอย่างคดีที่ผ่านมา

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

ในกรณีที่ผู้ขาย (ผู้ถูกฟ้อง) ส่งมอบผลงานล่าช้า ความล่าช้าในการตัดสินใจของผู้ใช้งาน (ผู้ฟ้อง) และอื่น ๆ ได้กลายเป็นประเด็นที่ถูกโต้แย้งเกี่ยวกับหน้าที่ในการร่วมมือของผู้ใช้งานในการพัฒนา ศาลได้ยอมรับว่าผู้ใช้งานไม่ปฏิบัติตามหน้าที่ในการร่วมมือ และปฏิเสธความรับผิดชอบในการไม่ปฏิบัติตามสัญญาของผู้ขาย (แม้ว่าการยกเลิกสัญญาจะได้รับการยอมรับ แต่ยังได้รับการลดหย่อนความผิดถึง 60% อีกด้วย)

สัญญาในการพัฒนาระบบคอมพิวเตอร์ในคดีนี้ เป็นสัญญาในการพัฒนาระบบที่ทำขึ้นตามความต้องการเฉพาะเจาะจง ในสัญญาการพัฒนาระบบแบบนี้ ผู้รับจ้าง (ผู้ขาย) ไม่สามารถสร้างระบบได้ด้วยตนเอง ผู้ว่าจ้าง (ผู้ใช้งาน) จำเป็นต้องประสานความคิดเห็นภายในอย่างถูกต้อง และสรุปความคิดเห็น แล้วแจ้งให้ผู้รับจ้างทราบว่าต้องการฟังก์ชันอะไร และร่วมกับผู้รับจ้าง ในการพิจารณาฟังก์ชันที่ต้องการ และตัดสินใจเรื่องฟังก์ชันสุดท้าย และตัดสินใจเรื่องหน้าจอและรายงาน และตรวจสอบผลงานที่ได้รับ ฯลฯ ซึ่งเป็นหน้าที่ที่ต้องร่วมมือกัน

คำพิพากษาศาลจังหวัดโตเกียว วันที่ 10 มีนาคม พ.ศ. 2547 (2004)

คำพิพากษานี้ไม่เพียงแค่แสดงว่าการพัฒนาระบบเป็นงานร่วมกันระหว่างผู้ใช้งาน แต่ยังระบุว่า “ควรร่วมมือกันในด้านใดบ้าง” ซึ่งเป็นคำแนะนำที่มีความหมายอย่างมาก

ลองแปลคำพิพากษาข้างต้นเป็นภาษา IT ที่ใช้ในการพัฒนาระบบดู

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

นอกจากนี้ หากผู้ใช้งานไม่ปฏิบัติตามหน้าที่ในการร่วมมือ อาจจะต้องเผชิญกับความเสี่ยงที่ผู้ขายจะเรียกร้องค่าเสียหายจากผู้ใช้งานตามสัญญาที่ไม่ปฏิบัติหรือการกระทำที่ผิดกฎหมาย

การร้องขอการเปลี่ยนแปลงข้อกำหนดหลังจากเริ่มโครงการจะถูกเข้าใจอย่างไร

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

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

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

ในกรณีที่งานเพิ่มเติมเกิดขึ้นก่อนการระบุข้อกำหนดของการออกแบบภายนอก

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

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

คำพิพากษาศาลจังหวัดโตเกียว วันที่ 10 มีนาคม พ.ศ. 2547 (ค.ศ. 2004)

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

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

ในกรณีที่งานเพิ่มเติมเกิดขึ้นหลังจากการยืนยันข้อกำหนดของกระบวนการผลิตและการทดสอบ

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

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

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

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

บทความที่เกี่ยวข้อง: วิธีการจดบันทึกการประชุมในการพัฒนาระบบจากมุมมองทางกฎหมาย

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

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

หากผู้ใช้ไม่ร่วมมือในกระบวนการพัฒนา แม้ว่าโครงการจะล้มเหลว ศาลอาจมีความเห็นที่เข้มงวดต่อผู้ใช้ ดังนั้น คุณควรรับรู้เรื่องนี้ก่อน