Hỏi về nguyên tắc 8/80 trong tạo WBS?

nghiavt

Well-known member
Khi đọc trong Scope (KA) đoạn Create WBS mình phân rã project ra nhiều phần tính năng, smaller task để có thể đánh giá nỗ lực dự án.

Mức nhỏ nhất mà bạn break theo nguyên tắc 8/80. Nhờ anh chị giải thích dùm nguyên tắc này :-?. Lý do tại sao phải dùng nguyên tắc này?
 

duongnt

Well-known member
Khi đọc trong Scope (KA) đoạn Create WBS mình phân rã project ra nhiều phần tính năng, smaller task để có thể đánh giá nỗ lực dự án.

Mức nhỏ nhất mà bạn break theo nguyên tắc 8/80. Nhờ anh chị giải thích dùm nguyên tắc này :-?. Lý do tại sao phải dùng nguyên tắc này?
Nếu ko có nguyên tắc này thì Phân rã WBS cho đến bao giờ, tùy vào dự án khi phân rã biết được cần thiết lúc nào là có thể estimate đuoc cost,schedule, reource 1 cách dễ dàng,còn khó quá thì cứ theo nguyên tắc
 

hoadn

Nhà truyền đạo
Không rõ cái KA của bác có nghĩa là gì.
Thực tế thì trong PMBOK cũng không nói việc chia nhỏ xuống tới mức nào thì dừng lại. Tùy từng dự án thì mức độ chia nhỏ khác nhau, tuy nhiên hầu hết các PM sử dụng nguyên tắc 8/80. Đây là dạng rule of thumb
Theo nguyên tắc 8/80 thì các Work package có thời gian hoàn thành không nên nhỏ hơn 8 tiếng và không nên lớn hơn 80 giờ.
Khi quyết định mức độ chi tiết của các work package, chúng ta nên cần thận và không nên để quá chi tiết. Điều này sẽ dẫn tới hậu quả của micromanage cho dự án và sẽ làm chậm tiến độ của dự án. Ngược lại nếu quá rộng, hoặc quá lớn thì PM sẽ khó có thể quản trị dự án một cách tổng thể được.
 

nghiavt

Well-known member
Thanks anh AUbe và Hoadn. Và hiện tại mình đang gặp ở thực tế là với 1 task: develop tính năng A, PM chưa có kinh nghiệm về lĩnh vực này:
-- Hỏi anh experience Dev anh ta nói là mất 8 mandays,
-- Hỏi anh team leader 10 mandays
-- hỏi expert thì đánh giá là 12 mandays

Và ông đang tính là trung bình (10 + 8 + 12) / 3 để đưa vào nỗ lực dự án. Còn các anh chị thì tính effort này như thế nào trong t/h này?
 

thebao

Active member
Theo tớ thì áp dụng PERT (O + 4M + P) ÷ 6

(8+4x10+12)÷ 6 = 10 ngày :-?

Goodluck

Thanks anh AUbe và Hoadn. Và hiện tại mình đang gặp ở thực tế là với 1 task: develop tính năng A, PM chưa có kinh nghiệm về lĩnh vực này:
-- Hỏi anh experience Dev anh ta nói là mất 8 mandays,
-- Hỏi anh team leader 10 mandays
-- hỏi expert thì đánh giá là 12 mandays

Và ông đang tính là trung bình (10 + 8 + 12) / 3 để đưa vào nỗ lực dự án. Còn các anh chị thì tính effort này như thế nào trong t/h này?
 

luckyluke

Well-known member
Khi tạo WBS cũng nên xây dựng 1 hệ thống WAS (Work Authorization System) thật tốt, nếu không sẽ dẫn đến Gold Plating.

Thí dụ trong lĩnh vực CNTT thì thường mình chia task nhỏ nhất là 4 hours. Đặc thù của sản xuất phần mềm là có những lỗi có thể mất cả ngày thậm chí là nhiều ngày mới fix xong! Tuy nhiên vẫn luôn có những task chỉ mất 4 hours nhưng tầm quan trọng của nó lại rất lớn, không thể xem thường. Do vậy nguyên tắc 8/80 chỉ là nhắc nhở PM về mức độ cảnh báo. Task càng nhiều hours thì cần nâng mức cảnh báo và xem xét phân rã tiếp để đạt được mức hợp lý tốt hơn. Cơ sở của ý tưởng 8/80 là bạn không muốn theo dõi bất cứ việc gì chỉ mất chưa đến một ngày để hoàn thành và nếu công việc đó đòi hỏi phải mất 10 ngày (80 giờ) để hoàn thành thì có lẽ nên chia nhỏ ra thành nhiều hơn một gói công việc để giám sát được tốt hơn.
 

dauvd

Super Moderator
Khi tạo WBS cũng nên xây dựng 1 hệ thống WAS (Work Authorization System) thật tốt, nếu không sẽ dẫn đến Gold Plating.

Thí dụ trong lĩnh vực CNTT thì thường mình chia task nhỏ nhất là 4 hours. Đặc thù của sản xuất phần mềm là có những lỗi có thể mất cả ngày thậm chí là nhiều ngày mới fix xong! Tuy nhiên vẫn luôn có những task chỉ mất 4 hours nhưng tầm quan trọng của nó lại rất lớn, không thể xem thường. Do vậy nguyên tắc 8/80 chỉ là nhắc nhở PM về mức độ cảnh báo. Task càng nhiều hours thì cần nâng mức cảnh báo và xem xét phân rã tiếp để đạt được mức hợp lý tốt hơn. Cơ sở của ý tưởng 8/80 là bạn không muốn theo dõi bất cứ việc gì chỉ mất chưa đến một ngày để hoàn thành và nếu công việc đó đòi hỏi phải mất 10 ngày (80 giờ) để hoàn thành thì có lẽ nên chia nhỏ ra thành nhiều hơn một gói công việc để giám sát được tốt hơn.
WAS ở chỗ bác làm nó có hình dạng như thế nào vậy ?
 

luckyluke

Well-known member
WAS là 1 hệ thống giám sát công việc, không phải giám sát nhân viên. Đối với các dự án Scrum thì WAS giống như một Scrum Backlog chuyên điều phối các công việc sắp được giao sao cho phù hợp với từng giai đoạn cụ thể, và phải thật khớp với mức độ sẵn có của tài nguyên nhân sự.

Đối với các dự án nhỏ thì mình chỉ sử dụng WAS dưới hình thức verbal trong các daily meeting. Còn đối với dự án lớn thì mình xây dựng document và các công cụ phần mềm quản lý chặt chẽ (bao gồm cả weekly status emails) để đảm bảo không có công việc nào bị trễ so với kế hoạch, cũng như không có công việc nào kết thúc quá sớm, hoặc phát sinh thêm một số kết quả (additional features) không nằm trong danh sách deliverable ban đầu, dẫn đến các vấn đề Scope Creep và Gold Plating.
 

trieuchau

Nhà truyền đạo
Đối với các dự án nhỏ thì mình chỉ sử dụng WAS dưới hình thức verbal trong các daily meeting. Còn đối với dự án lớn thì mình xây dựng document và các công cụ phần mềm quản lý chặt chẽ (bao gồm cả weekly status emails) để đảm bảo không có công việc nào bị trễ so với kế hoạch, cũng như không có công việc nào kết thúc quá sớm, hoặc phát sinh thêm một số kết quả (additional features) không nằm trong danh sách deliverable ban đầu, dẫn đến các vấn đề Scope Creep và Gold Plating.
Điểm này mình thấy áp dụng khá hay ở các dự án nặng tính waterfall/PMP như các dự án xây dựng nhà xưởng mà mình từng tham gia. Standup meeting tất cả các bên liên quan đầu mỗi ngày khoảng 15-20' nhằm quản lý tốt scope, time, cost, risk, quality, communication, ... Thanks bác [MENTION=29651]luckyluke[/MENTION]
 

Agile Project Management

Agile/Scrum

IT Management Professional

Information Technology Management Professional

Facebook

VietPMP Worldwide

vietpmp worldwide counters
Top