Phạm vi nào của chức năng không có trong tài liệu đặc tả phát triển hệ thống nên được triển khai theo pháp luật?

Dự án phát triển hệ thống IT được sử dụng trong doanh nghiệp theo nguyên tắc là được tạo ra theo các thông số đã được định rõ trước. Tuy nhiên, mặt khác, nếu xem xét ý nghĩa của việc nhà cung cấp được giao toàn bộ công việc phát triển hệ thống như một chuyên gia phát triển hệ thống, mức độ kỳ vọng của người dùng có thể không thấp chỉ vì việc cài đặt một cách cơ học những gì đã được ghi trong thông số. Trong bài viết này, chúng tôi sẽ giải thích về mức độ nào mà bạn nên chịu trách nhiệm cài đặt cho “chương trình cần thiết để cài đặt, mặc dù không được ghi trong thông số, nhưng theo mục đích phát triển”.

Vấn đề pháp lý liên quan đến việc triển khai những yếu tố không nằm trong thông số kỹ thuật

Quyền tự quyết được yêu cầu trong công việc của nhà cung cấp

Một trong những đặc điểm lớn của các vấn đề pháp lý liên quan đến hợp đồng liên quan đến dự án phát triển hệ thống và các vấn đề pháp lý đi kèm là nhà cung cấp nhận công việc có quyền tự quyết lớn.

Bài viết liên quan: Nghĩa vụ quản lý dự án trong phát triển hệ thống là gì[ja]

Tuy nhiên, “quyền tự quyết” mà chúng tôi nói ở đây không nhất thiết phải áp dụng cho tất cả các quy trình phát triển hệ thống. Sau khi xác định các quy trình và tiến hành phân loại công việc chi tiết, có thể có nhiều công việc gần như đơn giản. Tuy nhiên, nói chung, càng tiến vào quy trình đầu, càng khó thực hiện công việc mà không có quyền tự quyết lớn. Đây cũng là lý do tại sao các loại hợp đồng thường phù hợp với việc ủy quyền.

Bài viết liên quan: Sự khác biệt và phân biệt giữa hợp đồng thầu và hợp đồng ủy quyền trong phát triển hệ thống[ja]

Quyền tự quyết cũng nên được thể hiện trong quy trình phát triển nghiêm ngặt

Tuy nhiên, ngay cả khi nhà cung cấp phát triển hệ thống có quyền tự quyết lớn, việc chấp nhận yêu cầu của khách hàng một cách “lỏng lẻo” sẽ gây ra thiệt hại lớn cho các quy trình sau. Một hệ thống IT được tạo thành từ nhiều bộ phận nhỏ, do đó, ngay cả khi chỉ là một thay đổi nhỏ về hình thức, có thể yêu cầu thay đổi lớn về thời gian làm việc từ phía nhà phát triển. Ngoài ra, có các bài viết giải thích về cách quản lý tình hình thay đổi thông số kỹ thuật trong phát triển hệ thống từ góc độ pháp lý. Các bài viết dưới đây giải thích về cách quản lý thay đổi, nhưng cũng thảo luận về việc thay đổi thông số kỹ thuật có ảnh hưởng lớn đến công việc như thế nào từ góc độ của kỹ sư.

Bài viết liên quan: Cách quản lý thay đổi trong phát triển hệ thống từ góc độ pháp lý là gì[ja]

Không bị ràng buộc bởi thông số kỹ thuật, điều gì nên làm như một chuyên gia?

Để thúc đẩy dự án phát triển hệ thống một cách trôi chảy, việc xác định yêu cầu phát triển trước và tiến hành theo kế hoạch dựa trên đó là điều quan trọng. Mặt khác, chỉ làm những gì được nói và tuân theo yêu cầu đã xác định trước đó, có những tình huống mà bạn không thể đóng vai trò đầy đủ như một chuyên gia phát triển hệ thống. Trong những mâu thuẫn như vậy, vấn đề “Những gì không được chỉ ra trong thông số kỹ thuật nhưng nên được triển khai là gì” trở nên rõ ràng.

Nghĩa vụ pháp lý được quyết định dựa trên ‘mục đích’ của các tài liệu đặc tả và hợp đồng

Nội dung cần triển khai, ngay cả khi không được ghi trong hợp đồng hoặc tài liệu đặc tả, vẫn sẽ được quyết định dựa trên ‘mục đích’ của các mục đã ghi trong hợp đồng hoặc tài liệu đặc tả, tức là, ‘với ý nghĩa và mục đích gì, quyết định đó đã được thực hiện như vậy’. Hãy cùng xem qua một số ví dụ về các vụ án dưới đây.

Thực tế phán quyết phủ nhận nghĩa vụ triển khai do không có ghi chú

Trong ví dụ phán quyết được trích dẫn dưới đây, hệ thống mà nhà cung cấp phát triển đã tiến triển đến giai đoạn hoạt động thử nghiệm, nhưng đã phát triển thành tranh chấp khi yêu cầu hủy bỏ hợp đồng vì thiếu các chức năng cần thiết. Chức năng mà người dùng cho là thiếu là “chức năng cập nhật tự động dữ liệu”, và đã được cho rằng đây là điểm bán hàng chính của hệ thống này, nhưng tòa án đã không công nhận nghĩa vụ triển khai này.

Như đã xác nhận ở trên, trong hợp đồng và tài liệu thiết kế cơ bản cũng như tài liệu thiết kế chi tiết, không có ghi chú nào cho thấy chức năng ③ là mục tiêu phát triển của hệ thống này.

Nguyên đơn đã cho rằng chức năng ③ là điểm bán hàng chính của hệ thống này đối với nguyên đơn từ phía bị đơn, và nhấn mạnh sự cần thiết của chức năng này, nhưng nếu lập luận của họ là đúng, thì điều đó nên được ghi rõ trong hợp đồng và các tài liệu khác, và khó có thể cho rằng việc phát triển chức năng này đã được thỏa thuận mà không có điều đó.

Phán quyết của Tòa án Tokyo ngày 18 tháng 2 năm 2009 (Heisei 21)

Quả thật, nếu chỉ lấy ra kết luận một cách đơn giản, phán quyết này có thể được hiểu là “nếu không có ghi chú trong tài liệu thiết kế, thì không cần phải tạo ra những thứ không có”. Tuy nhiên, nếu nói một cách chính xác hơn, thì không phải là sự thật hình thức như việc có ghi chú trong tài liệu thiết kế hay không, mà là một quyết định dựa trên “mục đích” của ghi chú trong tài liệu thiết kế và hợp đồng. Nói cách khác, “nếu xem xét lý do vì sao không có ghi chú trong tài liệu thiết kế và hợp đồng, thì hợp lý khi cho rằng cũng không có thỏa thuận tương ứng với ghi chú đó”.

Thực tế pháp lý khẳng định nghĩa vụ triển khai ngay cả khi không được ghi trong hợp đồng

Mặt khác, có những thực tế pháp lý khẳng định rằng, ngay cả khi không có ghi chú trong hợp đồng hay tài liệu đặc tả, vẫn cần phải thừa nhận nghĩa vụ triển khai. Thực tế pháp lý được trích dẫn dưới đây liên quan đến việc phát triển hệ thống để quản lý lịch sử sử dụng thuốc, trong đó không thể chuyển dữ liệu từ hệ thống hiện tại sang hệ thống mới, do đó không thể sử dụng hệ thống mới và phía người dùng đã hủy bỏ hợp đồng. Tuy nhiên, phía nhà cung cấp đã tranh chấp rằng việc chuyển dữ liệu không nằm trong phạm vi công việc của họ.

Việc phát triển hệ thống mới thường đi kèm với việc loại bỏ hệ thống hiện tại và chuyển dữ liệu. Về tầm quan trọng của những công việc này và các vấn đề pháp lý liên quan, chúng tôi đã giải thích chi tiết trong bài viết dưới đây.

Bài viết liên quan: Vấn đề pháp lý liên quan đến việc chuyển đổi từ hệ thống cũ trong phát triển hệ thống[ja]

Hệ thống hiện tại đã lưu trữ dữ liệu của hơn 50.000 bệnh nhân, và nguyên đơn đã sử dụng dữ liệu này để cải thiện hiệu quả công việc. Nếu không thể chuyển dữ liệu bệnh nhân từ hệ thống hiện tại sang hệ thống mới, điều này rõ ràng sẽ gây rối loạn cho công việc tại hiệu thuốc, và người đại diện của nguyên đơn cũng được cho là đã nhận thức được điều này. Trước khi ký kết hợp đồng này, người đại diện của nguyên đơn đã hỏi người đại diện của bị đơn về khả năng chuyển dữ liệu, điều mà người đại diện của bị đơn cũng thừa nhận (trích dẫn), người đại diện của nguyên đơn, phải nhập thủ công dữ liệu của hơn 50.000 bệnh nhân, khó có thể nghĩ rằng họ đã quyết định triển khai hệ thống mới này. Ngoài ra, như đã nêu ở trên (1) I, bị đơn không thể chuyển dữ liệu lịch sử thuốc từ hệ thống hiện tại sang hệ thống mới, do đó, họ đã in dữ liệu này ra giấy và sau đó nhập nó vào tệp PDF, mặc dù việc chuyển dữ liệu không được giả định trong hợp đồng này, khó có thể nghĩ rằng bị đơn đã thực hiện công việc tốn kém này như một dịch vụ.

Phán quyết của Tòa án Tokyo ngày 18 tháng 11 năm 2010 (Heisei 22)

Điều quan trọng ở đây là mục đích của hợp đồng và “ý định” của các điều khoản được ghi trong hợp đồng. Nếu cả hai bên đều hiểu rằng việc chuyển dữ liệu không nằm trong phạm vi công việc và vẫn ký kết hợp đồng, thì Tòa án đã chỉ ra rằng cả người dùng và nhà cung cấp đều có ý định không tự nhiên khi ký kết hợp đồng. Nói cách khác, người dùng đã chấp nhận một lượng công việc thủ công lớn, và nhà cung cấp đã tiếp cận dự án biết rằng họ sẽ gây rối loạn cho công việc của người dùng sau này, điều này là rất phi lý.

Điều gì có thể hiểu từ hai phán quyết này?

Về việc chuyển dữ liệu, ngay cả khi không có ghi chú trong hợp đồng hoặc tài liệu đặc tả, nghĩa vụ thực hiện vẫn được khẳng định. Một trong những lý do cho điều này có thể là vì chúng ta đang nói về “dữ liệu”, một vấn đề không hiển thị trên màn hình. “Thiếu chức năng cần thiết” mà tôi đã nói ở phần trước, là một vấn đề hiển thị trực tiếp trên màn hình hoặc giao diện của hệ thống. Do đó, ngay cả đối với người không chuyên về phát triển hệ thống, việc phát hiện ra sự thiếu sót trong việc ghi chú trong tài liệu đặc tả không phải là khó khăn. Ngược lại, vấn đề chuyển dữ liệu có đặc điểm là khó nhận biết đối với người không chuyên về phát triển hệ thống về tầm quan trọng của quy trình, độ khó của công việc và thời gian cần thiết. Do đó, có thể coi là có một tình huống mà nhà cung cấp, với chuyên môn của mình, nên điều hành một cách trôi chảy.

Nếu xem xét như vậy, việc thiếu sót trong việc ghi chú trong tài liệu đặc tả hoặc hợp đồng có thể được coi là một vấn đề liên quan chặt chẽ đến “nghĩa vụ hợp tác” của người dùng. Nói cách khác, đây là vấn đề liệu người dùng đã thực sự “thực hiện nghĩa vụ hợp tác” trong việc ký kết hợp đồng và soạn thảo tài liệu đặc tả hay không. Bài viết dưới đây giải thích chi tiết về nghĩa vụ pháp lý mà người dùng phải thực hiện trong dự án phát triển hệ thống.

Bài viết liên quan: Nghĩa vụ hợp tác mà người dùng, người đặt hàng phát triển hệ thống, phải chịu[ja]

Nếu bạn xem xét cả bài viết trên, bạn có thể hiểu rằng trong lĩnh vực yêu cầu sự hợp tác từ phía người dùng, như việc xác định màn hình và chức năng cần thiết, và trong trường hợp thiếu sót trong việc xem xét việc chuyển dữ liệu, câu chuyện hoàn toàn khác nhau.

Làm thế nào để xem xét việc thanh toán cho việc phát triển không nằm trong tài liệu yêu cầu kỹ thuật?

Một điểm khác liên quan đến chủ đề của bài viết này mà bạn có thể quan tâm là, liệu có thể yêu cầu thanh toán thêm phí pháp lý nếu bạn tạo ra một thứ không nằm trong tài liệu yêu cầu kỹ thuật hay không. Về việc có thể yêu cầu thanh toán thêm phí hay không và cách tính số tiền dự toán trong trường hợp có thể, chúng tôi đã giải thích chi tiết trong bài viết dưới đây.

Bài viết liên quan: Có thể tăng số tiền dự toán cho việc phát triển hệ thống sau khi đã dự toán hay không[ja]

Trong bài viết trên, chúng tôi đã giải thích rằng điều quan trọng là liệu có công việc vượt quá phạm vi công việc có liên quan đến việc thanh toán hay không. Nói cách khác, nếu nhà cung cấp đồng ý với việc phát triển không nằm trong yêu cầu ban đầu (trong trường hợp của bài viết này, đó là ví dụ phủ định), thì có thể chấp nhận việc yêu cầu thanh toán thêm phí.

Tóm tắt

Trong phát triển hệ thống, vai trò mà nhà cung cấp phải đảm nhận, một mặt nào đó, được quyết định theo nội dung của hợp đồng và tài liệu đặc tả. Tuy nhiên, xét về việc họ được giao công việc dựa trên sự tin tưởng cao độ như một chuyên gia, ta cũng hiểu rằng thực tế không phải lúc nào cũng được quyết định dựa trên hình thức. Tuy nhiên, để nắm bắt được bản chất của điều này, chúng ta cần hiểu rằng pháp luật đóng một vai trò lớn.