Phần lớn tranh chấp trong dự án phần mềm không nằm ở chất lượng lập trình, mà ở những điều hai bên tưởng là đã hiểu giống nhau nhưng chưa bao giờ viết ra giấy.
Mã nguồn cuối cùng thuộc về ai
Đây là câu hỏi nên hỏi sớm nhất và thẳng nhất. Có hợp đồng chuyển giao toàn bộ quyền sở hữu mã nguồn cho khách hàng; có hợp đồng chỉ cấp quyền sử dụng, còn mã nguồn vẫn thuộc về bên phát triển. Cả hai đều hợp lệ, nhưng dẫn tới hai tương lai rất khác nhau.
Nếu doanh nghiệp không sở hữu mã nguồn, việc đổi nhà cung cấp về sau không còn là quyết định thương mại thuần tuý mà trở thành quyết định làm lại hệ thống. Cần hỏi thêm: nếu hệ thống dùng thành phần của bên thứ ba thì giấy phép đứng tên ai. Câu trả lời nên nằm trong hợp đồng, không nằm trong email.
Bàn giao gồm những gì
“Bàn giao” là một từ dễ gây hiểu nhầm, vì nhiều người mặc định nó chỉ có nghĩa là hệ thống chạy được trên máy chủ. Một bàn giao đầy đủ nên bao gồm:
- Mã nguồn kèm lịch sử thay đổi, đặt trên kho mã mà doanh nghiệp có quyền truy cập.
- Hướng dẫn dựng lại hệ thống từ đầu trên một máy chủ trống, đủ chi tiết để một kỹ sư khác làm theo được.
- Tài liệu mô tả cấu trúc dữ liệu và các quy tắc nghiệp vụ đã cài đặt.
- Toàn bộ tài khoản quản trị, khoá bí mật và biến cấu hình, cùng danh sách dịch vụ bên ngoài mà hệ thống phụ thuộc vào.
- Tài liệu hướng dẫn sử dụng cho người dùng cuối và cho quản trị viên.
Phép thử tốt nhất cho một bàn giao là câu hỏi: nếu ngày mai đối tác không còn làm việc với chúng ta nữa, một đội kỹ thuật khác có tiếp quản được không, và mất bao lâu? Nên hỏi điều đó khi đàm phán, chứ không phải khi mọi chuyện đã xấu đi.
Ai đứng tên hạ tầng và tên miền
Tên miền, máy chủ, chứng chỉ bảo mật, tài khoản dịch vụ thư điện tử — những thứ này thường được đối tác đăng ký hộ trong giai đoạn đầu cho tiện, rồi không ai nhớ chuyển lại. Đến khi cần thay đổi bản ghi tên miền gấp, doanh nghiệp mới phát hiện mình không có quyền vào.
Nguyên tắc nên giữ: mọi tài sản số mang tên doanh nghiệp thì phải đứng tên doanh nghiệp, thanh toán bằng phương tiện của doanh nghiệp, và đối tác được cấp quyền truy cập với vai trò cộng tác viên. Đây không phải sự thiếu tin tưởng, mà là tách bạch quyền sở hữu với quyền vận hành.
Bảo hành không phải là bảo trì
Hai khái niệm này hay bị gộp làm một trong lúc thương thảo, rồi tách ra rất đau đớn khi vận hành. Bảo hành là việc sửa những chỗ hệ thống chạy sai so với yêu cầu đã thống nhất; nó có thời hạn và về nguyên tắc không phát sinh chi phí. Bảo trì là việc giữ cho hệ thống tiếp tục hoạt động tốt trong môi trường luôn thay đổi: cập nhật bản vá bảo mật, nâng cấp phiên bản nền tảng, theo dõi hiệu năng, sao lưu và diễn tập khôi phục.
Một phần mềm không được bảo trì sẽ không hỏng ngay, nó xuống cấp âm thầm cho tới lúc một lỗ hổng bảo mật buộc phải xử lý gấp. Vì vậy nên hỏi rõ thời hạn bảo hành, phạm vi của nó, và gói bảo trì sau đó gồm những mức dịch vụ nào với thời gian phản hồi cam kết ra sao.
Cách làm việc khi yêu cầu thay đổi
Yêu cầu sẽ thay đổi. Đó là điều bình thường, không phải dấu hiệu của một dự án tồi. Vấn đề chỉ phát sinh khi không có cơ chế nào để xử lý thay đổi một cách có trật tự. Nên thống nhất trước: ai bên phía doanh nghiệp có quyền chốt yêu cầu, đề nghị thay đổi được ghi nhận ở đâu, mất bao lâu để đối tác báo lại ảnh hưởng về chi phí và tiến độ, và thay đổi nhỏ tới mức nào thì không cần làm thủ tục.
Cũng nên hỏi về nhịp làm việc: bao lâu thì có một bản chạy được để xem, và họp rà soát tiến độ theo tần suất nào. Trong kinh nghiệm của chúng tôi, dự án có nhịp bàn giao ngắn và đều thì hiếm khi đi chệch xa, bởi sai lệch được phát hiện khi còn rẻ để sửa.
Nên làm gì tiếp theo
Trước khi ký, hãy soạn một danh sách ngắn gồm năm nhóm câu hỏi ở trên và gửi cho tất cả các đối tác đang cân nhắc, bằng văn bản. Cách trả lời nói nhiều điều hơn cả nội dung trả lời: đối tác làm việc bài bản thường có sẵn câu trả lời và sẵn sàng đưa chúng vào hợp đồng, còn đối tác hẹn “chuyện đó tính sau” đang cho bạn biết trước điều gì sẽ xảy ra khi dự án gặp khó khăn.