INFOCHIEF ACADEMY · IT PROJECT MANAGEMENT KNOWLEDGE SERIES
Phân rã phạm vi bằng WBS: Chuyển yêu cầu dự án thành các gói công việc có thể quản lý.
WBS đưa phạm vi lớn xuống các gói công việc có thể giao, ước lượng và kiểm tra. Ranh giới rõ, phần việc đầy đủ và điều kiện hoàn thành giúp dự án nhìn thấy những khoảng trống giữa yêu cầu và thực hiện.
Biên soạn: Infochief Academy · Chuyên đề: Quản lý dự án IT
“Làm phần tích hợp” nghe như một nhiệm vụ, nhưng thường chứa nhiều công việc chưa ai nhận. Trong một ví dụ giả định, nhóm phần mềm hoàn tất giao diện kết nối rồi phát hiện bên nghiệp vụ chưa thống nhất quy tắc dữ liệu. Đội kiểm thử lại chưa có môi trường phù hợp. Cả ba phần đều được xem là tích hợp, nhưng không có ranh giới đủ rõ để biết ai phải cung cấp đầu vào cho ai.
Work Breakdown Structure, gọi tắt là WBS, là cấu trúc phân rã công việc theo cấp để làm rõ toàn bộ phần việc cần thực hiện. Nó giúp đưa yêu cầu lớn xuống những gói có thể giao, ước lượng và kiểm tra. Một WBS tốt không phải danh sách càng dài càng tốt; nó phải khiến khoảng trống và phần chồng lấn trở nên nhìn thấy được.
Bắt đầu từ sản phẩm phải có, rồi xác định công việc tạo ra nó
Yêu cầu nghiệp vụ thường được viết theo điều người sử dụng muốn làm. Để phân rã, cần xác định sản phẩm hoặc năng lực cụ thể phải bàn giao để đáp ứng yêu cầu ấy. Với tích hợp đơn hàng, sản phẩm có thể bao gồm giao diện, quy tắc ánh xạ dữ liệu, cơ chế xử lý ngoại lệ và bằng chứng kiểm tra. Chỉ ghi một hạng mục “API hoàn thành” có thể bỏ qua những phần thiết yếu còn lại.
APM phân biệt cấu trúc sản phẩm, mô tả đầu ra, với WBS, mô tả công việc để tạo ra đầu ra. Trong thực hành, người quản lý có thể bắt đầu từ các nhóm sản phẩm rồi phân rã những phần việc cần thiết. Điều quan trọng là cách chia phải giúp kiểm soát phạm vi, không biến thành một sơ đồ tổ chức hoặc một bản lịch có ngày tháng.
Cần chọn một nguyên tắc phân nhóm nhất quán ở mỗi cấp. Nếu cùng cấp vừa chia theo chức năng, vừa chia theo phòng ban và giai đoạn, một công việc dễ xuất hiện ở nhiều nhánh. Ví dụ, kiểm thử tích hợp có thể bị ghi cả dưới nhóm phát triển lẫn nhóm chất lượng. Khi tổng hợp nguồn lực và chi phí, sự trùng lặp này sẽ làm sai dự báo.
Năng lực quản lý dự án IT giúp nối yêu cầu, sản phẩm và công việc thành một cấu trúc sử dụng được. Tuy nhiên, phân nhóm ban đầu chỉ là khung. Đội dự án cần rà soát những phần việc ít lộ diện trong bản mô tả chức năng trước khi tin rằng phạm vi đã đầy đủ.
Đưa những phần việc thường bị bỏ quên vào cùng cấu trúc
Dự án IT không chỉ có lập trình hoặc cài đặt. Làm sạch dữ liệu, chuẩn bị quyền truy cập, dựng môi trường, đào tạo và chuyển giao đều có thể cần thiết. Công việc quản lý, kiểm soát thay đổi và phối hợp nhà cung cấp cũng tiêu tốn năng lực. Nếu không được đưa vào phần việc có kế hoạch, chúng sẽ xuất hiện như những nghĩa vụ thêm vào khi lịch đã chật.
Rà soát phạm vi nên đi qua hành trình sử dụng của sản phẩm. Từ lúc dữ liệu được tạo, đi qua các hệ thống, đến lúc người dùng xử lý ngoại lệ và đội vận hành hỗ trợ, mỗi điểm cần hỏi sản phẩm nào phải có và việc nào tạo ra nó. Cách xem theo điểm bàn giao thường phát hiện thiếu sót tốt hơn việc chỉ hỏi mỗi trưởng nhóm đã liệt kê đủ việc của mình chưa.
Các giao diện với bên ngoài cần được ghi rõ. Nhà cung cấp chịu trách nhiệm cấu hình chưa chắc chịu trách nhiệm chuẩn bị dữ liệu hay kiểm tra nghiệp vụ. Phần việc của doanh nghiệp vẫn phải xuất hiện trong WBS, cùng điều kiện nhận sản phẩm từ đối tác. Một hợp đồng bao quát không thay thế việc phân định trách nhiệm ở cấp có thể điều hành.
Tư duy tiếp nhận trong chương trình Quản Lý Dịch Vụ IT – ITSM giúp nhìn thấy công việc phục hồi, giám sát và hỗ trợ sau triển khai. Khi những phần này đã có vị trí, dự án phải quyết định mức phân rã nào đủ để quản lý mà không tạo gánh nặng cập nhật không cần thiết.
Dừng phân rã khi gói công việc có thể được giao và kiểm chứng
Không có một số cấp cố định phù hợp mọi dự án. Một gói nên đủ rõ để ước lượng, giao trách nhiệm và xác nhận hoàn thành. Nếu trong cùng gói có nhiều sản phẩm thuộc các đội khác nhau với điều kiện hoàn tất khác nhau, cần cân nhắc chia tiếp. Nếu chia nhỏ đến mức theo dõi từng thao tác mà không giúp quyết định, cấu trúc có thể đã quá chi tiết.
Đối với một phần việc gần triển khai, đội có thể phân rã sâu hơn so với phần còn nhiều bất định. Phần ở xa vẫn cần được thể hiện để không mất phạm vi, nhưng ghi rõ giả định và thời điểm làm chi tiết. Cách lập kế hoạch cuốn chiếu này cho phép tăng độ chính xác theo thông tin mới. Nó không cho phép bỏ hẳn phần công việc chưa biết khỏi bức tranh tổng thể.
Gói “kiểm thử tích hợp” cần được xem xét nếu bao gồm cả chuẩn bị dữ liệu, thực hiện kịch bản và sửa lỗi thuộc nhiều người. Có thể tách phần chuẩn bị khỏi phần kiểm tra, đồng thời chỉ rõ điều kiện nhận đầu vào. Ngược lại, một nhóm thao tác nhỏ cùng người thực hiện và cùng bằng chứng hoàn tất có thể giữ trong một gói để dễ điều hành.
Mức chi tiết cũng phải phù hợp với nhịp kiểm soát. Một gói kéo dài qua nhiều kỳ báo cáo mà không có kết quả trung gian sẽ khó nhận biết sai lệch. Người quản lý có thể chia nhỏ hoặc xác định điểm kiểm chứng bên trong. Sau quyết định này, tên gói vẫn chưa đủ; cần một bản mô tả làm rõ nội dung được giao.
Dùng từ điển WBS để chốt ranh giới và điều kiện hoàn thành
Từ điển WBS là phần mô tả đi kèm các gói, giải thích điều mà sơ đồ không thể hiện hết. Nội dung thực hành nên có mã gói, sản phẩm, phần bao gồm và loại trừ, người chịu trách nhiệm, đầu vào và điều kiện chấp nhận. Những giả định quan trọng cũng cần được giữ ở đây hoặc liên kết đến nơi theo dõi. Mục tiêu là giảm khác biệt trong cách hiểu khi giao việc.
Bảng sau minh họa cách kiểm tra một gói công việc. Đây là ví dụ giả định về tích hợp đơn hàng, không phải mẫu bắt buộc cho mọi hệ thống.
| Thành phần mô tả | Nội dung minh họa | Câu hỏi cần xác nhận |
|---|---|---|
| Sản phẩm | Quy tắc ánh xạ dữ liệu đơn hàng | Ai xác nhận đúng nghĩa nghiệp vụ? |
| Bao gồm | Trường dữ liệu và cách xử lý giá trị thiếu | Có đủ các trường đã thống nhất chưa? |
| Loại trừ | Thay đổi quy trình tạo đơn ở hệ thống nguồn | Phần loại trừ có người quản lý riêng không? |
| Đầu vào | Mô tả dữ liệu và ví dụ đã đối soát | Đầu vào có sẵn trước khi làm không? |
| Hoàn thành | Quy tắc được kiểm tra trên kịch bản đã duyệt | Bằng chứng được lưu ở đâu? |
Điểm quan trọng trong ví dụ không phải mã hay hình thức bảng. Việc tách quy tắc dữ liệu khỏi thay đổi hệ thống nguồn giúp biết chỗ nào phải phối hợp và ai có quyền quyết định. Nếu phần loại trừ lại là điều kiện để giao diện sử dụng được, nó phải được quản lý ở một gói khác hoặc xử lý bằng thay đổi phạm vi. Không được dùng mục loại trừ để làm biến mất một nghĩa vụ thiết yếu.
Sự tham gia của người giám sát nhóm IT giúp kiểm tra khả năng giao và nhận công việc ở cấp thực hiện. Người nhận gói nên tham gia hoàn thiện mô tả thay vì chỉ được thông báo sau khi lịch và chi phí đã chốt. Sự xác nhận này tạo nền tảng để ước lượng sát điều kiện hơn.
Nối WBS với lịch, chi phí và thay đổi mà không trộn các công cụ
WBS trả lời công việc thuộc phạm vi nào; lịch trả lời công việc diễn ra khi nào và phụ thuộc điều gì. Các hoạt động trong lịch nên có thể liên kết về gói tương ứng. Một gói có thể cần nhiều hoạt động, nhưng tổng các hoạt động phải phản ánh đủ nội dung được giao. Đừng dùng thứ tự nhánh trên sơ đồ WBS để suy ra thứ tự thực hiện.
Mã gói cũng giúp tổng hợp nỗ lực và chi phí. Khi một yêu cầu mới xuất hiện, người quản lý có thể xác định nó tác động vào gói nào, cần thêm việc gì và làm thay đổi điều kiện chấp nhận ra sao. Nếu cấu trúc được dùng nhất quán, báo cáo phạm vi, lịch và ngân sách sẽ dễ đối chiếu hơn. Không nhất thiết phải dùng phần mềm phức tạp để đạt sự nhất quán đó.
Việc cập nhật WBS cần theo cơ chế quản lý phạm vi. Một yêu cầu đã được duyệt có thể dẫn đến gói mới hoặc sửa gói hiện có. Phải giữ dấu vết về lý do, phiên bản và tác động. Nếu người thực hiện tự thêm việc rồi chỉ sửa cấu trúc sau khi hoàn thành, dự án vẫn bị mở rộng ngoài kiểm soát dù sơ đồ cuối cùng rất đầy đủ.
Ở cấp điều hành, chương trình Giám Đốc Dự Án IT nhấn mạnh trách nhiệm nối phần việc với mục tiêu và quyền quyết định. WBS phục vụ trách nhiệm đó bằng cách làm rõ nơi phát sinh cam kết. Nó không thay thế cơ chế phê duyệt, nhưng giúp quyết định có căn cứ cụ thể hơn.
Thử độ đầy đủ bằng một cuộc rà soát điểm bàn giao
Trước khi đưa cấu trúc vào sử dụng, hãy chọn một sản phẩm quan trọng và đi qua những điều kiện cần để nhận nó. Có gói nào tạo ra từng đầu vào, có người xác nhận từng kết quả và có phần việc đưa sản phẩm vào sử dụng không? Đối chiếu các gói cùng cấp để phát hiện chồng lấn; đối chiếu với phạm vi cấp trên để phát hiện bỏ sót. Đây là một cuộc kiểm tra thực chất, không chỉ rà số thứ tự.
Với ví dụ mở bài, hãy tách giao diện, quy tắc dữ liệu và môi trường kiểm thử thành những phần có chủ sở hữu phù hợp. Sau đó ghi quan hệ nhận đầu vào trong lịch, thay vì để mọi thứ nằm trong một mục tích hợp. Kết quả kỳ vọng là đội biết cần chốt điều gì trước khi bắt đầu và xác nhận điều gì trước khi báo hoàn thành.
Một WBS sử dụng được khiến cuộc trao đổi chuyển từ “phần này gần xong” sang “sản phẩm này còn thiếu đầu vào hoặc bằng chứng nào”. Khi có thông tin mới, cấu trúc được điều chỉnh có kiểm soát để phản ánh phạm vi thật. Đó là cách người quản lý giữ công việc nhìn thấy được mà không biến dự án thành một danh sách thao tác vô tận.