Là gì vấn đề pháp lý và hợp đồng liên quan đến phát triển Agile?
Có nhiều phương pháp để tiến hành phát triển hệ thống. Mô hình thác nước (Waterfall Model) là một trong những mô hình cổ điển và phổ biến nhất, và nhiều sách về luật liên quan đến phát triển hệ thống cũng thảo luận dựa trên mô hình này. Trong bài viết này, chúng tôi sẽ giải thích về các vấn đề pháp lý có thể xảy ra trong quá trình phát triển hệ thống dựa trên mô hình phát triển linh hoạt (Agile Development Model), một mô hình khó có thể tìm hiểu thông qua sách vở.
Mô hình phát triển Agile và Pháp lý
Mô hình trong phát triển hệ thống
Trong dự án phát triển hệ thống, có một khung để nắm bắt toàn bộ tiến trình, đó là mô hình phát triển. Đại diện cho điều này là mô hình “Waterfall”. Nói cách khác, giống như nước từ “nguồn” đến “cửa sông” rơi xuống một cách liên tục, các giai đoạn như định nghĩa yêu cầu, thiết kế, triển khai, kiểm tra, v.v. được thực hiện một cách liên tục. Mục tiêu là giảm thiểu việc quay lại các bước và lặp lại công việc, phù hợp với việc tiến hành công việc một cách kế hoạch.
Trong mô hình phát triển Agile, bạn sẽ lặp lại việc triển khai và kiểm tra các chương trình nhỏ. Trong quá trình lặp lại công việc này, bạn sẽ dần dần xây dựng một hệ thống lớn hơn. Đối với mô tả chi tiết hơn về mô hình phát triển hệ thống này và so sánh ưu nhược điểm của cả hai mô hình phát triển, xem bài viết dưới đây.
https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]
Đặc điểm của mô hình phát triển Agile
Một lợi ích lớn của việc phát triển bằng mô hình phát triển Agile là khả năng tiếp cận công việc thực tế một cách nhanh chóng. Do công việc “upstream” như định nghĩa yêu cầu và tạo tài liệu thiết kế không được tách biệt với công việc triển khai chương trình, nó phù hợp với việc điều chỉnh linh hoạt, bao gồm việc thêm và sửa đổi chức năng, thay đổi thông số kỹ thuật, v.v. Từ góc độ pháp lý, điểm quan trọng để thành công với mô hình phát triển Agile là làm thế nào để quản lý tài liệu và quản lý thay đổi. Trong mô hình phát triển Agile, vai trò và trách nhiệm không được phân chia rõ ràng như mô hình Waterfall. Ngoài ra, do phương pháp này nhấn mạnh “tốc độ” để thực hiện, thay vì “quản lý”, nó dễ dẫn đến việc không hoàn thiện các tài liệu thiết kế, tài liệu thông số kỹ thuật, biên bản họp, v.v.
Thêm vào đó, liên quan đến việc quản lý thay đổi, mô hình phát triển Agile dễ dàng đối phó với thay đổi, do đó, có nguy cơ dự án bị cháy khi quá trình phê duyệt với người ra quyết định bị bỏ qua và yêu cầu thay đổi thông số kỹ thuật được đáp ứng tại cấp độ hiện trường. Nếu điều này xảy ra, “việc đối phó với thay đổi sau này dễ dàng” – một lợi ích của mô hình phát triển, có thể trở thành rủi ro cháy dự án.
Cách quản lý tài liệu và quản lý thay đổi trong phát triển Agile
Tầm quan trọng của việc quản lý tài liệu
Trong các dự án phát triển dựa trên mô hình Agile, một điểm lo ngại từ phía pháp lý là việc giao tiếp dựa trên lời nói có thể tích lũy và dẫn đến thiếu tài liệu. Chúng tôi đã giải thích chi tiết về vấn đề này trong bài viết dưới đây, nói về tại sao việc quản lý tài liệu lại quan trọng trong các dự án phát triển hệ thống.
https://monolith.law/corporate/the-minutes-in-system-development[ja]
Bài viết này giải thích tầm quan trọng của việc quản lý tài liệu trong các dự án phát triển hệ thống từ hai góc độ: phòng ngừa tranh chấp (tức là “pháp lý dự phòng”) và bảo tồn chứng cứ khi có tranh chấp (tức là “quản lý khủng hoảng”).
Thiết lập Hội đồng Liên lạc có hiệu quả trong việc quản lý tài liệu
Khi áp dụng mô hình phát triển Agile, khác với mô hình Waterfall, không có kế hoạch rõ ràng được chuẩn bị trước. Do đó, không chỉ cần quản lý sự khác biệt giữa kế hoạch và thực tế, mà còn có nguy cơ tăng chi phí về thời gian và tiền bạc nếu để mọi thứ phụ thuộc vào công trường.
Vì vậy, một biện pháp hiệu quả là người chịu trách nhiệm tổ chức Hội đồng Liên lạc định kỳ để đảm bảo tiến trình suôn sẻ của dự án. Trong trường hợp quy mô phát triển nhỏ, thực sự, việc tổ chức Hội đồng Liên lạc định kỳ có thể không được ưa chuộng so với việc tụ tập cùng nhau mỗi khi các người chịu trách nhiệm có thể gặp nhau. Tuy nhiên, trong trường hợp của mô hình phát triển Agile, nguy cơ bỏ sót các vấn đề cần giải quyết ngay lập tức tại cuộc họp cũng tăng lên. Do đó, việc tổ chức Hội đồng Liên lạc định kỳ nên được đưa vào hợp đồng và coi là an toàn. Cách quy định này được mô tả như sau trong Hợp đồng mẫu của Bộ Kinh tế, Thương mại và Công nghiệp Nhật Bản (Japanese METI Model Contract).
(Thiết lập Hội đồng Liên lạc)
Điều 12: Bên A và Bên B sẽ tổ chức Hội đồng Liên lạc để thảo luận về các vấn đề cần thiết để hoàn thành công việc này một cách trôi chảy, bao gồm tình hình tiến độ, quản lý và báo cáo rủi ro, công việc chung giữa hai bên và tình hình thực hiện công việc phân chia, xác nhận nội dung cần đưa vào Tài liệu đặc tả hệ thống, thảo luận và giải quyết vấn đề. Tuy nhiên, (đang bỏ qua)…
2. Hội đồng Liên lạc sẽ được tổ chức định kỳ với tần suất được quy định trong Hợp đồng riêng, và ngoài ra, sẽ được tổ chức bất cứ khi nào Bên A hoặc Bên B cho rằng cần thiết.
3. Người chịu trách nhiệm và người phụ trách chính của cả hai bên, cũng như những người mà người chịu trách nhiệm cho rằng thích hợp sẽ tham dự Hội đồng Liên lạc. Ngoài ra, Bên A và Bên B có thể yêu cầu người khác tham dự Hội đồng Liên lạc nếu cần thiết cho cuộc thảo luận, và bên kia phải đáp ứng yêu cầu này trừ khi có lý do hợp lý.
4. Bên B sẽ tạo và nộp Báo cáo quản lý tiến độ theo định dạng đã thỏa thuận riêng giữa Bên A và Bên B tại Hội đồng Liên lạc, xác nhận tình hình tiến độ dựa trên Báo cáo quản lý tiến độ đó, cùng với việc thảo luận và quyết định về các vấn đề như sự có mặt của các mục bị trễ, lý do và biện pháp đối phó nếu có mục bị trễ, việc thay đổi cơ cấu thúc đẩy được quy định trong Chương này (như thay đổi nhân sự, tăng giảm, thay đổi nhà thầu phụ…), tình hình thực hiện các biện pháp bảo mật, sự có mặt của các lý do cần thay đổi Hợp đồng riêng, nếu có lý do cần thay đổi Hợp đồng riêng thì nội dung đó là gì, và xác nhận các mục đã được quyết định, các mục cần xem xét tiếp, và nếu có mục cần xem xét tiếp thì lịch trình xem xét và người tham gia xem xét.
(Đang bỏ qua các mục 5, 6, 7…)
Điểm quan trọng nhất là việc gán ý nghĩa cho sự tồn tại của Hội đồng Liên lạc, khác biệt so với các cuộc họp tổ chức một cách tình cờ, thông qua các điều khoản hợp đồng.
Định hướng sử dụng Hội đồng Liên lạc để tận dụng quản lý thay đổi
Ngoài ra, trong phát triển Agile, việc các bên thay đổi những điều đã thống nhất ban đầu sau này là điều được giả định. Do đó, việc quản lý tình hình thay đổi sau này cũng rất quan trọng.
Trong trường hợp này, nếu Hội đồng Liên lạc được tổ chức định kỳ, việc quản lý thay đổi cũng trở nên mượt mà hơn. Ví dụ, bạn có thể quy định trong hợp đồng rằng cuộc thảo luận về thay đổi sẽ được tiến hành tại Hội đồng Liên lạc, và khi một bên yêu cầu thảo luận về thay đổi, bên kia có nghĩa vụ tham gia cuộc thảo luận đó. (Dưới đây là một đoạn trích từ Hợp đồng mẫu của Bộ Kinh tế, Thương mại và Công nghiệp Nhật Bản.)
(Quy trình quản lý thay đổi)
Điều 37: Khi Bên A hoặc Bên B nhận được đề xuất thay đổi từ bên kia, họ sẽ gửi cho bên kia một văn bản (gọi là “Tài liệu quản lý thay đổi”) ghi rõ các điều sau đây trong vòng ○ ngày kể từ ngày nhận, và Bên A và Bên B sẽ thảo luận về việc có nên thay đổi hay không tại Hội đồng Liên lạc quy định trong Điều 12. (Đang bỏ qua các điều ghi sau đây)
Các điểm quan trọng của quy định trên có thể được tổng hợp như sau:
- Đơn giản hóa phương pháp tiếp nhận yêu cầu thay đổi bằng cách sử dụng một định dạng “Đề xuất thay đổi”
- Đặt thời hạn cho ngày từ khi nhận được đề xuất cho đến khi thảo luận về nó → Thay vì ghi “trong vòng ◯ ngày”, bạn cũng có thể xem xét việc thay thế bằng từ ngữ như “ngay lập tức”.
- Đơn giản hóa nơi thảo luận về việc có nên thay đổi hay không bằng cách tổ chức tại “Hội đồng Liên lạc”
Nói cách khác, để tránh sự hiểu lầm về việc “đã đưa ra yêu cầu thay đổi hay chưa”, “đã trả lời về việc có nên thay đổi hay không hay chưa”, họ đã làm rõ phương pháp thủ tục.
Hiểu biết về nghĩa vụ trung thực và nguyên tắc tín nhiệm được đặt ra
Đến nay, chúng tôi đã giới thiệu về các mô hình điều khoản hợp đồng liên quan đến “Hội đồng liên lạc”, “Thảo luận về thay đổi”. Tuy nhiên, điều quan trọng để hiểu rõ bản chất của những điều này là các vấn đề như “nghĩa vụ trung thực”, “nguyên tắc tín nhiệm”. Ban đầu, mô hình phát triển linh hoạt (Agile) thường khó tiến triển nếu không có mối quan hệ tin tưởng giữa bên đặt hàng và bên nhận hàng. Điều này là do việc tập trung vào tốc độ bắt đầu công việc thực tế, và các thủ tục dẫn đến việc bắt đầu thường được giảm thiểu. Do đó, việc bao gồm các điều khoản yêu cầu đối tác “nghĩa vụ trung thực” cũng trở nên phổ biến trong thực tế.
Điều 4, khoản 3: Trong cuộc thảo luận về việc thay đổi, cả hai bên phải thảo luận một cách trung thực về đối tượng của sự thay đổi, khả năng thay đổi, ảnh hưởng của sự thay đổi đối với giá cả và thời hạn giao hàng, v.v.
Điều này nhằm ngăn chặn việc đột ngột “việc có đồng ý với việc thay đổi hợp đồng hay không hoàn toàn tùy thuộc vào tự do của bên nhận yêu cầu, không có nghĩa vụ phải tuân theo yêu cầu bắt buộc” và những cách làm khác như vi phạm lý thuyết pháp lý hình thức đã được thỏa thuận từ ban đầu dựa trên mối quan hệ tin tưởng. Điều này cũng phản ánh nguyên tắc pháp lý liên quan đến giao dịch giữa các cá nhân, không chỉ trong phát triển hệ thống.
Điều 1, khoản 2 của Luật Dân sự Nhật Bản (Bộ luật Dân sự): Việc thực hiện quyền và nghĩa vụ phải tuân theo nguyên tắc tín nhiệm và được thực hiện một cách trung thực.
Pháp luật không nhất thiết luôn tôn trọng “nội dung ghi trong hợp đồng” hoặc “ngôn từ của điều khoản”. Đặc biệt trong giao dịch với đối tác, bạn nên sử dụng linh hoạt trong khi tích hợp “tín nhiệm” và “sự trung thực” thực tế. Ngoài ra, chúng tôi đã giải thích chi tiết về việc “nghĩa vụ” theo pháp luật không nhất thiết phải dựa trên quy trình “hợp đồng” trong bài viết dưới đây.
Tóm tắt
Trong các dự án phát triển hệ thống dựa trên mô hình phát triển Agile, việc hiểu rõ rủi ro khi các thủ tục hành chính và hệ thống quản lý trở nên lỏng lẻo là vô cùng quan trọng. Tuy nhiên, không chỉ vậy, việc hiểu rõ các đặc tính linh hoạt của luật pháp gốc, dựa trên các nguyên tắc như “nguyên tắc tín nhiệm”, và thái độ áp dụng chúng vào thực tế cũng được coi là rất quan trọng.
Category: IT
Tag: ITSystem Development