Chi phí phát triển web app: cách lập ngân sách không bị thiếu

Vì sao không thể báo giá web app chỉ từ một danh sách tính năng?

Hai web app cùng có đăng nhập, dashboard và xuất báo cáo vẫn có thể khác nhau rất lớn về công sức. Một hệ thống có một vai trò và dữ liệu nhập tay khác hoàn toàn hệ thống phải phân quyền theo chi nhánh, đồng bộ ERP, xử lý hàng nghìn bản ghi và lưu dấu vết cho từng quyết định. Tên tính năng không mô tả được quy tắc nghiệp vụ, ngoại lệ và mức rủi ro bên trong.

Ước tính sớm nên được trình bày thành khoảng hoặc các kịch bản, không phải một con số chính xác giả tạo. GOV.UK Service Manual xem discovery là giai đoạn hiểu người dùng, vấn đề và ràng buộc trước khi quyết định có nên đi tiếp. Với dự án doanh nghiệp, kết quả discovery cần đủ để xác định lát cắt đầu tiên, rủi ro kỹ thuật và các giả định ảnh hưởng ngân sách.

• ✓Workflow chính, ngoại lệ và người chịu trách nhiệm ở từng bước.
• ✓Vai trò người dùng, phạm vi dữ liệu và quy tắc phân quyền.
• ✓Hệ thống phải tích hợp, chất lượng API và yêu cầu migration.
• ✓Mức sẵn sàng, hiệu năng, kiểm toán và hỗ trợ sau ra mắt.

Con số báo giá chỉ hữu ích khi doanh nghiệp biết nó đang mua kết quả nào, với giả định nào và còn phải vận hành điều gì sau ngày ra mắt.

Bảy nhóm chi phí cần xuất hiện trong ngân sách

Ngân sách đầu tiên là discovery và thiết kế: phỏng vấn, vẽ workflow, kiểm tra dữ liệu, prototype, kiến trúc và tiêu chí chấp nhận. Tiếp theo là chi phí xây sản phẩm gồm giao diện, backend, cơ sở dữ liệu, phân quyền, quản trị và kiểm thử. Nếu chỉ tính giờ lập trình mà bỏ qua hai nhóm này, dự án thường trả lại chi phí dưới dạng sửa sai và làm lại.

Các nhóm còn lại gồm migration dữ liệu, tích hợp bên thứ ba, chuẩn bị production, an toàn phần mềm và vận hành. NIST SSDF khuyến nghị theo dõi yêu cầu an toàn, rủi ro và quyết định thiết kế trong vòng đời phát triển; đây là công việc cần được ước tính thay vì để thành bước kiểm tra cuối. Sau ra mắt còn có hạ tầng, giám sát, sao lưu, hỗ trợ, cập nhật dependency và backlog cải tiến.

• ✓01. Discovery, prototype và đặc tả có thể kiểm thử.
• ✓02. Thiết kế trải nghiệm, kiến trúc, dữ liệu và API.
• ✓03. Phát triển, kiểm thử chức năng và nghiệm thu.
• ✓04. Migration, tích hợp và chi phí dịch vụ bên thứ ba.
• ✓05. Bảo mật, hiệu năng, logging, sao lưu và khôi phục.
• ✓06. Hạ tầng, giám sát, hỗ trợ và xử lý sự cố.
• ✓07. Bảo trì, thay đổi nghiệp vụ và cải tiến roadmap.

Công thức lập dự toán mà doanh nghiệp có thể kiểm tra

Một công thức đơn giản là: chi phí đội ngũ theo giai đoạn + dịch vụ bên thứ ba + hạ tầng + dự phòng cho rủi ro đã biết. Chi phí đội ngũ được hình thành từ năng lực cần có, thời lượng và mức tham gia thực tế; không nên lấy số màn hình nhân với một đơn giá vì một màn hình có thể chứa quy tắc nghiệp vụ rất khác nhau.

Hãy yêu cầu ba kịch bản: lát cắt tối thiểu để kiểm chứng, phiên bản vận hành mục tiêu và phần mở rộng chưa cam kết. Mỗi kịch bản phải nêu chức năng, dữ liệu, tích hợp, tiêu chí chất lượng và điều gì bị loại ra. AWS Well-Architected khuyến nghị phân tích các thành phần của workload, mô hình hóa chi phí theo mức sử dụng và xem lại định kỳ; vì vậy dự toán vận hành nên có ít nhất kịch bản cơ sở và kịch bản tăng trưởng.

• ✓Phạm vi cơ sở: chức năng nào tạo ra một luồng end-to-end hoàn chỉnh.
• ✓Giả định: dữ liệu, API, tài khoản thử và người duyệt có sẵn hay không.
• ✓Biến số: số người dùng, giao dịch, dung lượng, môi trường và mức hỗ trợ.
• ✓Dự phòng: chỉ gắn với rủi ro đã mô tả, không phải một khoản mơ hồ.

Cách đọc báo giá và tránh chi phí bị giấu sau ngày ký

Một báo giá tốt liên kết deliverable với tiêu chí nghiệm thu. Nó nói rõ số vòng phản hồi, môi trường triển khai, dữ liệu thử, trình duyệt hoặc thiết bị hỗ trợ, tài liệu, đào tạo và bàn giao. Nó cũng chỉ ra phần nào là ước tính, phần nào cố định và quy trình phê duyệt khi scope thay đổi.

Doanh nghiệp cần kiểm tra quyền sở hữu repository, dữ liệu, tài khoản cloud, tên miền và tài liệu. Hỏi thêm ai trả phí email, lưu trữ, bản đồ, AI, SMS hoặc cổng thanh toán; giới hạn sử dụng là gì; và khi lưu lượng tăng thì chi phí đổi thế nào. Một giá xây thấp nhưng khóa doanh nghiệp vào tài khoản của nhà cung cấp có thể tạo chi phí chuyển đổi lớn hơn về sau.

• ✓Deliverable, lịch bàn giao và tiêu chí chấp nhận.
• ✓Exclusion, dependency và trách nhiệm của mỗi bên.
• ✓Quyền sở hữu mã nguồn, dữ liệu, hạ tầng và thông tin xác thực.
• ✓Bảo hành lỗi, hỗ trợ vận hành và đơn giá cho thay đổi mới.

Friday Works ước tính dự án web app như thế nào?

Friday Works bắt đầu từ quy trình, người dùng và kết quả cần thay đổi. Discovery tập trung thường nằm trong khoảng 1–3 tuần khi dữ liệu và người sở hữu nghiệp vụ sẵn sàng. Kết quả gồm scope theo luồng, rủi ro, prototype hoặc đặc tả, kiến trúc vừa đủ và một kế hoạch phát hành có thể báo giá rõ hơn.

Với một phạm vi MVP tập trung, mốc lập kế hoạch thường là 8–14 tuần; hệ thống có migration lớn, nhiều tích hợp, yêu cầu bảo mật hoặc mức sẵn sàng cao sẽ được chia thành giai đoạn. Đây không phải bảng giá cố định. Đề xuất chỉ được chốt sau khi các giả định quan trọng được kiểm tra và doanh nghiệp chọn mức đầu tư phù hợp với bằng chứng cần tạo.

• ✓Một lát cắt tạo giá trị thật thay vì danh sách màn hình rời rạc.
• ✓Khoảng ước tính kèm giả định, rủi ro và điều kiện thay đổi.
• ✓Chi phí xây và chi phí vận hành được trình bày riêng.
• ✓Mã nguồn, dữ liệu, môi trường và bàn giao được ghi rõ trong đề xuất.