Trách nhiệm hợp tác mà người dùng, người đặt hàng phát triển hệ thống, phải gánh chịu là gì?

Công việc phát triển hệ thống, càng lớn hệ thống được phát triển, càng cần đến sự hỗ trợ của nhiều người và thời gian công sức. Do đó, không chỉ nhà cung cấp (vendor) chịu trách nhiệm phát triển, mà cả người dùng đặt hàng phát triển hệ thống cũng có nghĩa vụ hợp tác nhất định.

Điều này khác với mối quan hệ đặt hàng thông thường. Ví dụ, nếu bạn đặt một chiếc suit may đo tại một cửa hàng suit thay vì một hệ thống IT, người mua hàng (người dùng) không phải chịu bất kỳ “nghĩa vụ” nào. “Nghĩa vụ” chủ yếu thuộc về người nhận đơn hàng, tức là cửa hàng suit (nhà cung cấp). Chính vì hệ thống IT cần nhiều người và thời gian công sức, người dùng cũng cần “hợp tác” với nhà cung cấp.

Bài viết này sẽ giải thích về những nghĩa vụ pháp lý mà người đặt hàng phải chịu trong việc phát triển hệ thống mà không thể giao hết cho nhà cung cấp.

Chúng ta không thể ‘giao hết’ mọi thứ chỉ vì đó là hệ thống của chính công ty

Dù chỉ là một dự án phát triển hệ thống, thường có nhiều người và tổ chức tham gia. Không chỉ có các kỹ sư và lập trình viên giỏi về kỹ năng lập trình, vai trò của người quản lý dự án cũng rất quan trọng trong việc tổng hợp các kết quả thành một sản phẩm cuối cùng.

Tuy nhiên, dù nhà cung cấp có kỹ năng kỹ thuật và tổ chức cao đến mấy, họ cũng không thể hoàn thành dự án phát triển hệ thống chỉ bằng sức mạnh của mình. Ví dụ, họ không thể biết về các thuật ngữ nội bộ chỉ được sử dụng trong công ty hoặc kiến thức kinh doanh đặc thù của công ty chỉ bằng cách nỗ lực một chiều. Càng phát triển hệ thống quy mô lớn, càng có xu hướng chung là công ty sử dụng hệ thống đó cũng là một công ty lớn với nhiều người và công việc. Để dẫn dắt thành công dự án phát triển hệ thống, thực tế là việc sắp xếp logic kinh doanh này thường chiếm một phần lớn trọng lượng, thậm chí trước cả công việc máy tính.

Do đó, người dùng không nên trở nên thụ động chỉ vì “tôi không phải là chuyên gia công nghệ thông tin”, mà ngược lại, họ nên cung cấp thông tin một cách tích cực, điều này có thể giúp dự án tiến triển một cách trơn tru. Trong ngữ cảnh này, vai trò mà người dùng đang đảm nhận trong dự án phát triển hệ thống thực sự không hề nhỏ.

Nghĩa vụ hợp tác của người dùng dựa trên các tiền lệ pháp lý

Vậy cụ thể, trong dự án phát triển hệ thống, nghĩa vụ hợp tác mà phía người dùng phải chịu trách nhiệm là gì? Về điểm này, có rất nhiều gợi ý trong các tiền lệ pháp lý trước đây.

Trong phiên tòa, vụ việc về việc nhà cung cấp (bị đơn) trễ hạn giao hàng, do sự chậm trễ trong việc ra quyết định của người dùng (nguyên đơn) và những vấn đề khác, việc có hay không nghĩa vụ hợp tác của người dùng đối với việc phát triển đã trở thành vấn đề tranh cãi. Trong vụ việc này, tòa án đã công nhận vi phạm nghĩa vụ hợp tác của phía người dùng và phủ nhận trách nhiệm không thực hiện nghĩa vụ của phía nhà cung cấp. (Mặc dù việc hủy bỏ hợp đồng đã được chấp nhận, nhưng cũng đã được giảm 60% trách nhiệm.)

Hợp đồng phát triển hệ thống máy tính trong vụ việc này, là hợp đồng phát triển hệ thống theo đơn đặt hàng, trong hợp đồng phát triển hệ thống theo đơn đặt hàng như vậy, nhà thầu (nhà cung cấp) không thể hoàn thành hệ thống một mình, người ủy thác (người dùng) phải điều chỉnh ý kiến nội bộ một cách chính xác trong quá trình phát triển, thống nhất quan điểm, rõ ràng yêu cầu nhà thầu về chức năng mong muốn, cùng với nhà thầu, thảo luận về chức năng mong muốn, quyết định cuối cùng về chức năng, hơn nữa, quyết định về màn hình và biểu mẫu, kiểm tra sản phẩm hoàn thiện và những vai trò khác cần phải được chia sẻ.

Phán quyết ngày 10 tháng 3 năm 2004 (2004) của Tòa án quận Tokyo

Phán quyết này không chỉ chỉ ra rằng việc phát triển hệ thống là một công việc chung với phía người dùng, mà còn nêu rõ “cần hợp tác ở những điểm cụ thể nào”, điều này có vẻ rất gợi ý.

Hãy thử dịch các từ ngữ trong phán quyết trên thành các thuật ngữ IT của việc phát triển hệ thống.

Bạn có thể sắp xếp như trên. Tất cả những điều này, dù chuyên môn về hệ thống IT có cao đến đâu, cũng không thể thực hiện một mình mà không cần sự hợp tác của người dùng. Việc rõ ràng hóa chức năng mong muốn và giao diện màn hình là những điều cơ bản mà người dùng cần làm, và việc xác nhận xem sản phẩm đã được thực hiện đúng yêu cầu hay chưa cũng chỉ có người dùng mới có thể làm được.

Ngoài ra, giống như việc nghĩa vụ quản lý dự án được giao cho nhà cung cấp, người dùng cũng có nghĩa vụ hợp tác. Do đó, nếu người dùng vi phạm nghĩa vụ hợp tác trong quá trình như trên, có thể xem xét khả năng bị nhà cung cấp yêu cầu bồi thường thiệt hại dựa trên việc không thực hiện nghĩa vụ hoặc hành vi pháp lý sai trái.

Yêu cầu thay đổi thông số sau khi hoàn thành dự án sẽ được giải quyết như thế nào?

Nếu coi dự án phát triển hệ thống là công việc chung giữa người dùng và nhà cung cấp, từ đó chúng ta có thể thảo luận sâu hơn về vấn đề này. Đó là, “Nếu người dùng yêu cầu thêm chức năng hoặc sửa đổi sau khi dự án đã hoàn thành, và điều này làm khó khăn việc hoàn thành dự án đúng hạn, vậy ai sẽ chịu trách nhiệm?”

Phát triển hệ thống thông thường bắt đầu từ việc xác định yêu cầu, sau đó là thiết kế cơ bản, thiết kế chi tiết, sản xuất (triển khai chương trình), và kiểm tra, với mục tiêu là tránh việc phải làm lại công việc (được gọi chung là mô hình thác nước). Tuy nhiên, do một số lý do, nếu phát hiện ra lỗi trong quá trình trước đó, việc phải làm lại công việc sẽ xảy ra, điều này thực sự thường xảy ra trong thực tế.

Vậy chúng ta nên xem xét như thế nào nếu không thể hoàn thành dự án đúng hạn trong những trường hợp như vậy? Khi phân tích các quyết định trước đó, có vẻ như kết luận sẽ khác nhau tùy thuộc vào thời điểm công việc bổ sung xảy ra.

Trường hợp công việc bổ sung xảy ra trước khi thông số kỹ thuật được xác định rõ ràng

Quyết định trước đó cho thấy rằng việc người dùng yêu cầu công việc phát triển bổ sung từ nhà cung cấp trong quá trình thiết kế cơ bản (trước khi triển khai chương trình) không vi phạm nghĩa vụ hợp tác.

Việc người dùng yêu cầu nhà cung cấp thực hiện nhiều yêu cầu liên quan đến hệ thống đang được xây dựng trong quá trình thiết kế cơ bản là điều tất yếu trong quá trình phát triển hệ thống như trường hợp này, và hơn nữa, đối với người dùng không có kiến thức chuyên môn, việc đánh giá chính xác liệu yêu cầu đó có yêu cầu phí dịch vụ bổ sung, kéo dài thời hạn giao hàng, có gây ra trở ngại cho quá trình công việc hay không, là khó khăn. Do đó, không thể nói rằng người dùng nên tự kiềm chế yêu cầu gây ra phí dịch vụ bổ sung hoặc kéo dài thời hạn giao hàng. Ngược lại, nếu người dùng yêu cầu điều đó, nhà cung cấp, người có nghĩa vụ quản lý dự án, nên thông báo cho người dùng và yêu cầu thảo luận về việc rút lại yêu cầu hoặc kéo dài thời hạn giao hàng, để tránh gây ra trở ngại cho công việc phát triển.

Quyết định của Tòa án quận Tokyo ngày 10 tháng 3 năm 2004 (năm 2004 theo lịch Gregory)

Quyết định này khẳng định rằng người dùng cũng có nghĩa vụ hợp tác nhất định, và cũng nên xem xét việc người dùng không phải là chuyên gia trong việc phát triển hệ thống. Nói cách khác, người đặt hàng không phải là chuyên gia trong việc phát triển hệ thống, vì vậy trong quá trình cho đến khi nội dung của hệ thống được xác định rõ ràng, việc đặt hàng từng phần không phải là điều bất thường (có thể họ còn không quen với việc đặt hàng), và việc yêu cầu họ tự nhận ra rằng nội dung đặt hàng yêu cầu xem xét lại thời hạn giao hàng là quá khắt khe.

Tuy nhiên, nghĩa vụ được giao cho nhà cung cấp ở đây, cuối cùng, được cho là nỗ lực giao tiếp, như yêu cầu kéo dài thời hạn giao hàng (hoặc, nếu không thể thay đổi thời hạn giao hàng, đề nghị rút lại yêu cầu bổ sung). Do đó, điều này không có nghĩa là bao gồm tất cả các nghĩa vụ, bao gồm việc giao hàng đúng hạn sau khi chấp nhận tất cả yêu cầu của người dùng, vì vậy cần lưu ý điều này.

Trường hợp công việc bổ sung xảy ra sau khi thông số kỹ thuật đã được xác định trong quá trình sản xuất hoặc kiểm tra

Nếu chúng ta xem xét nội dung của quyết định trên, chúng ta có thể dự đoán một phần kết luận nếu công việc phát triển bổ sung là sau khi thông số kỹ thuật đã được xác định. Trong trường hợp đó, việc yêu cầu như vậy sẽ khó khăn hơn. Quả thật, sự khác biệt về mức độ hiểu biết về công việc phát triển giữa người dùng và nhà cung cấp không thay đổi, dù trước hay sau khi xác định thông số kỹ thuật.

Tuy nhiên, việc thay đổi hoặc thêm vào nội dung đặt hàng sau khi xác định thông số kỹ thuật có khả năng buộc phải làm lại công việc. Trong nhiều trường hợp, việc bảo vệ việc “đặt hàng nhiều yêu cầu là điều tất yếu vì họ là khách hàng” khi chậm giao hàng do những lý do này sẽ khó khăn. Hơn nữa, việc thay đổi thông số kỹ thuật nhiều lần hoặc thêm chức năng sau khi dự án đã hoàn thành có thể gây ra nghi ngờ về việc có vi phạm nghĩa vụ hợp tác của người dùng trong quá trình thiết kế cơ bản, quá trình mà người dùng đã hoàn thành từ trước.

Từ những điểm này, việc thay đổi thông số kỹ thuật sau khi đã xác định một lần có thể coi là không thực tế khi coi việc chậm giao hàng do nguyên nhân này là trách nhiệm của nhà cung cấp. Có thể nói rằng việc đọc quyết định trước đó cũng hợp lý với ý nghĩa này.

Ngoài ra, việc đưa ra quyết định như vậy thường dựa trên không chỉ hợp đồng mà còn biên bản họp phù hợp với tiến trình phát triển hệ thống. Chúng tôi đã giải thích chi tiết về biên bản họp trong bài viết dưới đây.

Bài viết liên quan: Cách lưu lại biên bản họp trong quá trình phát triển hệ thống từ góc độ pháp lý[ja]

Tóm tắt: Quan trọng là không quên rằng việc định rõ yêu cầu là quy trình thuộc về phía người dùng

Việc định rõ yêu cầu không chỉ là cơ hội để nhà cung cấp thể hiện kỹ năng của mình, mà trước hết, chúng ta cần nhận thức rằng đó là công việc thuộc về phía người dùng. Bởi vì đó là hệ thống được sử dụng bởi chính công ty, ngay cả khi hệ thống được xây dựng với sự hỗ trợ của chuyên gia bên ngoài, theo quan điểm pháp lý, nó vẫn nằm trong phạm vi quản lý của công ty.

Nếu phía người dùng không hợp tác trong quá trình phát triển, thậm chí dự án có thể gặp rắc rối, tòa án có thể đưa ra quan điểm nghiêm khắc đối với phía người dùng. Điều này cần được nhận biết trước hết.