有个说法，打仗的本事，人们看到的是谋略，勇敢，因为那里面有故事，有谈资，男女老幼都爱听，都爱点评两句。而真正重要的事情，却不被人挂在嘴边：组织动员，数学物理，管理方法。管理的事讲起来枯燥，人们不愿看，不爱听，不想谈。大概是这样吧。

2014年开始，我们一边实践，一边对照理论，裁剪了适合自己的项目流程，并一直优化，直到2017年底，我们部门所有项目全部按合同成功交付，保质保量。优化过程中的理论部分，主要参考了以下资料《微软丛书：快速软件开发》，《PMBOK》，《敏捷革命》，《软件需求最佳实践》，《设计冲刺》，《产品研发管理》等。优化过程中的管理工具，我们从Excel，Project和禅道换到 trello，从 trello 换到 worktile，再从 worktile 换到 TAPD，最终在 TAPD 上扎根，尽管我们现在对 TAPD 的最佳使用方式还存在少量疑惑，但每一次切换管理工具，都对Scrum有更深入的理解，以至于我们存在疑问的同时，也感受到了 TAPD 设计者对敏捷过程的理解，也自定义了一些 TAPD 默认配置的不足之处。

尽管我们无比认同流程不能套用，只能根据每个团队的情况去裁剪，但写写过去的实践，一来给还在路上的同学们参考，二来回顾下过去的日子，想来也没什么坏处吧。

我们认为流程重要的同时，又好像丝毫都不重要。因为看过很多因为流程合适而保障成功的，也看过一些毫无章法却也最终成功的。我想，任何东西都不是银弹，项目流程并不保障成功，只是为了避免典型错误而已。投名状里李连杰在结冰的河面上对副官说，我这一辈子都如履薄冰，你觉得我能走到对岸吗，然而最终也并没有。可能这就是项目经理才能体会的乐趣吧，每一个项目都像是一个浓缩的人生，你有很多疑问，也有很多收获，还有很多后悔。说人生无悔，那都是赌气的话吧。

目录：

1. 2015年8月-极简版-基于模板文件

  1.1优缺点

  1.2 模版文件

  1.3 具体内容

2. 2018年7月-完整版-基于TAPD

  2.1 优缺点

  2.2 具体内容

1. 2015年8月-极简版

根据2014年到2015年的项目实践总结而来，是我们第一次把实践整理成建议标准，这里的开端是初审UE，因为当时需求分析是产品经理跟客户对接，UE出来之后项目经理才带队接手，因此不太涉及到需求工程的内容，也许这版叫开发流程更合适。

1.1 优点：

1. 用三个节点做需求评审。这三个节点非常重要，让所有人都有充分的时间反复思考，而非只看到最表面的需求就开始评估和开发，然后在过程中再不停确认一些很粗浅的问题。我们的做法是，产品经理必须在每个节点前两天把原型交付到项目组，项目组必须带着需求问题文档参加需求说明会，否则不许进会议室。

2. 中间产物少。只有任务计划模板，风险管理模板，需求变更模板。这样的好处就是管理成本非常低，同时又能在一定程度上保障项目。我们的做法是，通过每天的 standing talk 来跟踪和调整任务计划和风险。好处在于大家对任务分解和定义是一致的，当出现任务计划里没有的任务时，一定要调整和补充。

3. 管理过程极简，对开发团队影响小。三份模板都是office文件，只在项目经理手里控制，不需要开发人员配合过多管理工作。项目经理充分做到联系上下游，对开发团队屏蔽业务影响，对业务团队屏蔽开发过程细节。

4. 投入产出比高。只通过三份文件，就有效地提高了项目过程可视度。用 standing talk 的形式更新三份文件，几乎每天都能看到最新的项目状态。我们的做法是，周一把本周要做的所有事情，从任务计划贴到看板上，看板分为未开始，开发中，开发完成，测试中，已完成。每天的 standing talk 时，每个从看板上移动任务，而不是项目经理一个人去移动任务。这样的好处是避免 standing talk 变成任务汇报。standing talk 结束后项目经理再自己把看板任务同步到任务计划里。

5. 关于任务计划模板。最普遍最典型最恶心的错误，就是不维护不跟进不更新(半个月维护一次也叫不维护)，毕竟没有跟踪就没有管理。我们见了太多太多太多人和团队，只在项目前期做一份WBS拍个工时，拿给老板汇报下，就再没打开过了。这些同学是没有理解一个词，叫渐进明细。WBS是动态的，估算也是动态的，如下所示：

所以任务计划一定是动态的。如果不是，将导致项目可视度下滑，如下所示：

如果整个项目成本只允许支撑一个管理活动，那一定是任务计划的跟进。

1.1 缺点：

1. 项目经理必须自行处理其他问题。由于流程简单，所以实际生产中还会碰到各种问题，比如信息饱和度的问题，PM要自己想办法做好沟通管理和配置管理等，再比如说过程没涉及到 issue 的处理方式，PM要自己想办法搞定，这些都需要项目经理自行处理。

总之，项目经理要作为一个 owner，连接好业务团队和研发团队，千万不能只当传话筒，要在中间把信息加工过滤好，对研发团队屏蔽好垃圾信息，不让业务轻易地影响开发任务；对业务团队和甲方做好教育和期望管理，不让研发团队跟业务团队总是聚焦在冲突上。

1.2 模板文件

1.2.1 任务计划模板

Dashboard 根据后面的任务数和状态来自动计算。

任务计划：分为后台，接口，web，webUI，AndroidUI，AndroidAPI，iOSUI，iOSAPI。

1.2.2 风险管理模板

风险管理的核心都在表里，识别风险，计算影响量，准备预防措施，准备应对方案。

1.3 具体过程

前言

每个项目负责人都有自己的管理风格和运作过程，只要项目结果良好，不论怎样的过程都值得肯定。那么，我们创建这份文档的目的何在？

首先，每个公司的项目的运作过程都不一样，新员工入职后，需要很长时间才能知道项目是如何运作的。这无疑减慢了员工对于项目和公司的认知。本文档第一个目的是帮助员工理解整个项目的运作流程。

其次，项目负责人，也许并没有形成自己对项目周期的理解，还不太熟悉项目每个阶段应该做什么。本文档第二个目的在于给项目负责人提供参考，在每个阶段需要完成什么事情，大家在PMO会议时，对项目过程能有统一词汇。

最后需要注意，本文档只是说明公司大部分情况下的项目流程，仅供参考，不能作为强制规范。

1. 初审UE

1.1 说明

客户确认UE后(因为甲方确认UE有回款，所以先甲方确认，再内部项目组初审。)，产品经理将UE发到项目经理初审。初审由项目经理发起，开发人员，测试人员参与。初审主要关注项目数据流，业务逻辑。

1.2 产出

》产品业务导图，关键流程图(如果产品经理没有提供，则PM自己做)

》第一轮需求问题

1.3 建议

》项目经理，测试同学需要审核整个UE，开发人员如果有并行项目，则可以只审核部分UE。

》初审UE环节并不是一个会议，而是各自安排时间单独评审UE。

2. 需求说明会

2.1 说明

产品经理发起需求说明会，项目经理，开发，测试参加。产品经理尽量不要逐个讲解产品模块，而是重点讲产品背景，核心业务流以及每个人提交的第一轮需求问题。会议需要解决第一轮需求问题。

2.2 产出

》会议纪要邮件

》第一轮需求问题答复

2.3 建议

》会议纪要需要详细记录待确认的问题，每个问题需要确定谁负责，谁跟踪，谁协助，谁实施。第一轮需求问题答复可以作为附件。

》通常会议过后，UE会更新几个版本，产品导图会更新几个版本。

3. 复审UE

3.1 说明

由项目经理发起，开发，测试参与，逐个模块审核UE，复审主要注重UE细节问题。修正和完善项目思维导图，创建WBS和初步任务计划，整理第二轮UE或需求问题。复审主要关注细节。

3.2 产出

》第二轮需求问题文档

》初步WBS(包含初步任务分解，初步工时预估)

》通常复审过后，UE还会更新几个版本，产品导图也会更新几个版本

3.3 建议

》开发人员在这里可以开始分解自己的项目模块，预估任务工时。

》测试人员在这里可以开始做测试方案了。可以选择用导图，成本比较低。

4. 任务计划

4.1 说明

产品经理确认第二轮问题，最终UE，导图和关键流程图之后，开发团队就可以开始完善任务计划，设置里程碑清单，测试人员根据开发里程碑清单，制定测试计划。

4.2 产出

》第二轮需求问题确认

》最终WBS(包含详细任务分解，确定模块开发人员，确定任务量，设置里程碑)

》测试计划

4.3 建议

》开发任务分解，颗粒需要到功能点。原则上不允许一个任务超过8人时。

》里程碑一般以模块为单位。制作项目里程碑日历，并告知所有干系人。

》缺陷管理工具在这时，就应该配置好模块了。

》每个里程碑达成后马上进测试。

》任务计划分两版，一版做内部控制，一版提交到公司PMS系统和客户。通常内部控制版的时间更紧。

》很大一部分开发人员在这个阶段不敢预估工时。需要克服这个障碍，这里的预估工时只是粗略判断，后期还有一轮更细致的评估。可以充分使用三点估算，参数估算，拍脑袋等。

5. 项目设计

5.1 说明

项目设计通常跟4任务计划同步进行。工作包括数据库设计，框架选型，接口设计。开发人员接手自己负责的模块任务，测试同学开始设计测试用例。

5.2 产出

》数据库设计(PowerDesigner)

》接口文档(模板)

》模块功能流程图或数据流图(非必须)

》测试用例导图或excel

5.3 建议

》对于测试用例，导图成本更低，excel居中，用缺陷管理工具成本最高。

》在这个阶段，工作量需要谨慎评估，通常项目经理和技术负责人需要逐个任务评审工作量，必要的时候使用计划扑克，德尔菲法等技术手段对有争议的点进行处理。

6. 项目启动会

6.1 说明

项目经理发起，开发，测试，产品参与。明确技术框架，开发规范，里程碑日历，关键模块开发人员讲解流程图和数据流图，评审数据库设计和接口设计。启动会最重要的事情，就是反复强调两个目标，长期目标和短期目标。有了目标，奋斗才是有意义的。

7. 开发和测试

7.1 说明

这里没有约定开发测试的细则，因为可选的生命期模型很多，大概有：纯瀑布，生鱼片，螺旋模型，具有子项目的瀑布模型，降低风险的瀑布模型，渐进原型，阶段交付，渐进交付，面向进度的设计，面向开发工具的设计等。具体可以参考这里。

7.2 产出

》任务计划文档更新

》缺陷

7.3 建议

》尽早测试。

》尽早拉用户参与项目。虽然公司只要求ABM三个版本给客户交付验收，但最佳实践是在每个里程碑测试完成时，都给客户提交验收。一来客户能补充测试工作，二来尽早发现需求问题。

》建立任务看板。看板分为：未开始，开发中，开发完，测试中，测试完。

》每周一给看板贴上本周所有任务。

》每天 standing talk ，每个人在看板上移动自己的任务。结束后项目经理再把每个任务的进展同步到任务计划文档。

》每周五回顾本周任务。

》每周五需要发项目周报到PMO和客户。

8. 版本交付

8.1 说明

通常合同会分为：UE，UI，Alpha，Beta，Master几个交付。跟开发有关的是ABM三个交付节点。

8.2 产出

》交付邮件 参考模板

8.3 建议

》给客户的ABM版本交付邮件，一定要标明客户最迟回复时间和标准验收文字。具体时间参见合同，标准邮件参见交付邮件模板。

》ABM版本的交付邮件，一定要抄送Bluemobi.PMO@Bluemobi.cn 

2. 2018年7月-完整版-基于TAPD

这版增加了一些内容，包括需求工程，使用TAPD作为信息平台，细化了开发测试阶段的内容，包括定义了冲刺，冲刺回顾，测试规划和测试输出等。

同时也删了一些内容，比如Kick-Off Meeting，因为我们不再把时间看做线性，而更多以周期的视角看待时间，这时每一个冲刺启动的时候，其实都是一个Kick-Off。