Tự học PM

A fine WordPress.com site

Archive for the ‘90. Glossary’ Category

Padding – Vấn đề đáng suy nghĩ.

leave a comment »

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.

Image

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 (Oppoturnities).

———————————————————————————————————

Dưới đây là một bài sưu tầm trên Internet về Padding:

MANAGING PADDING IN TIME ESTIMATES

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?

Suy nghĩ sâu hơn thì một câu hỏi rất nghiêm trọng phát sinh:
Việc trao đổi ý kiến, quan điểm trong tổ chức của bạn (team member với bạn, bạn với management) một cách trung thực hay không? Hay là mọi người đều đang cố gắng lừa dối nhau?

http://pmstories.com/2007/09/14/managing-padding-in-time-estimates/

Advertisements

Written by hoantv

June 17, 2013 at 5:48 pm

Delphi technique là gì?

leave a comment »

Chẳng cần thiết vì ít áp dụng kỹ thuật này, nhưng nay trong khi discussion với các bạn thì có vẻ mình chưa hài lòng với kết quả lắm, nên đã lên mạng hỏi anh google tí.

Tóm lại, Kỹ thuật Delphi là một kỹ thuật lấy ý kiến của một nhóm chuyên gia có các đặc trưng sau:

  1. Những người tham gia không nhất thiết phải biết nhau.
  2. Có thể tham gia một cách ẩn danh (anonymously), kiểu như bỏ phiếu kín, không ai biết ý kiến của ai.
  3. Không phải nhất thiết cùng có mặt ở một địa điểm theo kiểu mặt đối mặt.

Image

Ưu điểm: tránh được yếu tố tâm lý (tâm lý đám đông; tâm lý nể nang đồng nghiệp, sợ hãi cấp trên,…)

Nhược điểm: chậm, thậm chí rất khó nhận được ý kiến trả lời.

—————————————————————————–

Ngoài lề: Tên Delphi được xuất phát từ một Thánh địa của Delphi, vùng Parnassus ở Hy Lạp, nơi có một Nhà tiên trị rất giỏi. Năm 1969, thời kỳ bắt đầu Chiến tranh lạnh (Cold War), khi nghiên cứu dự báo tình hình KT-XH Mỹ đến năm 2000, hai nhà khoa học Mỹ là O.Helmer và D.Gordon đã sử dụng phương pháp điều tra này, và sau đó phương pháp này được đặt tên là phương pháp Delphi. Ở PMBok gọi là Delphi technique.

250px-Delphi_Composite

Written by hoantv

June 14, 2013 at 5:15 pm

Posted in 90. Glossary

Rule of thumb (Quy tắc ngón tay cái)

leave a comment »

Quy tắc này giống một quy tắc có tên gọi tiếng Anh là Heurestic, là kỹ thuật dựa vào kinh nghiệm (experience-based technique) để giải quyết vấn đề, nghiên cứu hoặc khám phá. Chính vì chủ yếu dựa vào kinh nghiệm nên kỹ thuật này không đảm bảo tính chính xác trong tất cả tình huống.

Trong Rita có quy tắc 80/20 về chất lượng cũng là dạng “Rule of thumb”. Ngoài ra thì theo mình có rất nhiều quy tắc tương tự, chẳng hạn như quy tắc 8/80 ở phân rã (decomposition) work package.

Xem thêm:

1. http://en.wikipedia.org/wiki/Rule_of_thumb

2. http://en.wikipedia.org/wiki/Heuristic

Written by hoantv

June 12, 2013 at 5:24 pm

Posted in 90. Glossary