在你的项目中使用RASCI图表的8个理由

人类的超能力是将我们自己组织在一起，共同做伟大的事情的能力。但是，有了这种超级能力，就必须组织我们的相互工作。如果没有最负责任的朋友的适当管理，即使是一个小项目，如周日与朋友的野餐，也会变得混乱不堪。而更复杂的项目，如构建软件产品，如果没有适当的组织，将直接失败。

有很多工具可以帮助组织项目、流程和自己的任务，如ToDo列表、看板、电子表格、任务管理系统、聊天、电子邮件和各种通信工具。而且它们都可以是相当有效的。然而，很多时候，在组织工作时，我们并没有超越 "任务分配者 "的概念，因为我们只把一个任务与一个要完成它的人联系起来。

不仅如此，大多数常见的项目管理工具通常只有一个受让人的字段，这也给人一种印象，即除了执行任务的人，或许还有一个可以回答问题或提供细节的经理，就没有其他角色了。

但是，现代项目的现实要复杂得多，有更多的人参与其中，通常是隐性的。这就是责任分配矩阵（RAM），如RACI或RASCI，派上用场的地方。这样的矩阵考虑到了所有涉及的角色，并明确了哪些角色和人员参与其中，以何种方式参与。在这篇文章中，我们将讨论最流行的责任分配表，团队在使用它时可以得到的好处，为你的团队创建这样一个图表的逐步指导，以及一些来自我们经验的RASCI矩阵例子。

目录 隐藏

1 什么是RASCI图表

2 RASCI图表是怎样的

3 为什么你的项目需要一个RAM的8个原因

4 创建RASCI图表的简单步骤

5 Railsware使用RASCI图表的经验

6 RASCI图的例子

7 创建RASCI矩阵时，该做什么，不该做什么

8 总结

什么是RASCI图表

RASCI图是一种流行的管理工具，用于对参与者进行分类，并确定他们在项目或流程中的角色和责任。该工具的起源显然是未知的。然而，它通常与被称为 "目标导向项目管理"（GDPM）的项目管理方法有关，该方法在20世纪80年代Kristoffer V. Grude、Tor Haug和Erling S. Andersen的作品发表后获得了声誉。

RASCI是原始RACI图的一个更现代的版本，其目的是为项目中的每个关键任务定义负责的、可问责的、被咨询的和知情的利益相关者。RACI图和RASCI图的区别在于RASCI图随着时间的推移获得了额外的角色*（支持性*）。以下是RASCI图中每个角色的含义。

• 负责任--是一个推动项目和团队实现预定目标的人。担任这个角色，一个人将负责做出重要的决定，克服阻碍，带领团队做正确的事情，并决定不做什么。责任可以分享，但不能传递给另一个人。
• 负责任或批准者。担任这个角色的人对项目的成功和完成负有责任，同时在实施过程中参与最少，但在决策过程中参与最多。批准者会贡献想法、知识和其他任何可以帮助负责人和团队做出正确决定并实现目标的东西。在极少数情况下，审批人可以跳到工作的关键部分。请看我们的文章：如何保持权力、责任和义务之间的平衡，以避免项目管理中最常见的错误。
• 支持者。这个角色在项目实施/交付中支持负责人。担任这个角色的人可以在不同程度上参与。支持者可能成为团队按时交付项目的劳动力缓冲区。
• 被咨询者--通常是主题专家，他们希望负责人在做出最终决定之前与他们交谈。被咨询者的角色将作为背景持有人贡献他们的意见或知识。他们不做任何工作，但可能会参与决策。
• 知情者。知情者会希望负责人向他们提供项目进展的最新情况。致力于成为 "知情者 "的人将被动地获得关于项目关键决策和关键转折的最新信息。

这种模式非常灵活，根据项目的规模和性质，一些角色可以被添加或省略。在Railsware，我们使用RAtSCNIuo图表和一些额外的角色，我们将在稍后讨论。

RASCI图表是怎样的

一个经典的RASCI图表由项目任务组成，这些任务列在左栏，而完成项目所需的所有团队成员都在图表的上行提到，而团队成员所担任的角色则以字母表示--A、R、S、C和I。

从图表中可以看出，一个参与者可以在一个项目的不同任务中担任不同的角色。例如，CTO可以批准一些任务，在其他任务上被咨询和告知。

为什么你的项目需要RAM的8个原因

当为你的团队创建一个RACI或RASCI图时，你会得到一个强大的工具，用于高效的项目管理，有助于跨职能团队的顺利合作。以下是RASCI图带来的东西。

1.简化沟通

如果不知道谁负责什么，一个团队最终会面临误解、错误，有时甚至冲突。当新成员加入团队时，当工人从事几个项目时，或者当一个专家把他们的工作交给另一个专家时，就会发生这种情况。有了RASCI图表，所有的团队成员在整个项目中都有一个他们可以处理的单一信息来源。

2.快速决策

一个责任分配矩阵清楚地定义了谁是某项任务的负责人和批准人，这样就可以很明显地看出在执行和决策相关的问题上应该联系谁。

3.更好的工作协调

当所有的角色都明确了，每个团队成员都知道他们负责哪些任务，哪些问题应该联系谁，他们就可以直接开始工作。负责任的人知道他们应该咨询谁，谁会批准他们的任务，接下来该做什么，以及项目的目标和预期结果是什么。他们了解工作流程，不会浪费时间去寻找必要的利益相关者。

4.减轻风险

制定RASCI图表需要你将项目分解成较小的工作块，并在团队成员之间分担责任。通过这样做，你可以看到范围和每个专家负责的部分，这就减少了你遗漏的机会。它还显示你是否有足够的资源/人才来完成项目。

5.更好地分配工作量

该图表也很容易分析，可以看到每个人有多少责任领域。这是一个简单的方法来确定一个团队参与者是否有太多的责任，如果是的话，通过重新分配工作量来防止专家焦头烂额或留下一些未完成的任务。

6.保存的资源

RASCI图表允许更有效的工作流程，减少返工、停顿、重复的任务，或者反过来说，减少未完成的任务。

7.更容易管理变化

敏捷开发方法让团队在开发过程中调整项目范围。当使用RASCI图表时，团队可以很容易地跟踪谁将受到每个变化的影响，以及团队成员的工作量将如何变化。

8.快速解决冲突

RASCI图增加了项目管理的透明度。有了这个工具，你就可以知道每个人的预期结果，每个人都承诺了什么。该图表允许团队追踪谁对未完成的任务负责，并了解哪里出现了阻碍。这样的分析有助于发现瓶颈，并在未来防止它们。

创建RASCI图表的简单步骤

如果这是你的团队第一次创建RASCI图表，请遵循本段描述的步骤，并使其成为正式的。以后，你可能不需要正式创建它，因为每个人都会知道这个过程。以下是创建责任分配表的步骤，你的团队可以成功应用。

• 定义项目和它的目标。不是所有的项目都需要创建RASCI模型。如果项目范围很小，一个人就可以成功完成，那么图表的开发就是浪费时间。对于较大的项目，RASCI图将有助于了解工作量和你需要的团队。
• 与其他项目和任务相比，确定项目的优先次序**.**当考虑一个新项目时，要确保其价值足够大，以启动项目。如果你看到这个项目并不紧急，而且还有其他更关键的任务在排队，那就推迟它。
• 将项目分解成较小的任务。只有当项目足够大，并且包括不同团队成员应该执行的几个任务时，才需要这个步骤。通常情况下，项目分解是在产品开发路线图创建过程中进行的。没有必要重复这个步骤，只需从你的任务管理系统中提取任务，并将其添加到图表的左栏中。如果你的路线图是非常高层次的，你可能想进一步分解它，在RASCI矩阵中使用较小的任务。
• 定义完成项目所需的专家。包 括成功完成项目所需的所有角色（例如，项目经理、设计师、质量保证工程师），并将其列在图表的上一行。
• 找到能够承担每个角色的人。如果你有一个只有一个设计师或业务分析师的小团队，那么谁需要承担每个角色就很清楚了。然而，在一个大公司里，比方说，有15个设计师，你需要找到适合这个项目的人。如何做到这一点呢？在Railsware，我们关注的是具有必要的专业知识、技能和愿意参与特定项目的专家。为了简化团队组成过程，我们为同事们提供了检查所有项目清单的机会，并指定他们的兴趣水平，使用 "真的想要"、"想要"、"准备试验"、"如果真的要 "和 "不想参与 "等承诺。这种方法使我们能够看到被选中的人在执行指定的任务时是否会有积极性，还可以形成一个后备专家名单，如果发生意外，他们可以取代负责人或其他角色。
• 检查每个人的工作量，确保他们能够参与。在我们的团队中，我们不希望专家同时参与太多的项目，因为这会降低专家的生产力和项目成功完成的几率。
• 与团队一起批准矩阵。如果这是你第一次使用责任分配矩阵，那么这一步就特别关键。对创建的图表进行简短的介绍，让你的团队熟悉它。参与者需要将他们的新责任与他们的工作量联系起来，并自愿参加一个项目，如果需要的话，重新平衡已经安排的活动，或者拒绝参与。

图表本身是一个方便的工具。然而，你不应该忽视其他改善项目协调和团队治理的项目管理工具和方法，如带有受让人的项目管理系统、与项目参与者的专门沟通渠道、与团队的定期会议、预算审批的自动化业务流程等。

具有RASCI图的Railsware经验

我们的团队在为内部和外部项目创建和使用RASCI图表方面拥有悠久的历史。多年来，我们定义了一些额外的角色，使我们能够更准确地分配角色和责任，实现更好的结果。因此，我们开发了一个RAtSCNIuo模型。RAtSCNIuo图代表了负责任的、批准者、团队、支持性的、咨询的、如果没有人的话、知情的、用户和偶尔的用户。让我们来解释一下这些新角色的含义。

• 团队。在一个项目中担任这一角色的专家将在一个经常性的基础上工作。同时，他们将积极收集见解，做对愿景或背景有用的研究，并与其他团队成员或负责人合作。团队角色必须保持与项目进展同步，并推动其他人把事情做对。这个角色通常由以下职位占据：项目经理、工程师、设计师、HTML/CSS专家、文案、QA工程师等。
• 如果没有其他人的话。这个角色将确定最后要寻求帮助的人，如果没有其他人可以协助。这将意味着担任这个角色的人有领域知识，但想从活动中转移出来。
• 用户。代表使用系统或正在开发的项目的人，希望得到与使用有关的主题的更新。
• 偶尔的用户。这是该系统或项目的罕见用户。与用户类似，这个角色希望得到只与偶尔用户有关的更新。

不过，并不是所有的项目都需要我们使用所有列出的角色并吸引那么多人。每个项目都是不同的。在一些小项目中，我们可能只有一个负责人和批准人。

当我们创建一个责任分配表时

并不强制要求每次都要创建图表。有时，更简单的方法是有效的。这意味着你可以定义和确认每个人担任什么角色，仅此而已。不需要有任务清单和图表本身。此外，你不一定会事先知道任务清单。

然而，万一你认为你需要一个图表，你应该从项目的优先级开始。如果一个项目看起来不如队列中的其他项目有价值，为其创建图表是对资源的浪费，因为该项目需要推迟，因此，当项目开始时，图表很可能已经过时。

当我们处理一个现有的项目时，我们会在以下情况下创建一个RASCI（在我们的例子中是RAtSCNIuo）图表：范围发生变化，我们需要重新分配角色/范围；当团队组成发生变化，每个人都需要被提醒谁在做什么；当我们看到沟通问题，人们迷失了方向，需要这种清晰度。

如果是一个全新的产品开发项目，我们会在BRIDGeS探索会议期间或之后创建一个责任分配表。BRIDGeS是一个由Railsware设计的灵活的决策框架，有助于在一次会议中形成产品愿景并建立一个清晰的开发战略。了解更多关于BRIDGeS以及团队使用该框架可以获得的优势。

RASCI图表示例

Railsware团队对每个足够大的项目都使用RASCI模型。让我们来看看我们团队经验中的一些真实案例。

案例1.组织年度峰会

每年，我们的团队都会举办一次年度峰会。这是一个持续一周的线下聚会，在这里我们可以亲自了解对方，建立联系，进行合作，并与我们的队友和家人一起享受快乐。

考虑到Railsware是一个远程友好型团队，其成员来自13个不同的国家，因此每年的峰会组织工作是一项重要的大事情。活动组织者要解决很多问题，思考很多问题，比如。

• 决定并同意活动的目的地。
• 检查所选目的地的旅行规则。
• 确定参与者的数量。
• 为每个队友和他们的家人安排接送。
• 为所有参与者寻找合适的住宿。
• 创建一个包含各种活动的议程，以满足任何口味。
• 估计并批准预算。

以及很多很多其他问题。范围显然是巨大的。这就是为什么我们使用责任分配表来分配责任，确保一切顺利进行。我们上面列出的问题形成了一个任务清单，我们把它放在RASCI图表的左栏。

	角色1	角色2	角色3	角色4	角色5
决定并同意活动的目的地
检查所选目的地的旅行规则
确定参与者的数量
为每个队友
和他们的家人组织接送服务
为所有参与者寻找合适的住所
建立一个包含各种活动的议程，以满足任何口味的需要
估计并批准预算

谢尔盖作为总经理，与首席财务官阿加塔一起担任审批人的角色，后者负责验证所有财务问题。项目负责人阿纳斯塔西娅是负责人。她必须推动该项目，并对其结果负责。

负责人吸引了一些同事（不同领域的专家，有相关的经验和参与项目的愿望）来帮助她进行研究、转移组织、议程和其他对峰会至关重要的方面。他们担任团队的角色。我们联系了过去参与组织年度峰会的Railswarians，他们可以帮助我们提供一个咨询意见。

在这个项目中，我们与所有的Railswarians进行了几次民意调查和讨论，以了解他们对与此行有关的一个或另一个方面的意见。那些分享他们的想法和建议的人也是被咨询者。所有决定参加峰会的Railswarians都成为用户。

此外，我们与一家外部旅行社合作，负责购买机票、预订住宿，并根据活动议程寻找不同的服务供应商。这些人获得了支持性角色。

以下是那个特定项目的最终责任分配表的情况。

| | 总经理
(Sergey) | 首席财务官
(Agata) | 项目负责人
(Anastasia) | 项目团队 | 外部旅行社 | 有经验的同行 | 铁路人 | | --- | --- | --- | --- | --- | --- | --- | --- | | 决定活动的目的地 | A | I | R | T | C | c | C/U | | 检查一个目的地的旅行规则 | I | I | A | T | s | I | | 定义参与者的数量 | I | A | T | | 为每个人组织转移 | I | A | R | S | U | | 为每个人找到合适的住所 | I | A | T | S | C | u | | 创建一个议程 | A | I | R | s | c | U | | 估计并商定预算 | I | A | R | T | S |

案例2.为Mailtrap开发用户管理功能

Mailtrap是一个Railsware产品，旨在开发和暂存环境中进行安全的电子邮件测试。该工具最初是作为MVP为我们团队的需求而创建的。当Mailtrap证明其可行性后，我们的团队也允许其他开发者使用它。现在，该工具有50多万活跃用户，在个人开发者和各种机构和公司中都非常受欢迎。

Mailtrap正在积极成长，我们的团队定期向客户咨询，以了解他们缺少的功能。我们得到的企业客户越多，就越经常要求我们提供用户管理功能。以前，用户可以手动分享对系统某些部分的访问。这对个人用户或2-3人的小团队来说已经足够了。同时，机构有更多的系统用户，所以手动的用户管理过程需要一段时间。

当我们看到这个功能的真正需求，并意识到它对企业客户的价值时，团队决定给它一个机会。在项目开始之前，我们创建了一个RAtSCNIuo图表。

我们的总经理Sergey和Mailtrap产品经理Yevgen担任审批人的角色。同为Mailtrap产品经理的Julia同意成为负责人。为了开发该功能，我们吸引了一名后端和一名前端开发人员。我们还需要一位内容作家的协助，以编写UI文本。这些专家就是这个项目的团队。当我们公司的所有设计师都忙于一些紧急任务时，我们联系了一家外部设计机构来协助我们完成新功能的UI/UX。最后但并非最不重要的是，项目参与者是Mailtrap的用户，他们测试了该功能并分享了他们的反馈。

以下是这个项目的责任分配表的情况。

	总经理(Sergey)	Mailtrap产品经理(Yevgen)	产品经理(Julia)	团队（开发人员和一个内容作家）	外部设计机构	Mailtrap用户
为该功能创建用户故事	I	A	R	T	C
估计工作范围	I	A	R	T	C
开发功能的后端部分	I	A	R	T	I
开发功能的前端部分	I	A	R	T	I
创建功能的设计	A	C	R	T	C
为功能用户体验撰写文本	I	A	R	T
用真实用户测试该功能	I	A	R	I	I	U

案例3.计划与定价页面上的升级错误信息

这个案例也与Mailtrap产品有关。Mailtrap为其用户提供了一个免费订阅计划和几个付费计划。我们的数据分析员不断检查转换率，并检测对其有负面影响的方面。在一次检查后，我们发现免费用户在尝试使用付费功能时看到的错误信息令人困惑，并使客户放弃。

客户不仅不能理解他们可能会使用哪些功能，哪些功能是不可用的，而且他们也没有看到一个付费功能可能带来的价值，因此，没有动力将他们的订阅计划升级为付费选项。

为了解决这个问题并提高转换率，我们的团队启动了一个相应的项目。批准人仍然是前一个项目的批准人（谢尔盖和叶夫根）以及负责人（朱莉娅）。我们还需要一个内容作家来创造新的、清晰的和有吸引力的文本，一个设计师，前端和后端开发人员，以及一个数据分析师来完成这个项目。所有这些专家都担任着团队的角色。

我们的团队联系了一位讲母语的人，以检查文本并确保它们是直截了当的，不会被误解。这个人扮演着被咨询者的角色，因为这是一个一次性的工作。此外，我们与营销专家团队分享了我们的发现，因为他们可能对项目结果感兴趣。因此，我们把他们加入到我们的责任分配表中。下面是它的样子。

	总经理(Sergey)	Mailtrap产品经理(Yevgen)	产品经理 (Julia)	团队（开发人员、设计师、数据分析员、内容作家）	母语者	营销团队	Mailtrap用户
与客户澄清问题	I	A	R	I	I	C
为内容作者创建一个技术任务	A	R	T	I
校对文本以确保其清晰	I	A	R	C
为该信息进行设计	I	A	R	T
开发前台和后台	I	A	R	T
检查信息更新后的转换情况	I	A	R	T	I
进行客户访谈以获得反馈	I	A	R	T	I	U

所有这些图表帮助我们启动、管理并成功完成每个特定项目。为了创建这些图表，我们遵循上面分享的步骤和一些你也需要知道的最佳做法。

在创建RASCI矩阵时，该做什么和不该做什么

• 不要使用名字。使用位置。意思是说，最好在图表的上行写上项目所需专家的职位（后台开发人员、设计师、项目经理），而不是名字，因为角色是静态的，但人可以改变。
• 每个任务指定一个责任人。责任人不能被委托。应该只有一个人担任这个角色。每个任务都应该有一个负责任的人。
• 让一些单元格空着。如果图表中有一些空白的地方，也是可以的。最重要的角色是批准人和负责人，其他角色可以省略。不要因为你的图表中没有 "咨询者 "或 "被告知者"，就把不必要的人牵扯进来。最好是保持团队的小规模。否则，你将无法保持每个人的注意力。
• 在与团队进行审批时，要检查你的矩阵。确保每个人都明白自己的责任，并且有他们的承诺。不要只是假设他们接受自己的角色。可能会发生有些人不能参与，有些人对项目不感兴趣，或者你可能找到一个更适合项目的新人。
• 定义一个清晰的沟通渠道。确保团队中的每个人都知道谁拥有每个角色，以及他们要如何相互沟通。
• 定期检查这个过程是否有效，每个角色是否发挥了应有的作用。简单地规划矩阵并不意味着这个过程会自行运作。定期从项目参与者那里获得反馈，必要时修改图表。
• 当角色和任务发生变化时，再回到矩阵中去更新它。项目可以改变，团队的组成也可以改变。为了获得RASCI图表的所有好处，它需要只包含最新的信息。

总结

职责分配表是一个相对容易使用的工具，有很多显著的优点。开发一个图表不需要很多时间，特别是如果你以前做过的话。当为你的项目和你的团队使用RASCI图表时，最重要的规则是确保一个人同意他们被分配的角色和责任。另外，修改图表并根据每个特定项目的需要进行调整是完全可以的，就像我们的团队一样。

如果你想知道更多关于Railswarians如何组成团队，确保高水平的参与和激励，请阅读我们的博客和

订阅我们的Youtube频道!