Các khóa học đã đăng ký

WBS và Product Backlog: Anh em ruột hay họ hàng xa?

Bài viết gốc: WBS and Product Backlog: Siblings or Distant Cousins?

(Từ www.LeadingAnswers.com của Mike Griffiths)

- Nguyên tắc 1: Phân tách theo kết quả thực hiện và các bên liên quan - Chia nhỏ công việc thành các bước phân phối giá trị nhỏ (hàng tuần).

- Nguyên tắc 2: Thực hiện những bước có tính rủi ro cao trước tiên - Ưu tiên công việc dựa trên rủi ro.

- Nguyên tắc 3: Tập trung vào việc cải thiện các mục tiêu có giá trị nhất của bạn trước tiên – Đồng thời cũng ưu tiên công việc dựa trên giá trị doanh nghiệp.

Người ta tin rằng cấu trúc phân chia công việc (WBS) đã xuất hiện kể từ khi các kim tự tháp được xây dựng ở Ai Cập, và product backlog là phát minh mới của những người trẻ tuổi để có thể lên kế hoạch một cách vội vàng nhưng vẫn chính xác. Tuy nhiên, như mọi sự vật khác, sự thật luôn phức tạp hơn bạn tưởng.

Năm 1957, Kỹ thuật Ước lượng và Đánh giá Chương trình (PERT) được Bộ Quốc phòng Mỹ (DoD) tạo ra và mô tả các nhiệm vụ tạo thành các danh mục định hướng sản phẩm. Tuy nhiên, họ không sử dụng thuật ngữ “cấu trúc phân chia công việc” hay WBS cho đến năm 1962 khi DoD, NASA và ngành hàng không vũ trụ xuất bản một tài liệu về PERT trong đó có mô tả về phương pháp WBS.

Trong khi đó, vào năm 1960, Tom Gilb đã mô tả phương pháp phân phối giá trị tiến hóa của mình (hay gọi tắt là Evo) được chấp nhận rộng rãi để trở thành tiền thân của các phương pháp agile. Evo bao gồm các nguyên tắc như:

 - Nguyên tắc 1: Phân tách theo kết quả thực hiện và các bên liên quan - Chia nhỏ công việc thành các bước phân phối giá trị nhỏ (hàng tuần).

- Nguyên tắc 2: Thực hiện những bước có tính rủi ro cao trước tiên - Ưu tiên công việc dựa trên rủi ro.

- Nguyên tắc 3: Tập trung vào việc cải thiện các mục tiêu có giá trị nhất của bạn trước tiên – Đồng thời cũng ưu tiên công việc dựa trên giá trị doanh nghiệp.

Những ý tưởng này đã trở thành những khái niệm thể hiện trong các hồ sơ theo như phương pháp và khuôn khổ agile ngày nay.

Vì vậy, chúng ta có thể theo dõi các phương pháp cùng một lúc và cũng tự tin rằng những ý tưởng này đã được thiết lập vững chắc từ lâu trước đó. Việc xây dựng các kim tự tháp và các thành phố La Mã đòi hỏi nhiều cấp độ lập kế hoạch, phân rã công việc và phối hợp nhiệm vụ. Có rất ít tranh cãi về việc liệu WBS hay backlog xuất hiện trước vì nó rõ ràng còn nhiều yếu tố khác.

Ngày nay, tiêu chuẩn thực hành PMI cho các cấu trúc phân chia công việc định nghĩa WBS là một phân rã phân cấp (hierarchical decomposition) của toàn bộ phạm vi công việc sẽ được nhóm dự án thực hiện để hoàn thành các mục tiêu của dự án và tạo ra các giao phẩm được yêu cầu.. Hướng dẫn Scrum định nghĩa product backlog là một danh sách theo thứ tự của tất cả mọi tính năng cần thiết về sản phẩm.

Chúng thực sự rất khác nhau ư? Cả hai đều giúp hình thành một khuôn khổ về phạm vi. Tuy nhiên, do cách mà chúng được sử dụng, nhiều người cho rằng chúng khá khác nhau... đó là quan điểm mà tôi muốn thay đổi.

 

 WBS và Backlog. Những điểm giống và khác nhau giữa WBS và Backlog.

Cấu trúc phân chia công việc thường được xác định trước nhất và đi kèm với từ điển WBS (WBS dictionary). Chúng có thể được sử dụng để hình thành báo cáo công việc và hợp đồng. Nếu những giao phẩm này hữu ích cho các dự án của bạn, hãy tạo chúng. Tuy nhiên, chúng ta cũng có thể tạo các giao phẩm tương tự từ một product backlog.

Tuy nhiên, đối với các dự án agile, chúng ta thường không làm như thế vì các môi trường này có xu hướng năng động hơn nên các sản phẩm này sẽ sớm bị lỗi thời hơn. Thay vào đó, chúng ta tạo các kế hoạch phân đoạn (iteration plan), giải phóng các lộ trình và làm việc từ đầu của backlog trong khi product owner quản lý backlog với độ ưu tiên tăng dần và yêu cầu thay đổi. Những giao phẩm này dễ cập nhật hơn khi những thay đổi xuất hiện. Sự khác biệt trong hành động mà chúng ta nhận thấy xuất phát nhiều từ các đặc điểm của môi trường làm việc hơn so với việc sử dụng công cụ WBS hoặc backlog. Cả hai đều giúp chúng ta xác định và phân tích phạm vi.

 

Lợi ích trực quan.

Cả hai đều trực quan và cho phép chúng ta tập trung vào các hạng mục khi nói về chúng. Điều này là rất quan trọng. Mô tả trực quan về công việc cho phép chúng ta làm việc cộng tác hiệu quả hơn. Khi hai người đối mặt với bảng công việc (task board) hoặc sơ đồ WBS, họ có thể hợp tác làm việc cùng nhau, ít xảy ra tranh chấp hơn. Trực quan hóa giúp chúng ta chia sẻ những hiểu biết và tránh những nhầm lẫn chẳng hạn như có hai hạng mục tương tự được coi là cùng một thứ hoặc giả sử một giải pháp phù hợp với hai kịch bản nhưng lại không phải.

 Mô tả phạm vi trực quan cũng cho phép chúng ta làm mờ và nêu bật các hạng mục để chỉ ra loại, quyền sở hữu, rủi ro và trạng thái hoàn thành. Hình dung công việc là một thành phần chính của tư duy tinh gọn. Khi chúng ta hình dung ra một cái gì đó, não chúng ta cũng xử lý thông tin nhanh hơn nhiều so với việc đọc và giải thích thông tin bằng văn bản. Đây là lý do mà chúng ta có biển báo bằng hình ảnh thay vì mô tả để đọc. Đó là sự khác biệt giữa giải mã và hiểu ý nghĩa trong 150 micro giây (khi nhìn biển báo trên đường) so với 6.000 micro giây để đọc:

 

Product Backlogs như một dạng của WBS.

Quyển Tiêu chuẩn thực hành cho các cấu trúc phân chia công việc tái bản lần thứ 3 cho rằng backlog giống như một dạng của WBS. Nhiều người nghĩ rằng chỉ có cấu trúc cây (tree structures) dạng hộp (boxes) và đường (lines) là cấu trúc phân chia công việc, nhưng thực tế chúng có thể có nhiều dạng bao gồm cả backlog dạng bảng hoặc sơ đồ tư duy.

 Tôi có thể tưởng tượng một số người nguyên tắc sẽ hét lên “Không, đó không phải là WBS!” khi tôi đang gõ cái này, nhưng nếu bạn không tin hãy tự mình kiểm chứng. Tiêu chuẩn thực hành cho các cấu trúc phân chia công việc WBS là bản tải xuống miễn phí cho các thành viên PMI.

Tôi tham gia với tư cách là người đánh giá cho tiêu chuẩn và rất hài lòng khi biết nó bao gồm cả phân rã agile scope sử dụng chuỗi sự kiện, tính năng, câu chuyện của người dùng và tác vụ như các yếu tố WBS ứng cử. Một điều khiến tôi bối rối mà tôi hy vọng rằng người đọc bài viết này có thể rút ra được đó là các yếu tố WBS tiềm năng bao gồm sprint (khoảng thời gian tiến hành tất cả các hoạt động cần thiết để sản xuất được một phần tăng trưởng có khả năng chuyển giao được) hay iteration.

Sự nhầm lẫn của tôi bắt nguồn từ định nghĩa của công việc trong phần 2.1 rằng “…công việc đề cập đến kết quả đầu ra, sản phẩm hoặc giao phẩm là thành quả của sự nỗ lực,  nhưng cũng không phải chỉ dựa vào mỗi sự nỗ lực”. Tiếp theo đó, trong phần 2.3.1.1 về các quy tắc của WBS, viết rằng “các yếu tố WBS không bao gồm thời gian hoặc chuỗi các hành động”. Một lần nữa, điều này có vẻ hợp lý.

Tuy nhiên, các ví dụ cho các dự án agile bao gồm WBS với các hạng mục cấp 2 hiển thị “interation 1”, “interation 2”, v.v có chứa công việc. Điều này dường như vi phạm các giao phẩm so với sự nỗ lực của công việc và quy tắc “work and no-time”. Chúng ta không có yếu tố WBS nào gọi là “Tháng Chín” (September), vì vậy tại sao lại phải đưa ra một mốc thời gian tùy ý? Interation chỉ là cấu trúc thời gian và bạn có thể chọn sử dụng chúng hoặc làm việc mà không có chúng như là một tính năng liên tục từ backlog.

 Có vẻ như tôi đang diễn giải công việc, các giao phẩm và quy tắc no-time theo đúng nghĩa đen, giống như tranh luận về phương pháp nào có trước, nhưng đó có lẽ không quan trọng. Nếu có interation rõ ràng có thể giúp bạn chia sẻ kế hoạch của mình và có các cuộc đàm luận có ý nghĩa về phạm vi, thì hãy thực hiện nó. Tôi cho rằng nó sẽ dẫn đến việc tái cấu trúc (refactor) lại WBS thường xuyên khi các tình huống được chuyển đổi giữa các interation khi độ ưu tiên thay đổi và thông lượng thay đổi, nhưng cũng có thể là không.

Quan trọng hơn đó là chúng ta phải hình dung và thảo luận về phạm vi dự án với nhiều bên liên quan khác nhau để hiểu và sửa chữa những hiểu lầm. Tin tốt là product backlog là một hình thức hợp pháp của WBS và chúng giống như anh em ruột hơn là họ hàng xa. Một vài trích dẫn tuyệt vời từ quyển Tiêu chuẩn thực hành WBS nhắc lại giá trị và áp dụng tốt như nhau cho các backlog và lộ trình phát hành:

“WBS cung cấp nền tảng cho sự thể hiện trực quan về phạm vi công việc. . Nghiên cứu chứng minh rằng giao tiếp là một trong những phương pháp quản lý dự án có tác động cao nhất đến thành công của dự án. WBS phục vụ như một cơ chế truyền thông dự án quan trọng giúp truyền đạt phạm vi của dự án thông qua mô tả đồ họa của nó.”

Thông tin liên hệ

Thông tin chuyển khoản
Công ty Cổ phần ATOHA. Ngân hàng Á Châu (ACB). Số tài khoản: 6868 2468, PGD Tân Sơn Nhì, TPHCM.
Đăng ký khóa học
Chọn khóa học phù hợp bằng cách điền thông tin như link bên dưới. Tư vấn viên Atoha sẽ liên hệ anh/chị ngay.
Câu hỏi thường gặp

“Có. Atoha sẽ có chứng nhận hoàn thành chương trình đào tạo dành cho học viên và cung cấp 35 giờ đào tạo bắt buộc (1 trong 3 điều kiện thi lấy chứng chỉ PMP quốc tế)."

“Cả 2. Tài liệu có thể là tiếng Anh hoặc tiếng Việt tùy vào lớp. Atoha có thể đào tạo bằng cả tiếng Anh hoặc tiếng Việt."

“Chưa bao gồm. Học viên sẽ cần đóng phí thi trực tiếp cho viện PMI nếu muốn đăng ký thi, phí thi tham khảo 555usd/non-member và 405usd/member. Tham khảo thêm tại: www.pmi.org"

"Một số khách hàng doanh nghiệp tiêu biểu: Nestle, Colgate-Palmolive, Castrol, Coca-Cola, Suntory Pepsico, Carlsberg, Schneider Electric, GEA, Sonion, Terumo BCT, Lazada, NEC, Apave, Vinamilk, VNG, MB Bank, FE Credit, PTI, Mobifone, VNPT, PV Gas, CJS, MB Ageas Life, Deha Software, PNJ, Square Group, Delta, Gamma, DSquare, Vascara, FECON, VNT19, Vingroup (HMS),.."

Liên hệ ngay với Atoha để được tư vấn về chương trình phù hợp