Một doanh nghiệp đặt làm phần mềm quản lý bán hàng; sau nhiều tháng, phần mềm vẫn lỗi, khách hàng từ chối nghiệm thu và không trả đợt cuối. Bên phát triển nói khách liên tục thêm yêu cầu, đã làm vượt hợp đồng và đòi trả đủ. Hợp đồng có điều khoản trọng tài, nên tranh chấp đi tới một hội đồng trọng tài, có khi gồm cả trọng tài viên am hiểu công nghệ.
Bài này nhìn dự án phần mềm đổ vỡ từ hai phía: nghiệm thu được hiểu thế nào, yêu cầu phát sinh được tính ra sao, ai sở hữu mã nguồn, và giám định kỹ thuật đóng vai trò gì. Ví dụ là ví dụ giả định. Bài không bàn kỹ thuật lập trình, chỉ bàn chứng cứ và lập luận.
Vì sao dự án phần mềm hay đổ vỡ
Yêu cầu ban đầu mơ hồ. Hợp đồng chỉ ghi "phần mềm quản lý bán hàng đầy đủ chức năng". Mỗi bên hiểu "đầy đủ" một kiểu, và tranh chấp bắt đầu từ ngày đầu tiên.
Thay đổi phạm vi liên tục. Khách hàng thêm báo cáo, thêm quyền người dùng, đổi giao diện qua tin nhắn; bên phát triển làm theo cho giữ khách, nhưng không chốt chi phí và thời gian.
Tiêu chí nghiệm thu không rõ. Không có kịch bản kiểm thử, không định nghĩa lỗi nghiêm trọng và lỗi nhỏ, nên khách hàng có thể từ chối nghiệm thu vì bất kỳ lỗi nào.
Phụ thuộc lẫn nhau. Bên phát triển cần dữ liệu mẫu, tài khoản hệ thống cũ, người duyệt từ phía khách; mỗi lần chậm là một lần tiến độ trượt.
Mã nguồn và tài khoản hạ tầng. Máy chủ, tên miền, kho mã nguồn đứng tên bên phát triển; khi quan hệ xấu đi, đây trở thành đòn mặc cả.
Đổi người giữa chừng. Người phụ trách phía khách hàng nghỉ việc, người mới không biết các thoả thuận miệng trước đó và bắt đầu đánh giá lại từ đầu; hoặc lập trình viên chính của bên phát triển rời đi, chất lượng tụt hẳn.
Nghiệm thu: khi nào phần mềm được coi là đã bàn giao
Trong hợp đồng phần mềm, nghiệm thu thường là điều kiện thanh toán đợt cuối. Khách hàng có lợi khi trì hoãn nghiệm thu, bên phát triển có lợi khi chứng minh phần mềm đã đạt. Hội đồng trọng tài sẽ xem hợp đồng định nghĩa nghiệm thu thế nào và thực tế hai bên đã làm gì.
Nhiều hợp đồng có điều khoản nghiệm thu ngầm định: nếu khách hàng không phản hồi trong một số ngày sau khi nhận bản bàn giao, hoặc đưa phần mềm vào sử dụng chính thức, thì coi như đã nghiệm thu. Nếu có điều khoản như vậy, bên phát triển cần chứng minh đã bàn giao đúng cách và thời hạn đã trôi qua.
Ngay cả khi không có điều khoản ngầm định, việc khách hàng dùng phần mềm để vận hành kinh doanh thật trong nhiều tháng là chứng cứ mạnh cho thấy phần mềm đáp ứng mục đích cơ bản. Khách hàng muốn từ chối cần chỉ ra lỗi cụ thể, nghiêm trọng, đã được thông báo và không được sửa.
Một điểm hội đồng thường cân nhắc: phần mềm hầu như không bao giờ hết lỗi. Câu hỏi là lỗi có làm hỏng chức năng cốt lõi không, hay chỉ là lỗi nhỏ thuộc phạm vi bảo hành. Vì vậy danh sách lỗi có phân loại mức độ, ngày phát hiện, ngày sửa là tài liệu quan trọng với cả hai bên.
Yêu cầu phát sinh: ai trả tiền cho phần làm thêm
Tranh chấp thường gặp nhất là bên phát triển đòi tiền cho phần việc ngoài phạm vi, còn khách hàng nói đó chỉ là chi tiết của yêu cầu ban đầu. Để phân xử, hội đồng trọng tài phải so yêu cầu gốc với yêu cầu thực tế đã làm.
Bên phát triển cần chứng minh: tài liệu đặc tả ban đầu không có chức năng đó; khách hàng yêu cầu bằng văn bản hoặc tin nhắn rõ ràng; bên phát triển đã cảnh báo đây là phát sinh và ảnh hưởng chi phí, thời gian; và khách hàng vẫn yêu cầu làm. Thiếu bước cảnh báo, lập luận yếu đi nhiều, vì khách hàng sẽ nói mình tưởng đã nằm trong giá.
Khách hàng muốn bảo vệ mình cần chỉ ra yêu cầu đó đã nằm trong đặc tả, hoặc là hệ quả tự nhiên của chức năng đã cam kết. Ví dụ giả định: hợp đồng ghi có báo cáo doanh thu theo ngày; khách yêu cầu thêm theo tuần, theo tháng. Đó là phát sinh hay chỉ là mở rộng hợp lý của một chức năng? Không có câu trả lời chung, và chính sự mơ hồ này là lý do nên chốt từng thay đổi bằng phiếu yêu cầu thay đổi có chi phí và thời gian.
Mã nguồn và quyền sở hữu: tranh chấp hay bị bỏ sót
Chương trình máy tính được bảo hộ như tác phẩm theo Luật Sở hữu trí tuệ. Khi phần mềm được tạo ra theo hợp đồng giao kết, nếu không có thoả thuận khác, bên giao kết hợp đồng với tác giả thường là chủ sở hữu quyền tác giả. Nhưng hợp đồng phần mềm thực tế hay ghi chuyển quyền khi thanh toán đủ, hoặc chỉ cấp quyền sử dụng mà bên phát triển giữ mã nguồn để tái sử dụng cho khách khác.
Khi dự án đổ vỡ giữa chừng, câu hỏi là khách hàng có quyền nhận mã nguồn phần đã làm không, và nếu chưa trả đủ thì sao. Bên phát triển giữ mã nguồn và tài khoản máy chủ để đòi tiền là chuyện hay gặp; nhưng nếu hợp đồng đã chuyển quyền hoặc khách đã trả phần tương ứng, việc giữ có thể là vi phạm.
Một tình huống khó: bên phát triển dùng thư viện, khung phần mềm có sẵn của mình cho nhiều khách. Khách hàng đòi toàn bộ mã nguồn, bên phát triển chỉ đồng ý giao phần viết riêng. Hợp đồng có phân biệt hai phần này không là điểm mấu chốt.
Nếu tranh chấp đã chuyển sang hướng sao chép mã nguồn, xâm phạm quyền tác giả ngoài phạm vi hợp đồng, đó là loại tranh chấp có cơ chế riêng và nên có luật sư sở hữu trí tuệ.
Chứng cứ hai bên cần giữ trong dự án phần mềm
Phần lớn dự án phần mềm để lại dấu vết điện tử rất tốt; vấn đề là phải xuất và lưu đúng cách trước khi quyền truy cập bị cắt.
| Loại chứng cứ | Chứng minh điều gì | Lưu ý |
|---|---|---|
| Tài liệu đặc tả, biên bản chốt yêu cầu | Phạm vi gốc của dự án | Lưu mọi phiên bản có ngày |
| Phiếu yêu cầu thay đổi, tin nhắn yêu cầu thêm | Phát sinh và người yêu cầu | Xuất cả nhóm chat, không chụp màn hình rời |
| Lịch sử kho mã nguồn, hệ thống theo dõi công việc | Ai làm gì, khi nào, khối lượng thực tế | Xuất bản sao trước khi tài khoản bị khoá |
| Biên bản kiểm thử, danh sách lỗi | Chất lượng tại từng thời điểm, lỗi đã sửa hay chưa | Phân loại mức độ nghiêm trọng |
| Nhật ký sử dụng hệ thống thật | Khách hàng đã đưa vào vận hành | Có thể cần giám định để trích xuất |
Khi dữ liệu nằm trên hệ thống do bên kia kiểm soát, hãy gửi văn bản yêu cầu bảo toàn dữ liệu ngay khi tranh chấp bắt đầu. Đây cũng là chứng cứ cho thấy mình đã cảnh báo nếu dữ liệu sau đó bị xoá.
Giám định kỹ thuật trong trọng tài
Hội đồng trọng tài có thể gồm trọng tài viên có nền tảng công nghệ, nhưng với tranh chấp về lỗi, hiệu năng, khối lượng mã nguồn, ý kiến của chuyên gia độc lập thường vẫn cần. Hội đồng có thể trưng cầu giám định, hoặc mỗi bên nộp báo cáo của chuyên gia mình thuê và để hai chuyên gia trình bày tại phiên họp.
Giám định phần mềm thường trả lời các câu hỏi: phần mềm ở thời điểm bàn giao có đáp ứng các chức năng trong đặc tả không; lỗi tồn tại thuộc loại nào, mức độ nào; khối lượng công việc thực tế tương ứng bao nhiêu công; mã nguồn bàn giao có đầy đủ để bên khác tiếp tục phát triển không.
Để giám định có kết quả đáng tin, môi trường kiểm tra phải tái hiện được: bản phần mềm đúng phiên bản đã bàn giao, dữ liệu mẫu, tài liệu cài đặt. Bên nào làm mất khả năng tái hiện, ví dụ đã sửa đè lên bản bàn giao, sẽ gặp khó khi muốn chứng minh tình trạng gốc.
Trước khi tới giám định, một buổi kiểm thử chung có biên bản giữa hai bên đôi khi giải quyết được phần lớn bất đồng, và kết quả kiểm thử chung thường được hội đồng tin hơn mọi báo cáo một phía.
Lộ trình khi dự án phần mềm đang trượt
Trước khi quan hệ đổ vỡ hẳn, mỗi bên có thể làm vài việc để vừa cứu dự án vừa giữ quyền:
- Họp chốt danh sách việc còn lại, phân loại việc trong phạm vi và phát sinh, có biên bản.
- Chốt tiêu chí nghiệm thu cụ thể cho phần còn lại nếu hợp đồng chưa có.
- Gửi thông báo bằng văn bản về các điểm vướng do phía bên kia, ví dụ thiếu dữ liệu, chậm duyệt.
- Thoả thuận về mã nguồn và tài khoản hạ tầng trong thời gian tranh chấp, tránh cắt hệ thống đang vận hành của khách.
- Xuất và lưu bản sao toàn bộ chứng cứ điện tử.
- Nếu không cứu được, chuẩn bị đơn khởi kiện hoặc bản tự bảo vệ theo quy tắc của tổ chức trọng tài trong hợp đồng.
Bên phát triển không nên tự ý tắt hệ thống đang chạy của khách để đòi tiền; thiệt hại kinh doanh của khách có thể lớn hơn nhiều khoản tiền đang đòi và đảo ngược vị thế của hai bên.
Tương tự, khách hàng không nên tự ý khoá tài khoản kho mã nguồn hay thu hồi quyền truy cập của bên phát triển khi chưa chấm dứt hợp đồng hợp lệ; việc đó có thể bị coi là cản trở bên kia thực hiện nghĩa vụ, và làm mất luôn dấu vết công việc mà chính khách hàng cần để chứng minh lỗi.
Câu hỏi thường gặp
Khách hàng dùng phần mềm nhiều tháng nhưng không ký nghiệm thu thì có phải trả tiền không?
Việc đưa phần mềm vào vận hành thật là chứng cứ mạnh cho thấy phần mềm đáp ứng mục đích cơ bản, nhất là khi hợp đồng có điều khoản nghiệm thu ngầm định. Khách hàng muốn từ chối thanh toán cần chỉ ra lỗi nghiêm trọng đã thông báo mà không được sửa.
Bên phát triển có được giữ mã nguồn cho tới khi được trả đủ không?
Tuỳ hợp đồng. Nếu hợp đồng quy định chuyển giao mã nguồn khi thanh toán đủ, việc giữ là phù hợp. Nếu khách đã trả phần tương ứng hoặc hợp đồng quy định chuyển giao theo từng giai đoạn, giữ toàn bộ có thể là vi phạm.
Thay đổi yêu cầu qua tin nhắn có được tính là phát sinh không?
Tin nhắn có thể là chứng cứ về yêu cầu, nhưng bên phát triển cần chứng minh thêm đó là việc ngoài phạm vi và mình đã thông báo về chi phí, thời gian. Không có thông báo, khách hàng dễ lập luận rằng họ tưởng việc đó đã nằm trong giá.
Hợp đồng không có tiêu chí nghiệm thu thì hội đồng trọng tài dựa vào đâu?
Hội đồng sẽ dựa vào đặc tả, mục đích của phần mềm được nêu trong hợp đồng, quá trình trao đổi giữa hai bên và thông lệ của ngành. Giám định kỹ thuật thường được dùng để đánh giá phần mềm có đáp ứng chức năng cốt lõi hay không.
Khách hàng thuê bên khác sửa tiếp thì có ảnh hưởng tới vụ trọng tài không?
Có thể làm mất khả năng tái hiện tình trạng gốc của phần mềm. Trước khi giao cho bên khác, khách hàng nên lưu bản sao nguyên trạng có xác nhận, tốt nhất có biên bản với bên phát triển cũ hoặc với chuyên gia độc lập.
Có nên chọn trọng tài cho hợp đồng phần mềm giá trị nhỏ không?
Với hợp đồng nhỏ, chi phí và thủ tục trọng tài có thể không tương xứng. Nhiều bên chọn thương lượng, hoà giải trước. Danh mục có nên chọn trọng tài trên trang phân tích theo từng tình huống để giúp bạn cân nhắc trước khi ký.