Cần làm rõ những gì khi nhận báo giá phần mềm?
Khi nhận hai báo giá cho cùng một hệ thống, doanh nghiệp thường nhìn vào tổng tiền để so sánh. Tuy nhiên, cùng ghi “cổng thông tin khách hàng”, một bên có thể chỉ tính phần xây dựng chức năng, trong khi bên còn lại đã bao gồm chuyển dữ liệu cũ, đưa hệ thống vào sử dụng và hướng dẫn nhân viên.
Chênh lệch giá vì thế chưa đủ để kết luận phương án nào phù hợp hơn. Trước hết, cần hiểu mỗi bên đang nhận làm những việc gì, bàn giao kết quả nào và dựa trên những điều kiện nào để tính giá. Khi các thông tin này rõ ràng, doanh nghiệp mới có cơ sở so sánh và dự tính những khoản còn phải chuẩn bị.
Bài viết dưới đây dành cho người phụ trách lựa chọn hoặc làm việc với đơn vị phát triển phần mềm. Ví dụ cổng thông tin khách hàng được dùng để minh họa cách đọc báo giá, không phải một dự án thực tế của Fenix. Mức độ chi tiết cần làm rõ sẽ tùy giai đoạn dự án; những phần chưa xác định nên được ghi lại thay vì mặc nhiên coi là đã bao gồm.
1. Hiểu phạm vi và kết quả sẽ nhận được
Một danh sách chức năng có thể trông khá đầy đủ nhưng vẫn để lại nhiều cách hiểu. Với cổng hỗ trợ khách hàng, dòng “đăng nhập” có thể chỉ nói đến tài khoản do quản trị viên tạo. Ở một báo giá khác, nó lại bao gồm cả đăng ký tài khoản, xác thực, đặt lại mật khẩu và kết nối với hệ thống tài khoản sẵn có. Hai bên cùng ghi một tên chức năng nhưng lượng công việc không giống nhau.
Chức năng “xem lịch sử yêu cầu” cũng tương tự. Nếu chỉ hiển thị những yêu cầu tạo mới sau khi hệ thống hoạt động, phần việc sẽ khác với việc chuyển và hiển thị dữ liệu từ nhiều năm trước. Vì vậy, thay vì đếm số chức năng, hãy trao đổi về người sẽ sử dụng, thao tác họ cần thực hiện, dữ liệu liên quan và kết quả mong đợi.
Không phải báo giá nào cũng cần chứa một bản đặc tả đầy đủ. Tuy nhiên, báo giá nên chỉ rõ tài liệu yêu cầu hoặc phiên bản phạm vi mà hai bên đang cùng tham chiếu. Nếu có phần chưa quyết định, hãy ghi nhận phần đó để tiếp tục làm rõ. Với dự án còn nhiều điểm mở, có thể cần khảo sát trước khi xác định phạm vi triển khai.
Bên cạnh chức năng, doanh nghiệp cũng nên hình dung mình sẽ nhận được gì ở từng mốc. Đó là bản thiết kế để xem xét, phần mềm chạy trong môi trường thử, hay một hệ thống đã sẵn sàng sử dụng? Tài liệu, mã nguồn theo thỏa thuận và buổi hướng dẫn có nằm trong phần bàn giao không? Những câu hỏi này giúp tránh hiểu mốc “hoàn thành phát triển” thành thời điểm nhân viên có thể bắt đầu làm việc ngay.
2. Kiểm tra những công việc ngoài lập trình
Sau khi đã hiểu chức năng và kết quả bàn giao, hãy xem những công việc cần thiết để đưa chúng vào sử dụng. Đây là nơi hai báo giá dễ khác nhau, dù danh sách chức năng gần như giống hệt.
Phân tích yêu cầu và thiết kế
Trước khi lập trình, nhóm dự án cần thống nhất cách phần mềm sẽ hỗ trợ công việc thực tế. Vì vậy, hãy kiểm tra báo giá có bao gồm làm rõ yêu cầu, thiết kế màn hình và xác nhận cách xử lý hay không. Đồng thời, hai bên nên biết khách hàng phải chuẩn bị tài liệu đến mức nào, ai phê duyệt và sẽ có những lượt rà soát nào.
Nếu trách nhiệm này chưa rõ, khách hàng có thể nghĩ bên phát triển sẽ tự hoàn thiện mọi chi tiết, trong khi bên phát triển lại chờ một bộ yêu cầu hoặc thiết kế đã chốt. Làm rõ cách phối hợp từ đầu sẽ giúp hai bên hiểu phần việc của mình trước khi dự án bắt đầu.
Kết nối với phần mềm khác và chuyển dữ liệu
Cổng khách hàng có thể cần lấy thông tin từ hệ thống hỗ trợ đang dùng. Khi đó, báo giá nên cho biết phần kết nối đã được tính chưa và dựa trên tài liệu kỹ thuật nào. Nếu cần nhà cung cấp hệ thống hiện tại tham gia, phí và công việc của họ có thể phải được tính riêng.
Với dữ liệu lịch sử, hãy xác định loại dữ liệu, khoảng thời gian, nguồn lấy và cách kiểm tra sau chuyển đổi. Cụm từ “hỗ trợ chuyển dữ liệu” vẫn chưa trả lời ai sẽ làm sạch các bản ghi sai hoặc thiếu. Đây là trách nhiệm nên được thống nhất trước, thay vì để đến lúc chuyển mới phát hiện.
Kiểm thử và nghiệm thu
Phần mềm cần được kiểm tra trước khi sử dụng, nhưng một dòng “kiểm thử” chưa cho biết phạm vi đã bao gồm những gì. Hãy làm rõ bên phát triển sẽ kiểm tra phần nào, khách hàng tham gia ở đâu và có được hỗ trợ kiểm thử theo tình huống nghiệp vụ hay không. Việc sửa lỗi trong phạm vi đã thống nhất và kiểm tra lại sau sửa cũng cần được thể hiện rõ.
Nếu dự án có yêu cầu riêng như kiểm tra khả năng chịu tải hoặc đánh giá bảo mật, hãy mô tả mục tiêu và phạm vi của các hoạt động đó. Không nên hiểu rằng mọi loại kiểm tra đều nằm trong báo giá chỉ vì đã có một mục mang tên “kiểm thử”.
Nghiệm thu phần mềm: Doanh nghiệp cần kiểm tra gì?
Đưa hệ thống vào sử dụng và hỗ trợ sau đó
Một phần mềm đã xây xong vẫn cần môi trường để vận hành. Hai bên nên xác định ai chuẩn bị máy chủ hoặc dịch vụ lưu trữ, cấu hình tên miền, thiết lập môi trường và thực hiện phát hành. Phí hạ tầng, dịch vụ gửi thư và công cụ bên ngoài có thể không nằm trong phí phát triển, nên cần được nhìn thấy khi dự tính ngân sách.
Sau khi đưa vào sử dụng, lỗi được tiếp nhận qua đâu, bảo hành và bảo trì kéo dài bao lâu, yêu cầu mới được xử lý thế nào? Những nội dung này nên có phạm vi, thời hạn và kênh hỗ trợ cụ thể để doanh nghiệp biết mình đang được hỗ trợ đến đâu.
3. Làm rõ cách tính giá và các điều kiện đi kèm
Khi đã biết những công việc được bao gồm, bước tiếp theo là hiểu số tiền được tính trên cơ sở nào. Với báo giá theo một phạm vi cố định, cần có căn cứ xác định phần việc mà mức giá đó áp dụng. Nếu tính theo nhân sự hoặc thời gian thực hiện, doanh nghiệp cần biết đơn vị tính, vai trò tham gia, cách xác nhận thời gian làm việc và cách theo dõi ngân sách.
Không có cách tính nào tự động bảo đảm chi phí phù hợp. Điều đáng xem là cách tính đó có khớp với mức độ rõ ràng của yêu cầu và cách hai bên sẽ quản lý công việc hay không. Nếu báo giá dùng đơn vị tháng-người, hãy hỏi cách quy đổi cụ thể. Tổng công sức thực hiện không thể được đọc thẳng thành số tháng theo lịch, vì còn phụ thuộc vào cơ cấu nhóm, thứ tự công việc và khả năng làm song song.
Báo giá cũng có thể dựa trên một số điều kiện: dữ liệu được cung cấp đúng mẫu, khách hàng phản hồi trong thời gian nhất định, bên thứ ba cung cấp kết nối hoặc hệ thống chỉ hỗ trợ số ngôn ngữ đã nêu. Những điều kiện này giúp giải thích mức giá đang áp dụng cho trường hợp nào. Khi thực tế khác đi, phạm vi hoặc kế hoạch có thể cần điều chỉnh.
Vì vậy, bên cạnh việc đọc các điều kiện, hãy thống nhất cách xử lý nếu chúng thay đổi. Ai ghi nhận yêu cầu, ai đánh giá ảnh hưởng và khi nào hai bên phải xác nhận trước khi làm? Có một cách trao đổi rõ ràng sẽ giúp doanh nghiệp theo dõi thay đổi trong quá trình triển khai, thay vì chỉ biết đến chi phí bổ sung sau khi công việc đã được thực hiện.
4. So sánh trên cùng phạm vi và xác nhận phần còn thiếu
Khi những nội dung trên đã rõ hơn, doanh nghiệp có thể đặt các báo giá cạnh nhau theo từng nhóm công việc. Với cổng hỗ trợ khách hàng, hãy tách riêng tài khoản, dữ liệu lịch sử, kết nối, kiểm thử, môi trường, đào tạo và hỗ trợ. Ở mỗi nhóm, ghi bên nào bao gồm gì, phần khách hàng phải tự làm và thông tin nào còn thiếu.
Ví dụ, nếu một bên chưa tính chuyển dữ liệu, có thể yêu cầu bổ sung phần đó hoặc tách khỏi cả hai báo giá khi so sánh phạm vi ban đầu. Những khoản chưa được xác minh nên được giữ riêng; không cần điền một con số ước đoán chỉ để bảng có vẻ đầy đủ.
Việc đối chiếu này giúp hiểu sự khác biệt về công việc, nhưng chưa thay thế việc đánh giá đơn vị thực hiện. Năng lực, cách phối hợp và bằng chứng dự án vẫn là những nội dung cần xem xét riêng.
Đâu là đối tác phát triển phần mềm phù hợp?
Trước buổi trao đổi tiếp theo, có thể dùng năm câu hỏi sau để kiểm tra xem còn điểm nào chưa rõ:
• Báo giá dựa trên tài liệu yêu cầu và những điều kiện nào?
• Mỗi mốc sẽ bàn giao kết quả gì và được kiểm tra ra sao?
• Khách hàng hoặc bên thứ ba cần tự thực hiện phần việc nào?
• Ngoài mức giá đã nêu, còn chi phí định kỳ hoặc phần loại trừ nào?
• Nếu yêu cầu hay điều kiện thay đổi, hai bên sẽ xác nhận ảnh hưởng thế nào?
Các câu trả lời nên được phản ánh vào tài liệu mà hai bên cùng sử dụng, đặc biệt với nội dung ảnh hưởng đến phạm vi và chi phí. Nếu chưa đủ thông tin để chốt giá, hãy xác định phần cần khảo sát thêm và kết quả sẽ nhận được từ đợt khảo sát đó.
Sau cùng, một báo giá rõ ràng cần giúp doanh nghiệp hiểu mình sẽ nhận được gì, còn phải chuẩn bị gì và những điểm nào vẫn chưa được quyết định. Đó là cơ sở để trao đổi với bên phát triển và lựa chọn phương án phù hợp với công việc thực tế.
