Chi phí phát triển phần mềm theo yêu cầu gồm những gì?

Các khoản cần tính khi lập ngân sách phần mềm

Chi phí phát triển phần mềm theo yêu cầu không chỉ là tiền lập trình. Ngân sách còn có thể gồm tìm hiểu quy trình, thiết kế, kiểm thử, chuyển dữ liệu và duy trì hệ thống sau bàn giao. Mỗi nhà cung cấp có thể gộp các khoản này theo cách khác nhau. Vì vậy, trước khi so giá, hãy hỏi rõ bạn sẽ nhận được gì, phần nào chưa bao gồm và ai chịu trách nhiệm.

Đếm số màn hình chưa đủ để ước tính chi phí. Một biểu mẫu chỉ lưu thông tin đơn giản khác với đơn hàng phải qua nhiều cấp duyệt và lưu đầy đủ ai đã thay đổi điều gì. Dù giao diện trông gần giống nhau, lượng công việc phía sau có thể rất khác. Bảng trong bài giúp bạn kiểm tra dự toán, không phải bảng giá của Genki.

Vì sao hai phần mềm trông giống nhau lại có giá khác nhau?

Chi phí thường tăng khi phần mềm phải xử lý nhiều quy tắc hoặc nhiều tình huống ngoại lệ. Dữ liệu cũ cần sửa nhiều, kết nối chưa rõ cách hoạt động và yêu cầu vận hành cao cũng làm tăng công sức. Chẳng hạn, kết nối kế toán có tài liệu và nơi thử sẵn sẽ dễ ước tính hơn một kết nối chưa có người phụ trách. Cần khảo sát những điểm chưa rõ trước khi chốt phạm vi và giá.

• Số vai trò, luồng phê duyệt, ngoại lệ và yêu cầu lưu lịch sử.
• Chất lượng dữ liệu cần chuyển, quy tắc làm sạch và cách xác nhận kết quả.
• Các thiết bị, ngôn ngữ và nhu cầu hỗ trợ người khuyết tật khi sử dụng giao diện.
• Tích hợp thanh toán, kế toán hoặc hệ thống nội bộ cùng các giới hạn của bên thứ ba.
• Mức bảo mật, tốc độ xử lý, cách khôi phục khi gặp sự cố và tài liệu cần bàn giao.

Phân biệt tiền xây dựng ban đầu và tiền duy trì

Hãy tách ngân sách thành hai nhóm. Nhóm xây dựng ban đầu gồm khảo sát, thiết kế, lập trình, kiểm thử, chuyển dữ liệu và hướng dẫn người dùng. Nhóm duy trì gồm máy chủ, giấy phép phần mềm, theo dõi hoạt động, sao lưu, hỗ trợ và cập nhật. Với từng khoản, hỏi rõ đã nằm trong báo giá chưa, trả cho ai và có tăng theo mức sử dụng không.

Doanh nghiệp cũng cần dành thời gian cho nhân sự nội bộ giải thích yêu cầu, sửa dữ liệu và kiểm tra phần mềm. Khi tính tổng chi phí sở hữu, tức toàn bộ chi phí từ xây dựng đến sử dụng và thay đổi hệ thống, đừng bỏ qua phần này. Một giải pháp rẻ lúc đầu nhưng khó sửa hoặc khó lấy dữ liệu ra có thể tốn kém hơn về sau.

Cộng các khoản thế nào để không thiếu hoặc trùng?

Trước hết, chọn cùng một khoảng thời gian để tính ngân sách, chẳng hạn từ lúc khảo sát đến hết năm vận hành đầu tiên. Với mỗi khoản, ghi số lượng, đơn giá theo báo giá, lúc thanh toán, bên trả tiền và nguồn xác nhận. Khoản chưa biết phải được đánh dấu để hỏi thêm, không coi là miễn phí chỉ vì báo giá chưa nhắc tới.

Có thể tính ngân sách tiền dự kiến bằng cách cộng: chi phí triển khai trả một lần, phí định kỳ trong kỳ, phí theo sử dụng ước tính và dự phòng được duyệt. Mỗi khoản chỉ cộng một lần. Ví dụ, nếu gói phát triển đã gồm chuyển dữ liệu hoặc máy chủ giai đoạn đầu, không cộng lại những khoản đó ở dòng riêng.

Ghi riêng thời gian nhân sự nội bộ dành cho yêu cầu, dữ liệu và nghiệm thu. Nếu quy đổi phần thời gian này thành tiền, hãy nêu cách tính và tránh cộng lại tiền lương đã nằm trong ngân sách khác. Trước khi so sánh các phương án, cũng cần thống nhất loại tiền, thuế và cách tính khi phí sử dụng thay đổi.

Nên chọn giá cố định hay trả theo thời gian thực hiện?

Khi yêu cầu đã rõ và ít thay đổi, bạn có thể cân nhắc hợp đồng giá cố định, nhưng vẫn cần quy định cách tính phần phát sinh. Khi còn phải tìm hiểu nhiều, cách trả theo thời gian và nhân sự thực tế có thể linh hoạt hơn. Cách này cần giới hạn ngân sách, báo cáo công việc và các mốc quyết định có tiếp tục không. Không hình thức hợp đồng nào tự giúp tiết kiệm nếu yêu cầu liên tục mở rộng mà không được kiểm soát.

• Yêu cầu danh sách kết quả bàn giao ở từng giai đoạn và điều kiện để xác nhận hoàn thành.
• Hỏi báo giá đang dựa trên điều kiện nào và điều gì có thể khiến chi phí thay đổi nhiều.
• Hỏi chi phí phát sinh được phê duyệt trước bằng cách nào.
• Làm rõ bảo hành, bảo trì và hỗ trợ vận hành là các phạm vi nào.
• Xác nhận quyền với mã nguồn, dữ liệu và điều kiện chuyển giao.

Muốn giảm ngân sách, nên làm ít tính năng hơn trước

Ví dụ giả định: doanh nghiệp muốn làm phần mềm quản lý bảo trì có lịch công việc, phân công, ứng dụng di động và báo cáo nâng cao. Nếu vấn đề chính là bỏ sót việc, phiên bản đầu có thể tập trung vào lập lịch, giao việc và xác nhận hoàn thành. Phần báo cáo nâng cao có thể quyết định sau khi đã có dữ liệu sử dụng thực tế.

Muốn giảm ngân sách, hãy giảm phần chưa cần làm, không bỏ kiểm thử hoặc bảo mật thiết yếu. Giữ một quy trình chính có thể sử dụng trọn vẹn, tận dụng thành phần có sẵn khi phù hợp và tránh làm tính năng chưa rõ ai sẽ dùng. Mỗi giai đoạn cần tạo ra chức năng dùng được hoặc kết quả khảo sát đủ để bạn quyết định bước tiếp theo.

AI hỗ trợ phát triển có làm giá rẻ hơn không?

AI có thể giảm thời gian ở một số việc, nhưng không bỏ được nhu cầu khảo sát, thiết kế hệ thống, rà soát code và nghiệm thu. Đội ngũ còn cần thời gian sửa đề xuất sai, bảo vệ dữ liệu và quản lý công cụ. Vì vậy, một bản demo làm nhanh chưa đủ để kết luận tổng giá dự án sẽ thấp hơn.

Nếu đối tác đề xuất dùng AI, hãy hỏi công việc nào dự kiến tốn ít công hơn và họ sẽ kiểm tra chất lượng ra sao. Phần tiết kiệm cần được giải thích trong ước tính công việc, đi cùng tiêu chí nghiệm thu. Một tỷ lệ giảm giá chung chung chưa cho bạn biết điều gì thực sự thay đổi trong cách triển khai.

Trước khi lấy báo giá, chuẩn bị bản mô tả yêu cầu và câu hỏi dành cho nhà cung cấp