วิธีการจัดการเมื่อพบปัญหาในระบบหลังจากการตรวจรับ

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

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

ไม่แปลกใจที่จะพบบั๊กหลังจากการตรวจรับหรือกระบวนการทดสอบ

จากมุมมองทางเทคนิค, ไม่ใช่เรื่องแปลกหรือน่าตกใจที่จะพบบั๊กหรือปัญหาต่างๆ หลังจากที่ผู้ขายทำการทดสอบทุกขั้นตอนและผู้ใช้งานผ่านการตรวจรับแล้ว. การตรวจรับที่ผู้ใช้งานทำมักจะเป็นการตรวจสอบการป้อนข้อมูลและการแสดงผลบนหน้าจอ. แต่ระบบ IT มักจะมีโครงสร้างที่ซับซ้อนและละเอียดยิบอยู่เบื้องหลังหน้าจอที่ผู้ใช้งานสามารถเห็นได้, ไม่ว่าจะเป็นฐานข้อมูลหรือโปรแกรมที่ควบคุมการคำนวณและการควบคุมต่างๆ. ดังนั้น, การตรวจสอบการป้อนข้อมูลและการแสดงผลบนหน้าจอจากมุมมองของผู้ใช้งานจึงมีข้อจำกัด. ดังนั้น, การตรวจสอบทุกความเป็นไปได้ของปัญหาที่อาจเกิดขึ้นในระยะการใช้งานจริงอาจไม่เป็นไปตามความเป็นจริง.

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

ในขั้นตอนของการตรวจรับหรือการทดสอบ, การค้นหาและแก้ไขบั๊กหรือปัญหาทั้งหมดอาจไม่เป็นไปตามความเป็นจริง, และอาจพบปัญหาต่างๆ หลังจากเริ่มใช้งานจริง. นี่คือจุดที่ควรเข้าใจเกี่ยวกับระบบ IT.

ปกติแล้วจะถือว่าได้ทำหน้าที่ชำระหนี้แล้ว

แล้วถ้าเกิดปัญหาเช่นนี้ขึ้นจริง ๆ ควรจะจัดการอย่างไรดี? จะจัดเรียงตามลำดับทางกฎหมาย

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

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

https://monolith.law/corporate/system-development-contact-agreement[ja]

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

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

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

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

ขั้นตอนในการดำเนินการตามความรับผิดชอบจากการรับประกันความบกพร่อง

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

ขั้นแรกคือการยืนยันระดับความสำคัญและความรุนแรงของข้อผิดพลาดหรือความบกพร่อง

เมื่อข้อผิดพลาดหรือความบกพร่องเกิดขึ้นหลังจากนั้นและถูกจำแนกว่า “ความบกพร่อง” ตามกฎหมาย, ความรุนแรงของข้อผิดพลาดหรือความบกพร่องจะกลายเป็นปัญหา ปัญหาของความบกพร่องตามกฎหมายมีสาเหตุมาจาก

1. แม้จะเป็นข้อผิดพลาดหรือความบกพร่อง แต่ถ้าเป็นเพียงเรื่องเล็กน้อยและไม่สามารถถือว่าเป็น “ความบกพร่อง” ตามกฎหมาย
2. ถ้าเป็น “ความบกพร่อง” ตามกฎหมาย แต่ยังสามารถทำให้สามารถบรรลุวัตถุประสงค์ของสัญญา
3. ถ้าเป็น “ความบกพร่อง” ตามกฎหมาย และไม่สามารถทำให้สามารถบรรลุวัตถุประสงค์ของสัญญา

มี 3 แบบ ความรับผิดชอบจากการรับประกันความบกพร่องที่สามารถแบ่งออกเป็นสองส่วนคือ ข้อ 1 และ 2 และความสามารถในการยกเลิกสัญญาตามความรับผิดชอบจากการรับประกันความบกพร่องคือ ข้อ 2 และ 3.

บทความที่ 634

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

2. ผู้สั่งงานสามารถขอ ค่าเสียหาย แทนการซ่อมแซมความบกพร่องหรือร่วมกับการซ่อมแซมความบกพร่อง ในกรณีนี้, จะใช้บทความที่ 533

บทความที่ 635

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

นอกจากนี้, เราได้ทำการอธิบายเกี่ยวกับการแบ่งความบกพร่องในแต่ละขั้นตอนอย่างละเอียดในบทความต่อไปนี้.

https://monolith.law/corporate/defect-warranty-liability[ja]

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

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

https://monolith.law/corporate/the-minutes-in-system-development[ja]

นอกจากการยกเลิก, สิ่งที่สามารถขอตามความรับผิดชอบจากการรับประกันความบกพร่องได้รวมถึงการขอค่าเสียหายและการขอซ่อมแซมความบกพร่อง.

ข้อควรระวังอื่น ๆ

เมื่อทำการทางกฎหมาย เช่น การยกเลิกสัญญา ควรระมัดระวังวิธีการ

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

https://monolith.law/corporate/cancellation-of-contracts-in-system-development[ja]

การแก้ไขปัญหาด้วยการต่อรอง ไม่ใช่การทะเลาะวิวาท คือสิ่งที่ควรประสงค์

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

https://monolith.law/corporate/disputes-related-to-system-development[ja]

ควรแยกความคิดเห็นระหว่างบั๊กหรือปัญหา และขาดแคลนฟังก์ชัน

ในกรณีที่ฟังก์ชันหรือข้อกำหนดที่ได้รับการสร้างมามีบั๊กหรือปัญหา หรือไม่มีฟังก์ชันที่จำเป็นอยู่เลย การสนทนาจะต่างกัน หากไม่มีฟังก์ชันที่จำเป็นอยู่ การ “เสร็จสิ้นงาน” ในสัญญาจ้างงานอาจไม่ได้รับการยอมรับ และอาจไม่ได้รับการยอมรับในการปฏิบัติตามหน้าที่

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

สรุป

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