Teambition项目进度控制手册

Teambition项目进度控制手册

为什么要写这么一份手册？

项目在推进过程中，各部门间总会有这样的问题：

1. 产品接下来又要搞什么事情？
2. 设计图呢？原型图呢？开过会改了啥？
3. 技术做到哪一步了，我想打个包看看行么？
4. 这玩意儿能按时上线吗？

归根到底，所有问题的解决方案都来自于项目进度的实时更新与信息随时同步。我们希望通过使用Teambition这一工具来尽量消解上述问题，因此就有了这份手册。

---

项目角色

项目角色我们笼统地分为四类：

• 需求方：项目主管、运营部门以及可能的需求方部门等
• 产品：产品部门的产品经理
• 设计：设计部门设计师
• 技术：技术部门的开发、测试等

需求确认与落地流程

就需求本身而言，从收集到确认到落地会经历【1.需求收集】、【2.迭代规划】、【3.需求规划】、【4.需求确认】、【5.需求开发】、【6.需求验收】、【7.需求上线】七个阶段。

需求收集

【需求收集】版本需求一般来源于如下几种途径：

1. 需求方召集产品经理进行需求收集会议，此类会议一般会收集大版本需求，并在会议上确定需求的基本要点及优先级
2. 在各种会议中产生的优化性需求，例如演示会、各类评审会等，优化性需求一般取决于优先级随着各版本一起上线
3. 日常工作中产生的优化性需求，例如测试或使用过程中发现的优化点，优化性需求一般取决于优先级随着各版本一起上线

迭代规划

在版本规划前，需要确认当前版本需要迭代的内容：

1. 就开发阶段的工时而言，大版本需要控制在二周内，小版本需要控制在一周内
2. 在确认版本迭代规划后，需要在项目wiki中更新版本目标及大致的需求点，示例见「示例：版本目标」部分

需求规划

此阶段内由产品经理完成产品原型图以及必要的产品说明文档，此后由设计完成UI设计部分的工作：

1. 在此期间，产品应与需求方进行至少一次需求内部评审会议，是否需要后续会议由首次内部评审会议确定；
2. 内部评审期间，产品经理根据会议结论进行规划修整；
3. 在通过内部评审后，由产品经理召集设计及开发进行需求公开评审会议，需求方酌情参加公开评审，一般情况下不需要参加；
4. 公开评审完成后，产品一般在1-2个工作日内完成细节调整，并发布会议纪要同步到各部门，与此同时设计开始设计工作；
5. 设计完成后召开设计评审会，设计评审会议全员参加；会议后设计在1-2个工作日内完成细节调整并发布会议纪要同步到各部门。

需求确认

此阶段会确认产品出具的需求、设计出具的设计稿，开发、产品、设计就部分分歧点进行讨论，达成一致。

需求开发

此阶段由开发进行需求的开发、测试工作；开发阶段内需要进行定期的演示会，收集问题与优化点，同时产品收集涉及到的需求点。

需求验收

在需求开发完成、测试确认通过后，由产品及设计进行需求验收，当然也可以将灰度环境提供给需求方使用，需求验收基本包含以下几点：

1. 本次版本目标是否完成，功能细节是否有遗漏
2. 本次版本是否还原了设计稿，设计稿还原度如何
3. 实际上手体验过程中是否有可以改进的交互及功能等，有则予以记录

需求上线

在完成上述所有步骤后，技术对本次版本进行代码上线、数据库更新等等，产品辅助完成各应用市场、开放平台的上线工作。完成上述步骤后及时进行内部通知，并将版本更新信息更新到内网。

各版本用时

如「需求确认与落地流程」所述

1. 大版本的功能开发、测试用时一般需要控制在二周内，小版本控制在一周内。
2. 相应的设计用时一般控制在一到二周内。

版本迭代协作工作流

一般情况下，在同一时间内，会有版本A与版本B同时进行迭代工作，版本A处于技术开发阶段，版本B处于规划阶段。因而版本迭代的工作流实际上是一个环环相扣的过程，具体的节点如下。

1. 【需求确认节点】假设目前正在进行版本A的开发，则在版本A上线前2周左右确认版本B的需求，进行公开评审，评审后在1-2个工作日内完成细节调整，并同步到会议纪要中。
2. 【设计稿确认节点】版本B的公开评审结束后，设计开始进行版本B的设计工作；完成设计工作后，进行设计评审，评审后在1-2个工作日内完成细节调整，并同步到会议纪要中。
3. 【验收节点】版本A的开发工作基本结束后，由产品及设计进行验收工作，也可将灰度环境提供给需求方使用。
4. 【上线节点】版本A上线的时间点，同时意味着版本B正式进入开发阶段的节点。

当然，实际工作情况不可能如约定的工作流一般理想，在出现异常情况时，及时沟通，做好必要的人力资源与时间资源的调配。

会议

版本迭代中不免需要召开各类会议，其中跨部门的常规会议包含【1.产品规划内部评审会议】、【2.产品规划公开评审会议】、【3.设计评审会议】、【4.产品演示会议】四种。

产品规划内部评审会（内部评审）

• 会议目的：及早做好信息同步，及时修正各部门认知偏差
• 参会人员：产品、需求方、技术酌情参加
• 召开时间：产品规划在产生阶段性成果后需要召开内部评审会议
• 会前准备：提前一晚上传原型图及相关文档，并在钉钉上发起日程
• 周期内次数：至少一次，是否进行后续评审取决于首次内部评审的结果

产品规划公开评审会议（公开评审）

• 会议目的：详解新版本需求及规则，及时补充发现规划中缺失的细节
• 参会人员：产品、设计、技术，需求方酌情参加
• 召开时间：产品规划在完成内部评审后召开公开评审会议
• 会前准备：提前一晚上传原型图及相关文档，并在钉钉上发起日程
• 周期内次数：一般为一次，重大版本更新可能会进行多次

设计评审会议（设计评审）

• 会议目的：详解新版本设计图，提前展示新版本的产品形态，补充设计细节
• 参会人员：项目全员
• 召开时间：设计在完成版本设计图后召开设计评审会议
• 会前准备：提前一晚上传设计图，并在钉钉上发起日程
• 周期内次数：一般为一次，重大版本更新可能会进行多次

产品演示会议（演示会）

• 会议目的：开发人员就已经完成的部分进行功能演示，收集问题与优化点
• 参会人员：项目全员
• 召开时间：大型的产品演示一般安排在每周四，中途穿插小型演示会
• 会前准备：确认当次演示会演示内容
• 周期内次数：根据实际的迭代时间决定

蓝湖原型及设计稿上传约定

因蓝湖在单项目内上传超过300张设计图时会造成网页的卡顿，并且会给技术带来查找设计图困难的问题。因此建议在遇到更新次版本号的情况下，在蓝湖内新建一个项目，例如「App-2.0」与「App-2.1」，将相应版本的原型图及设计图上传到项目内。

---

Teambition任务流设计

任务时间控制

在任务正式开始前，需要根据估时填写任务的开始时间及结束时间，以在「甘特图」应用中展示所有需求、任务的进行情况。

产品任务流

产品工作流主要呈现在「需求」项中，可总览迭代内所有需求的规划、设计、开发、上线情况。

需求池

迭代开始前由产品确定本次迭代的需求点，整理在需求池中，需求池中的需求可能会有如下三种结果：

1. 需求正常规划，并完成设计与开发工作
2. 需求迁移到后续版本完成，且版本可确定
3. 需求暂时移出所有迭代，等待重新计划

规划中

在确定本版本中的需求后，产品开始需求的规划工作

1. 规划中的需求需要指定需求规划完成的时间节点，以方便在甘特图上呈现后几个版本的关键时间节点
2. 规划中的需求会经历需求内部评审，内部评审过后产品会对需求进行修改
3. 待内部评审通过后，视作需求规划完成，进入待评审阶段

待评审

规划完成后，需求进入待评审阶段

1. 需求在待评审阶段不会停留太久
2. 在待评审阶段内，产品需要将需求的原型图、文档等上传到相应平台，并在项目组内予以通知
3. 待评审阶段内，设计、技术可自行查看原型图及规则文档，记录问题待需求正式评审后提出，或有较大的疑问点可在待评审阶段提出及交流

设计中

需求在正式评审且经过产品的修正后视为冻结，设计开始进行UI设计工作。

开发中

需求开发包含技术的编码工作及测试的测试工作，其中可能包含内部演示及灰度包内部测试。

测试中

迭代进入持续测试阶段，该阶段内可根据技术的安排进行内部测试或验收。

已完成

需求完成验收及上线。

设计任务流

待补充

开发任务流

待补充

测试任务流

待补充

任务/缺陷关联

一般情况下，任务需要关联到对应的需求、设计、开发任务下，方便关联任务的跳转以及相应资源的获取。

---

其他待补充

1. 产品产出质量约定
2. 设计产出质量约定
3. 技术开发质量约定