Không có một mức giá chung cho mọi phần mềm
Hai dự án có tên gọi giống nhau, như phần mềm quản lý bán hàng, vẫn có thể khác về số vai trò, quy tắc giá, phê duyệt, tồn kho, tích hợp và yêu cầu báo cáo. Những khác biệt đó ảnh hưởng đến công sức làm rõ yêu cầu, thiết kế, triển khai và kiểm thử.
Vì vậy, câu hỏi “làm phần mềm hết bao nhiêu?” chỉ có thể trả lời sau khi hiểu phần mềm cần giải quyết việc gì và phạm vi nào được tính. Một con số tách khỏi giả định, đầu ra và tiêu chí nghiệm thu không đủ để so sánh nhà cung cấp.
8 yếu tố tạo nên chi phí
Mỗi báo giá có thể nhóm công việc khác nhau. Hãy xem những đầu ra nào được tính và ai chịu trách nhiệm cho từng phần.
1. Discovery / BA
Giai đoạn discovery và phân tích nghiệp vụ giúp làm rõ người dùng, luồng công việc, dữ liệu, ngoại lệ và phạm vi. Nếu bỏ qua hoặc chỉ làm rất sơ lược, những câu hỏi chưa thống nhất có thể xuất hiện giữa lúc phát triển và làm thay đổi kế hoạch.
2. UX/UI
Thiết kế trải nghiệm và giao diện bao gồm cách người dùng tìm thông tin, hoàn thành tác vụ và xử lý trường hợp bất thường. Số màn hình không phải thước đo duy nhất; quy trình có nhiều vai trò hoặc cần thử nghiệm với người dùng thường đòi hỏi thêm công sức thiết kế và chỉnh sửa.
3. Development
Phát triển bao gồm các chức năng, quy tắc nghiệp vụ, phân quyền và cách dữ liệu được xử lý. Phạm vi cần nói rõ điều gì được làm, điều gì chưa làm và điều kiện để một tính năng được xem là hoàn tất.
4. QA
QA và kiểm thử xác nhận các luồng chính, quyền truy cập, dữ liệu biên và những kết nối liên quan. Cần hỏi loại kiểm thử nào được bao gồm, ai sửa lỗi và doanh nghiệp tham gia nghiệm thu theo cách nào.
5. Infrastructure
Hạ tầng có thể gồm môi trường chạy, lưu trữ, sao lưu, giám sát và dịch vụ bên thứ ba. Tách chi phí triển khai ban đầu khỏi khoản vận hành định kỳ, đồng thời xác định tài khoản nào do doanh nghiệp sở hữu và quản lý.
6. Integration
Tích hợp phụ thuộc vào số hệ thống, chất lượng tài liệu, quyền truy cập và quy tắc trao đổi dữ liệu. Một kết nối chỉ đọc dữ liệu có thể khác đáng kể so với đồng bộ hai chiều, xử lý trùng lặp và phục hồi khi một hệ thống tạm ngừng.
7. Security
Bảo mật có thể ảnh hưởng đến thiết kế phân quyền, quản lý bí mật truy cập, nhật ký, sao lưu và cách xử lý dữ liệu. Phạm vi kiểm soát nên dựa trên loại dữ liệu, cách sử dụng và yêu cầu của doanh nghiệp; hãy yêu cầu nhà cung cấp nêu rõ những biện pháp được tính trong báo giá.
8. Maintenance
Sau khi phát hành, phần mềm có thể cần sửa lỗi, cập nhật tương thích, theo dõi vận hành và điều chỉnh theo thay đổi nghiệp vụ. Bảo hành lỗi, hỗ trợ người dùng, bảo trì định kỳ và phát triển tính năng mới là các loại công việc khác nhau; nên làm rõ phạm vi và thời hạn từng loại.
Vì sao hai báo giá có thể chênh nhau rất nhiều?
Trước hết hãy kiểm tra hai bên có báo giá cùng một phạm vi không. Một đề xuất có thể bao gồm discovery, UX/UI, QA, triển khai, tài liệu, tích hợp và hỗ trợ; đề xuất khác có thể giả định doanh nghiệp tự cung cấp các phần đó hoặc chỉ tính phát triển một tập tính năng.
So sánh thêm vai trò tham gia, kiến trúc, cách nghiệm thu, giả định về dữ liệu, phụ thuộc vào dịch vụ ngoài, bảo hành và phần loại trừ. Chênh lệch không tự chứng minh bên nào tốt hơn: cần hỏi điều gì tạo ra khác biệt và nó có cần thiết cho dự án hay không.
- Phạm vi, luồng và ngoại lệ được tính
- Giả định về dữ liệu, người dùng và hệ thống hiện hữu
- Vai trò BA, UX/UI, phát triển, QA và quản lý
- Tích hợp, hạ tầng, bảo mật và tài liệu
- Nghiệm thu, bảo hành, maintenance và phần bị loại trừ
Báo giá theo feature, man-day hay team?
Báo giá theo tính năng giúp người mua liên hệ chi phí với đầu ra, nhưng chỉ hữu ích khi tính năng được mô tả đủ rõ và cách xử lý thay đổi đã thống nhất. Nếu phạm vi còn mơ hồ, danh sách tính năng có thể tạo cảm giác chính xác hơn thực tế.
Ước lượng theo man-day thể hiện giả định về công sức, nhưng cần biết vai trò nào tham gia, đầu ra dự kiến và cách xử lý khi yêu cầu thay đổi. Mô hình theo team hoặc thời gian có thể phù hợp với công việc cần ưu tiên linh hoạt qua từng giai đoạn, nhưng đòi hỏi phối hợp và quản lý phạm vi thường xuyên. Không có mô hình nào tự bảo đảm chi phí thấp; hãy chọn cách báo giá khớp với độ rõ ràng của yêu cầu và cách doanh nghiệp ra quyết định.
Một phần mềm 100 triệu và 500 triệu khác nhau ở đâu?
Hai con số riêng lẻ không cho biết giải pháp nào tốt hơn hoặc phạm vi nào phù hợp. Hãy kiểm tra tính năng và ngoại lệ được làm, vai trò tham gia, mức độ tích hợp, kiểm thử, bảo mật, hạ tầng, tiêu chí nghiệm thu và hỗ trợ sau bàn giao. Mức giá chỉ có ý nghĩa khi đi cùng phạm vi và giả định cụ thể; không thể suy ra chênh lệch chỉ từ tên gọi của phần mềm.
MVP có thể giảm chi phí như thế nào?
MVP có thể giới hạn khoản đầu tư ban đầu bằng cách tập trung vào một vấn đề và luồng sử dụng quan trọng nhất. Cách này hữu ích khi doanh nghiệp cần kiểm tra giả định trước khi mở rộng. MVP không phải phiên bản thiếu kiểm soát: dữ liệu, bảo mật, độ tin cậy và tiêu chí thành công vẫn cần được tính cho phạm vi đã chọn.
Để giới hạn phạm vi, hãy xác định người dùng đầu tiên, công việc cần hoàn thành, dữ liệu tối thiểu, tích hợp bắt buộc và điều gì sẽ khiến doanh nghiệp tiếp tục, điều chỉnh hoặc dừng. Không nên đưa mọi yêu cầu tương lai vào bản đầu tiên, nhưng cũng không nên bỏ các điều kiện cần thiết để thử nghiệm có ý nghĩa.
Những khoản thường bị bỏ quên trong báo giá
Khi xem tổng chi phí, kiểm tra xem các việc sau đã được giao cho bên nào và có nằm trong phạm vi không:
- Làm rõ yêu cầu, BA và xác nhận phạm vi
- QA, kiểm thử tích hợp và hỗ trợ người dùng nghiệm thu
- Triển khai, cấu hình môi trường và phương án khôi phục
- Phí hạ tầng, giấy phép và dịch vụ bên thứ ba
- Tích hợp, làm sạch hoặc chuyển đổi dữ liệu
- Kiểm soát bảo mật, phân quyền và nhật ký cần thiết
- Tài liệu kỹ thuật, hướng dẫn sử dụng và bàn giao
- Bảo hành, bảo trì, hỗ trợ và xử lý yêu cầu mới
Checklist đọc một báo giá phần mềm
Trước khi duyệt, hãy xác nhận được các câu trả lời dưới đây bằng văn bản:
- Phạm vi, giả định, hạng mục loại trừ và tiêu chí nghiệm thu là gì?
- Discovery, UX/UI, phát triển và QA tạo ra đầu ra nào?
- Tích hợp, dữ liệu, hạ tầng và bảo mật được xử lý ra sao?
- Phần nào là chi phí một lần, phần nào tiếp tục phát sinh khi vận hành?
- Ai sở hữu repository, tài khoản dịch vụ, tài liệu và dữ liệu?
- Bảo hành khác maintenance và hỗ trợ như thế nào?
- Thay đổi phạm vi được đánh giá, phê duyệt và tính phí ra sao?
Kết luận
Để hiểu doanh nghiệp đang trả tiền cho những gì, hãy đọc báo giá cùng phạm vi, giả định, đầu ra, tiêu chí nghiệm thu và chi phí sau phát hành. Nếu cần thu hẹp lựa chọn kỹ thuật trước khi yêu cầu báo giá, bài Mua phần mềm hay xây riêng? giúp so sánh các phương án. Pogofdev cũng trình bày năng lực phát triển phần mềm theo yêu cầu để doanh nghiệp đối chiếu với nhu cầu của mình.