Câu hỏi đầu tiên của gần như mọi dự án phần mềm là “bao nhiêu tiền”. Câu trả lời trung thực nhất ở thời điểm đó là một khoảng, không phải một con số.
Ước lượng sớm là ước lượng cho một phạm vi chưa rõ
Khi hai bên mới ngồi với nhau, thứ được mô tả thường là mong muốn: “một hệ thống quản lý đơn hàng”, “một ứng dụng chấm công”, “một cổng thông tin cho khách”. Mỗi cụm từ như vậy có thể nở ra thành mười màn hình hoặc một trăm màn hình, tuỳ vào những chi tiết mà chưa ai kịp hỏi tới. Đơn hàng đi qua bao nhiêu trạng thái? Ai được phép sửa sau khi đã duyệt? Có phải đối soát với kho không? Có nhiều chi nhánh dùng chung dữ liệu không?
Con số đưa ra khi những câu hỏi đó chưa có lời đáp là con số ước lượng cho một phạm vi tưởng tượng. Điều này không phải lỗi của bên báo giá, cũng không phải lỗi của bên hỏi giá. Nó là đặc điểm tự nhiên của công việc: phần lớn chi phí nằm ở các quy tắc nghiệp vụ mà chính doanh nghiệp cũng chỉ phát biểu rõ ra được khi nhìn thấy một bản phác thảo cụ thể trước mặt.
Con số thay đổi vì hiểu biết thay đổi
Một ước lượng phần mềm giống dự báo thời tiết hơn là giống bảng giá trong siêu thị. Càng gần thời điểm thực hiện, dự báo càng sát, vì lúc đó người ta đã biết nhiều hơn. Khi bản mô tả yêu cầu được viết chi tiết, khi giao diện chính đã được phác, khi các trường hợp ngoại lệ đã được liệt kê, khoảng dao động của chi phí hẹp lại đáng kể.
Vì thế cách làm việc lành mạnh không phải là ép một con số duy nhất ngay từ buổi gặp đầu, mà là thống nhất sẽ ước lượng lại ở vài mốc: sau khi chốt phạm vi, sau khi có thiết kế, và trước mỗi giai đoạn lớn. Mỗi lần ước lượng lại, hai bên cùng nhìn thấy điều gì đã thay đổi và vì sao.
Đọc một báo giá như thế nào
Giá trị của một báo giá nằm ở phần diễn giải nhiều hơn ở con số cuối trang. Khi so sánh các báo giá, nên đọc kỹ những mục sau:
- Phạm vi công việc: liệt kê cụ thể từng nhóm chức năng, hay chỉ vài dòng mô tả chung chung mà mỗi bên có thể hiểu một kiểu.
- Giả định: một báo giá nghiêm túc luôn ghi rõ nó đang giả định điều gì về số lượng người dùng, khối lượng dữ liệu, hay việc doanh nghiệp sẽ cung cấp sẵn thứ gì.
- Phần không bao gồm: nhập liệu ban đầu, tích hợp với hệ thống đang chạy, đào tạo người dùng, chi phí hạ tầng và giấy phép phần mềm của bên thứ ba.
- Cách xử lý thay đổi: khi yêu cầu phát sinh thì tính theo đơn giá nào, ai được quyền duyệt, và mất bao lâu để báo lại chi phí.
- Bảo hành: kéo dài bao lâu, gồm những gì, và ranh giới giữa sửa lỗi với làm thêm tính năng nằm ở đâu.
Hai báo giá chênh nhau gấp đôi thường không phải vì một bên tham lam, mà vì hai bên đang hình dung hai sản phẩm khác nhau. Khi các mục trên được viết rõ, phần lớn khoảng chênh đó tự giải thích.
Vì sao báo giá rẻ nhất thường đắt nhất về sau
Một báo giá thấp bất thường thường đến từ một trong ba chỗ. Thứ nhất, phạm vi được hiểu hẹp hơn thực tế, và phần chênh sẽ quay lại dưới dạng phụ lục hợp đồng. Thứ hai, phần việc khó bị đẩy sang giai đoạn sau, khi doanh nghiệp đã đầu tư quá nhiều để có thể đổi hướng. Thứ ba, chất lượng bị cắt ở đúng những chỗ khách hàng không nhìn thấy trong buổi nghiệm thu: kiểm thử, xử lý lỗi, tài liệu kỹ thuật, và bảo mật.
Chi phí không biến mất, nó chỉ đổi chỗ. Một hệ thống thiếu kiểm thử sẽ đòi trả bằng thời gian của nhân viên vận hành. Một hệ thống không có tài liệu sẽ đòi trả khi người viết nó nghỉ việc.
Nên làm gì tiếp theo
Nếu doanh nghiệp đang chuẩn bị đầu tư một hệ thống, việc đáng làm trước tiên không phải là đi thu thập báo giá, mà là viết ra cho rõ bài toán của mình: quy trình hiện tại đang chạy thế nào, chỗ nào đang tắc, và thành công sau một năm sẽ được đo bằng chỉ số gì. Với một bản mô tả như vậy, các báo giá nhận về sẽ so sánh được với nhau, và con số đầu tiên tuy vẫn chưa chính xác nhưng đã sai trong một biên độ chấp nhận được. Nếu chưa có đủ thông tin để viết bản mô tả đó, hãy đặt hàng riêng một giai đoạn khảo sát ngắn và trả phí cho nó — đây gần như luôn là khoản chi rẻ nhất trong toàn bộ dự án.