Tự học PM

A fine WordPress.com site

Archive for the ‘06. Prj Time Mgt’ Category

Network Diagram Method và áp dụng trong thực tế?

leave a comment »

Theo PMBok thì Network Diagram (còn được gọi là Project Schedule Network Diagram) là một thành phần không thể thiếu trong khi tạo schedule: là output của Sequence Activities process.

Network Diagram chỉ thể hiện các sự phụ thuộc về logic (logical relationship) giữa các hoạt động của dự án.

Phương pháp Network Diagram áp dụng lý thuyết đồ thị có hướng (cấu trúc mạng lưới) vào trong các thuật toán để lập kế hoạch tiến độ và tổ chức thực hiện dự án.

Ví dụ đơn giản sau đây là một Network Diagram:

Image

Có nhiều phương pháp sơ đồ mạng đã được phát triển, dưới đây là một số phương pháp chính hay nhắc đến:

  1. CPM (Critical Path Method): là phương pháp xác định đường đi dài nhất trong network tính từ thời điểm khởi công đến thời điểm kết thúc dự án. Đường đi dài nhất (hay còn gọi là Đường găng) chính là tổng thời gian thực hiện dự án.
  2. PERT (Project Evaluation and Review Technique): là phương pháp áp dụng kết hợp giữa lý thuyết xác suất thống kê (để ước tính thời lượng của công việc) với dạng sơ đồ mạng đường găng (CPM) sử dụng lý thuyết đồ thị.
  3. ADM (Arrow Diagram Method): là phương pháp sơ đồ mạng CPM thể hiện activity bằng mũi tên. Loại này chỉ thể hiện được mối quan hệ FS (Finish to Start).
  4. MPM (Metra Potential Method): là phương phá sơ đồ mạng CPM thể hiện activity bằng nút (node), quan hệ giữa các nút bằng mũi tên (do người Pháp phát triển độc lập với PERT vào năm 1958).
  5. PDM (Precedence Diagram Method): là phương phá sơ đồ mạng CPM thể hiện activity bằng nút (node), quan hệ giữa các nút bằng mũi tên do Mỹ phát triển trên cơ sở cải tiến phương pháp CPM của Hoa Kỳ và MPM của Pháp. Phương pháp này chú trọng đến việc thể hiện tất cả các mối quan hệ trên thực tế giữa các activities mà phương pháp ADM không thể hiện được. Phương pháp PDM là cơ sở thuật toán cho phần mềm Microsoft Project.
  6. CCM (Critial Chain Method): sơ đồ mạng chuỗi găng.

Chi tiết về các phương pháp sơ đồ mạng thì mỗi cái sẽ có một topic riêng.

Quay trở lại về việc áp dụng trong thực tế như thế nào cho hợp lý ở các dự án phát triển phần mềm?

Trong dự án phát triển phần mềm, một trong công việc quan trọng nhất mà chúng ta thường tập trung vào làm rõ trong giai đoạn lập kế hoạch là Xác định phạm vi dự án (Define Scope). Một trong những tài liệu quan trọng phải tạo được ra là WBS (Work Breakdown Structure). Mục chi tiết nhất trên WBS gọi là gói công việc (work package).

Từ WBS này chúng ta sẽ tạo ra được 2 loại sơ đồ, một cái ở mức tổng thể (master) và một cái ở mức chi tiết (detail).

Hình sau mô tả sự mapping giữa WBS và Network Diagram:

Image

Tiếp theo ở giai đoạn tạo schedule, bạn thường phải tạo 2 loại schedule sau mà buộc phải lấy kết quả từ Network Diagram:

  1. Master Schedule
  2. Detail Schedule

Bạn cũng có thể nói là tôi chả bao giờ tạo Network Diagram mà các dự án mà tôi từng làm PM đều thành công đó thôi. Đúng, bạn có thể đúng. Theo tôi lý do bạn đúng bởi vì (1) bạn là người nhiều kinh nghiệm và (2) các dự án đó thường là quy mô nhỏ, ít phức tạp mà thôi.

————————————————-

Chia sẻ thêm: Để mà tạo ra được một tài liệu schedule đầy đủ, chi tiết, và nhất là chính xác ngay từ sớm là việc rất khó vì rất nhiều lý do, đại loại như:

  1. Mức độ rõ ràng của estimate: thời gian đầu rất khó để mọi thứ sẵn sàng cho bạn xơi ngay.
  2. Scope cũng hay bị thay đổi: thêm/bớt/update work package.
  3. Resource cũng không phải sẵn sàng ngay từ đầu.
  4. Change request: cái này cũng hay có trong suốt dự án.
  5. Risk: cái này cũng là một phần tất yếu trong suốt dự án và rất đau đầu.
Advertisements

Written by hoantv

June 20, 2013 at 5:54 pm

Posted in 06. Prj Time Mgt

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/

Written by hoantv

June 17, 2013 at 5:48 pm