我是一个看客 今天给各位分享软件开发责任分配矩阵的知识，其中也会对开发软件分工进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录一览：
- 1、【PMBOK】你必须知道的数据表现技术
- 2、RASCI责任矩阵
- 3、#PMBOK第六版# 易混淆概念-辨析
- 4、简述软件项目进度计划在哪个阶段制定及背景
- 5、管理工具系列之RACI矩阵
- 6、责任分配矩阵的构成
【PMBOK】你必须知道的数据表现技术
在PMBOK知识体系中，工具与技术是很重要的考点，同时也是适用于工作和生活的直接技能和方法。深刻理解工具与技术可以提高自己处理问题的能力。
备考的同学们建议完整看完工具在不同过程中的应用， 提别注意关键字，用于在做题时快速定位某个工具。 仅自我提升的同事们只需要看 定义或加粗过程的介绍 就可以了。
收集需求阶段 用来对大量创意 进行分组 的技术，以便进一步审查和分析。
管理质量过程 亲和图可以对潜在缺陷成因 进行分类 ，展示最应关注的领域。
管理质量过程 因果图，又称“鱼骨图”、“why-why分析图”和“石川图”，将问题陈述的原因分解为离散的分支，有助于识别问题的主要原因或根本原因。图 8-9 是因果图的一个例子。
控制质量过程 因果图用于识别质量缺陷和错误可能造成的结果。
控制质量过程 控制图用于确定一个过程是否稳定，或者是否具有可预测的绩效。
规格上限和下限（USL/LSL） ----反映了可允许的最大值和最小值。超出规格界限就可能受处罚（次品）。 控制上限和下限（UCL/LCL） ----代表一个稳定的过程的自然波动范围（失控—无需停产但必须查原因）。控制界限通常设在离过程均值（0西格玛）±3西格玛旳位置。
项目经理和相关方可基于计算出的控制界限，识别须采取纠正措施的检查点，以预防不在控制界限内的绩效。
控制图可用于监测各种类型的输出变量。虽然控制图最常用来跟踪批量生产中的重复性活动，但也可用来监测成本与进度偏差、产量、范围变更频率或其他管理工作成果，以便帮助确定项目管理过程是否受控。
控制图----用来确定一个 过程是否稳定 ，或者 是否具有可预测的绩效 。（无界限的控制图叫“趋势图”）
也称过程图，用来显示在一个或多个输入转化成一个或多个输出的过程中所需要的步骤顺序和可能分支。
它通过映射水平价值链的过程细节来显示活动、决策点、分支循环、并行路径及整体处理顺序。图 8-6 展示了其中一个版本的价值链，即 SIPOC（供应商、输入、过程、输出和客户）模型。
规划质量管理 流程图可能有助于了解和估算一个过程的质量成本。通过工作流的逻辑分支及其相对频率来估算质量成本。这些逻辑分支细分为完成符合要求的输出而需要开展的一致性工作和非一致性工作。用于展示过程步骤时，流程图有时又被称为“过程流程图”或“过程流向图”，可帮助改进过程并识别可能出现质量缺陷或可以纳入质量检查的地方。
管理质量过程 流程图展示了引发缺陷的一系列步骤。
实施定性风险分析 如果使用了 两个以上的参数 对风险进行分类，那就不能使用概率和影响矩阵，而需要使用其他图形。
例如，气泡图能显示三维数据。在气泡图中，把每个风险都绘制成一个气泡，并用x 轴值、y 轴值和气泡大小来表示风险的三个参数。图 11-10 是气泡图的示例，其中，X轴代表可监测性，Y轴代表邻近性，影响值则以气泡大小表示。
管理质量过程 直方图是一种 展示数字数据的条形图 ，可以展示每个可交付成果的缺陷数量、缺陷成因的排列、各个过程的不合规次数，或项目或产品缺陷的其他表现形式。
控制质量过程 直方图可按来源或组成部分展示缺陷数量。
逻辑数据模型把 组织数据可视化 ，以商业语言加以描述， 不依赖 任何特定 软件开发技术 。
规划质量管理 逻辑数据模型可用于 识别 会出现 数据完整性 或其他 质量问题 的地方。
矩阵图在行列交叉的位置展示因素、原因和目标之间的 关系 强弱。根据可用来比较因素的数量，项目经理可使用不同形状的矩阵图，如L 型、T 型、Y 型、X 型、C型和屋顶型矩阵。
规划质量管理 它们有助于识别对项目成功至关重要的质量测量指标。
管理质量过程 矩阵图在行列交叉的位置展示因素、原因和目标之间的 关系强弱 。
规划资源管理过程 适用于本过程的数据表现技术包括（但不限于）图表。数据表现有多种格式来记录和阐明团队成员的角色与职责。大多数格式属于层级型、矩阵型或文本型。有些项目人员安排可以在子计划（如风险、质量或沟通管理计划）中列出。
无论使用什么方法来记录团队成员的角色，目的都是要确保每个工作包都有明确的责任人，确保全体团队成员都清楚地理解其角色和职责。层级型可用于表示高层级角色，而文本型则更适合用于记录详细职责。
1. 层级型。 可以采用传统的组织结构图，自上而下地显示各种职位及其相互关系。
1.1 工作分解结构 (WBS)。 WBS 用来显示如何把项目可交付成果分解为工作包，有助于明确高层级的职责。
1.2 组织分解结构(OBS)。 WBS 显示项目可交付成果的分解，而OBS 则按照组织现有的部门、单元或团队排列，并在每个部门下列出项目活动或工作包。运营部门（如信息技术部或采购部）只需要找到其所在的OBS 位置，就能看到自己的全部项目职责。
1.3 资源分解结构。 资源分解结构是按资源类别和类型，对团队和实物资源的层级列表，用于规划、管理和控制项目工作。每向下一个层次都代表对资源的更详细描述，直到信息细到可以与工作分解结构（WBS）相结合，用来规划和监控项目工作。
2 责任分配矩阵。 责任分配矩阵展示项目资源在各个工作包中的任务分配。矩阵型图表的一个例子是 职责分配矩阵(RAM) ，它显示了分配给每个工作包的项目资源，用于说明工作包或活动与项目团队成员之间的关系。
在大型项目中，可以制定多个层次的RAM。例如，高层次的RAM 可定义项目团队、小组或部门负责WBS 中的哪部分工作，而低层次的 RAM 则可在各小组内为具体活动分配角色、职责和职权。矩阵图能反映与每个人相关的所有活动，以及与每项活动相关的所有人员，它也可确保任何一项任务都只有一个人负责，从而避免职权不清。
RAM的一个例子是 RACI（执行、负责、咨询和知情） 矩阵，如图9-4所示。图中最左边的一列表示有待完成的工作（活动）。分配给每项工作的资源可以是个人或小组，项目经理也可根据项目需要，选择“领导”或“资源”等适用词汇，来分配项目责任。如果团队是由内部和外部人员组成，RACI矩阵对明确划分角色和职责特别有用。
3 文本型。 如果需要 详细描述 团队成员的职责，就可以采用文本型。文本型文件通常以概述的形式，提供诸如职责、职权、能力和资格等方面的信息。这种文件有多种名称，如职位描述、角色 — 职责 — 职权表，该文件可作为未来项目的模板，特别是在根据当前项目的经验教训对其内容进行更新之后。
收集需求阶段 把从 头脑风暴中获得的创意整合成一张图 ，用以反映创意之间的 共性与差异，激发新创意。
规划质量管理 思维导图是一种用于可视化组织信息的绘图法。质量思维导图通常是基于单个质量概念创建的，是绘制在空白的页面中央的图像，之后再增加以图像、词汇或词条形式表现的想法。思维导图技术可以有助于快速收集项目质量要求、制约因素、依赖关系和联系。
规划相关方参与 思维导图用于对相关方信息、相互关系以及他们与组织的关系进行可视化整理。
实施定性风险分析 概率和影响矩阵是把每个风险发生的概率和一旦发生对项目目标的影响映射起来的表格。此矩阵对概率和影响进行组合，以便于把单个项目风险划分成不同的优先级组别（见图 11-5）。
基于风险的概率和影响，对 风险进行优先级排序 ，以便未来进一步分析并制定应对措施。采用风险管理计划中规定的风险概率和影响定义，逐一对单个项目风险的发生概率及其对一项或多项项目目标的影响（若发生）进行评估。
然后，基于所得到的概率和影响的组合，使用概率和影响矩阵，来为单个项目风险分配优先级别。组织可针对每个项目目标（如成本、时间和范围）制定单独的概率和影响矩阵，并用它们来评估风险针对每个目标的优先级别。组织还可以用不同的方法为每个风险确定一个总体优先级别。即可综合针对不同目标的评估结果，也可采用最高优先级别（无论针对哪个目标），作为风险的总体优先级别。
管理质量过程 散点图是一种展示 两个变量之间的关系 的图形，它能够展示两支轴的关系，一支轴表示过程、环境或活动的任何要素，另一支轴表示质量缺陷。
控制质量过程 散点图可在一支轴上展示计划的绩效，在另一支轴上展示实际绩效。
规划沟通管理 如图13-6所示，相关方参与度评估矩阵显示了个体相关方 当前和期望参与度之间的差距 。在本过程中，可进一步分析该评估矩阵，以便为填补参与度差距而识别额外的沟通需求（除常规报告以外的）。
监督沟通 它可以提供与沟通活动效果有关的信息。应该检查相关方的期望与当前参与度的变化情况，并对沟通进行必要调整。
规划相关方参与 相关方参与度评估矩阵用于将相关方当前参与水平与期望参与水平进行比较。对相关方参与水平进行分类的方式之一，如图 13-6 所示。相关方参与水平可分为如下：
u n 不了解型。不知道项目及其潜在影响。
u n 抵制型。知道项目及其潜在影响，但抵制项目工作或成果可能引发的任何变更。此类相关方不会支持项目工作或项目成果。
u n 中立型。了解项目，但既不支持，也不反对。
u n 支持型。了解项目及其潜在影响，并且会支持项目工作及其成果。
u n 领导型。了解项目及其潜在影响，而且积极参与以确保项目取得成功。
在图 13-6 中，C 代表每个相关方的当前参与水平，而D 是项目团队评估出来的、为确保项目成功所必不可少的参与水平（期望的）。应根据每个相关方的当前与期望参与水平的差距，开展必要的沟通，有效引导相关方参与项目。弥合当前与期望参与水平的差距是监督相关方参与中的一项基本工作。
监督相关方参与 使用相关方参与度评估矩阵，来跟踪每个相关方参与水平的变化，对相关方参与加以监督。
识别相关方 相关方映射分析和表现是一种利用 不同方法对相关方进行分类 的方法。
对相关方进行分类有助于团队与已识别的项目相关方建立关系。常见的分类方法包括：
权力利益方格、权力影响方格，或作用影响方格。基于相关方的职权级别（权力）、对项目成果的关心程度（利益）、对项目成果的影响能力（影响） ，或改变项目计划或执行的能力，每一种方格都可用于对相关方进行分类。对于小型项目、相关方与项目的关系很简单的项目，或相关方之间的关系很简单的项目，这些分类模型非常实用。
相关方立方体。 这是上述方格模型的改良形式。本立方体把上述方格中的要素组合成三维模型，项目经理和团队可据此分析相关方并引导相关方参与项目。作为一个多维模型，它将相关方视为一个多维实体，更好地加以分析，从而有助于沟通策略的制定。
凸显模型。 通过评估相关方的权力（职权级别或对项目成果的影响能力）、紧迫性（因时间约束或相关方对项目成果有重大利益诉求而导致需立即加以关注）和合法性（参与的适当性），对 相关方进行分类 。在凸显模型中，也可以用邻近性取代合法性，以便考察相关方参与项目工作的程度。这种凸显模型适用于复杂的相关方大型社区，或在相关方社区内部存在复杂的关系网络。
凸显模型可用于确定已识别相关方的 相对重要性 。
影响方向。 可以根据相关方对项目工作或项目团队本身的影响方向，对相关方进行分类。可以把相关方分类为：
u n 向上（执行组织或客户组织、发起人和指导委员会的高级高级管理层）；
u n 向下（临时贡献知识或技能的团队或专家）；
u n 向外（项目团队外的相关方群体及其代表，如供应商、政府部门、公众、最终用户和监管部门）；
u n 横向（项目经理的同级人员，如其他项目经理或中层管理人员，他们与项目经理竞争稀缺项目资源或者合作共享资源或信息）。
优先级排序。 如果项目有大量相关方、相关方社区的成员频繁变化，相关方和项目团队之间或相关方社区内部的关系复杂，可能有必要对相关方进行优先级排序。
PMBOK第六版工具与技术系列【更新中】
RASCI责任矩阵
RACI矩阵的中文名字叫责任分配矩阵，顾名思义是管理职责分配的工具。RACI矩阵是非常有效的人力资源管理工具和项目管理工具。
A: Accountable负责批准与布置任务，具有目标导向，负责确定目标、确定目标牵头者（即R），并评价“R”所承担目标的完成情况。
R: Responsible负责牵头完成“A”布置的任务与目标，具有结果导向，对“A”布置的任务与目标的结果负全责。所承担任务与目标与其他部门（或岗位）配合时，负责确定需要的配合部门，确定配合部门的工作内容、工作标准等。“R”负责将其牵头的工作分解给相关的“S”、“C”与“I”。
S: Support负责配合“R”完成指标的工作，达到既定的目标。对于同一任务，“R”可指定多个“S”。
C: Consulted负责为各个相关的角色提供咨询服务。
I: Informed信息的接受者，与任务的关系最为间接。
项目阶段分为：需求阶段、开发阶段、测试阶段、发布验收阶段。
#PMBOK第六版# 易混淆概念-辨析
项目集管理 重点关注项目间的依赖关系，通过对彼此间存在内在联系的一系列项目的集中管理，实现项目集收益。
项目组合管理 的目的是通过对其所有组成部分（项目集、项目和其他相关工作但彼此间不一定存在必然联系）的审查，实现项目组合的价值最大化。项目集中的项目，彼此间一定有相互的内在联系；而项目组合中的项目集及项目之间，不一定有这种关系。
项目生命周期 是指项目从启动到收尾所经历的一系列阶段，阶段的名称和数量取决于参与项目的一个或多个组织的管理与控制的需要、项目本身特征及其所在的应用领域。通常来说，阶段与阶段的关系有两种基本类型：一是顺序关系排列，二是交叠关系排列，这种阶段交叠被称为“快速跟进”。项目生命周期可长可短，大型项目可划分为多个项目阶段，而简单的小项目可能只有一个阶段，具体划分要根据不同项目的具体需要来确定。所以，不同的项目具有不同的项目生命周期。项目生命周期也有一个框架性的总体结构，不论项目的大小繁简，都可以分为启动项目、组织与准备、执行项目工作和结束项目。
项目管理生命周期 适用于任何项目，不论是大型的土建项目，还是组织一场晚会，都具有相同的项目管理生命周期。
项目采购管理过程所涉及的各种活动构成了 合同生命周期 。在复杂项目中、可能需要同时或先后管理多个合同或分包合同。在这种情况下，单项合同的生命周期可在项目生命周期中的任何阶段结束。从这个意义上说，只有涉及对外采购的项目才具有合同生命周期，并且合同生命周期在时间范围上，包括在对应的项目生命周期内。也就是，合同生命周期的长度小于或等于项目生命周期，一个项目生命周期内可以包含一个或多个合同生命周期。
产品生命周期 包含通常顺序排列且不相互交叉（注意与项目生命周期的区别）的一系列产品阶段，由组织的制造和控制要求决定，如市场调研、产品研发、量产、运营、维护、退市等。产品生命周期往往包括一个或多个项目生命周期。
项目进度管理计划 是项目管理计划的一部分，或者说是其中一个子计划，是项目时间管理知识领域规划进度管理过程的输出。PMBOK指南（第6版）指出，进度管理计划为编制、监督和控制项目进度建立准则和明确活动。其中包括确定进度计划的编制方法和工具，活动持续时间估算的可接受区间、计量单位、绩效测量规则及报告格式等内容。由此可见，项目进度管理计划中并不包含项目具体进展、里程碑等与项目工作进度密切相关的内容。
项目进度计划 是指利用各种进度计划编制工具，如网络分析法、关键路径法、关键链法、资源平衡及相关项目管理软件等，在考虑资源约束的情况下制定的一份标明各项活动的计划开始和结束时间，确定项目里程碑的文件。被批准的进度计划就是进度基准，用来与实际的进度情况对比，得出项目进度绩效。可见项目进度计划是与具体的项目工作密切相关的，这一点与项目管理计划不同。
与进度管理计划和进度计划相类似，范围管理计划和范围基准、成本管理计划和成本基准、质量管理计划和质量测量指标等也有类似区别。总之， “XX管理计划”通常都不会涉及具体的管理内容，而是强调相关制度、流程、政策、工具的选择与应用。在各种“管理计划”中， 唯一例外的是沟通管理计划，其中详细规定了与项目工作相关的沟通对象、沟通需求、沟通频率、沟通方式等细节内容。
根据各 项目管理过程 之间的整合、相互作用及不同用途，将这些过程归纳为5 类，即 启动、规划、执行、监控和收尾 。项目管理过程组是项目管理自身特性决定的，这5大过程组之间有清晰和确定的相互依赖关系，在每个项目上通常都按相同的顺序进行，与应用的领域或行业无关。为有效完成某些重要的可交付成果，在需要特别控制的位置将项目分界，就形成项目阶段。项目阶段大多是按顺序完成的，但在某些情况下也是可以重叠的。
将项目人为划分 阶段 ，完全是出于对项目有效管理、规划和监控的目的考虑，所以项目的阶段划分是由具体项目的自身需求、特点决定的，不同的项目有不同的项目阶段。任何一个项目阶段都要有相应的阶段成果，成果的完成并被接受是阶段结束的标志。项目阶段不同于项目管理过程组，每个项目阶段一定程度上可以看做一个“子项目”，因此不论这个项目阶段的名称是什么，具体执行时都要用到项目管理全部5大过程组、49个过程的知识与技能。
阶段与阶段之间通常存在3 种基本关系:
①顺序关系—依次完成，无法压缩进度;
② 交叠关系—可以“快速跟进”以压缩进度，但引入了风险;
③迭代关系—走一步看一步，应用于不明确、不确定或快速变化的环境中，但不利于长期规划。
在多阶段项目中，上述3种关系可能都有出现。
纠正措施、预防措施、缺陷补救和更新都属于变更请求的范畴 。其中纠正措施是指为了使项目工作的未来期望绩效与项目管理计划保持一致，而对项目执行工作下达的书面指令。即在监控活动中，当发现当前绩效已经偏离原计划时，所采取的必要措施。该措施必须是正式的、书面的。预防措施是指通过实施某项活动。以降低项目风险消极后果的发生概率的书面指令。即在监控活动中，对预计将要发生的消极风险所采取的事前应对手段。该措施必须是正式的、书面的。
缺陷补救是指识别项目组成部分的某一缺陷之后所形成的正式文件，用于就如何修补该缺陷或彻底替换该部分而提出的建议。即针对已经出现的缺陷所采取的弥补办法，一般缺陷补救仅用于与质量相关的问题。更新是对正规受控的文件或计划等的变更，以反映修改或增加的意见或内容:即更新主要针对既有的流程、制度、政策、计划等文件的修订，而不是指具体的办法和措施。虽同为变更请求范畴的概念，这是区别于纠正措施、预防措施和缺陷补救最大的不同。
项目启动会和项目开踢会这一组概念在考试中经常出现，主要是由于翻泽的问题，让人感觉难以区分。项目启动会议的英文是 initiating meeting ，是在启动阶段结束时召开的会议。该会议的主要任务是发布项目章程，宣布任命的项目经理，并说明项目经理所拥有的权力。另外，还包括团队成员互相认识，介绍项目目标，主要工作内容。让客户方领导表达信心和推动的决心，调动员工的积极性，让客户方从上到下达成一种共识，为项目团队日后开展相关的工作扫除障碍等。项目启动会议的特点是以单向发布为主，不需要互动的讨论、分析等团队活动，通常时间都比较短。
项目开踢会议的英文是 kick‐off meeting ，是在规划阶段结束时召开的会议。该会议的主要目的包括正式批准综合性项目计划，并在干系人之间达成共识，落实具体项目工作， 为进人项目执行阶段做准备;开踢会议召开前，通常已经确定了项目的组织结构，并已经对团队成员的角色与职责进行定义。此时用于指导项目的项目管理计划已经制定出来，已经有了项目范围说明书、范围基准、各分项管理计划、进度计划、采购计划、风险登记册等文件。因此，在开踢会议中，通常需要对项目的范围、进度、成本、风险应对等事项进行确认，并在干系人之间达成共识。
焦点小组会议和引导式研讨会都是项目范围管理知识领域收集需求过程的工具，其中焦点小组会议是把相关干系人、专家集中在一起，由专业的主持人引导大家就产品、服务或成果的期望和态度进行沟通。
引导式研讨会和焦点小组会议相类似的地方是有主持人把控，但最显著的特征是参加引导式研讨会的人一定是跨职能部门的干系人。这种会议方式由于同时引入了不同职能部门人员参与，因而更容易发现问题，是快速定义跨职能需求和协调干系人差异的重要技术，它比单一的会议能更快地发现和解决矛盾，并且效率更高。引导式研讨会的典型实例是软件行业的联合应用开发(JAD)和制造行业的质量功能展开(QFD )。在敏捷开发中，用户故事(user story)也是引导式研讨会的具体应用。
项目工作说明书(SOW) 是制定项目章程过程的输入，是对项目所需交付的产品、服务或成果的叙述说明。项目工作说明书由项目团队以外的发起人、组织、客户等提供，内容相对简单，是对可交付成果的简要介绍，主要包括项目的业务需求、产品范围的大致描述和项目所在组织的战略计划。
采购工作说明书 是规划采购过程的输出，根据PMBOK指南(第6版)中给出的定义，采购工作说明书依据项目范围基准，为每次采购编制工作说明书(SOW)，对将要包含在相关合同中的那一部分项目范围进行定义。采购工作说明书虽然也叫 SOW，但与内容简略、不严谨的项目工作说明书不同，采购工作说明书必须清晰、完整，详细描述拟采购的产品、服务或成果，以便潜在卖方确定他们是否有能力提供这些产品、服务或成果。
项目范围说明书 是定义范围过程的输出，它详细描述项目的可交付成果，以及为提交可交付成果而必须开展且仅需开展的工作，项目范围说明书的编制是由项目团队完成的，是项目干系人之间就范围所达成的共识，主要包括产品范围描述、验收标准、可交付成果、项目除外责任、项目的制约因素和假设条件。如果有合同，合同的条款通常也属于制约因素。项目范围说明书为评价变更请求，或额外工作是否超出项目边界提供基准。从内容上看，项目范围说明书和项目章程有一定程度的重叠，但它们的详细程度完全不同，项目章程记录的与范围相关的内容以高层级信息、为主，而项目范围说明书则是对项目具体范围的详细描述。
项目工作说明书简略，而采购工作说明书和项目范围说明书详细。前者由项目团队以外的组织、发起人、客户提供，后者由负责采购工作的部门或项目团队共同编制。对它们的区分，要抓住上述特点。
工作包 是项目范围管理知识领域中，创建WBS 过程的输出——工作分解结构的底层单元。在这个分解过程中，被分解的对象是项目的可交付成果，虽然叫“工作分解结构”，但是这里的工作是指经过努力而取得的产品、服务或成果，而不是“努力”本身，所以分解得到的工作包，也是精细化、具体化的可交付成果，是名词。可交付成果的分解通常遵循如下原则: 分解层级一般控制在 5层以内，完成每个工作包的工作时间控制在80小时以内(按每天工作 8 小时计算，即不超过 10 个工作日)。
活动 是指为了完成工作包而必须开展的工作，是对工作包进一步分解的产物，是项目时间管理知识领域中，定义活动过程的输出。WBS中的每一个工作包都要分解成活动、通过这些活动来完成可交付成果，所以分解得到的活动描述都是动词。活动是开展估算、编制进度计划及执行和监控项目工作的基础。
确认范围 关注的是客户对已经完成的可交付成果的接受程度，是在项目监控过程中对可交付成果的外部验收。确认范围就是要检查范围，而项目范围是由WBS全部底层的工作包界定的。既然WBS 是对可交付成果的分解，最底层的工作包都是足够精细的可交付成果，那么确认范围自然也是对这些可交付成果的确认和检查。
控制质量 主要关注的是可交付成果是否正确，是否满足质量要求。从对可交付成果的认可角度来说，控制质量是团队内部的自查、自测，属于内部验收。只有通过了内部验收，接下来才能提请外部客户来验收，即确认范围，这属于外部验收。因此控制质量往往要先于确认范围二另外，从它们不同的输出结果也能体现二者的差异:控制质量的输出是核实的可交付成果(内部，团队自己核实、检查);确认范围的输出是验收的可交付成果(外部，由客户确认)。
强制依赖关系 又叫硬逻辑关系、物理依赖关系，它们往往与一些实际的客观限制有关。例如，先计划、再生产，先建地基、再盖楼，是活动本身的特性决定的，是刚性的。另外，合同中规定的、需要执行的条款，也属于强制依赖关系，不能随意改动。
外部依赖关系 是项目活动和非项目活动之间的依赖关系，涉及外部组织的、项目以外的、项目团队无法控制的约束，如项目活动得以开展的配合条件，政府的法律、法规等。例如，产品测试需要受到实验室准备工作的完成才能得以开始，工程的开工必须要通过政府环境测评，节假日的加班必须提前得到类似工会组织的批准等。
内部依赖关系 是项目活动之间的紧前关系，通常在项目团队的控制之中，如只有机器组装完毕，团队才能对其进行测试。这和外部依赖关系是不一样的，属于内部依赖关系的活动其范围在项目以内、或者说它们都是在项目活动清单中记录的内容。
强制依赖关系是项目活动自身客观规律决定的;外部依赖关系多是项目外部组织、部门人为设定的，项目团队无法改变。虽然与项目相关的合同也是法律文件的一种，必须要遵守，但是合同属于项目内部文件，所以也属于强制依赖关系，而不是外部依赖关系，要注意区别。
类比估算和参数估算都是估算活动的工具与技术，在估算活动时间、估算成本等过程中都有应用。
类比估算 是以过去类似项目的参数值为基础，来估算当前项目或未来项目的同类参数。在真实项目中采用类比估算的方法，实际上经常是把和当前类似的以往项目数据照搬过来，直接应用。这种方式通常在项目早期信息不足的情况下使用。类比估算的优点是耗费时间短、成本低，但估算的结果准确性较差，属于粗略估算，这种估算方法综合利用了历史信息、和专家判断。如果用于参考的项目与当前项目有本质的相似，而且参与估算的人员有足够的专业知识和经验，则这种估算结果也是可靠的:请注意，类比估算和自下而上估算不是同一种工具！
从PMBOK指南(第6版)项目成本管理知识领域估算成本过程中可以清楚地看到，类比估算和自下而上估算同属估算成本过程的工具与技术。自下而上估算是对单个工作包或活动的成本、历时进行最具体、细致的估算，然后把这些细节性数据向上汇总或“滚动”到更高层次。这种估算方法实际上可以使用包括类别、参数、三点等所有恰当的估算技术，其准确性通常取决于单个活动或工作包的规模和复杂程度。参数估算也是参照过去的项目经验，但是与类比估算最大的区别是参数估算一定有成熟的数学模型或公式，通过套用公式，计算得出结果。
参数估算通 常适用于简单重复性的工作(如修路、搬砖、铺设电缆等)，而不适用于脑力劳动、创造性劳动(如咨询服务、新产品开发、设计等)。参数估算的准确性取决于参数模型的成熟度和基础数据的可靠性。
资源日历 是站在资源的角度，说明相关人员、设备、物资等什么时间可投入项目，什么时间不可用或休息。资源日历中要列出资源的属性，包括经验和/或技能水平，以及资源的来源等信息。资源日历是估算活动资源过程的输入，组建项目团队过程的输出，实施采购过程的输出。
与资源日历概念类似，还有项目日历和自然日历。项目日历规定了可以开展进度活动的工作日和工作班次，是指开展项目工作的基准日历，不含节假日;自然日历是自然时间标段，包括工作日和节假日。这两种日历仅仅表示时间概念，与项目资源无关。例如，虽然资源在周末可以工作(资源日历定义)，但是项目并不可以在周末来执行(项目日历定义)，那么该项任务就不会在周末被执行;或者，虽然定义了任务可以在周末执行(项目日历定义)，但是资源不可以在周末工作(资源日历定义)，那么这项任务也是不会在周末被执行的。
资源直方图 是站在项目的角度，说明项目工作对具体资源的需求，包括在整个项目期间每单位时间，如每周(或每月)需要某人、某部门或整个项目团队的工作小时数。资源直方图是规划人力资源管理的输出(人力资源管理计划的组成部分)的工具。
责任分配矩阵 显示工作包或活动与项目团队成员之间的联系，说明哪项工作由谁负责， 可确保任何一项任务都只有一个人负责，从而避免混乱。责任分配矩阵的典型应用是RACI(执行、负责、咨询和知情)图，用以具体说明每个人在具体工作中的职责差别。责任分配矩阵是规划人力资源管理过程的工具。
提前量和滞后量都是排列活动顺序及制定进度计划过程的工具与技术。
提前量 是指相对于紧前活动，其紧后活动可以提前开始的时间。例如在设计图纸完全交付前 2 周，开始对已经完 成部分进行审核，这是带 2 周提前量的完成到开始的逻辑关系。这里紧后活动的提前开始，不同于进度压缩技术中的快速跟进，提前量是活动本身允许的，不存在引人风险的问题，而快速跟进是把本应顺序执行的活动进行部分或全部并行，以压缩时间，这有可能造成返工和风险增加。
滞后量 是相对于紧前活动，其紧后活动需要推迟开始的时间。例如在标书提交 1 周后，开始启动评标活动，这是带 1 周滞后量的完成到开始的逻辑关系。在进度网络图中，加入提前量可以在条件允许的情况下提早开始紧后活动;而滞后量是在某些限制条件下，在紧前和紧后活动之间增加一段不需要工作或资源的自然时间。需要注意的是，提前量和滞后量的使用不能代替进度活动的逻辑关系。另外，虽然活动的提前量和滞后量将体现在最终的项目进度计划里，但是在估算活动持续时间的时候，不应包含任何活动的滞后量(例如，某活动持续时间 3 天外加 2 天的滞后量，则该活动历时就是 3 天，不能计算为 5 天)。
总浮动时间 ，也叫总时差，是指整个项目的最后一项活动的最早完成时间与项目要求的完工时间的差值。它受到活动的选择性依赖关系的影响。总浮动时间为正，说明进度计划不但可以满足项目按时完成的要求，而且还可以提前完成。总浮动时间为负，说明项目进度不能满足项目按时完工的要求。需要通过赶工等进度压缩技术才能弥补时间的差距。例如，某项目要求 100 天完成，进度计划规划 105 天才能完成，总浮动时间就是‐5 天。如果进度计划规划 97 天完成，总浮动时间就是+3 天。如果进度计划规划也是 100 天完成，总浮动时间就是 0。关键路径就是总浮动时间为 0 或负数的路径，即关键路径法是一个时间约束性的进度计划规划方法，中间没有喘息的机会。关键路径法不考虑资源的约束。
自由浮动时间 ，也叫自由时差，是指某项活动在不影响其紧后活动最早开始时间的情况下可以延迟的时间量，是指向同一活动的各项活动总浮动时间之间的相对差值。既然自由浮动时间是指向同一活动的各项活动的总浮动时间的相对差值，那么只有两项或更多项活动指向同一活动时才存在自由浮动时间。自由浮动时间总是正值。
赶工 是指投人更多的资源.加快工作进度，进而缩短工期，如加班、增加人员、投入额外的费用。并不是所有工作都可以通过赶工压缩进度，赶工一般只对简单重复的工作有效，如卸货、修路、挖沟等。在一般情况下，赶工有可能导致风险和/或成本增加，但是如果当成本与项目持续时间有直接关联时，如项目工作需一要从组织外部聘请按工作日计薪的技术专家，通过赶工来缩短工作周期，也有可能节省总成本。认为采用赶工的手段就一定导致项目成本增加的说法是片面的、不正确的。
快速跟进 把原来应该串行的工作在一定程度上并行执行，比如样机的设计图纸还没有全部通过审核。就开始零部件的生产。活动之间的选择性依赖关系是实现快速跟进的基础，它可能导致返工和风险的增加。
赶工和快速跟进都属于进度压缩技术。两种方法相同的地方是都不改变项目范围，都是针对关键路径上的活动，都可以缩短项目的进度时间，都可能引入风险。一旦压缩了历时，就要重新检查关键路径，压缩后可能出现新的关键路径。
资源平衡和资源平滑都属于资源优化技术。
资源平衡技术 的核心在于将稀缺资源首先用到关键路径的关键活动，使关键路径上的活动的资源需求得到优先保证:通过资源平衡手段，可以避免资源被过度分配的情况。资源平衡会导致关键路径的改变，所以项目工期也会发生变化，通常是延期。
资源平滑 是对进度模型中的活动进行调整，使项目资源需求不超过预定资源限制。不同于资源平衡，资源平滑不改变关键路径，也不影响完工时间，活动只在其自由浮动时间和总、浮动时间允许的范围内延迟，所以资源平滑技术可能无法完全解决资源紧缺、抢夺及过度分配问题。
制约因素和假设条件存在于项目范围说明书中，制约因素是指已经客观存在且对项目范围、成本、进度、人员选择等方面起限制与约束作用的因素，如客户或执行组织事先确定的预算、强制性日期或强制性里程碑(如果把北京奥运会的开幕式看作一个项目，开幕日期定在 2008 年 8 月 8 日，就是一个时间上的制约因素。如果项目是根据合同实施的，那么合同条款的具体规定通常也是项目执行中的制约因素。假设条件是指当前不能确定的，假定为正确、真实或确定的因素。假设条件存在不确定性，影响项目规划的所有方面，也是风险的重要来源。制约因素和假设条件都会限制项目的灵活性。二者最大的区别在于:制约因素是确定的、客观存在的;而假设条件是当前不能确定的。作为项目范围基准的一部分，制约因素和假设条件是定义活动、估算活动持续时间、制定进度计划、估算成本、制定预算、识别风险和规划采购等多个过程的输入。
偏差分析 是控制范围、控制成本、控制风险等过程的工具与技术，是一种事后审查，把实际项目绩效与计划或预期的绩效相比较，根据偏离程度决定是否采取纠正、预防和改进等措施。
趋势分析 是控制成本和控制风险的工具与技术，是一种事前预测，它通过对项目绩效随时间的变化情况进行分析，根据已有的绩效信息，推断、预测项目绩效的未来发展趋势。偏差分析是用当前的绩效数据判断当前的项目状态，趋势分析是用一段时间内的绩效进展情况推断今后的项目状态，含有预测的成分。假设情景分析是制定进度计划过程和控制进度过程的工具/技术。
假设情景分析 是基于己有的进度计划，考虑各种各样的情景，根据假设情景分析的结果来评估项目进度计划在不利条件下的可行性，以及为克服或减轻意外情况的影响而编制应急和应对计划。
假设情景分析与偏差分析和趋势分析不同，它所分析的内容并不是客观存在的，或已经 发生 的绩效，而是对项目活动中有可能出现的假设情况、预置的问题进行推测，即对“如果情景 X 出现，情况会怎样?”这样的问题进行分析。
项目预算决定了被批准用于项目的资金，这个被批准的预算是考核项目成本绩效的基准。
完工预算(BAC) 是在项目启动前做出的，并没有实际工作绩效可以参考，是通过对 WBS 工作包中活动成本进行估算，然后自下而上地汇总，最终得出整个项目的总成本，加上应急储备后，还需经过管理层批准，就是项目完工预算。
完工估算(EAC) 是在项目已经启动，根据当前实际工作绩效估算的项目完工费用。由于工作进展期间的不确定因素影响，实际成本绩效可能偏离最初的完工预算（BAC），如果偏差过大，原绩效基准就需要用当前的完工估算(EAC)取代，成为新的成本基准，也称为新的 BAC。
完工尚需估算(ETC) 指的是从进行估算的当前时间点到最终项目完工这段时间内的工作全部完成需要多少资金的一个估算值。
工作绩效报告 是对收集的信息、进行组织与归纳，并通过与绩效测量基准的比较，来分析和展示绩效:绩效报告是正式的，主要向外部干系人提交项目过程文档。常用格式包括横道图、S 曲线、直方图和表格等，要有对比、分析和结论，通常还要对未来项目的状况和进展做出预计，并定期提交，如工程项目日/周/月报等。工作绩效报告是实施整体变更控制、管理沟通、管理项目团队、控制风险、控制采购等过程的输入，监控项目工作。
工作绩效信息 是从各控制过程收集并整合分析得到的绩效数据，是监控项目工作过程的输入，是确认范围、控制范围、控制进度、控制成本、控制质量、控制沟通、控制风险、控制采购和控制干系人参与等过程的输出。
工作绩效数据 是在执行项目工作过程中，从每个正在执行的活动中收集到的原始数据。相对于经过组织、归纳的绩效报告，工作绩效数据更像原材料，是没有经过加工的原始信息，可以包括项目活动过程中的各种状态、进展、阶段的情况。工作绩效数据可以内部共享并相互传递，但不适合直接提供给外部干系人:工作绩效数据是指导与管理项目工作过程的输出，也是确认范围、控制进度、控制成本、控制质量、控制沟通、控制风险、控制采购和控制干人参与等过程的输入。
（1）质量审计: 它是实施质量保证的工具，是一种独立的结构化审查，用来确定项目活动是否遵循了组织和项目的政策、过程与程序。质量审计的主要目的是在质量保证过程中识别良好/最佳实践和全部的差距/不足，为采取纠正措施提供借鉴:质量审计可事先安排，也可随机进行;司由内部或外部审计师进行。
（2）风险审计: 它是控制风险过程的工具，主要目的是检查并记录风险应对措施在处理已识别风险及其根源方面的有效性，以及风险管理过程的有效性。风险审计应该由尽可能多的项目干系人参与，可以在日常的项目审查会中进行风险审计，也可单独召开风险审计会议。
更多知识点陆续更新，有需要的同学可以私我领取资料。
简述软件项目进度计划在哪个阶段制定及背景
软件项目的生命周期包括项目启动阶段、项目规划阶段、项目执行阶段、项目控制阶段和项目收尾阶段。项目启动阶段的任务是识别客户需求内容，对客户提出的需求内容进行可行性分析、评估和立项。项目规划阶段的任务是为拟研发的软件项目制订一个详细的解决方案。为各种可交付成果准备工作计划。项目执行阶段就是具体实施项目规划中制订的各项工作内容。项目控制阶段任务是定期监测与度量项目执行情况阶段各项工作进展情况，识别是否有偏离计划之处，对于项目执行过程中出现的问题，及时发现并采取纠正措施，以确保项目目标实现。项目收尾阶段是交付产品以及总结经验教训。
一、项目启动阶段
（1）项目识别。开发部门接到业务部门提出的客户需求后，对客户需求内容进行确认，对客户需求做可行性研究分析，通过与客户进行交流沟通、分析评估后，对需求的可实现内容和不能实现的内容达成一致意见，开发部门对于确认的需求内容纳入公司整体项目管理体系中管理。并配合与业务部门撰写出详细的项目需求说明书。
（2）项目立项。软件项目通过评审后就可以进行立项，编制需求开发任务书。软件公司接到项目任务后，首先由公司项目管理办公室按照公司IT项日管理流程，为新项目建立信息档案，编制项目代码，启动项目开发工作。
二、项目规划阶段
（1）项目范围规划。包括给出项目背景描述、项目目标描述，对项目工作结构进行分解（WBS）。制订里程碑计划和工作责任分配矩阵。
（2）编制项目工作计划。项目工作计划编制要依据合同对工期的约定和要求、里程碑计划、WBS，参照公司类似项目的历史信息和项目内外部条件，各种资源状况等内容，编制项目工作计划，常用的技术方法是PERT网络技术、甘特图法。具体包括项目进度计划、项目人力资源计划、项目费用预算、风险控制计划、质m控制计划、项目采购计划、培训计划和方案评估计划。
（3）设计项目实现方案。包括项目技术实现方案、项目开发方案和项月测试方案。
（4）确定信息沟通与披露渠道。确认项目沟通的渠道和方式，建立项目信息披露机制。
（5）项目信息管理。通过专用的项目管理软件为项目编号建立信息档案，详细记载项目生命周期中每一个阶段产生的项目信息资料，要求项目组随时提交项目信息，逐步建成一个项目信息管理知识库。
三、项目执行阶段
（1）建立项目开发团队，明确团队组成形式。依据业务需求开发任务书中对项目完成时间、费用的要求，确认项目开发团队人员数量，明确项目经理，建立以项目经理为项目负责人的开发团队。团队组建完成后，项目经理组织团队人员进行交流学习和互相熟悉，说明项目任务、目标、规模、人员组成、规章制度和行为准则，个人岗位和责任，建立团队与外界的初步联系及相互关系，确立团队的权限，建立团队的绩效管理机制，争取公司各方面支持，根据团员特点分配职责，收集有关项目信息。
（2）实施项目开发测试。依据软件项目设计开发制度要求和软件项目管理规范，按照需求实现方案为项目具体开发做好准备。
（3）实施项目采购。项目经理及项目成员按照公司采购制度和流程控制要求，了解软件产品供应商市场，咨询市场询价，采购招投标及与中标供应商签订合同。
（4）项目信息人档管理。在项目的研发过程中，会产生很多来自不同层次和客户的项目管理所需信息和文档资料，及时、正确地搜集好这些项目信息并纳人项目信息管理档案中统一管理，为跟踪项目进程、提高项目控制能力及项目后评价、项目绩效考核打好基础。
四、项目控制阶段
（1）项目进度与费用控制。做好项目进度和费用分析。撰写项目进度报告。每周定期召开项目工作例会，并与项目外包商沟通会议，及时解决存在的问题。根据里程碑计划中制订的需求分析完成时间、系统设计完成时间、编码完成时问、测试完成时间和投产完成时间，在每一个阶段完成时召开会议，确认该时间段是否按计划完成工作。
（2）项目资源的控制。项目的资源包括人力资源、开发环境资源、测试环境资源、设备资源等，在项目开发过程中。项月经理要根据项目开发进度情况，优化资源分配，合理安排项目使用的开发和测试环境，调整开发人员和测试人员数量和工作内容，通过项目资源优化，确保项目开发进度和质量。
（3）采购过程及合同控制。监督和控制软件项目采购过程，要确保供应商招投标及中标是否按流程工作。供应商的资质是否符合要求，要求提供的文档资料是否齐全。对于中标的供应商要做好合同管理，确保卖方符合要求，买方要根据项目进度情况，做好项目阶段付款、合同内容变更管理。
（4）需求变更管理。在软件项目的研发过程中，对于需求内容变化请求都要求做出快速的响应，这需要制订相应的变更什理工作流程，控制来自各方面的变更，同时更新项目计划内容，并及时把更新项目信息资料存人项目信息管理档案。
（5）项目风险控制。根据项目规划阶段对项目开发过程中不问风险的识别及应对策略，实行项目“实时监控、实时询问、及时披露”制度。在项目开发过程中，对于出现的风险要及时向上级领导、客户反映，同时要采取措施把风险减小到低程度。对于外包商，项目经理需要密切监控项目的实施情况。
（6）项目质量控制。按照质量确保计划，由质量控制员全程跟踪项口研发过程中质量控制点，提醒项目经理提交项目管理需要的质量信息资料，对于发现的问题要及时通知项目经理改正。
五、项日收尾阶段
（1）项目验收。由客户进行验收测试，验证软件项目实现的功能是否实现了需求的要求。
（2）项目后评价。项目开发结束，需要项目开发团队撰写项目报告，总结分析整个项目研发工作，分析项目开发期间出现的问题原因及解决的方法，撰写出项目总结分析报告。为以后项目研发提供借鉴经验。
根据具体项目活动，对项目进行分解和活动的接点界定，明确项目组织和工作任务的分配，采用关键路径法制定详细的进度计划表，主要包括任务工作量、开始时间、持续时间、结束时间、版本号以及人员和资源分配。使每个人都知道自己工作任务的时间表及其工作任务的排序。管理主管总体掌握其业务时间在项目的地位，建立互动机制。操作人员根据实际情况写出乐观、悲观、可能完成时间、问题等情况。运用关键路线图的方法将工作分解结构和活动，按照逻辑关系加以整合，计算出某项活动的最早开始时间和最迟结束时间等，并且安排各子系统负责人，用统一格式编写小组情况报告。
项目进度控制
在项目中采取定期检查和定点检查的方式控制项目进度。其中定期检查的主要形式是周项目例会。规定在每周三下午定时召开任务进度情况汇报会，了解项目的实际进度。根据负责人汇报的工作情况，对完成情况与计划进行比较，如果出现偏差，及时调整，给出解决措施，纠正偏差。定点检查主要是事先设定的检查点如：里程碑，基线，对其完成情况进行检查，如果有偏差，需分析原因，判断偏差影响，并制定出解决方案。对愿意主动承担项目任务的员工多发奖金和公开表扬进行激励，或者不必要的功能和过度修饰。在项目进度动态监测后，形成项目进展报告有概要级进度控制报告，主要是针对整个项目对干系人进行汇报；管理级进度控制报告，主要是以分项目为对象由分项目主管进行汇报；业务管理及进度控制报告，主要是以某重点部位或重点问题为对象由普通研发工作人员进行汇报。这些报告除了日常报告，还有例外报告和特别分析报告的形式。项目进度报告的有效管理和制度的健全，可以帮助本项目的进度有效控制，便于项目干系人能够及时理解项目的情况。为以后项目经验教训的总结提供了有效的依据。
管理工具系列之RACI矩阵
RACI矩阵的中文名字叫责任分配矩阵，顾名思义是管理职责分配的工具。RACI矩阵是非常有效的人力资源管理工具和项目管理工具。
在人力资源活动中，RACI矩阵常用于组织结构调整；而在项目管理活动中，RACI矩阵在项目初期分配、澄清项目组成员权利与责任的有效工具；也可以在项目早期以及进行过程当中作为沟通工具使用；更可以在项目中期和后期的撕逼大战中占得先机。
1. 缩写释义：RACI的含义
RACI这四个字母的意思分别是：
RACI矩阵，有时又被成为RASCI矩阵，即多了一个S：
2. 填写RACI矩阵前的准备工作
填写RACI矩阵之前，需要准备两份材料。一个是分解好的工作包列表；另一个是人员、部门或人员+部门名单。二者缺一不可。这两项内容分别在矩阵的列标题和行标题。
figure class="7a51b8a1ee805110 Editable-styled" data-block="true" data-editor="q38d" data-offset-key="3q8t8-0-0" contenteditable="false" style="box-sizing: inherit; font-weight: normal; margin: 24px 0px; color: rgb(51, 51, 51); font-family: -apple-system, BlinkMacSystemFont, "Helvetica Neue", "PingFang SC", "Microsoft YaHei", "Source Han Sans SC", "Noto Sans CJK SC", "WenQuanYi Micro Hei", sans-serif; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: pre-wrap; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);"
/figure
如图中所示，左侧第一列即是工作包列表，含需要完成的各项工作；表格中的第二行则是人员名单。这个图中的人员名单是一个典型的错误示范，即只放了人的名字，正确的做法应该是放人员的岗位名称和所在部门。
3. RACI矩阵使用方法之：初级篇
最常用的RACI矩阵使用方法是单纯地用RACI矩阵来分工和派活。完成RACI之后，可以看到每一项工作是如何分配到各个部门或团队成员中去的，也可以看到每一个项目成员或部门名下，都会做哪些事情。用RACI矩阵来做这项工作的好处是，可以避免遗漏，并提高项目分工的细致度。
4. RACI矩阵使用方法之：中级篇
RACI矩阵的中阶用法是被用来做检查工具与沟通工具。
(1) 横向检查
横向检查即检查每一个工作包在每个部门的分工。关注点是：
如果出现某一个工作包被多个部分负责的时候，经常要强制选择一个部门来负责，将另外一个或多个R改成S或C。另外一种可能性是，工作包的分解不够细致，以至于无法拆分到某一个部门，这时就要将工作包继续拆分，直到可以将这个工作包合理地分到两个部门为止。
一个工作包被两个以上的部门负责是项目经理的噩梦，经常会出现由于部门间的推诿而导致进度缓慢的情况，最坏的情况就是导致整个项目的延期。
(2) 纵向检查
纵向检查即是按部门来检查：
(3) 沟通工具
制作好的RACI矩阵或者空白的RACI矩阵都是非常好的沟通工具。无论是在各种会议中，如项目启动会；邮件沟通，或非正式的对话中，都可以借助该工具来促进沟通。可以通过将该矩阵投放在投影仪，或者打印在A4纸上的形式，或者通过邮件发送该矩阵的形式，将信息的接受者的注意力集中在这个矩阵上，引导到家围绕这个矩阵进行讨论并达成共识。
经过前面的横向检查和纵向检查，RACI矩阵可以暴露出需要解决的的几大问题， 而这些问题都需要通过沟通来解决。通过召集相关人员聚集在一起完成RACI矩阵的制作和检查过程之后，便可以引导各部门来讨论需要解决的问题并就一些关键议题达成共识：
5. RACI矩阵使用方法之：高手篇
RACI矩阵在应对与分工有关的复杂情况时，是一个非常有效的思考工具。
(1) 变化管理
在管理项目或管理业务的时候，经常会出现组织结构或人员发生变化的情况；如团队成员离职、晋升或转岗，或部门的整合或拆解等等。这种变化会带来诸多的不确定性，为保证顺利的通过过渡期，RACI矩阵是一个非常好工具来分析应该做出哪些调整。管理人员或项目经理亦可以通过组织RACI讨论会来组织各方来正面地讨论这个问题。
(2) 诊断工具
RACI是一个很好的工具来帮助管理者决定是否要做以及如何做组织结构的调整。
贡献率较低的部门：如上面所述，如果某一个人或某一个部门在目前的工作中，R和A很少，更多是I和S，那么这个部门则在需要做组织瘦身的时候被优先考虑，或可以将负担过重的其他部门的职能迁移到该部门当中。
功能重叠的部门：如果有多个部门在多个任务上同时有R或A，那么这两个部门或两个人将有大量的跨部门协作方面的问题或冲突；作为管理者，需要特别关注这几个部门间的合作情况，及时干预并预防由于互相推诿而导致进度较慢的情况。
任务过重的人员：如果有的人身负过多的R，则该人的工作压力需要去关注；或某一个部门的工作压力过大，该部门的人员的心理是否平衡，是否得到了应有的鼓励和奖赏。
责任分配矩阵的构成
责任矩阵中纵向为工作单元，横向为组织成员或部门名称，纵向和横向交叉处表示项目组织成员或部门在某个工作单元中的职责。
责任分配矩阵是一种矩阵图，矩阵中的符号表示项目工作人员在每个工作单元中的参与角色或责任。采用责任矩阵来确定项目参与方的责任和利益关系。
关于软件开发责任分配矩阵和开发软件分工的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
软件开发责任分配矩阵