1、项目管理中的困境
问题一:多人协作项目尤其是跨团队,没有人整体协调,团队内外不清楚整体进度、风险点是什么;对内,信息周知不流畅(如需求、时间点、技术方案变动等);
问题二:大小项目都是TL同学跟进,同时多项目并行时,TL成为项目的阻塞点;
2、RACI矩阵模型简述
RACI矩阵的中文名字叫责任分配矩阵,是一种管理职责分配的工具,它来源于四个英文单词的首字母缩写,我们经常听到的“这件事谁是主R?”或者“谁来R下这件事?”里面的R就来源与RACI模型;RACI矩阵的作用是明确项目或者人事中的责、权划分问题。
英文全称 | 中文全称 | 职责 | 解释 |
---|---|---|---|
R(Responsible) | 负责人 | 谁来负责 | 负责执行任务的角色,具体负责操控项目、解决实际问题 |
A(Accountable/Approve) | 批准人 | 谁来批准 | 对任务负全责的角色,只有经过批准人同意或者签署的项目才能够通过立项 |
C(Consulting) | 顾问 | 咨询谁 | 在实施前、中提供意见建议的人员(咨询专家角色) |
I(Inform) | 知情人 | 告知谁 | 及时被通知结果,不必向其咨询、征求意见 |
2.1、如何绘制RACI矩阵
- 辨识整个流程、找出各项活动,将它们记录在RACI表的左侧。
示例
小型项目
TASK |
---|
咖啡“买10送1”活动 |
新增拼单场景 |
大型项目,就需要进一步进行拆分,如ERP系统的建设
story |
---|
会员体系建设 |
会员成长规则 |
会员权益部分 |
- 辨识流程、活动中的所有角色,将它们记录在RACI表的上方。
示例
穷举出所有参与项目的角色,如果角色没有这么多,可以列举人员也可以
TASK | 业务方 | PM | FE | RD | QA | SRE |
---|---|---|---|---|---|---|
咖啡“买10送1”活动 | ||||||
新增拼单场景 |
- 完成RACI矩阵表的方格单元: 辨识每一个流程、活动的角色(R、A、C、I)。
示例
TASK | 业务方 | BL | PM | FE | RD | QA | SRE |
---|---|---|---|---|---|---|---|
咖啡“买10送1”活动 | I | A | C | R | |||
新增拼单场景 |
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)有放权就有对应的收权
仅仅从日常工作的项目研发来看,各个阶段角色的职责
需求宣讲 | 需求消化&目标对齐 | 设计&评审 | 研发/测试 | 上线 | 线上运营 | |||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
角色 | A | R | A | I | R | A | R | A | R | A | R | A |
动作 | 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哥]