RACI矩阵模型

254 阅读6分钟

1、项目管理中的困境

问题一:多人协作项目尤其是跨团队,没有人整体协调,团队内外不清楚整体进度、风险点是什么;对内,信息周知不流畅(如需求、时间点、技术方案变动等);

问题二:大小项目都是TL同学跟进,同时多项目并行时,TL成为项目的阻塞点;

2、RACI矩阵模型简述

RACI矩阵的中文名字叫责任分配矩阵,是一种管理职责分配的工具,它来源于四个英文单词的首字母缩写,我们经常听到的“这件事谁是主R?”或者“谁来R下这件事?”里面的R就来源与RACI模型;RACI矩阵的作用是明确项目或者人事中的责、权划分问题。

英文全称中文全称职责解释
R(Responsible)负责人谁来负责负责执行任务的角色,具体负责操控项目、解决实际问题
A(Accountable/Approve)批准人谁来批准对任务负全责的角色,只有经过批准人同意或者签署的项目才能够通过立项
C(Consulting)顾问咨询谁在实施前、中提供意见建议的人员(咨询专家角色)
I(Inform)知情人告知谁及时被通知结果,不必向其咨询、征求意见

2.1、如何绘制RACI矩阵

  1. 辨识整个流程、找出各项活动,将它们记录在RACI表的左侧。

 示例

小型项目

TASK
咖啡“买10送1”活动
新增拼单场景

大型项目,就需要进一步进行拆分,如ERP系统的建设

story
会员体系建设
会员成长规则
会员权益部分
  1. 辨识流程、活动中的所有角色,将它们记录在RACI表的上方。

 示例

穷举出所有参与项目的角色,如果角色没有这么多,可以列举人员也可以

TASK业务方PMFERDQASRE
咖啡“买10送1”活动
新增拼单场景
  1. 完成RACI矩阵表的方格单元: 辨识每一个流程、活动的角色(R、A、C、I)。

 示例

TASK业务方BLPMFERDQASRE
咖啡“买10送1”活动IACR
新增拼单场景

2.2、矩阵检验

A、横向检查

横向检查即检查每一个工作包在每个部门的分工。

关注点

  • 检查右侧是否有没有遗漏的人员或部门;

  • 检查每一个工作包是否没有部门负责,即右侧是否没有R,每一个流程理想状态应该只有一个R,如果有多个R,建议把流程fork出一个子流程,继续拆分;

  • 是否有过多的C, 如果引入了过多的咨询人员或咨询过程也会导致成本过高;

  • 是否有过多的I,避免无关的人得到无关的信息,也是消除浪费,提高效率。

B、纵向检查

纵向检查即是按部门来检查:

关注点

  • 检查每个部门分配了分工类型为R的工作包,评估该部门是否有足够的资源来负责这些任务;
  • 是否某一个部门被分配的任务过重或过轻;
  • 是否有部门没有接收到应有的信息或接收到了不该收到的信息;
  • 特别要检查的是作为管理层,是否在最关键的节点上被分配了A以做把控;
  • 是否有太多的A,是否这个人授权不够,能否将为C或I。

2.3、常见误区

Q1:一个项目确立R责任人后,责任人的直属leader或者A的角色就可以彻底信任放权,交给R同学去跟进;

 答案

放权有分层, 一些权利是绝对不能下发的,属于红线权限(最基本的如人事任免、薪酬调整等等);在日常项目中则是涉及范围(需求做多少,哪些做哪些不做)、成本(投入多少资源,或者审批多少资源)、时间(上线时间等等);

可以放权的部分,需要有抓手有监控,对结果有目标,对过程有抓手,监控过程,给出辅导或资源帮助;

Q2: 假设一个项目失败了,那么一定是R同学的问题,需要对R同学进行批判;

 答案

放权不放责

项目失败/成功的第一责任人永远都是A或者R的直属leader,向下释放的永远都是部分权利而责任永远是不能下放的

Q3:一个流程中RACI四个角色可以同时存在多个;

 答案

一个RACI矩阵无论横向还是纵向,同一种角色都不应该出现过多(A也一样,如果有过多的A,应该考虑部分项目降级为C或者I)

3、放权的延伸讲解

1)放权不放责

2)放权有红线,红线职责不放权

3)放权不意味“撒把”,过程有管理抓手

4)有放权就有对应的收权

仅仅从日常工作的项目研发来看,各个阶段角色的职责

需求宣讲需求消化&目标对齐设计&评审研发/测试上线线上运营
角色ARAIRARARARA
动作1)需求要不要做&什么时候做审视需求价值,判断需求优先级要不要现在做2)投入多少资源这个需求可以投入多少资源进去,结合研发工作量要做多久?3)谁是项目的负责人(R)角色确定需求跟进的主R(谁有能力适合胜任?有没有意愿或信心完成?需要什么样的支撑?)1)相关方信息拉齐需求涉及到的相关责任人是否信息拉齐(如数仓、QA)2)目标拉齐业务目标、阶段目标与所有相关责任人拉齐,如果是大型项目要有routemap和可阶段性验收的milestone3)收集反馈集中收集相关方对于需求的反馈,是否有疑问需要重新评审,还是需求通过1)确认目标对目标(包含milestone或routemap)进行确认2)检查相关方理解程度是否周知所有相关人,相关人对目标和信息的理解程度是否一致1)业务建议提供业务咨询1)组织设计&评审工作R同学不一定就是架构师,但是要负责架构评审的梳理和评审,并对架构产出物进行初审1)架构评审确认1)跟进进度收集进度,检查milestone2)识别风险&风险反馈1)监控项目进度&风险控制1)上线前准备检查checklist,统一编写回滚方案,多配合方的配合顺序2)上线期间协调****3)上线后验收&问题处置1)检查上线前准备工作,批准上线****2)上线失败或者回滚决策1)上线后1-2周核心指标监控系统指标和业务指标是否达成预期1)长期监控,业务价值闭环

转[wei哥]