5 sai lầm khiến chi phí phát triển phần mềm vượt dự kiến

“Cần hệ thống quản lý đơn hàng” hay “muốn số hóa quy trình nội bộ” chưa cung cấp đủ thông tin để lập một ước tính chi tiết. Độ tin cậy của ước tính còn phụ thuộc vào mức độ rõ của người dùng, quy trình, dữ liệu, phạm vi và các ràng buộc liên quan.

Nếu dự án bắt đầu khi những điểm này còn bỏ ngỏ, nhiều chi tiết chỉ được phát hiện sau khi thiết kế hoặc lập trình đã bắt đầu. Khi đó, việc bổ sung một yêu cầu mới có thể không chỉ tạo thêm một chức năng mà còn ảnh hưởng đến dữ liệu, giao diện hoặc luồng xử lý đã được xây trước đó.

Ví dụ, yêu cầu “quản lý đơn hàng” ban đầu có thể chỉ được ước tính với các chức năng tạo và cập nhật đơn. Sau đó doanh nghiệp mới phát hiện cần phân quyền theo chi nhánh, kiểm tra tồn kho theo thời gian thực và xử lý nhiều trạng thái giao hàng. Khối lượng công việc lúc này đã khác đáng kể so với phạm vi ban đầu.

Phân tích yêu cầu là gì?

Thay đổi có thể phát sinh trong quá trình phát triển phần mềm, đặc biệt khi yêu cầu hoặc bối cảnh kinh doanh được làm rõ thêm. Rủi ro tăng khi một yêu cầu mới được thêm vào nhưng ảnh hưởng đến thời gian, ngân sách và phạm vi không được đánh giá tương ứng.

Một yêu cầu nhìn có vẻ nhỏ, chẳng hạn thêm một trạng thái mới cho đơn hàng, có thể kéo theo thay đổi ở cơ sở dữ liệu, màn hình quản lý, thông báo, báo cáo và kiểm thử. Nếu chỉ nhìn vào phần chức năng hiển thị ra ngoài, doanh nghiệp dễ đánh giá thấp khối lượng công việc thực tế.

Vì vậy, trước mỗi thay đổi, cần xem xét ít nhất ba câu hỏi: thay đổi này ảnh hưởng đến phần nào của hệ thống, cần thêm bao nhiêu công việc và có cần điều chỉnh ưu tiên hoặc thời hạn hay không.

Khi việc thay đổi được ghi nhận và đánh giá rõ ràng, doanh nghiệp có thể chủ động lựa chọn giữa thêm chức năng, lùi một phần khác sang giai đoạn sau hoặc điều chỉnh ngân sách.

Khi xác định phạm vi phiên bản đầu tiên, doanh nghiệp có thể nhận thêm nhiều yêu cầu từ các bộ phận liên quan. Nếu các yêu cầu này được bổ sung mà không đánh giá lại phạm vi, tiến độ và ngân sách, khối lượng công việc có thể tăng so với kế hoạch ban đầu.

Không phải mọi chức năng hữu ích đều cần được xây ngay. Phiên bản đầu tiên nên tập trung vào những chức năng cần thiết để giải quyết bài toán chính và đủ để doanh nghiệp đưa hệ thống vào sử dụng thực tế.

Ví dụ, một hệ thống quản lý đơn hàng có thể cần tạo đơn, kiểm tra tồn kho, cập nhật trạng thái và theo dõi xử lý ngay từ đầu. Báo cáo nâng cao, tùy chỉnh sâu hoặc nhiều loại tự động hóa có thể được triển khai sau khi quy trình cốt lõi đã được kiểm chứng.

Việc chia phạm vi thành từng giai đoạn có thể làm giảm khối lượng cần đầu tư cho phiên bản đầu tiên và tạo cơ hội kiểm chứng nhu cầu trước khi mở rộng. Tuy nhiên, tổng chi phí của toàn bộ sản phẩm vẫn phụ thuộc vào phạm vi, số lần thay đổi và cách triển khai các giai đoạn sau.

Phần mềm có sẵn hay phát triển riêng?

Một báo giá thấp chưa chắc đồng nghĩa với tổng chi phí thấp. Nếu phạm vi, điều kiện thay đổi, cách kiểm thử, bàn giao hoặc hỗ trợ sau phát hành chưa được làm rõ, phần chi phí chưa nhìn thấy có thể xuất hiện trong quá trình triển khai.

Khi so sánh phương án phát triển, doanh nghiệp nên nhìn vào phạm vi được bao gồm trong báo giá: phân tích yêu cầu có nằm trong dự án hay không, bao nhiêu vòng chỉnh sửa được tính, kiểm thử được thực hiện ở mức nào, dữ liệu có cần chuyển đổi và sau khi phát hành ai chịu trách nhiệm xử lý lỗi.

Hai báo giá có thể chênh nhau đáng kể vì phạm vi công việc, điều kiện và sản phẩm bàn giao khác nhau. Nếu chỉ so sánh con số cuối cùng, doanh nghiệp có thể bỏ sót những khác biệt này.

Điều cần quan tâm không chỉ là “giá bao nhiêu”, mà là “với mức giá này, doanh nghiệp thực sự nhận được những gì và phần nào có thể phát sinh thêm”.

Tổng chi phí của một dự án hoặc vòng đời hệ thống có thể bao gồm nhiều công việc ngoài lập trình, tùy phạm vi hợp đồng và nhu cầu thực tế. Ví dụ có thể gồm kiểm thử, triển khai lên môi trường vận hành, chuyển dữ liệu, hướng dẫn người dùng và hỗ trợ sau phát hành.

Nếu những công việc này không được tính từ đầu, doanh nghiệp có thể gặp thêm chi phí ngay khi tưởng rằng dự án đã gần hoàn thành.

Chi phí bảo trì cũng cần được xem xét trong vòng đời hệ thống. Khi môi trường vận hành, quy trình kinh doanh hoặc dịch vụ bên ngoài thay đổi, phần mềm có thể cần được cập nhật. Việc thiếu tài liệu hoặc phụ thuộc nhiều vào kiến thức của một cá nhân có thể làm việc bảo trì và sửa đổi sau này phức tạp hơn.

Vì vậy, trước khi bắt đầu, doanh nghiệp nên làm rõ phạm vi kiểm thử, cách bàn giao mã nguồn và tài liệu, thời gian bảo hành, hình thức hỗ trợ sau phát hành và trách nhiệm của từng bên.

Trước khi phát triển, doanh nghiệp nên thống nhất bài toán cần giải quyết, người dùng chính, quy trình, yêu cầu cốt lõi và phạm vi phiên bản đầu tiên. Trong quá trình triển khai, mỗi thay đổi quan trọng nên được đánh giá về ảnh hưởng đến phạm vi, tiến độ và ngân sách trước khi thực hiện.

Các mốc kiểm tra theo từng giai đoạn có thể giúp phát hiện sai lệch sớm hơn. Việc xem mẫu thử, bản phát triển trung gian hoặc kết quả sau từng phần nhỏ tạo cơ hội điều chỉnh trước khi phạm vi làm lại tăng lên.

Tại Fenix, phạm vi và yêu cầu được làm rõ trước khi phát triển và tiếp tục được theo dõi trong suốt dự án. Khi có thay đổi, ảnh hưởng đến công việc và ưu tiên được trao đổi trước để doanh nghiệp có thể đưa ra quyết định dựa trên thông tin rõ ràng, thay vì chỉ nhìn thấy chi phí khi công việc đã phát sinh.

Xem dịch vụ phát triển hệ thống của Fenix

Chi phí phát triển phần mềm tăng ngoài dự kiến thường không đến từ một nguyên nhân duy nhất. Phạm vi mơ hồ, thay đổi không được kiểm soát, phiên bản đầu tiên quá lớn hoặc những công việc sau phát triển chưa được tính đến đều có thể làm ngân sách tăng dần.

Việc xác định rõ phạm vi, ưu tiên và đánh giá tác động của thay đổi tạo thêm cơ sở để theo dõi ngân sách và giải thích vì sao chi phí thay đổi trong quá trình triển khai.

Nếu phạm vi hiện tại vẫn khó ước tính hoặc báo giá giữa các phương án chênh lệch lớn, đó có thể là dấu hiệu cho thấy yêu cầu, phạm vi hoặc các giả định trong từng phương án cần được làm rõ thêm trước khi quyết định bắt đầu phát triển.