项目管理 - 工具箱

《产品经理》是思想工具，而项目管理方法才是真正的锄头。

但是，当我看到《PMBOK》这本大部头的时候，感觉实在是挥不动。

所以我着手于自己眼前的一亩三分地，从整套的管理方法中抽丝剥茧，找出了目前我急用的一些工具，整理如下。

需求采集卡

在我们开始一个项目之前，第一步是收到需求，如何收集到全面的一手需求是关键。

以下是一个需求采集卡的模板，其中包含了详细的用户信息、场景描述、需求挖掘、方案沟通、权重用户自评、用户所用竞品、其他关联信息等等，基本上包含了一手需求的所有需要信息：

由于二手需求是不确定和曲解的，当开始一个项目或者产品的时候，确保一定比例的一手需求是项目成功的关键，上述的需求采集卡则保证了我们采集到的一手需求的质量。

而更多数量的一手需求，我们可以尝试从以下渠道来获取：

WBS任务分解

WBS：工作分解结构（Work Breakdown Structure）， 是项目管理重要的专业术语之一。

WBS的基本定义 ：以可交付成果为导向对项目任务进行分解，实现了对项目工作的范围划分和更详细的定义。

在实际使用中：就是把一个项目，按一定的原则分解，项目分解成任务，任务再分解成一项项工作，再把一项项工作分配到各个小团队，再从团队分解到每个人，每个人的每个可交付成果中，直到分解不下去为止，每个人都要给出明确的交付物和交付时间节点。

WBS工作分解树

• 分解是从树根开始，自上而下，逐级进行分解的。
• 上一结点为下一节点的总和。
• 相同任务只能在WBS的一个树节点上出现，不能出现工作重复的节点内容。
• 一个树梢节点只能由一个人来完成，一个任务节点也只能一个人负责，其它人配合。
• 节点最终分解到一个人日的工作量为宜。
• 分解的任务节点树，应该与实际工作情况一致，这样才能对项目进行指导。
• 每个叶子节点为一个可交付的成果，它们可以用一个事件卡片来描述，里面包含了责任人、交付物、交付时间等关键信息，这个事件卡片在实际项目中可以进行自定义。
• 上述分解树示例是根据不同的阶段来分解任务的，也可根据产品的不同组件、软硬件迭代版本、组织的不同部门等等的分解形式来进行任务分解，甚至多种嵌套的分解方式，可根据项目情况灵活使用。

WBS分解表

在实际使用时，上述树状图在做层级划分的时候比较便利，自上而下的树状图更符合我们思考的习惯，但由于事件卡的项目比较多，需要一些统计和数据分析的工具，所以详细的WBS任务分解表一般使用Excel表。

自上而下的树状图转化成由左到右的表格，如下WBS任务分解表-示例所示：

上述表格除了包含WBS任务分解树和事件卡片，还插入了一个自动统计工时和当前进度的公式。

WBS特性总结

• 对一个大的工作包往往无法准确的进行评估，通过细分，可以统筹整个项目所需的人力、时间、成本。
• 通过功能分解，便于了解及控制项目进度，规避风险。
• 详细的WBS文档可以让成员清楚地看到自己在项目中的位置以及对项目总目标的贡献，也可以让项目组成员了解到什么事是对项目最重要的事，进而对自己手上的工作做出更精准的优先级判断。让成员自觉地从项目整体地视角来工作，每个成员心中地产品远景高度一致，紧紧围绕产品目标作战。
• 可以看清相互之间的依赖，哪些工作是要在固定时间点前完成的，自己需要哪些外部协助。通过工作分解便于制订出合理的工作计划。
• 事件划分颗粒度拆的越细，抗风险能力越高，建立文档和维护的成本也越高，需要根据项目情况酌情使用。

里程碑事件

释义：里程碑事件又称关键事件。是以项目中某些重要事件作为基准所形成的事件列表，是一个战略计划或项目框架，以中间产品或可实现结果为依据。能显示项目为达到最终目标而必须经过的条件或状态序列，以及项目在每一阶段应达到的状态。并可明确工作主要阶段由哪些主要组织分部负责，从而提供必要的资源和技术专家。

里程碑事件列表可以看一个以中间产物为颗粒度的战略性WBS表，以主要过程为主体架起了通向项目目标的桥梁。

里程碑的使用

基础的里程碑事件中应清楚地定义开始时间、结束时间、负责人、阶段成果、检验标准。（详细的可以使用WBS事件卡片）

开始时间、结束时间为里程碑事件带上了时间属性，说明了里程碑是基于时间规划的，也可以使用时间进度来计算项目完成百分比，以明确项目进度。

负责人明确了各个角色责权的划分，基于里程碑的项目管控也包含了对人员的管控，这样才能真正达到对项目控制。

阶段成果和检验标准，用来验证是否达到里程碑，没有设定检验标准就等于没有里程碑管理。

里程碑的作用

1.监控进度，降低风险

项目进度是以里程碑为界限，将整个开发周期划分为若干阶段。根据里程碑的完成情况，适当的调整每一个较小的阶段的任务量和完成的任务时间，这种方式非常有利于整个项目进度的动态调整，也利于项目质量的监督。
在里程碑式的开发模式下，因为按子项目或子阶段来划分里程碑，每一个子项目都会经过一定的稳定化阶段。当再进入到第二个子项目的时候，就是基于前一个相对稳定的子项目基础之上，这样就将风险或错误的累加分散到最低。以局部的进度控制和质量控制来保证整体开发过程的稳定，使得质量和进度得以很好的控制，这就是里程碑式的开发模式优秀之处。

2.可以作为一类WBS颗粒度

可以基于此颗粒度，建立WBS的细分表。在架构上的调整也可以直接转化为调整里程碑事件列表。

3.可为进度预留缓冲时间

将大项目分成若干里程碑式的重要阶段时，可在各重要阶段之间预留有缓冲时间。一般来说，在项目中我们需要为意外事故保留总开发1/3的时间，即“缓冲时间”。缓冲时间有助于一个项目适应意料之外的事件，例如缓冲时间可以用于弥补进度延误，或者是技术困难或是由于疏忽而忘记把任务写入进度，或者是未料到的难题而形成的时间损失，这种应付突发事件的缓冲时间在开发和稳定化过程中是每一个主要里程碑的一部分。

里程碑陷阱

里程碑陷阱表现为人们在软件项目的里程碑被设定以后，认为“目标管理是只问结果，不计过程”，从而忽视对过程的监控而导致项目里程碑不能按期达到。

燃尽图

燃尽图也叫燃烧图，是罕见的敏捷度量。它的全称是“总剩余时间的燃尽图”，就是本次迭代中，所有故事（或拆分的任务，以下仅称故事）的剩余时间总和，随日期的变化而逐日递减的图，随着剩余工作的完成，“烧尽”至零。

燃尽图是在项目完成之前，对需要完成的工作的一种可视化表示。燃尽图向项目组成员和企业主提供工作进展的一个公共视图。

燃尽图横坐标为工作日期，纵坐标估计剩余的工作量，每个点代表了在那一天估计剩余的工作量，通过折线依次连接起所有的点形成为估计剩余工作量的趋势线。另外还有一条控制线，为最初的估计工作量到结束日期的连线，一般用不同的颜色画上边的两根线。

根据自己的理解，我制作了一个基于Excel和工时的燃尽图-示例.xls，具体效果如下图：

燃尽图的研判规则

　　1.如果趋势线在控制线以下，说明进展顺利，有比较大的概率按期或提前完工；

　　2.如果趋势线在控制线以上，说明有比较大的概率延期，此时需要关注进度了。

需要注意，趋势线并非一直下行，也有可能上行，即发生了错误的估计或遗漏任务时，估计剩余的工作量也有可能在某天上升了。

燃尽图最好是张贴在白板上，让每个项目组成员抬头就能看见，这样给大家一个明确的视觉效果，每个人随时都能看到团队离目标有多远。

燃尽图可以每天画，表示完成某个迭代的进展趋势，也可以某次迭代结束的时候画，表示完成整个项目的进展趋势，此时横坐标就是迭代的顺序号。

甘特图

甘特图（Gantt Chart）又称为横道图、条状图(Bar chart)。在图上，项目的每一步在被执行的时间段中用线条标出。完成以后，甘特图能以时间顺序显示所要进行的活动，以及那些可以在同时进行的活动。

甘特图以图示通过活动列表和时间刻度表示出特定项目的顺序与持续时间。一条线条图，横轴表示时间，纵轴表示项目，线条表示期间计划和实际完成情况。直观表明计划何时进行，进展与要求的对比。

以之前的WBS任务分解表-示例为例，生成的甘特图如下所示:

Excel好像能直接生成甘特图，但是看了教程，没有学会。而对多个文件的话就更难了，所以花了一点儿时间自己写了一个生成工具（PyQt+openpyxl），如下：

每一行，文件：文件路径；表名：数据所在的Sheel名称；Line：从多少行开始，到多少行结束；事件列：事件简述所在的列，以数字表示，如D == 4；开始时间列：开始时间所在列，以数字表示；结束时间列：结束时间或者完成时间所在列，以数字表示。

点击“Add Input Line”可以新增一行，如果不想重复输入，可以写成一个Json文件，点击“Load Config”可以加载配置文件。例如，对WBS任务分解表-示例可写如下配置：

{
    "Input":
    [
        {"file":"./WBS任务分解表-示例.xlsx",
         "sheet_title":"WBS",
         "line_start":"3",
         "line_end":"8",
         "activity_col":"4",
         "start_time_col":"8",
         "end_time_col":"9"}
    ],

    "Output": {"path":".","file":"Gantt.xlsx"}
}

下方的文件夹、文件名用来指示甘特图表输出的路径及名称。

最后点击“开始生成”。

最后，如果想要使用此程序，可以下载“GantCharGenerator-EXE.zip”，解压后双击即可运行。

想要自定义功能或者改进的可以下载源码，自行修改。

关键字释义

• PPQA

  PPQA（Process and Product Quality Assurance ）即过程与产品质量保证，属于CMMI 概念。

  过程与产品质量保证过程域通过提供成员和各阶层的管理人员，对于生命周期中的过程和工作产品提供适当的能见度和回馈，以支持交付高质量的产品和服务。

  PPQA的目的，在提供成员与管理阶层客观洞察过程与相关工作产品。包括：

  • 依据适用的过程说明、标准及程序，客观评估所执行的过程、工作产品及服务
  • 界定并记录不符合的议题
  • 对成员与管理人员，提供质量保证活动结果的回馈
  • 确保不符合议题已经处理

  执行客观评估的方法包含如下：

  • 由独立的质量保证组执行的正式审计
  • 执行不同形式的同行审查
  • 深入的实地审查(办公桌审计)
  • 工作产品分布式的审查和评论

• CMMI

  CMMI的全称为Capability Maturity Model Integration，即能力成熟度模型集成。CMMI是在CMM（Capability Maturity Model For Software，软件能力成熟度模型）的基础上发展而来的。由美国卡耐基梅隆大学软件工程研究所（Software Engineering Institute，SEI）组织全世界的软件过程改进和软件开发管理方面的专家历时四年而开发出来的，并在全世界推广实施的一种软件能力成熟度评估标准，主要用于指导软件开发过程的改进和进行软件开发能力的评估。

  CMMI是一个庞大的过程元模型，自发布以来在世界软件界产生了巨大的影响。CMMI等级评估已经成为业界公认的标准，CMMI的证书成了一个企业或组织能力和形象的标志，没有这个证书不仅难以获得国外项目，甚至也难以在国内一些项目的竞标中获胜。CMMI适合企业操作，避免了某些管理体系只重理论而忽视实践的缺陷。在我国，随着媒体的宣传和政府的支持，许多企业引入了CMMI咨询和认证，对于整个软件行业的管理提升及研发效率提高起到了很大的帮助作用。但也有一些企业引入CMMI体系后，只留下一些形式上的开发流程和文档模板，在管理上并无实质性改进。

参考

• 项目管理知识体系指南（PMBOK®指南）：第6版/美国项目管理协会（Project Management Institute）著.—北京：电子工业出版社，2018.4
• 燃尽图 - MBA智库百科