Quan điểm pháp lý về việc thực hiện quản lý thay đổi trong phát triển hệ thống

Trong các dự án phát triển hệ thống, thường xuyên xảy ra tình huống nội dung mà người dùng đã giải thích trước đó thay đổi trong quá trình tiến hành công việc. Do đó, ngay cả khi là nhà cung cấp nhận công việc, cũng có thể cần phải đáp ứng việc thay đổi nội dung hợp đồng sau khi đã ký kết hợp đồng một lần.

Bài viết này giải thích cách xử lý hiện tượng “thay đổi” được thực hiện sau này từ góc độ pháp lý đối với các dự án phát triển hệ thống mà khó có thể tiến triển theo như dự kiến.

Tại sao dự án phát triển hệ thống lại thường bị “thay đổi” sau khi hoàn thành?

Phát triển hệ thống là sự hợp tác giữa nhà cung cấp và người dùng

Phát triển hệ thống thường đi qua các giai đoạn như lập kế hoạch, đề xuất, định rõ yêu cầu phát triển và ký kết hợp đồng. Sau khi hợp đồng được ký kết, dự án sẽ tiếp tục với các giai đoạn thiết kế và triển khai theo thiết kế, cuối cùng là kiểm thử trước khi kết thúc. Trong toàn bộ quá trình này, nhà cung cấp nhận việc không chỉ có trách nhiệm rộng rãi như một chuyên gia phát triển hệ thống, mà người dùng cũng có nghĩa vụ hợp tác nhất định. Trong các giai đoạn như xác định yêu cầu (định rõ chức năng mà hệ thống cần có), thiết kế cơ bản (giao diện và trải nghiệm người dùng), và kiểm tra (hoặc chấp nhận) xem sản phẩm có đáp ứng yêu cầu hay không, sự hợp tác từ phía người dùng trở nên rất quan trọng. Đối với nghĩa vụ mà người dùng phải chịu trong phát triển hệ thống, chúng tôi đã giải thích chi tiết trong bài viết dưới đây.

Mặc dù có nghĩa vụ hợp tác, người dùng thường yêu cầu thay đổi

Tuy nhiên, không phải lúc nào người dùng, những người không phải là chuyên gia phát triển hệ thống, cũng có thể truyền đạt đầy đủ và toàn diện thông tin cần thiết cho nhà cung cấp. Trên thực tế, do công việc chi tiết và tỉ mỉ, người dùng thường không thể dự đoán được những sự thật nào sẽ có ý nghĩa quyết định trong các giai đoạn sau. Do đó, một cách trớ trêu, những sự thật quan trọng nhất thường chỉ được tiết lộ dần dần. Do những lý do này, trong các dự án thực tế, mặc dù lý tưởng là “thực hiện liên tục từ giai đoạn đầu đến cuối”, nhưng dựa trên giả định rằng có thể có nhiều thay đổi sau này, việc quản lý những thay đổi này trở nên quan trọng.

Giấy quản lý thay đổi là gì?

Tình huống sử dụng giấy quản lý thay đổi

Giấy quản lý thay đổi là tài liệu mà người dùng sử dụng để yêu cầu nhà cung cấp thay đổi thông số kỹ thuật hoặc thêm chức năng so với nội dung đã giải thích trước đó. Như đã nói ở trên, trong các giai đoạn như định nghĩa yêu cầu và thiết kế cơ bản, người dùng cũng có nghĩa vụ hợp tác với công việc của nhà cung cấp, nhưng việc đưa ra yêu cầu khác sau trong quá trình tiếp theo là điều có thể xảy ra thực tế.

Ví dụ về tình huống cần giấy quản lý thay đổi, chẳng hạn như:

• Trong giai đoạn định nghĩa yêu cầu và thiết kế cơ bản, nếu có sự bỏ sót trong việc xem xét và yêu cầu thêm chức năng sau đó
• Trong quá trình phát triển, nếu cần thay đổi thông số kỹ thuật do xem xét lại chính sách kinh doanh, v.v.

đều có thể được xem xét.

Ngoài ra, liên quan đến các chủ đề như thêm chức năng, thay đổi thông số kỹ thuật, điều mà bên nhận công việc quan tâm nhất là liệu việc thay đổi số tiền dự toán có được pháp luật công nhận hay không. Chúng tôi đã giải thích chi tiết về điểm này trong một bài viết khác.

Khi tăng số tiền dự toán sau này, giấy quản lý thay đổi sẽ là cơ sở để đánh giá tính hợp lý của nội dung dự toán. Để tránh gây ra tranh chấp với đối tác khi yêu cầu thanh toán dựa trên số tiền dự toán đã tăng sau này (và để làm cho lập trường của mình có sức thuyết phục khi có tranh chấp), việc tạo giấy quản lý thay đổi trở nên quan trọng.

Nội dung cần ghi trong giấy quản lý thay đổi

Vậy, theo pháp luật, những nội dung nào nên được ghi trong giấy quản lý thay đổi? Cơ chế hợp đồng sử dụng giấy quản lý thay đổi để đáp ứng việc thay đổi thông số kỹ thuật, thêm chức năng đã được công nhận rộng rãi. Do đó, bằng cách kiểm tra mẫu điều khoản hợp đồng mà cơ quan chính phủ như Bộ Kinh tế, Thương mại và Công nghiệp Nhật Bản (METI) đưa ra, bạn có thể hiểu rõ những nội dung nào nên được ghi lại.

(Quy trình quản lý thay đổi)
Điều 37 Khi A hoặc B nhận được đề xuất thay đổi dựa trên Điều 34 (Thay đổi thông số kỹ thuật hệ thống, v.v.), Điều 35 (Phê duyệt tài liệu trung gian bởi người dùng), Điều 36 (Xử lý vấn đề chưa xác định), họ phải, trong vòng ○ ngày kể từ ngày nhận, gửi cho đối tác một văn bản (dưới đây gọi là “giấy quản lý thay đổi”) ghi rõ các nội dung sau, và A và B sẽ thảo luận về việc chấp nhận hay từ chối sự thay đổi tại Hội đồng liên lạc quy định trong Điều 12.
① Tên của sự thay đổi
② Người chịu trách nhiệm đề xuất
③ Ngày tháng năm
④ Lý do thay đổi
⑤ Chi tiết về sự thay đổi bao gồm thông số kỹ thuật liên quan đến sự thay đổi
⑥ Nếu cần chi phí để thay đổi, số tiền đó
⑦ Lịch trình công việc thay đổi bao gồm thời gian xem xét
⑧ Ảnh hưởng khác của sự thay đổi đối với điều kiện hợp đồng và hợp đồng riêng (thời gian làm việc hoặc thời hạn giao hàng, phí ủy thác, điều khoản hợp đồng, v.v.)

Đọc trực tiếp từ văn bản và xác nhận các mục được khuyến nghị ghi chú, không cần thêm bất kỳ giải thích nào khác. Để không gây ra vấn đề “nói – không nói” sau này, bạn nên ghi lại chi tiết và cụ thể về quá trình thay đổi.

Khi ghi rõ những nội dung này, ký tên hoặc đóng dấu của người chịu trách nhiệm, người ra quyết định của cả nhà cung cấp và người dùng sẽ tạo thành một bộ, ngay cả khi có một cuộc tố tụng, nó sẽ có ý nghĩa tương đương với hợp đồng như một bằng chứng.

Những điều cần biết về quản lý thay đổi

Quản lý thay đổi thường được thực hiện cùng với quản lý vấn đề

Lý do để tạo tài liệu quản lý thay đổi là để quản lý lịch sử thay đổi, điều này giúp dẫn dắt dự án đến mục tiêu hoặc tránh bị truy cứu trách nhiệm không công bằng nếu không đạt được mục tiêu. Trong thực tế, việc tạo tài liệu quản lý thay đổi thường được thực hiện cùng với việc tạo và cập nhật bảng tổng quan vấn đề. Nghĩa là, sau khi quản lý lịch sử thay đổi bằng bảng quản lý thay đổi, các mục thay đổi đã được đồng ý sẽ được đưa vào bảng tổng quan vấn đề như những vấn đề cần giải quyết trong tương lai.

Điều chỉnh cách thảo luận về thay đổi cũng là một điều tốt

Không chỉ cách quản lý thay đổi, việc thiết lập quy định về cách thảo luận về thay đổi cũng có thể giúp việc xử lý thay đổi diễn ra một cách trơn tru. Điều này đặc biệt quan trọng khi áp dụng phương pháp phát triển như phát triển linh hoạt (Agile), nơi mà việc thay đổi sau cùng được coi là điều tất yếu. Trong thực tế, có nhiều ví dụ về việc thiết lập quy định về thời gian phản hồi cho cuộc thảo luận về quản lý thay đổi.

Thảo luận về thay đổi và nghĩa vụ trung thực

Khi hai bên thỏa thuận thay đổi hợp đồng mà họ đã đồng ý từ trước, đó cũng giống như việc ký kết một hợp đồng mới. Theo nguyên tắc, nhà cung cấp không có nghĩa vụ phải đồng ý với hợp đồng thay đổi vì hợp đồng dựa trên ý chí tự do của các bên. Tuy nhiên, nếu quá nhấn mạnh về quyền lợi, có thể sẽ gây ra lo ngại về việc dự án phát triển hệ thống không thể tiến triển một cách trơn tru.

Do đó, trong thực tế, thường có nhiều trường hợp trong đó “nghĩa vụ trung thực trong việc thảo luận về thay đổi” được ghi rõ trong hợp đồng, và nếu nhà cung cấp không trung thực trong việc đáp ứng thay đổi, có thể yêu cầu bồi thường thiệt hại.

Ví dụ về việc ghi chú, ví dụ như sau (Dưới đây là một ví dụ về việc ghi chú trong điều khoản. Trích dẫn từ “Mẫu hợp đồng cơ bản/riêng lẻ” do Tổ chức Xúc tiến Xử lý Thông tin Độc lập của Nhật Bản tạo ra).

Điều 4, khoản 3: Trong việc thảo luận về thay đổi, cả hai bên cần thảo luận một cách trung thực về đối tượng thay đổi, khả năng thay đổi, ảnh hưởng của việc thay đổi đối với giá cả và thời hạn giao hàng, v.v.

Quy định về phương pháp thay đổi

Như đã nói ở trên, khi thực hiện thay đổi, việc tổ chức cuộc thảo luận về thay đổi cho mỗi lần là “an toàn” về mặt pháp lý. Tuy nhiên, trong trường hợp dự án nhỏ, có thể không cần thiết phải quy định cách thảo luận về thay đổi. Trong trường hợp đó, thay vì đặt quy định về cuộc thảo luận, bạn có thể quy định rằng thay đổi chỉ được thực hiện sau khi người phụ trách của người dùng và nhà cung cấp ký tên và đóng dấu vào tài liệu quản lý thay đổi. Nếu cho phép thay đổi một cách dễ dàng chỉ bằng thỏa thuận bằng lời nói, việc xác định liệu có thay đổi hay không sẽ trở nên mơ hồ và có thể gây ra rắc rối lớn sau này. Vì vậy, việc quản lý tài liệu nên được thực hiện một cách nghiêm túc.

Tuy nhiên, việc chuẩn bị tài liệu riêng cho mỗi lần quản lý thay đổi có thể là một gánh nặng, và bạn có thể muốn ưu tiên việc phản ứng linh hoạt hơn. Trong trường hợp đó, một giải pháp có thể là việc ghi chú về các vấn đề liên quan đến thay đổi trong biên bản họp. Về cách lưu trữ biên bản họp trong phát triển hệ thống, chúng tôi đã giải thích chi tiết trong bài viết dưới đây.

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

Tóm tắt

Thật không thể phủ nhận rằng, tại những nơi thường xuyên thay đổi yêu cầu, rủi ro về sự cố và tranh chấp thường xảy ra. Tuy nhiên, tại những nơi đòi hỏi sự linh hoạt như vậy, việc chỉ nhấn mạnh về “tầm quan trọng của việc quản lý” một cách cứng nhắc có thể khiến việc thực hiện các biện pháp thực tế trở nên khó khăn.

Vấn đề về việc làm thế nào để cân nhắc giữa tốc độ yêu cầu trong kinh doanh và việc chuẩn bị cho những tình huống bất ngờ có thể thay đổi tùy thuộc vào tình hình của công ty và nội dung của dự án. Dựa trên nội dung của bài viết này, chúng tôi tin rằng việc mỗi công ty, mỗi dự án tìm kiếm phương pháp phù hợp cho riêng mình cũng rất quan trọng.