Biện pháp đối phó khi phát hiện lỗi hệ thống sau khi kiểm tra

Phát triển hệ thống, nói chung, được tiến hành theo nội dung đã được quyết định trong giai đoạn định rõ yêu cầu, và cuối cùng là việc xác nhận cùng người dùng và nhà cung cấp liệu chương trình đã được hoàn thiện theo đúng yêu cầu hay chưa, và kết thúc khi được chấp nhận trong quá trình kiểm tra.

Tuy nhiên, trong thực tế, có thể xảy ra tình huống mà các lỗi hoặc sự cố không thể phát hiện được trong quá trình kiểm tra và khi được chấp nhận, nhưng lại được phát hiện trong giai đoạn vận hành sau đó. Nếu đã chấp nhận việc giao hàng một lần, vậy theo pháp luật, chúng ta có thể yêu cầu điều gì?

Không lạ khi vẫn còn lỗi sau khi kiểm tra hoặc sau quá trình thử nghiệm

Từ quan điểm kỹ thuật, việc phát hiện ra nhiều lỗi và sự cố sau khi hoàn thành các quá trình thử nghiệm của nhà cung cấp và sau khi người dùng kiểm tra không phải là điều hiếm gặp. Những gì người dùng thường thực hiện trong quá trình kiểm tra là kiểm tra đầu vào và đầu ra có thể xác nhận từ màn hình. Tuy nhiên, hệ thống IT thường có cấu trúc phức tạp và tinh vi hơn nhiều so với giao diện mà người dùng có thể xác nhận từ màn hình, bao gồm cơ sở dữ liệu phía sau và các phần của chương trình điều khiển các phép tính và điều khiển khác nhau. Do đó, có giới hạn về những gì có thể được kiểm tra từ việc kiểm tra đầu vào và đầu ra trên màn hình từ góc nhìn của người dùng. Do đó, việc kiểm tra toàn diện tất cả các khả năng sự cố có thể xảy ra trong giai đoạn vận hành sau đó không phải là thực tế.

Trường hợp tương tự cũng đúng khi nhìn từ góc độ của nhà cung cấp phụ trách công việc phát triển. Ví dụ, việc kiểm tra xem có lỗi hay sự cố nào trong nội dung của chương trình đã được triển khai hay không là “quá trình thử nghiệm”. Tuy nhiên, trong quá trình thử nghiệm, không phải lúc nào cũng có thể kiểm tra toàn diện tất cả các khả năng lỗi và sự cố. Ngay cả sau khi hệ thống đã được phát triển bắt đầu được sử dụng một cách chính thức trong công việc, có thể có các hoạt động mà nhà cung cấp không dự đoán được, hoặc có thể bắt đầu đăng ký dữ liệu lớn, hoặc nhiều người dùng có thể bắt đầu truy cập cùng một lúc. Việc tạo ra một hệ thống có thể tiếp tục hoạt động mà không gặp trở ngại trong những tình huống như vậy đòi hỏi kỹ năng kỹ thuật xuất sắc.

Trong các giai đoạn như kiểm tra và thử nghiệm, việc phát hiện ra tất cả các lỗi và sự cố không phải là thực tế, và việc hiểu rằng có thể phát hiện ra nhiều vấn đề sau khi bắt đầu sử dụng là điều cần thiết đối với hệ thống IT.

Thường thì nợ tự thân đã được thực hiện

Vậy nếu những rắc rối như thế này thực sự được phát hiện, chúng ta nên xử lý như thế nào? Hãy sắp xếp theo thứ tự pháp lý.

Đầu tiên, nếu các lỗi và sự cố đã được phát hiện, dù là sau cùng, người dùng sẽ muốn truy cứu trách nhiệm từ nhà cung cấp đã được yêu cầu thực hiện công việc cho đến nay. Tuy nhiên, thường thì, nếu việc giao hàng đã hoàn tất và đã được chấp nhận, việc truy cứu trách nhiệm dựa trên việc không thực hiện nghĩa vụ thường khó khăn.

Trước hết, nếu không có thỏa thuận đặc biệt nào được chuẩn bị, các quy định về việc triển khai chương trình trong hợp đồng phát triển hệ thống sẽ được áp dụng theo quy định của hợp đồng thầu trong luật dân sự Nhật Bản. Chi tiết về hợp đồng thầu được giải thích trong bài viết dưới đây.

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

Và trong hợp đồng thầu, “hoàn thành công việc” là yêu cầu thực hiện nghĩa vụ. Bài viết dưới đây giải thích chi tiết về “hoàn thành công việc” nghĩa là gì.

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

Ở đây, chúng tôi giải thích rằng “hoàn thành công việc” trong hợp đồng thầu, nếu nói trong ngữ cảnh phát triển hệ thống, có nghĩa là kết thúc toàn bộ quá trình phát triển. Và chúng tôi giải thích rằng các vấn đề như lỗi và sự cố sau khi toàn bộ quá trình phát triển đã kết thúc là vấn đề về trách nhiệm bảo đảm khuyết tật trong hợp đồng thầu.

Để tổng kết, nếu việc giao hàng đã được chấp nhận một lần và việc kiểm tra đã hoàn tất, thì điều đầu tiên cần làm là giả định rằng nghĩa vụ đã được thực hiện, và sau đó là vấn đề về bảo đảm chất lượng, tức là việc có thể truy cứu trách nhiệm bảo đảm khuyết tật hay không.

Con đường tiếp tục trách nhiệm dựa trên trách nhiệm bảo đảm khiếm khuyết

Vậy, khi yêu cầu nhà cung cấp phản ứng dựa trên trách nhiệm bảo đảm khiếm khuyết, chúng ta nên xem xét điều gì và theo thứ tự nào? Hãy xem xét những điều sau đây.

Đầu tiên, hãy xác định mức độ nghiêm trọng và sự nghiêm trọng của lỗi và sự cố

Khi lỗi và sự cố được phát hiện sau cùng, và nếu chúng được coi là “khiếm khuyết” theo luật pháp và yêu cầu một số loại bảo đảm, mức độ nghiêm trọng của lỗi và sự cố trở thành vấn đề. Vấn đề về khiếm khuyết theo luật pháp, ngay từ đầu

1. Ngay cả khi có thể coi là lỗi và sự cố, nó chỉ là nhỏ và không thể coi là “khiếm khuyết” theo luật pháp
2. Đủ điều kiện để được coi là “khiếm khuyết” theo luật pháp, nhưng vẫn có thể đạt được mục tiêu của hợp đồng
3. Đủ điều kiện để được coi là “khiếm khuyết” theo luật pháp, và cũng không thể đạt được mục tiêu của hợp đồng

Có 3 mô hình. Điều phân biệt khả năng tiếp tục trách nhiệm dựa trên trách nhiệm bảo đảm khiếm khuyết là ranh giới giữa 1 và 2, và điều phân biệt khả năng hủy bỏ hợp đồng dựa trên trách nhiệm bảo đảm khiếm khuyết là ranh giới giữa 2 và 3.

Điều 634

1. Khi có khiếm khuyết trong mục tiêu công việc, người đặt hàng có thể yêu cầu người nhận công việc sửa chữa khiếm khuyết trong một khoảng thời gian hợp lý. Tuy nhiên, điều này không áp dụng khi khiếm khuyết không quan trọng và việc sửa chữa đòi hỏi chi phí quá mức.

2. Người đặt hàng có thể yêu cầu bồi thường thiệt hại thay cho việc sửa chữa khiếm khuyết hoặc cùng với việc sửa chữa đó. Trong trường hợp này, quy định của Điều 533 được áp dụng

Điều 635

Khi có khiếm khuyết trong mục tiêu công việc và do đó không thể đạt được mục tiêu của hợp đồng, người đặt hàng có thể hủy bỏ hợp đồng. Tuy nhiên, điều này không áp dụng cho các công trình trên đất đai như tòa nhà.

Ngoài ra, về sự phân biệt theo từng giai đoạn của “khiếm khuyết” này, chúng tôi đã giải thích chi tiết trong bài viết dưới đây.

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

Tiếp theo, hãy làm rõ những điều cần yêu cầu từ nhà cung cấp

Đồng thời, cần phải rõ ràng về việc cần yêu cầu gì từ đối tác. Nếu bạn muốn hủy bỏ hợp đồng, việc chỉ chứng minh rằng nó là một khiếm khuyết không đủ, nó phải là một thứ có thể nói là “không thể đạt được mục tiêu của hợp đồng”. Trong việc xác định “mục tiêu” này, biên bản họp và các mục ghi chú trong tài liệu đặc tả được thực hiện khi dự án phát triển hệ thống bắt đầu được coi là manh mối quan trọng. Có thể có trường hợp lỗi và sự cố được phát hiện sau khi chấp nhận, vì vậy sau khi dự án phát triển kết thúc, bạn nên lưu trữ tất cả các tài liệu một cách kỹ lưỡng.

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

Ngoài việc hủy bỏ, những điều có thể yêu cầu dưới dạng nội dung trách nhiệm bảo đảm khiếm khuyết bao gồm yêu cầu bồi thường thiệt hại và yêu cầu sửa chữa khiếm khuyết.

Điểm cần lưu ý khác

Khi thực hiện các hành động pháp lý như hủy bỏ hợp đồng, cần chú ý cách thức

Nếu bạn thực hiện hủy bỏ hợp đồng như một nội dung của trách nhiệm bảo đảm khiếm khuyết, bạn cũng nên nắm vững kiến thức về cách thức thực hiện các thủ tục hành chính pháp lý để hủy bỏ. Về hiệu quả của việc hủy bỏ hợp đồng, cách thức biểu lộ ý chí hợp lệ, cách thức thông báo để không gây rắc rối sau này, chúng tôi đã giải thích chi tiết trong bài viết dưới đây.

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

Giải quyết thông qua đàm phán, không phải tranh chấp, là điều mong muốn

Ngoài ra, các lý thuyết pháp lý liên tiếp như vậy không chỉ có ý nghĩa khi xảy ra tố tụng. Việc giải quyết tranh chấp thông qua tố tụng là một gánh nặng lớn đối với cả hai bên liên quan. Thay vào đó, những kiến thức này nên được tận dụng tối đa trong giai đoạn đàm phán trước khi dẫn đến tố tụng. Về ý nghĩa của các kiến thức pháp lý trong các cuộc đàm phán không liên quan đến tố tụng, chúng tôi đã giải thích trong bài viết dưới đây.

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

Nên phân biệt giữa lỗi và khuyết điểm, và thiếu tính năng

Trong trường hợp có lỗi hoặc khuyết điểm trong các tính năng hoặc thông số kỹ thuật đã triển khai, và trong trường hợp không có các tính năng cần thiết từ đầu, cuộc thảo luận sẽ khác nhau. Nếu các tính năng cần thiết không được đầy đủ, có thể không thể công nhận “hoàn thành công việc” trong hợp đồng nhận thầu, và có thể không thể công nhận việc thực hiện nghĩa vụ.

Ngoài ra, ngay cả khi không có các tính năng hoặc thông số kỹ thuật cần thiết, nếu kết quả là do người dùng không cung cấp thông tin phù hợp trong giai đoạn định rõ yêu cầu, có thể có trường hợp nên đánh giá là không phù hợp để xem đó là một phần của nội dung hợp đồng.

Tóm tắt

Vấn đề phát sinh trong quá trình thực hiện dự án có thể được phát hiện trong quá trình tiến hành dự án hoặc sau khi dự án đã hoàn thành và đang trong giai đoạn vận hành. Đặc điểm của dự án phát triển hệ thống, đó là không thể hoàn toàn yên tâm ngay cả khi tất cả các công đoạn đã hoàn thành, có thể được thể hiện rõ nét trong hệ thống “Trách nhiệm bảo đảm khuyết điểm”. Việc quản lý tài liệu một cách kỹ lưỡng, nhìn vào tương lai sau khi dự án phát triển hệ thống kết thúc, cùng với việc nắm bắt được toàn bộ quy trình này, được cho là rất quan trọng.