5.4
典型的项目文件

在产品开发项目中有很多文件，这些文件都是项目的交付物。通常，这些文件被分成两大类：项目文件与产品开发过程文件。在第4章表4-2各阶段的典型交付物中的文件就可以被分成这两类。其中，产品开发过程文件与产品开发密切相关，是产品开发项目的主要输出。这些内容将在后续各章中陆续分享，这里不再展开。本节主要分享项目文件及其典型作用。

项目文件，从广义上来说，代表项目所包含的所有文件，但本节所指的项目文件特指项目管理所要求的特定文件。这些特定文件是项目管理的必要文件，记录了项目管理与活动执行的过程。由于篇幅限制，本节仅介绍项目文件中最具典型意义的文件。

1. 项目章程

项目章程（Charter）是项目的总纲性文件，从项目开始之初就被创建，贯穿整个项目，是企业管理团队评价项目、管理项目、追踪项目的重要文件。

通常，项目章程最早是由企业内部的需求提出方草拟的。例如，市场部或产品经理等在产品开发需求被确定后就开始草拟项目章程。项目章程主要包含项目的必要背景信息、市场或客户需求、企业的预期收益、项目执行的技术或资金风险、项目的资源配置等信息。为获取这些信息，需求提出方需要先完成必要的技术可行性分析和商业论证等工作，并将这些信息作为项目章程的原始输入。

项目章程由项目发起人带至项目评审委员会进行立项审批，其中的信息是评审委员会批准立项的主要依据。一旦评审委员会批准项目立项，就意味着项目可以获得必要的启动资源并获得必要的授权。通常，在项目章程中会预分派项目经理以及必要的核心资源，批准项目章程的同时，也是项目经理获取这些资源承诺的时候。注：预分派的项目经理有可能被正式批准的项目经理所取代。

在立项审批之后，项目章程就会被转移给项目经理，由其去维护和管理。章程内的信息对整个项目的后续活动有最高的指导性意义。如果项目发生变更，项目经理应及时更新项目章程，并提交评审委员会审批。图5-2为项目章程的目录示例，实际内容可由各企业定制。

2. RACI矩阵

RACI矩阵，即责任分配矩阵，是项目管理的基础工具，主要用于项目角色的职能分配。该工具最早在项目章程中出现，在项目执行过程中，必要时可以发生变更。

RACI矩阵将项目成员与项目活动相互关联，至少被分配成四个不同的角色（RACI矩阵的名称也来自这四个角色的英语单词首字母组合）。

1）负责人（Responsibility，R）

负责人是实际负责完成项目活动的角色，即执行或完成（Act/Do）项目活动的人。给每个项目活动分配相应的负责人，是完成项目交付的前提条件。要给每个项目活动至少分配一个负责人。

2）责任人（Accountability，A）

责任人是对项目活动的交付结果负责的角色，也可将其视为该项目活动的主人（Owner）。责任人同样可以参与项目活动的实际交付过程，也就是说，项目活动的责任人可以是活动的负责人之一。无论项目活动的负责人有多少个，原则上，项目活动的责任人有且只有一个。负责人与责任人之间不一定存在工作汇报关系。

3）咨询者（Consultant，C）

咨询者是项目活动在执行之前需被告知且听取其意见的角色。咨询者一般都是具有特定职能、特定专业技能或特定身份的人，如企业的法务、财务、技术专家或公司总经理等。在重要活动执行前，项目团队需要听取相关咨询者的意见，并根据其意见做出判断。咨询者的意见非常重要，很大程度上可左右项目活动的进程。咨询者不是RACI矩阵的必需角色。

4）被告知者（Inform，I）

被告知者是需要被告知项目活动输出结果的角色。通常，被告知者无须采取特别的行动，他们只需知道项目的进展或活动的输出结果即可。常见的被告知者往往是活动的执行对象或上层管理者。例如，在产品完成了设计发布后，开发团队向设计师和公司总经理告知这个消息，此时设计师和总经理只需接收这个信息即可。被告知者不是RACI矩阵的必需角色。

表5-1是简单的RACI矩阵示例，示例的责任分配数量可能远远多于该表所示。

所有项目成员都被分配成这四个角色，而有的企业还会增加一个新的角色——支持者（Support，S），然后将RACI矩阵升级为RACIS矩阵。通常情况下，支持者的项目参与程度比负责人和咨询者略低。

3. 项目活动分解

项目活动分解是项目管理的最基础动作，将项目活动分解至最小且可执行和管理的层级，以便项目经理进行工作任务分配。项目活动分解是项目经理的典型工作，分解时常用工具是工作分解结构（Work Breakdown Structure，WBS）。

WBS是将项目所涉及的活动按指定的维度进行分解。该维度可以有多种考量方式，比较常见的是按项目的阶段分解、按项目涉及的职能团队分解、按项目目标的属性分类分解等。无论哪种考量方式，分解后的项目活动的输出总和就等于项目目标。也就是说，分解后，不可以出现项目目标被遗漏的情况。如果出现部分项目活动的交付有重复现象，那么说明有的项目资源被浪费了，也说明分解存在问题。

在分解时很可能无法一次就将项目活动分解到最合适的底层活动，所以WBS允许进行分层分解，项目经理与团队应自行考虑活动分解的层级。通常，不建议进行多层级的分解，因为这会增加项目管理的难度。WBS分解的程度因企业、项目规模和人员能力而不同，并没有统一标准。通常，WBS分解到项目成员可执行的具体动作为止。例如，当某项目活动的WBS分解到“完成验证试验”时，项目经理会考量团队中的设计师是否能独立负责并完成该验证试验。如果设计师可以完成任务，那么该分解到此为止。如果设计师无法完成任务（因为这个验证试验不仅需要内部团队验证，还需要外部第三方验证），那么项目经理要识别该问题，并进一步将该活动继续分解到下一层，即包括内部验证、外部第三方验证等其他更细致的活动。

由于WBS存在层级结构，因此多数WBS看起来就像一个树状结构。其实WBS就是特殊形式的鱼骨图。通常，鱼骨图的鱼头向右（找原因），而在用于WBS时，鱼头向上（显示层级结构）。图5-3是一个按功能分解的WBS，图中仅显示了两层结构。如果任务较为复杂，可继续向下分解。

如果对WBS分解后的每个活动都分配相应的资源，并且限定其预期的交付时间（如设计团队需要在8月1日之前完成概念设计），WBS就会演化成资源计划，并成为项目计划的重要组成部分。

4. 项目计划（综合管理计划）

项目计划是一个宽泛的概念。狭义上，项目计划特指项目活动的推进计划，也就是项目的整体完成度计划或综合管理计划。广义上，项目计划是一个计划组，包括项目进度计划、成本计划、质量计划、资源计划、沟通计划、采购计划和客服计划等一系列子计划。也就是说，一个项目可能存在很多项目子计划，而通常所说的项目计划（整体完成度计划）其实是这些子计划的集合。本节将介绍狭义上的项目计划，其他子计划请参见项目管理的专业书籍。

项目计划是一份具体的项目活动完成度一览表。最简单的项目计划就是项目里程碑计划，该计划可以非常简单，仅罗列项目中最重要的几个里程碑节点以及相应预估的完成时间。例如，最简单的项目计划可能是这样的：定义在6月1日之前完成，设计在8月1日之前完成，验证在10月1日之前完成……项目在12月30日之前结束。

在实际应用中，过于简单的项目计划可能无法用于指导项目推进，所以企业往往将项目活动进一步细化。这个细化过程与WBS强相关，多数企业会直接使用WBS作为项目计划的原始输入。由于多数WBS存在层级结构，因此项目计划也会相应地分层。通常，项目计划会被分成主计划（Master Plan）和子计划（Sub Plan）。项目经理更专注于主计划。主计划通常包含项目里程碑、阶段评审等项目最重要的节点；子计划则视情况而定，有的子计划由项目经理制订，有的子计划由项目核心成员来完成，然后向项目经理汇报进度。

为了使项目计划具备可操作性和指导意义，多数企业的项目计划是复杂的。这些项目计划集合了WBS、里程碑计划、资源计划和交付计划等，这使得项目计划很庞大，导致项目经理不得不使用一面墙来展示整个项目计划。制订项目计划时，常使用甘特图（Gantt Chart），这是一种既包含WBS和资源计划等信息，又将这些分解后的活动与日历结合在一起的图形，可以给项目团队和管理者提供可视化管理的渠道。甘特图有多种画法，绘制时不应拘泥于工具，而应注重该工具的实际应用意义。图5-4是一份较为简化的甘特图示例（未显示紧前工作及紧后工作关系，相关方法请参考项目管理专业书籍）。

项目计划是项目经理用于管理项目的重要工具，项目成员也应尽可能配合项目计划完成指定的交付成果。如果项目实施过程中出现重大的进度偏差，项目经理应及时更新项目计划，并与项目成员沟通变化点。如果项目主计划发生变更，就要获得项目评审委员会的批准。

5. 项目报告

项目报告，也称项目结项报告，是项目团队在项目正式关闭前的总结报告。项目团队完成该报告就意味着项目进入收尾和资料归档阶段。项目报告的内容非常广泛，通常由项目经理完成。一般来说，项目经理在项目报告中至少要汇总以下几点内容：项目信息（包括最初的项目背景等原始信息）、项目成果、企业收益、项目执行过程中的重大事件、经验教训总结、后续事宜等。由于项目报告没有固定的格式和要求，因此项目经理编写项目报告时的自由度较高，无论是正面影响还是负面影响都应如实汇总。项目报告可作为团队绩效评价的重要参考，而且应作为重要的组织过程资产永久保存。

6. 其他典型项目文件

在执行项目过程中有一些过程文件，这些文件记录了项目执行的重要信息，如项目评审记录、项目变更记录等。这些文件与其他项目文件一起组成了项目档案（Profile），作为项目追溯的证据。项目过程文件通常没有统一的格式，其内容由企业根据项目特点和关注重点进行定制。例如，项目评审记录可以多次出现在项目执行过程中，与项目节点的设置强相关，而评审内容与企业项目管理体系有关；项目变更记录应完整记录项目的重大变更信息，包括变更的时间、内容、执行对象、风险评估和影响程度等。不少企业还对变更等级进行划分，并进行分层审核和管理。

项目管理是一个动态的过程，项目文件是支持这个过程的重要佐证。项目文件由整个团队共同完成，但核心项目文件主要由项目经理负责。虽然准备项目文件会增加团队的工作量，但产品开发团队应借助项目管理的工具和方法，把产品开发过程变得可控和稳健。 sSUQQaf3dPHbQK0jZQQqG2dTMjT9QPiZYx9V0HQ3dDVVOrkIz3qpnggxoOlKJplo