Một người phát triển phần mềm viết cho tôi: “Tại sao ước lượng dự án phần mềm thường sai? Tại sao nhiều dự án phần mềm không đáp ứng lịch biểu? Ai nên đặt ra lịch biểu cho dự án?”

Đáp: Ước lượng dự án phần mềm thường không chính xác bởi vì người phát triển có khó khăn với việc ước lượng thời gian được cần để hoàn thành nhiệm vụ của họ. Phần lớn các lí thuyết ước lượng đều giả định rằng người phát triển sẽ dành 100% thời gian làm việc nhưng thực ra có nhiều hoạt động thường chen vào với việc phát triển mà không được tính tới.

Chẳng hạn họp tổ, thảo luận nhóm, và các hoạt động khác của công ti. Những hoạt động bên ngoài này là không thể dự kiến được. Bên cạnh việc viết mã, người phát triển phải gặp gỡ khách hàng để lấy yêu cầu, thiết kế, kiểm thử, viết tài liệu dự án, tham gia vào các buổi kiểm điểm v.v. Tất cả những hoạt động này là khó ước lượng. Cho dù người quản lí có yêu cầu người phát triển tham gia vào những hoạt động này trong ước lượng của họ, cũng không dễ làm. Làm sao bạn ước lượng được thời gian cho việc thảo luận tổ? Bạn có thể ước lượng được bao nhiêu thời gian là cần để kiểm thử mã phần mềm? Có thể là vài phút nếu mã làm việc tốt và qua mọi kiểm thử hay có thể vài ngày mới nhận diện và gỡ lỗi được nếu phần mềm không làm việc tốt.

Nhiều lịch biểu dự án được trao cho người quản lí dự án từ khách hàng. Bạn đã bao giờ hỏi liệu người phát triển có gặp khó khăn gì trong ước lượng thời gian của họ không mà làm sao khách hàng có thể đi tới lịch biểu giao cho họ được? Khách hàng có thể có lí do chính đáng cho lịch biểu vì họ cần sản phẩm phần mềm vào lúc đó, trong trường hợp đó họ phải thảo luận với người quản lí dự án để đi tới bản kế hoạch hợp lí hài hoà với việc phát triển và giảm bớt rủi ro chứ.

Lịch biểu dự án nên được dựa trên ước lượng tốt nhất từ tổ dự án và thương lượng với khách hàng để đi tới lịch biểu hợp lí mà cả tổ dự án và khách hàng có thể đồng ý. Ngay cả với điều đó xảy ra, người quản lí dự án vẫn phải giám sát lịch biểu đã lập kế hoạch và việc thực hiện thực tại để kiểm về bất kì biến thiên lớn này và có hành động sửa chữa để đảm bảo dự án sẽ không bị lỡ lịch biểu đã thoả thuận.

—-English version—-

Project estimates

A software developer wrote to me: “Why software project estimates are often wrong? Why many software projects do not meet schedule? Who should set schedule for the project?

Answer: Software project estimates are often inaccurate because developers have difficulty with estimating the time required to complete their tasks. Most estimation theories assume that developers would spend 100% doing work but in fact there are many activities that often interfere with development work that are not accounted for.

For example team meetings, group discussions, and other company’s activities. These external activities are impossible to predict. In addition to write code, developers have to meet with customers to get requirements, design, test, write project documents, participating in reviews etc. All of these activities are difficult to estimate. Even if manager asks developers to include these activities in their estimates, it is not easy to do. How do you estimate the time for a team discussion? How long can you estimate the time needed to test software code? It can be few minutes if the code works well and passes all tests or it can be few days to identify and debug if the software does not work well.

Many project schedules are given to project managers from customers. Have you ever asked if developers have difficulty in estimate their time how can customers come up with a schedule for them? Customers may have good reason for a schedule because they need the software product by that time, in that case they must discuss with the project manager to come up with a reasonable plan to accommodate the development and reduce risks.

Project schedule should be based on the best estimates from the project team and negotiate with the customers to come up with a reasonable schedule that both project team and customer can agree. Even with that in place, project manager should monitor the planned schedule and actual accomplishment to check for any significant variation and take corrective action to ensure the project will not miss the agreed upon schedule.