PM duyệt từng đầu việc, đội ngồi chờ: chuyển sang đội tự tổ chức bằng bảng phân quyền quyết định

Tình huống minh hoạ

Tình huống dưới đây là giả định, dùng để minh hoạ.

Chị Mai là PM dự án phát triển ứng dụng khách hàng thân thiết cho một chuỗi siêu thị bán lẻ có hơn 80 cửa hàng. Đội 8 người làm theo Scrum, sprint hai tuần. Chị Mai rất tận tâm: chị duyệt từng user story trước khi đội bắt đầu, xem từng màn hình thiết kế, quyết định cả việc đặt tên biến môi trường và chọn thư viện giao diện.

Sau bốn sprint:

• Trung bình mỗi đầu việc chờ chị Mai phản hồi 1,5 ngày; chị thường trả lời lúc tối muộn.
• Thành viên ít đề xuất cải tiến, câu quen thuộc là "chị Mai quyết đi ạ".
• Khi chị nghỉ phép một tuần, gần như toàn bộ công việc đứng lại.
• Trong retrospective, đội nói họ "không biết mình được quyết đến đâu".

Chị Mai thì cảm thấy quá tải và cho rằng đội "chưa đủ chín chắn để tự quyết".

Phân tích theo PMBOK® Guide

Team Performance Domain mô tả các phong cách lãnh đạo từ tập trung (centralized) đến phân tán (distributed). PMBOK® Guide – Seventh Edition nhấn mạnh lãnh đạo phục vụ (servant leadership): người lãnh đạo tạo điều kiện, gỡ trở ngại và phát triển năng lực của đội thay vì ra mọi quyết định. Đội tự tổ chức (self-organizing team) là đặc trưng của nhiều cách tiếp cận Agile – đội tự quyết cách thực hiện công việc để đạt mục tiêu.

Agile Practice Guide mô tả vai trò của người lãnh đạo phục vụ là tạo ra môi trường để đội tự tổ chức, đồng thời gỡ bỏ các trở ngại mang tính tổ chức. Một PM trở thành "cổ chai" cho mọi quyết định đang đi ngược hướng đó.

Tuy vậy, tự tổ chức không có nghĩa là không có giới hạn. Trao quyền cần đi kèm mục tiêu rõ, ràng buộc rõ và thông tin minh bạch.

Nguyên nhân gốc:

1. Quyền quyết định chưa được làm rõ: đội không biết việc nào được tự quyết, việc nào cần hỏi.
2. Thiếu "lan can" (guardrails): không có Definition of Done, nguyên tắc kiến trúc hay tiêu chí chất lượng thành văn, nên chị Mai dùng việc duyệt thủ công thay thế.
3. Thiếu tin tưởng hai chiều: PM chưa tin đội, đội chưa tin mình được phép.

Cách xử lý

Bước 1 – Liệt kê các loại quyết định thường gặp. Cùng đội liệt kê 10–15 loại quyết định: chọn thư viện, ước lượng, thứ tự task trong sprint, thay đổi thiết kế giao diện nhỏ, thay đổi API ảnh hưởng hệ thống khác, xử lý lỗi khẩn cấp...

Bước 2 – Gán mức phân quyền. Một cách phổ biến là bảy mức phân quyền trong Management 3.0 (Jurgen Appelo) – từ "Tell" (người quản lý quyết định và thông báo) đến "Delegate" (đội toàn quyền). Có thể đơn giản hoá: