RACI Matrix(RACI)

Ba tuần trước go-live, không ai biết ai được quyền duyệt bản migration dữ liệu cuối cùng. Mỗi bên đều nghĩ bên kia lo. Ma trận RACI sinh ra để tình huống đó không diễn ra: một bảng, hàng là công việc, cột là vai trò, ô là một trong bốn chữ.

RACI ghi rõ với mỗi đầu việc thì ai làm, ai chịu trách nhiệm cuối cùng, ai phải hỏi ý kiến trước, ai chỉ cần được báo sau.

Bốn chữ

• R — Responsible: người trực tiếp làm. Một việc có thể có nhiều R.
• A — Accountable: người chịu trách nhiệm về kết quả và là người ký duyệt. Mỗi việc chỉ được có đúng một A. Đây là luật cứng của RACI, và cũng là luật bị vi phạm nhiều nhất.
• C — Consulted: người phải được hỏi ý kiến trước khi quyết, trao đổi hai chiều.
• I — Informed: người được thông báo sau khi xong, một chiều, không cần phản hồi.

Một A không có R thì A tự làm luôn. Một việc có hai A nghĩa là chưa có ai chịu trách nhiệm — lúc hỏng, hai người cùng chỉ sang nhau, chuyện này mình chứng kiến đủ nhiều lần để tin rằng luật một-A là phần giá trị nhất của cả phương pháp.

Ví dụ thực tế

Tuần thứ hai của dự án, cả nhóm mất trọn một buổi chiều chỉ để chốt xem ai ký cái gì. Dự án là thay hệ thống quản lý học viên cho một trung tâm ngoại ngữ 14 cơ sở, 8.600 học viên đang học, 5 tháng, team 6 người. Đây là phần rút gọn của ma trận, giai đoạn phân tích và bàn giao:

Đọc bảng này thấy ngay vài điều. Kế toán trưởng là A của luồng thu học phí chứ không phải giám đốc vận hành — đó là tiền, và người ký sổ phải là người chịu. Tech Lead vừa A vừa R ở phần kiến trúc, hoàn toàn hợp lệ. Dòng go/no-go: PM chạy quy trình (R), nhưng người gật đầu cuối cùng là giám đốc vận hành (A), vì hệ thống hỏng thì 14 cơ sở dừng nhận học viên chứ PM không chịu thay được.

Dòng "Duyệt BRD" cũng đáng chú ý: trưởng phòng đào tạo chỉ là C. Nghe hơi phũ, nhưng nó tránh được cảnh tài liệu chờ 5 chữ ký trong 3 tuần.

Cách dựng một ma trận không vô dụng

1. Liệt kê công việc ở mức deliverable hoặc quyết định, không phải mức task hằng ngày. Khoảng 15–30 dòng là vừa; 80 dòng thì không ai đọc.
2. Liệt kê vai trò, không phải tên người. Người nghỉ việc thì bảng vẫn dùng được.
3. Điền A trước, cho từng dòng, trước khi điền bất kỳ chữ nào khác.
4. Điền R, rồi mới tới C và I.
5. Đưa ra họp và đọc to từng dòng. Ai phản đối thì tranh luận ngay tại đó — đó mới là phần có giá trị, cái bảng chỉ là biên bản.
6. Soát ngang và soát dọc.

Soát ngang: dòng nào không có A là dòng sẽ trôi. Dòng nào có hai A là dòng sẽ cãi nhau. Dòng nào toàn C thì tức là bạn đang thiết kế một cuộc họp chứ không phải một công việc.

Soát dọc: cột nào dày đặc R là người đó sẽ quá tải. Cột nào chỉ toàn I thì hỏi thật lòng xem người đó có cần trong dự án không, hay chỉ đang được mời cho phải phép.

Lỗi hay gặp

• Nhét quá nhiều C. Mỗi chữ C là một cuộc trao đổi bắt buộc trước khi quyết. Mười C trên một dòng nghĩa là dòng đó sẽ đứng yên.
• Lập ma trận rồi lưu vào SharePoint và không bao giờ mở lại. Lúc có tranh chấp mà không ai nghĩ tới việc mở nó ra thì buổi họp dựng bảng coi như bỏ.
• Dùng RACI cho công việc thường ngày của team dev. Không cần. RACI dành cho những chỗ có ranh giới tổ chức và có quyết định.
• Điền A cho người không có thẩm quyền thật. Ma trận không tạo ra quyền lực, nó chỉ ghi lại quyền lực có sẵn.

Biến thể RASCI thêm chữ S (Support), RACI-VS thêm V (Verify) và S (Sign-off). Dùng khi thật sự cần, còn thường thì bốn chữ đã đủ mệt.