Cách đánh giá báo giá phần mềm
Đánh giá báo giá phần mềm qua 6 bước: (1) Compare side-by-side trên cùng scope, (2) Hỏi breakdown chi phí (man-day, design, QC, deploy), (3) Verify timeline realistic, (4) Check assumptions + exclusions, (5) Đàm phán milestone payment, (6) Reference call. Báo giá thấp nhất ≠ tốt nhất. Hidden costs là điểm cần xem kỹ.
Trong VN, báo giá phần mềm cùng yêu cầu có thể chênh 5-10x - không phải vì 1 bên gian dối, mà vì 'phần mềm' có thể nghĩa rất khác nhau. Hướng dẫn này dạy cách phân tích báo giá ra sao thay vì 'lấy số rẻ nhất'.
Các bước
Compare side-by-side trên cùng scope
2-3 ngàyExcel template so sánh: cột vendor A/B/C, hàng là scope items. Bug số 1: so sánh 'tổng giá' mà không check vendor có cùng scope.
- List scope items từ Brief gốc
- Đánh dấu mỗi item: vendor A bao gồm? vendor B? vendor C?
- Identify gap - vendor nào bỏ sót item nào (yêu cầu báo giá lại)
- Calculate 'apples to apples' price - chỉ so sánh khi scope match
- Note extra value vendor offer - vendor A có CMS, vendor B không
Kết quả: Excel so sánh detailed, normalized scope
Yêu cầu breakdown chi phí
1 tuần'Tổng 200 triệu' không đủ. Phải biết: bao nhiêu giờ dev, ai làm (senior/junior), design bao nhiêu, QC bao nhiêu, deploy + maintenance bao nhiêu. Vendor không chịu breakdown = warning.
- Hỏi: 'Anh có thể breakdown theo: design / dev FE / dev BE / QC / PM / deploy?'
- Hỏi: 'Bao nhiêu man-day mỗi role? Rate trên giờ là gì?'
- Verify rate hợp lý cho VN: Junior 250-400k/giờ, Mid 400-550k/giờ, Senior 550-700k/giờ
- Verify timeline match man-day: 200 man-day / 4 dev = 10 tuần
- Identify role missing - không có designer = vendor reuse template, không có QC = quality risk
Kết quả: Breakdown sheet - clear ai làm bao nhiêu, ở rate nào
Verify timeline realistic
1-2 ngàyTimeline quá nhanh = vendor cut corner. Quá chậm = inefficient. Verify dựa man-day + team size.
- Calculate: total man-day / team size = working days
- Add 20-30% buffer cho meetings, review, UAT, deploy
- Verify timeline match với benchmark ngành: web 4-12 tuần, app mobile 10-20 tuần, ERP 16-36 tuần
- Identify cụm timeline bất thường: 'làm app mobile trong 4 tuần' = warning, 'làm landing page trong 8 tuần' = waste
- Yêu cầu milestone breakdown: deliverable mỗi 2 tuần
Kết quả: Timeline review - realistic hay không, lý do
Check assumptions + exclusions
1 ngày'Báo giá 200tr' bao gồm những gì không bao gồm? Đọc kỹ section 'Assumptions' + 'Exclusions' - đây là nơi vendor giấu hidden costs.
- Bao gồm: hosting năm đầu? domain? SSL? CDN? backup?
- Loại trừ: tích hợp 3rd party? Bản quyền images/icons? Translation cost?
- Hỏi: 'Nếu phát sinh feature ngoài scope, tính phí thế nào?' (Change Request rate)
- Hỏi: 'Phí maintenance từ tháng 13 trở đi là gì?' (post-warranty)
- Hỏi: 'Apple Developer + Google Play registration đứng tên ai?'
Kết quả: Document tất cả assumptions + exclusions làm rõ
Đàm phán milestone payment
1-2 ngàyMilestone payment là cấu trúc bảo vệ khách hàng. Vendor tốt accept milestone, vendor xấu đòi 50% upfront.
- Đề xuất: 20% kick-off, 30% sau khảo sát + design approve, 30% demo module chính, 20% UAT pass
- Vendor không chịu milestone → red flag
- Đàm phán điều khoản fail: nếu vendor delay 4 tuần ngoài lý do bất khả kháng, refund X% milestone
- Verify hợp đồng có điều khoản chấm dứt (termination clause)
- Yêu cầu warranty 12 tháng + support tier (P1/P2/P3 response time)
Kết quả: Term sheet với milestone + fail conditions
Reference call với KH cũ
3-5 ngàyTrước khi ký, yêu cầu vendor sắp xếp call với 2-3 KH cũ. Hỏi câu khó để verify trải nghiệm thực.
- Yêu cầu vendor connect với 2-3 KH cũ similar ngành/quy mô
- Câu hỏi: 'Vendor có giữ promise về deadline?' 'Quality code thế nào?'
- Câu hỏi: 'Sau bàn giao, support có tốt không?' 'Đã từng có dispute không?'
- Câu hỏi: 'Bạn có hire lại vendor này không?'
- Compare answer với pitch của vendor - discrepancy = warning
Kết quả: Reference call summary + final decision
Danh mục kiểm
Scope analysis
- Scope items rõ ràng từ Brief
- Side-by-side comparison Excel
- Identify scope gap giữa vendors
- Apples-to-apples price calc
- Note extra value mỗi vendor
Cost breakdown
- Breakdown man-day theo role
- Rate trên giờ verify hợp lý
- Team size + composition
- Missing role identified
- Rate match seniority
Hidden costs check
- Hosting / domain năm đầu?
- SSL / CDN cost?
- 3rd party API costs?
- Translation / localization?
- Apple/Google registration?
- Change Request rate?
- Post-warranty maintenance?
Contract terms
- Milestone payment 4-5 đợt
- SLA tiến độ + bồi thường
- Warranty 12 tháng
- Sở hữu mã nguồn 100%
- Termination clause
- Support tier P1/P2/P3
- Bug fix policy in warranty
Rủi ro và lưu ý
Dấu hiệu rủi ro
- Báo giá thấp hơn mặt bằng 5 đến 10 lần. Thường là mẫu dựng sẵn không khớp nghiệp vụ, người làm ít kinh nghiệm, không có quy trình kiểm tra, hoặc báo thấp để thắng thầu rồi tính thêm sau khi ký. Rẻ lúc mua, đắt lúc dùng.
- Đòi trả trước từ 50% trở lên. Đơn vị có tài chính vững thường chịu chia đợt theo nghiệm thu, ví dụ 20/30/30/20. Đòi trả trước quá nửa nghĩa là họ thiếu vốn, hoặc không có lý do để giao tốt.
- Không có bản mô tả phạm vi chi tiết. Chữ 'làm website' chưa phải phạm vi. Phải có danh sách trang, danh sách tính năng và mô tả người dùng làm được gì. Báo giá mà không cần hỏi phạm vi thì con số đó không có căn cứ.
- Tiến độ không thực tế. Ứng dụng di động xong trong 4 tuần hay ERP trong 8 tuần là không thể. Có đơn vị hứa quá mức để lấy hợp đồng rồi trễ. Hãy tính theo số ngày công và số người làm.
- Không có quy định về yêu cầu thay đổi. Trong lúc làm, chắc chắn sẽ có thay đổi. Nếu hợp đồng không ghi đơn giá và cách xử lý, mỗi lần đều phải thương lượng lại, hoặc bị tính giá cao đột ngột.
Lưu ý khi làm
- Không chọn báo giá rẻ nhất, chọn báo giá rõ nhất. Báo giá chia nhỏ từng hạng mục, ghi rõ các giả định, là dấu hiệu của đơn vị làm việc nghiêm túc. Con số một cục kiểu '200 triệu xong hết' thì nên hỏi lại.
- Thương lượng phạm vi, đừng ép giá. Không ai giảm 30% mà vẫn giao đủ chất lượng. Thay vì xin giảm giá, hãy bàn việc cắt tính năng ưu tiên thấp, thu nhỏ bản đầu tiên, hoặc chia làm hai giai đoạn.
- Chốt đơn giá trong 12 tháng. Ghi vào hợp đồng đơn giá giờ công của kỹ sư trong 12 tháng đầu, để không bị tăng giá ở các yêu cầu thay đổi sau khi đã ký.
- Làm thử một phần nhỏ trước. Trả 20 đến 50 triệu cho một mô-đun nhỏ trong 2 đến 3 tuần. Xem chất lượng và cách làm việc rồi mới quyết định ký cả dự án.
Công cụ gợi ý
- Bảng Excel so sánh báo giáĐặt cạnh nhau 3 đến 5 báo giá trên cùng một phạm vi
- Mẫu thỏa thuận sơ bộMẫu trước hợp đồng: đợt nghiệm thu, bảo hành, quyền sở hữu mã nguồn
- Bộ câu hỏi gọi khách hàng cũ10 câu nên hỏi khách hàng cũ của đơn vị bạn đang cân nhắc
Câu hỏi thường gặp
Báo giá chênh nhau 5 đến 10 lần, bên nào đúng?
Có thể cả hai đều đúng, nhưng giao hai thứ khác nhau. Bản 50 triệu cho ERP thường là mẫu dựng sẵn, người làm ít kinh nghiệm, không kiểm tra kỹ, bảo hành ngắn. Bản 500 triệu là làm riêng, kỹ sư giàu kinh nghiệm, có kiểm tra, bảo hành 12 tháng. Đó không phải chuyện gian dối mà là hai sản phẩm khác nhau, nên phải so trên cùng phạm vi và cùng chất lượng.
Có nên chọn đơn vị đắt nhất để yên tâm?
Không. Giá cao nhất chưa chắc chất lượng tốt nhất. Thường nên chọn mức giữa: có quy trình, có kỹ sư giàu kinh nghiệm, nhưng không tính thêm tiền cho thương hiệu. Xem hồ sơ dự án đã làm và gọi hỏi khách hàng cũ quan trọng hơn con số báo giá.
Vì sao có đơn vị không muốn chia nhỏ báo giá?
Có lý do chính đáng: không muốn khách mang cách làm đi nơi khác. Cũng có lý do không tốt: không biết mình tốn bao nhiêu công vì ước lượng cảm tính, hoặc cố ý để lại khoảng trống để tính thêm. Đơn vị tốt chia nhỏ đủ để khách hiểu, không nhất thiết phải chi tiết đến từng giờ.
Đơn vị không chịu chia đợt thanh toán, có nên ký?
Không nên. Chia đợt theo nghiệm thu bảo vệ cả hai bên. Từ chối thường do một trong ba lý do: tài chính yếu nên không thể làm trước, không tự tin giao đúng hẹn, hoặc muốn thu tiền sớm rồi giao qua loa. Tốt nhất là chọn đơn vị khác.
Đơn vị đề nghị giảm 30% nếu ký ngay, có nên nhận?
Nên cẩn thận. Thường là một trong ba trường hợp: đang khó khăn tài chính, đội đang thiếu việc nên cần ký gấp, hoặc báo thấp để lấy hợp đồng. Đơn vị tự tin vào chất lượng và đang có nhiều khách thì không cần bán gấp. Hãy chậm lại và tìm hiểu kỹ trước khi ký.
Cách chuẩn bị doanh nghiệp trước khi triển khai phần mềm
Bảy việc nên xong trước khi đơn vị làm phần mềm bắt đầu: (1) cử một người phụ trách nội bộ, (2) làm sạch dữ liệu, (3) lập kế hoạch đào tạo, (4) quản lý thay đổi, trong đó lãnh đạo dùng trước, (5) chuẩn bị sẵn hạ tầng gồm máy chủ, tên miền, tài khoản, (6) dự phòng 15 đến 20% ngân sách, (7) chốt chỉ số đo kết quả và mức dịch vụ cam kết.
Cách đưa bản chạy thử lên hệ thống chạy thật
Mở rộng qua 5 giai đoạn: (1) trả nợ kỹ thuật ở phần nền, (2) dựng giám sát, (3) tối ưu cơ sở dữ liệu và bộ nhớ đệm, (4) chạy nhiều máy chủ song song, (5) mở rộng đội và quy trình. Không làm tất cả cùng lúc: nút thắt đầu tiên mới là chỗ cần làm. Tối ưu quá sớm chỉ tốn tiền.
