Trong mọi dự án thì đều có những phần mà chúng ta biết và phần không biết, gọi là Knowns và UnKnowns. Đại khái là 2 phần này được tổ chức như hình dưới.

Cái mà thuộc nhóm “Knowns Knowns” thì là những cái đã có trong kế hoạch của PM rồi.

Nhưng vấn đề rắc rối là ở những cái còn lại, vấn đề thêm thời gian, chi phí (padding) vào chính là những chỗ này. Hay nói cách khác, padding thường xảy ra như là một phản ứng tự nhiên ở những chỗ mà PM/ team member chưa biết rõ ràng.

Điều này dẫn đến hệ quả là gì? Chính là dẫn đến các rủi ro, cơ hội đã bị che dấu đi, việc mà đáng lẽ ra người estimate cần phải nhận diện rõ ràng công khai cho PM biết.

Không thể đòi hỏi một dự án phải biết hết mọi thứ ở một thời điểm (nhất là khi tạo kế hoạch), nhưng nguyên tắc chung là phải đảm bảo tất cả những phần chưa biết đều phải được nghiên cứu, phân tích kỹ lượng, dự phòng thông qua tiến trình quản lý rủi ro (Risk Management Process). Thông qua tiến trình quản lý rủi ro, những phần chưa biết sẽ được nhìn nhận, đánh giá như những điểm xấu (Threats), hoặc thậm chí là cơ hội tốt (Oppotunities).

Quản lý padding trong lập dự toán phần mềm như thế nào?

Một trong những công việc “khó nhằn”, mà cũng dễ mắc sai lầm nhất của PM trong giai đoạn tạo schedule là estimate thời gian.

Trong thực tế, hầu hết developer hoặc PM đều có xu hướng add thêm thời gian vào các estimate của họ, và vấn đề này gọi là “Padding”.

Có 2 nguyên nhân dẫn đến vấn đề này:

1. Do sức ép từ phía management là hãy rút ngắn duration của dự án, điều này dẫn đến việc rút ngắn schedule một cách không khả thi. Đôi khi (thường là do những người trẻ, thiếu kinh nghiệm) cứ bị cuốn theo luồng của sức ép tôi ưu này và tạo ra các estimate không khả thi. Là PM, có vẻ bạn cũng đã biết điều này. Và sau đó, khi tạo schedule, bạn thường add thêm một tỷ lệ % nào đó (ví dụ 10%, 15%, 20%,…) để tạo một cảm giác gọi là an toàn, kể cả là khi phía management đã rút ngắn schedule của bạn rồi.
2. Khác hẳn nguyên nhân trên, bây giờ member của bạn đều là những người có đủ kinh nghiệm, nhưng cũng chính vì lẽ này mà mà họ đã estimate cho cả việc phía management cắt giảm estimate của họ đi. Sau khi estimate thì họ tự thêm “padding” vào và làm cho estimate của họ trở lên dài hơn (không khả thi). Bằng cách này thì họ muốn chắc chắn là sau khi bạn (PM) và phía management rút ngắn schedule thì họ vẫn đủ khả năng để hoàn thành nhiệm vụ của mình.
    

Các câu hỏi cần PM trả lời được trong vấn đề này là:

1. PM có biết team member tạo esimate như thế nào không?
2. PM có thể phán đoán là estimate của team member chính xác hay không?
3. PM có biết họ đã estimate duration của các task một cách tối ưu rồi, hãy là họ đã thêm thời gian dự phòng (padding) vào rồi?
4. PM có tinh chỉnh, chỉnh sửa estimate của team member không?
5. Bạn có thêm padding khi biết rằng management sẽ rút ngắn schedule và đặt bạn vào một “Impossible Mission”? Hoặc thậm chí bạn tự rút ngắn schedule khi bạn biết là team member của bạn đã thêm thời gian dự phòng (padding) rồi?
    

Tìm hiểu thêm: Khác nhau giữa Padding và Buffer trong quản lý rủi ro dự án

Nguồn: TIGO Solutions