项目管理开发流畅

目前的问题

  1：需求没有规划，没有目标，没有评审优先级，没有跟版本走，随想随做，需求变更频繁，干系人不能保证变更信息同步

  2：耦合高的工作拆分到不同人，导致沟通问题，还有依赖问题，同一个功能由同一个产品跟进就行

  3：开发拿到需求就做，没有计划，没有排期，部门之间不能正常协作

  4：上线前才发现还有工作没有做

想要达到的效果

  1：每一个版本都有明确的需求，并且需求是通过内部讨论筛选出来的符合当前优先级的

  2：当前需要实现的需求在项目成员中是达成共识认可，有明确的计划排期，可控

  3：迭代式开发和测试，一个版本需要根据功能计划明确多个交付点，每个交付点需要提供可用，可测试的版本，减少一次性最终交付的风险。

版本开发流程

1：需求收集

任务描述

收集下一版本可能需要实现的需求。需求可以分为功能性需求和非功能性需求。

​功能性需求：

​由产品提出，可以来源于产品发展战略规划，需求池，上一版本遗留的问题或改进方案，运营或市场诉求;

​非功能性需求：

​由技术提出，比如有利于扩展的技术重构；

​ 当前环节需要确定需求优先级，需求目标，可以开会讨论；

时间点

最好是在当前版本开发过程中同步进行，不占用下个版本的开发时间

参与人员

管理决策层，项目经理，产品经理（策划）

交付内容或成果

具有优先级和明确目标的需求列表

2：确定版本需求-编写需求文档

任务描述

对需求收集中的需求编写需求文档，明确描述需求的逻辑，交互，异常流程，缺省状态，尽量考虑全面，考虑得越全面，后续需要UI，研发修改的地方就越少，风险就越小。  需求文档写得最理想的状态是，任何人但凡有任何需求上的疑惑，都可以通过需求文档找到答案

时间点

最好是在当前版本开发过程中同步进行，不占用下个版本的开发时间

参与人员

管理决策层，项目经理，产品经理（策划），主要是产品经理

交付内容或成果

需求文档，需求原型图（交互设计）

3：项目启动-需求评审

任务描述

    产品通过提前准备的需求文档和产品原型给大家演示讲解需求，以达到以下目的：

    1：确定需求是否完善或有漏洞，有则完善

    2：干系人就需求的具体目标达成一致，统一认识

    3：抛出需求中可能存在的风险，比如技术难点，确认性价比，衡量是否需要修改需求

时间点

项目启动第一天

参与人员

项目经理，产品经理（策划），UI，美术，研发，测试

交付内容或成果

项目成员对该版本目标达成共识，需求评审一般以不超过三次为宜

4：计划和排期

任务描述

项目管理开发流畅

根据评审后的明确需求文档，建立工作分解结构，工作分解结构用于避免我们遗漏项目中的任务，工作分解粒度以天为单位。

根据工作分解结构各部门沟通后给出可交叉进行的工作排期，不是所有工作都是一条流水线，沟通后的排期是可以最大程度保证工作同步进行。

时间点

需求确定后当天或第二天

参与人员

项目经理，产品经理（策划），UI，美术, 研发，测试

交付内容或成果

各部门沟通后给出可交叉进行的工作排期计划，计划中明确具体功能的交付时间点，提测时间点，上线时间点

ps:

“我不能预测创造需要多少时间 ” 事实上最能激发创造性的因素便是时间底线

5：执行和控制

任务描述

根据排期计划按进度完成内容,根据功能计划明确多个交付点，每个交付点需要提供可用，可测试的版本，减少一次性最终交付的风险。

时间点

排期后到测试完成

参与人员

项目经理，产品经理（策划），UI，美术，研发，测试

交付内容或成果

项目经理：

      执行过程中的目标，进度，成本控制；

    产品经理：

      1：验收研发完成的功能点，确保满足产品需求；

      2：解答项目人员开发过程中的问题以及准备下一版本需求计划

    UI设计：

      1：按计划完成UI设计并根据需要决定是否组织UI评审会议，确定交付给研发的UI为最终版；

      2：验收测试完成的功能的UI还原度，还原度不符合要求的可以主研发完善，或协商解决；

    美术：

      1：按计划完成美术需求

      2：验收美术资源在产品中的效果以及通知验收人验收

    测试：

      1：根据需求文档编写各功能的正式测试用例，冒烟测试用例

      2：组织评审测试用例，保证测试用例完善全面

      3：按功能迭代，执行测试用例进行验收，按时发送测试报告，提交bug，跟踪bug

      4：每个功能上线，需进行线中跟踪回归测试

    研发：

      1：按计划完成功能开发，按功能提测，提测前需自测并通过冒烟测试；

      2：上线后通知测试回归，自己也需要跟踪测试以及历史版本兼容问题；

6：上线

    1：提前确定上线时间，并将上线信息同步给相关项目人员

    2：项目人员提前整理上线后的checklist,上线后及时根据checklist检查

其他事项

需求变更

  完成比完美更重要，需求变更是否是产品需求文档设计环节没有考虑全面？

  遇到变更，首先考虑必要性。如果影响到主流程，不改不行，保证信息及时同步给相关人，如：管理层，UI，开发，说明变更原因，评估变更额外增加的开发量以及对项目进度的影响。

  非必须的变更，考虑移入需求池，下一个版本开发。

项目例会

项目例会很有必要，至少每周一次，多方可以及时同步信息，暴露问题，提前解决风险