Mở đầu — vì sao bài này quan trọng
Bạn có bao giờ rơi vào tình huống này chưa: đến ngày deadline, một hạng mục quan trọng vẫn chưa ai đụng vào, và khi bạn hỏi thì cả nhóm đùn đẩy — "Em tưởng anh A làm", "Không, chị B mới là người phụ trách chứ". Hoặc ngược lại, hai người cùng làm một việc, ra hai bản khác nhau, cãi nhau xem bản nào đúng. Đó chính là căn bệnh kinh điển của quản lý nguồn lực: vai trò và trách nhiệm không rõ ràng.
Trong PMP, Resource Management (Quản lý Nguồn lực) không chỉ nói về con người mà cả nguồn lực vật chất (thiết bị, vật tư, cơ sở hạ tầng). Nhưng ở bài này, chúng ta tập trung vào hai công cụ thực chiến nhất mà một PM dùng gần như hàng tuần: RACI Matrix để phân định vai trò con người, và Resource Histogram để nhìn thấy tải công việc của đội theo thời gian. Hai công cụ này bổ trợ cho nhau: RACI trả lời câu hỏi "AI làm gì", còn Histogram trả lời "làm BAO NHIÊU và KHI NÀO thì quá tải".
Trong kỳ thi PMP, đây là kiến thức xuất hiện dày đặc trong nhóm câu hỏi về Resource Management và về nguyên tắc Stewardship của người dẫn dắt đội. Hiểu chắc hai công cụ này, bạn vừa trả lời tốt câu hỏi thi, vừa quản lý dự án thực tế trơn tru hơn rất nhiều.
Khái niệm cốt lõi
RACI Matrix — bản đồ trách nhiệm
RACI (còn gọi là Responsibility Assignment Matrix — RAM) là một bảng ma trận: cột dọc là các đầu việc/deliverable, cột ngang là các cá nhân hoặc vai trò trong dự án. Ở mỗi ô giao nhau, ta điền một trong bốn chữ cái:
- R — Responsible (Người thực thi): người trực tiếp làm ra công việc. Một đầu việc có thể có nhiều R (nhiều người cùng làm).
- A — Accountable (Người chịu trách nhiệm cuối): người phải trả lời "được hay không được" cho kết quả, người phê duyệt và gánh hậu quả. Quy tắc vàng: mỗi đầu việc chỉ được có ĐÚNG MỘT chữ A. Nếu có hai A, không ai thực sự chịu trách nhiệm. Nếu không có A, công việc sẽ trôi nổi.
- C — Consulted (Người được tham vấn): người có chuyên môn hoặc quyền lợi, được hỏi ý kiến TRƯỚC khi ra quyết định. Đây là giao tiếp hai chiều — có trao đổi, phản hồi qua lại.
- I — Informed (Người được thông báo): người cần biết kết quả nhưng không tham gia quyết định. Giao tiếp một chiều — chỉ nhận thông tin.
Các biến thể của RACI
Thực tế có nhiều biến thể để phù hợp bối cảnh:
- RASCI / RACI-S: thêm S — Support (Hỗ trợ), tách người hỗ trợ ra khỏi người làm chính. Ví dụ dev viết code (R) nhưng cần DevOps hỗ trợ triển khai (S).
- RACI-VS: thêm V — Verify (người kiểm tra kết quả đạt tiêu chí) và S — Sign-off (người ký duyệt cuối).
- CARL, DACI, RAPID: các mô hình phân quyền ra quyết định của một số tổ chức.
Resource Histogram — biểu đồ tải nguồn lực
Resource Histogram là biểu đồ cột thể hiện số giờ (hoặc số người) cần dùng cho một nguồn lực theo từng khoảng thời gian (tuần/tháng). Trục hoành là thời gian, trục tung là khối lượng nguồn lực. Nó cho bạn thấy ngay: tuần này đội cần 200 giờ nhưng chỉ có 160 giờ khả dụng — tức là quá tải (over-allocation).
Đường ngang vẽ trên biểu đồ chính là đường giới hạn năng lực khả dụng (available capacity). Bất kỳ cột nào vượt qua đường này là dấu hiệu cảnh báo. Từ đó ta có hai kỹ thuật xử lý:
- Resource Leveling (San bằng nguồn lực): điều chỉnh lịch khi nguồn lực bị giới hạn cứng — thường kéo dài thời gian dự án, và có thể thay đổi đường găng (critical path).
- Resource Smoothing (Làm mượt nguồn lực): điều chỉnh trong phạm vi float/slack sẵn có, không thay đổi ngày kết thúc dự án và không đụng vào critical path.
Tình huống thực tế
Ví dụ 1 — Công ty fintech Sài Gòn và tấm RACI cứu dự án onboarding
Một startup fintech ở Quận 1, TP.HCM (tạm gọi là VietPay) triển khai tính năng eKYC (định danh khách hàng điện tử). Dự án có 4 bên: đội Backend, đội Mobile, phòng Pháp chế (Legal), và nhà cung cấp OCR bên ngoài. Trong 3 tuần đầu, tính năng liên tục trễ vì đội Mobile chờ Backend, Backend lại chờ Legal duyệt điều khoản lưu trữ dữ liệu sinh trắc học, còn Legal thì "không biết mình phải duyệt gì".
PM lập một RACI đơn giản cho hạng mục "Duyệt điều khoản lưu trữ dữ liệu eKYC":
| Đầu việc | PM | Backend Lead | Mobile Lead | Legal | Nhà cung cấp OCR |
|---|---|---|---|---|---|
| Soạn điều khoản lưu trữ | I | C | I | A/R | C |
| Tích hợp API OCR | A | R | C | I | S |
| Hiển thị luồng eKYC trên app | I | C | A/R | I | I |
Bài học: RACI không tạo ra công việc mới, nó chỉ làm lộ ra khoảng trống trách nhiệm đang ẩn giấu. Một bảng 30 phút giải quyết được thứ mà 3 cuộc họp không gỡ nổi.
Ví dụ 2 — Agency thiết kế Hà Nội và cơn quá tải của designer
Một agency sáng tạo ở Hà Nội có 3 designer, cùng lúc chạy 4 dự án khách hàng. PM ban đầu chỉ nhìn deadline từng dự án nên tưởng mọi thứ ổn. Nhưng khi cô vẽ Resource Histogram cho bạn Linh — designer giỏi nhất, ai cũng muốn giành — kết quả gây sốc:
- Tuần 1: cần 32 giờ (khả dụng 40) — ổn.
- Tuần 2: cần 58 giờ (khả dụng 40) — quá tải 145%.
- Tuần 3: cần 52 giờ — vẫn quá tải.
- Tuần 4: cần 20 giờ — nhàn.
Bài học: Nếu chỉ nhìn danh sách task, bạn không bao giờ thấy được điểm nghẽn nguồn lực theo thời gian. Histogram biến "cảm giác nhóm đang bận" thành con số cụ thể để ra quyết định và để thương lượng với khách hàng.
Ví dụ 3 — Nhà máy sản xuất ở Bình Dương và bẫy "quá nhiều A"
Một nhà máy điện tử FDI ở Bình Dương triển khai dự án lắp đặt dây chuyền SMT mới. Bảng RACI ban đầu do phòng dự án soạn có tới ba chữ A cho hạng mục "Nghiệm thu an toàn dây chuyền": Trưởng phòng Sản xuất, Trưởng phòng An toàn (EHS), và Giám đốc Kỹ thuật đều là A. Kết quả: khi xảy ra sự cố chập điện lúc chạy thử, cả ba đổ lỗi cho nhau, không ai đứng ra quyết định dừng hay tiếp tục.
PM buộc phải sửa: chỉ Trưởng phòng EHS là A duy nhất (vì an toàn thuộc thẩm quyền của họ), Sản xuất và Kỹ thuật chuyển thành C. Ngay lập tức có một người "cầm trịch" quyết định, và quy trình nghiệm thu chạy trơn tru.
Bài học: "Một A duy nhất" không phải quy tắc cứng nhắc cho vui — nó là cơ chế đảm bảo luôn có một người chịu trách nhiệm cuối cùng khi khủng hoảng xảy ra. Nhiều A = không A.
Hướng dẫn từng bước
Bước 1 — Liệt kê deliverable/đầu việc (hàng dọc). Lấy từ WBS hoặc danh sách công việc. Đừng liệt kê quá chi tiết đến từng task nhỏ — chọn cấp độ deliverable hoặc work package để bảng không bị rối.
Bước 2 — Liệt kê vai trò/cá nhân (hàng ngang). Dùng vai trò (Backend Lead, Legal) thay vì tên riêng nếu đội thay đổi nhân sự thường xuyên — bảng sẽ bền hơn.
Bước 3 — Điền A trước tiên. Với mỗi hàng, hỏi: "Ai là người phải trả lời khi sếp hỏi việc này xong chưa?" Chỉ điền đúng một A. Đây là bước quan trọng nhất.
Bước 4 — Điền R. "Ai thực sự xắn tay làm?" Có thể nhiều R. Mỗi hàng phải có ít nhất một R (nếu A cũng làm thì ghi A/R).
Bước 5 — Điền C và I. C là người cần hỏi ý kiến trước (hai chiều); I là người chỉ cần thông báo sau (một chiều). Đừng lạm dụng C — quá nhiều C làm quyết định chậm rề.
Bước 6 — Rà soát theo hàng và theo cột.
- Rà hàng ngang: mỗi hàng đúng 1 A? Có ít nhất 1 R? Không có hàng nào trống hoàn toàn?
- Rà cột dọc: một người có quá nhiều A không (quá tải trách nhiệm)? Một người toàn chữ I — họ có thực sự cần trong bảng không?
Bước 8 — Vẽ biểu đồ cột và kẻ đường capacity. Vẽ đường ngang bằng năng lực khả dụng (ví dụ 40 giờ/tuần/người). Cột nào vượt đường = quá tải.
Bước 9 — Xử lý quá tải. Còn float và muốn giữ deadline → Smoothing. Nguồn lực bị giới hạn cứng, buộc phải dời → Leveling. Ghi lại tác động lên lịch và trao đổi với stakeholder.
Bước 10 — Đưa cả hai vào Resource Management Plan và cập nhật khi phạm vi hoặc nhân sự thay đổi. RACI và Histogram là tài liệu sống, không phải làm một lần rồi cất tủ.
Lỗi thường gặp & mẹo
Lỗi 1 — Gán nhiều A cho một hàng. Đây là lỗi số một. Khi đọc câu hỏi thi thấy "hai người cùng chịu trách nhiệm phê duyệt", hãy nghĩ ngay đến việc sửa lại còn một A.
Lỗi 2 — Lẫn lộn Responsible và Accountable. Nhớ: A là người ký duyệt và gánh hậu quả, R là người làm. Sếp thường là A, nhân viên thường là R.
Lỗi 3 — Nhầm C và I. C là hai chiều (hỏi ý kiến, có phản hồi qua lại); I là một chiều (chỉ thông báo). Câu hỏi thi hay xoáy vào chi tiết này.
Lỗi 4 — Lạm dụng chữ C. Đưa quá nhiều người vào diện Consulted khiến mọi quyết định phải "họp cả làng". Chỉ tham vấn người thực sự có chuyên môn/quyền lợi liên quan.
Lỗi 5 — Nhầm Leveling với Smoothing. Mẹo nhớ: Leveling có thể làm dự án Lâu hơn (dời deadline, đổi critical path). Smoothing giữ nguyên Schedule (chỉ dùng float). Trong đề thi, nếu ràng buộc là "nguồn lực có hạn, chấp nhận trễ" → Leveling; nếu là "phải giữ đúng deadline" → Smoothing.
Lỗi 6 — Vẽ RACI xong rồi bỏ xó. Nhân sự thay đổi, phạm vi đổi, nhưng bảng không cập nhật → bảng trở thành sai lệch còn nguy hiểm hơn không có bảng.
Mẹo thực chiến: Treo RACI ở nơi cả đội nhìn thấy (Confluence, Notion, hoặc bảng chung). Với dự án nhỏ, một RACI 5x5 trên một trang giấy đã đủ tạo khác biệt. Đừng chờ có công cụ xịn mới làm.
Bài tập thực hành
Bài 1 — Lập RACI. Bạn quản lý dự án ra mắt website bán hàng cho một shop mỹ phẩm. Có 5 đầu việc: (1) Viết nội dung sản phẩm, (2) Thiết kế giao diện, (3) Lập trình website, (4) Duyệt ngân sách quảng cáo, (5) Nghiệm thu và go-live. Các vai trò: PM (bạn), Content Writer, Designer, Developer, Chủ shop. Hãy điền RACI cho cả 5 hàng, đảm bảo mỗi hàng đúng một A.
Bài 2 — Sửa lỗi RACI. Cho hàng "Phê duyệt thiết kế" có: Designer = A, Chủ shop = A, PM = R. Chỉ ra hai lỗi và sửa lại.
Bài 3 — Đọc Histogram. Một developer có capacity 40 giờ/tuần. Nhu cầu 4 tuần lần lượt là: 30, 48, 45, 25 giờ. Tuần nào quá tải? Nếu tuần 4 còn float và bạn muốn giữ nguyên deadline, bạn dùng kỹ thuật nào và làm gì?
Bài 4 — Tình huống thi. Đề bài: "Dự án của bạn có nguồn lực bị giới hạn cứng do một chuyên gia duy nhất, và bạn buộc phải chấp nhận kéo dài thời gian." Đây là Resource Leveling hay Smoothing? Vì sao?
(Gợi ý đáp án: Bài 2 — lỗi hai A và thiếu người làm rõ; sửa Chủ shop = A, Designer = R, PM = C/I. Bài 3 — tuần 2 và 3 quá tải; dùng Smoothing, dời việc sang tuần 4. Bài 4 — Leveling, vì ràng buộc là nguồn lực chứ không phải deadline.)
Tóm tắt
- RACI phân định vai trò con người: Responsible (người làm), Accountable (chịu trách nhiệm cuối — chỉ một), Consulted (tham vấn hai chiều), Informed (thông báo một chiều).
- Quy tắc sống còn: mỗi đầu việc đúng một A, ít nhất một R. Nhiều A = không ai chịu trách nhiệm.
- RASCI là biến thể phổ biến, thêm Support cho người hỗ trợ.
- Resource Histogram cho thấy tải nguồn lực theo thời gian; cột vượt đường capacity = quá tải.
- Xử lý quá tải: Leveling (giới hạn nguồn lực, có thể dời deadline và đổi critical path) và Smoothing (giữ deadline, chỉ dùng float).
- Cả hai công cụ là tài liệu sống trong Resource Management Plan — làm rõ, treo lên, cập nhật thường xuyên. RACI trả lời "AI làm gì", Histogram trả lời "bao nhiêu và khi nào quá tải".