Pháp luật liên quan đến 'cháy' trong dự án phát triển hệ thống

Dự án phát triển hệ thống không phải là điều có thể hoàn thành trong một thời gian ngắn, mà đòi hỏi sự đầu tư của nhiều nguồn lực như một số lượng lớn người và tổ chức, một lượng lớn vốn và một thời gian phát triển kéo dài. Trong bài viết này, chúng tôi sẽ giải thích cách tổ chức hiện tượng “cháy” trong dự án phát triển hệ thống dưới khung pháp lý, cũng như tổng hợp các hướng dẫn giải quyết.

Tại sao dự án lại ‘bùng cháy’

Một hệ thống IT, dù không phải là một dự án quy mô lớn đặc biệt, chỉ có thể hoạt động đúng cách khi có sự xếp chồng lên nhau của hàng loạt các tệp chương trình và mã nguồn. Độ tinh vi và chi tiết của nó thường vượt xa khả năng tưởng tượng từ cảm giác hoạt động từ phía màn hình (hoặc ngược lại, càng đơn giản và gọn gàng cảm giác hoạt động từ phía màn hình của hệ thống IT, càng tinh vi và chi tiết).

• Chỉ có thời hạn giao hàng được xác định trước, trong khi các yêu cầu và đặc điểm vẫn mơ hồ và thời gian trôi qua
• Thành viên chỉ tập trung vào vấn đề chính trị nội bộ, và nhiều người rời bỏ giữa chừng do căng thẳng trong mối quan hệ giữa con người
• Thiếu khả năng đàm phán ở cấp quản lý, bao gồm PM, và không yêu cầu thành viên báo cáo, liên lạc, và thảo luận một cách phù hợp

Có thể có nhiều lý do cụ thể cho việc ‘bùng cháy’ của dự án. Tuy nhiên, từ góc độ pháp lý, các lý do ‘bùng cháy’ của dự án có thể được sắp xếp một cách tương đối đơn giản theo một số mô hình phổ biến.

Loại cháy lớn 1: Dự án bị đình trệ giữa chừng

Trong quá trình phát triển hệ thống, một lý do tiêu biểu khiến dự án bị đình trệ giữa chừng là sự thiếu giao tiếp giữa người dùng và nhà cung cấp. Đầu tiên, dự án phát triển hệ thống không chỉ cần sự hỗ trợ từ kỹ năng chuyên môn và sức mạnh tổ chức của nhà cung cấp, mà còn cần sự hợp tác từ người dùng cuối cùng sử dụng hệ thống.

Do đó, nếu một dự án tiếp tục mà không rõ ràng về vai trò mà mỗi bên phải đảm nhận, có thể sinh ra một loại “đẩy nhiệm vụ cho nhau” và làm cản trở sự tiến triển suôn sẻ của dự án. Đối với nghĩa vụ của người dùng và nghĩa vụ của nhà cung cấp, vui lòng tham khảo các bài viết dưới đây.

Để biết chi tiết về trách nhiệm mà mỗi bên phải đảm nhận, vui lòng xem các bài viết trên. Điểm quan trọng trong cuộc thảo luận ở đây là trong một dự án phát triển hệ thống, cả người dùng và nhà cung cấp đều có trách nhiệm nhất định. Một sự phân biệt cơ bản là, việc định rõ yêu cầu, thiết kế giao diện và kiểm tra, những phần không thể hoàn thành mà không có sự hợp tác của người dùng, đã được các phán quyết và tiền lệ trước đây công nhận là nghĩa vụ hợp tác của người dùng.

Ngược lại, nhà cung cấp cũng có nghĩa vụ toàn diện trong việc tiến triển suôn sẻ dự án và phát hiện cũng như loại bỏ các yếu tố cản trở, sau khi nhận được sự hợp tác từ người dùng (và cùng lúc đó, nỗ lực giao tiếp để yêu cầu sự hợp tác như trên).

Dựa trên quan điểm này, tòa án đã chỉ ra rằng người dùng có nghĩa vụ thực hiện quản trị từ bên trong như một hệ thống nội bộ, và nhà cung cấp có nghĩa vụ thực hiện công việc với sự chuyên môn và kỹ năng kỹ thuật của mình như một chuyên gia bên ngoài, và đều phải đối xử công bằng với mọi tranh chấp.

Ngoài ra, “đình trệ” thường xảy ra trong quá trình kiểm tra. Chi tiết về kiểm tra được giải thích chi tiết trong bài viết dưới đây.

Trong trường hợp như vậy, một khi tranh chấp xảy ra, các bằng chứng có thể xác nhận được một cách khách quan như sự tiến triển của dự án trong quá khứ, nội dung của cuộc họp, v.v., thường được coi trọng. Do đó, tài liệu đã được ghi lại trước đó thường có ý nghĩa lớn. Để không làm tổn hại đến vị trí của mình, việc quản lý tài liệu cần được thực hiện một cách nghiêm túc. Đối với quan điểm về tầm quan trọng của quản lý tài liệu trong phát triển hệ thống, vui lòng tham khảo bài viết dưới đây.

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

Loại hỏa hoạn 2: Trường hợp hủy bỏ do lý do cá nhân từ phía người dùng

Cũng có thể xảy ra trường hợp dự án bị hủy bỏ giữa chừng do nguyện vọng từ phía người dùng. Ví dụ, công ty đã bắt đầu xây dựng hệ thống IT để quản lý nhân sự toàn diện, bao gồm cả các cơ sở ở nước ngoài, nhưng sau đó, chiến lược mở rộng thị trường thông qua việc mở rộng ra nước ngoài của công ty đã bị rút lại. Trong trường hợp như vậy, việc phát triển hệ thống mà công ty đã bắt đầu có thể không còn cần thiết đối với người dùng.

Trước hết, vấn đề về cách xây dựng hệ thống IT sử dụng trong công ty không thể tách rời khỏi vấn đề về “những công việc gì đang tồn tại trong công ty đó” như một tiền đề. Do đó, yêu cầu về hệ thống cần thiết (hoặc không cần thiết) có thể thay đổi sau khi công ty nhận được ảnh hưởng từ việc thay đổi lớn về cơ cấu tổ chức, tái tổ chức các bộ phận kinh doanh, hoặc xem xét lại chiến lược từ gốc rễ.

Do những lý do như vậy, việc dự án bị gián đoạn giữa chừng cũng có thể dẫn đến nhiều vấn đề pháp lý. Trong trường hợp đó, thường thì do lý do cá nhân của người dùng, nhà cung cấp cũng được công nhận một số quyền pháp lý nhất định, chẳng hạn như yêu cầu thanh toán dựa trên tỷ lệ hoàn thành. Tùy thuộc vào loại hợp đồng nào đã được áp dụng, có sự khác biệt về điều khoản cơ sở, nhưng nội dung có thể được tổ chức như sau:

・Trường hợp hợp đồng thầu: Điều 641 của Bộ luật dân sự Nhật Bản
Điều 641 của Bộ luật dân sự Nhật Bản
→ Trong khi người thầu chưa hoàn thành công việc, người đặt hàng có thể hủy bỏ hợp đồng bất cứ lúc nào bằng cách bồi thường thiệt hại.
・Trường hợp hợp đồng ủy quyền: Điều 648 khoản 3 của Bộ luật dân sự Nhật Bản (tùy thuộc vào tình hình, có thể yêu cầu bồi thường thiệt hại dựa trên Điều 651)
Điều 648 của Bộ luật dân sự Nhật Bản
→ Khi việc thực hiện bị kết thúc giữa chừng do lý do không thể quay trở lại người nhận ủy quyền, người nhận ủy quyền có thể yêu cầu thanh toán dựa trên tỷ lệ hoàn thành công việc đã thực hiện.
Điều 651 của Bộ luật dân sự Nhật Bản
→1. Ủy quyền có thể được hủy bỏ bất cứ lúc nào bởi mỗi bên liên quan.
→2. Khi một trong các bên liên quan hủy bỏ ủy quyền vào thời điểm không lợi cho bên kia, bên đó phải bồi thường thiệt hại cho bên kia. Tuy nhiên, điều này không áp dụng khi có lý do không thể tránh khỏi.

Loại hình cháy lớn 3: Khi phát hiện ra lỗi trong hệ thống đã được giao sau một thời gian

Người dùng thường đánh giá chất lượng hệ thống qua cảm giác khi thao tác trên màn hình, nhưng từ góc độ của người nhận việc, những điều khó khăn hơn có thể là thiết kế cơ sở dữ liệu, hoặc việc xác định các mục kiểm tra dựa trên việc dự đoán tất cả các phương pháp thao tác.

Nói cách khác, ngay cả với hệ thống mà ban đầu có vẻ hoạt động không có vấn đề gì, thì cũng có thể xảy ra các vấn đề như:

• Khi lượng dữ liệu được đăng ký tăng lên, tốc độ xử lý trở nên chậm hơn
• Hệ thống có vẻ hoạt động không có vấn đề trong công việc hàng ngày, nhưng đã phát hiện ra lỗi trong các hoạt động đặc biệt xảy ra một vài tháng hoặc một vài năm một lần
• Dù trên bề mặt, kết quả được xuất ra đúng, nhưng thực tế logic không đúng (ví dụ gần gũi, đối với đầu vào từ người dùng là 1+1, ngay cả khi “2” được xuất ra đúng, không nhất thiết là đã thực hiện đúng quá trình tính toán. Có nhiều trường hợp không thể phát hiện ra lỗi logic chỉ bằng cách thao tác màn hình một cách vô tư. Trong quá trình kiểm tra, có thể nói rằng một loại “kỹ năng kỹ thuật” cần thiết.)

Các vấn đề như vậy có thể xảy ra thực tế. Nếu phân tích các vụ việc như vậy từ góc độ pháp lý, có thể xem xét khả năng vi phạm nghĩa vụ quản lý dự án của bên cung cấp, tức là vấn đề thi hành không hoàn chỉnh theo luật dân sự.

Trong trường hợp này, nếu không có bất kỳ quy định đặc biệt nào trong hợp đồng, thì quy định về hợp đồng chuyển nhượng thông thường sẽ được áp dụng.

Các điểm cần xem xét trong trường hợp này được tổ chức như sau:

Được tổ chức như vậy.

Tổng kết

Mỗi dự án phát triển hệ thống sẽ trải qua nhiều biến cố và thay đổi khác nhau. Tuy nhiên, khi nói đến vấn đề “cháy” của dự án từ góc độ pháp lý, khung cấu trúc mà chúng tôi đã đề xuất trong bài viết này sẽ trở thành một sơ đồ tổng quan. Các vấn đề pháp lý liên quan đến phát triển hệ thống chắc chắn bao gồm nhiều chủ đề đa dạng.

Tuy nhiên, giống như công việc phát triển hệ thống đòi hỏi khả năng tư duy xây dựng, việc quản lý rủi ro liên quan đến nó cũng có thể được thực hiện một cách xây dựng hơn nếu chúng ta không mất đi cái nhìn tổng quan về lĩnh vực này.