首页 > 读 文 > 【必读】产品经理必须要熟练掌握的五类产品管理框架---辅助框架五:RACI和DACI的关系
2023
09-27

【必读】产品经理必须要熟练掌握的五类产品管理框架---辅助框架五:RACI和DACI的关系

本篇开始的时候先回答一个朋友针对DACI提出的问题,这个朋友问:

在产品管理中,有很多的决策,难道对于I(知情者)类角色而言,他们也需要知道决策内容吗?

回答一下,DACI只是确定在群体角色中,每个团队成员要扮演的角色,对于I类角色而言,他们需要知道的只是“做出了一个什么样的决策”,而通常不需要知道具体的“决策内容”。

1、RACI概述

通过对DACI的了解,我们已经知道这是一个“群体决策框架”,也就是说,这个框架在产品管理中,既不是对产品管理过程中相关任务和职责的分配,也不是对各类项目的计划。

它本质上就是一个用来直观地显示团队中不同人员角色将如何为特定的决策做出贡献的矩阵。

那么,一个问题又出现了,对于产品管理过程中的项目计划,我们有各种项目管理类的机制来辅助我们,那么,对于产品管理过程中的任务和职责的分配,是否也有相关的机制或类似DACI的框架呢?

那是肯定有的,因为在上一篇中我就提到了,DACI就是RACI的延伸,而RACI就被称为是“职责分配矩阵”。

它用来描述不同角色在完成工作时的参与情况。

RACI由来已久,它不像DACI有明确的来源,目前业内有三种认识:

1)来源于以研究组织结构和管理系统著称的Edmond F. Sheehan;

2)来源于美国的杜邦公司;

3)来源于E&Y(安永会计师事务所),它在20 世纪 70 年代使用了一种名为“RASCI” 矩阵的类似模型。

但无论是哪个来源,至少有一点是有共识的,就是RACI本质上其实是一种“人力资源”层面的管理矩阵。

当然,别看到“人力资源”,大家就把它看成是企业内的“人事部”要做的事,格局放开了,这里的“人力资源”指的是企业中的“人,财,物”的“人”。

因为这个矩阵要明确的是“为了产品或项目的顺利完成,需要哪些个人或小组,以及每个人在整个项目中所扮演的角色” 。

简单点说,就是确定“责、权、利”中的“责”。

2、RACI的四个角色都指什么

RACI是Responsible(负责人)、Accountable(责任人)、Consulted(咨询人)和Informed(知情人)四个单词的首字母缩写,那么,这四类角色都分别指什么呢?大家看下图:

1)Responsible | 负责人

负责人是指负责完成工作的角色,也就是执行任务的人,也被称为是“亲历者”,这类角色一般向他的直接经理汇报工作。

比方说这类角色可以包括:

  • 项目经理
  • 业务分析师
  • 开发人员
  • 平面设计师
  • 文案

2)Accountable | 责任人

责任人是指负责监督工作完成的角色,这类角色要确保工作正常完成,他们不需要亲力亲为,只需要确保工作按时按质完成即可。

比方说这类角色可以包括:

  • 产品经理/产品负责人
  • 有签字权的人
  • 业务负责人
  • 推荐人/保荐人
  • 主要利益相关者

3)Consulted | 咨询人

咨询人是指提供相关信息或技术来支持或协助负责人完成工作的角色,这类角色不直接负责某项工作,但是他们通过提供信息能够协助负责人完成工作,通常这类角色由那些在特定领域具备专业知识的人扮演。

比方说这类角色可以包括:

  • 法律专家
  • 技术专家
  • 合规顾问

4)Informed | 知情人

知情人是指需要随时了解工作进展或交付成果情况的角色,这类角色不直接参与工作事务,但可能是整个产品或项目的所有者,通常这类角色是高层管理者或相关的潜在客户。

比方说这类角色可以包括:

  • 产品/项目委员会成员
  • 外部利益相关者
  • 企业所有者

RACI中的“咨询人”和“知情人”基本上和DACI中的“贡献者”和“知情者”类似,需要重点区分的是“负责人”和“责任人”。

它俩的区别在于:

“负责人”指的是完成工作的个人或团队,而“责任人”指的是对最终结果负责的人,这类角色必须对交付成果出具报告并签字。

这就好比去医院看病,大夫给你开了需要院长才能批准的药,那么,大夫就是“负责人”,而院长则是“责任人”。

同一个人可以同时担任这两个角色,但一定要明白他们的职责不同,要随时转换角色。

3、如何使用RACI矩阵

其实讲到这里,大家一定会有一个感觉,就是RACI矩阵其实在实践中已经应用的很广泛了,哪个企业不对员工进行职责的划分(如果HR部门划分到位的话),对吧,但是既然咱们是基于产品管理框架在讲,这就涉及到产品管理团队如何采用RACI矩阵,接下来,我就讲一下产品管理团队如何使用RACI矩阵。

1)列出产品管理过程中某个具体项目需要完成的所有任务、里程碑和决策

比方说,针对某个产品,你要做一次盈亏分析,你设定有个任务是“对北京市场的客户进行访谈”,里程碑是“完成20个客户的访谈”。

这里有一点需要注意:

(1)如果某个具体项目所涉及到的任务很多,那么,可以按照任务分类进行划分,比方说,“盈亏分析”这个具体工作就属于“市场研究”这个大类。

2)确定出参与项目的所有团队成员、利益相关者和主题专家的姓名或职称/职务

比方说,针对这次盈亏分析,涉及到的团队成员包括产品经理,销售,客户支持和数据分析师。

这里有两点需要注意:

(1)团队成员一定要全,不但要有直接涉及这个工作的成员,还要包括那些不会直接参与项目工作,但可能需要寻求咨询、管理或最终做出关键决策的人。

(2)如果是大型项目,可以不填入每个人的姓名,建议使用职务或角色。

3)为每项任务分配 RACI 职责

这个就简单了,按照RACI的职责设定为每个参与者分配对应的职责,比方说,在盈亏分析中,产品经理是A(责任人),销售和客户支持是R(负责人),数据分析师是C(咨询人),高层和客户是I(知情人)。

这里有三点需要注意:

(1)每项任务只能有一个A(责任人)和一个R(负责人)。

(2)I(知情人)只需接收最新信息,但不一定向 R(负责人) 或 A(责任人) 提供反馈。

(3)责任人和负责人是每项任务都需要的角色,但不一定都有咨询人和知情人,比方说一些简单的任务。

4)共享RACI矩阵并得到反馈

RACI 矩阵完成后,与所有团队成员共享该矩阵并得到他们的反馈直至最终确定。这可以确保每个人都了解自己在整个项目中的具体角色和职责,从而最大限度地提高 RACI 矩阵的效率。

4、RACI矩阵是什么样的

通过以上四步,你就可以绘制出一个RACI矩阵图表,大家看下图:

5、RCAI和DACI的区别

学习了RACI和DACI的知识,最后呢,我们对两者之间的区别做一个比较总结,大家看下图:

最后呢,回答一个大家可能关心的问题,就是这俩矩阵用哪一个合适呢?

按照业内的观点:

如果你的产品/项目涉及多人提供意见,决策过程复杂,那么 DACI 框架可能更合适。

如果你的产品/项目涉及多个需要完成的任务,那么 RACI 框架可能更合适。

但我个人认为两种框架的组合可能会更合适。我们可以在决策过程中使用 DACI 框架,在任务管理中使用 RACI 框架。

为什么这么说呢,其实道理很简单:

我们都知道无论做什么事,都需要“责权利”清晰,RACI矩阵帮助我们确定“责”,DACI矩阵帮助我们确定“权”(决策应该是最大的一种“权”),至于“利”嘛,怎么说到这个了呢!


本文》有 0 条评论

留下一个回复