1需求阶段

产品经理-准备需求

1、产品经理调研需求，编写《需求文档》，画《产品原型图》。

2、产品内部评审需求。

产出《XXX项目需求文档》

产出《XXX项目产品原型图》

《产品原型图》有文字说明，交互说明，涉及“核心业务流程”的需要详细说明。

产品经理-发起需求评审会

1. 为项目指定一名产品负责人。
2. 产品经理确定项目名称，一定要给项目起一个名字便大家沟通。示例：养车家2.3-用户注册流程优化项目
3. 总监指定一名项目负责人来担任项目经理。
4. 产品经理招集项目干系人，组织“需求评审会”。
5. 产品经理与项目经理沟通确认参会人员，包含：产品经理、项目经理、研发、UI、前端、App、测试、BI，及其它配合部门的人员，请根据实际情况增减。
   
6. 会上进行需求评审、确认产品原型。可多次评审直到通过。
7. 产品经理维护项目需求到TAPD，上传需求原型到TAPD。
   

1. 会前，产品经理发出《XXX项目需求评审邀请》邮件，收件人是项目干系人。
2. 会后，并且PRD补充完成，产品经理发出《XXX项目需求评完成通知》邮件，收件人是项目干系人。且附最终版的PRD.
3. 最终PRD确认后的24小时内，UI人员发出《XXX项目UI设计时间计划》邮件，收件人是项目干系人。
4. 会后24小时内，项目经理给出《软件设计时间计划》
   

一、影响分析：在“需求评审会”上项目经理带领研发团队，理解需求，并做“影响分析”，分析要改哪里？要关联哪些子系统。与产品经理就需求的合理性能进行交流。

二、需求评审会上，刚宣讲完需求，需求方立即问：什么时间能上线？

答：

1. 一般项目：具体的上线时间，需要在完成“设计评审”后给出。
2. 紧急项目：例如为了参加双12活动，实际交付日期已确定为12月11号之前，只能采用“倒推法”，没得商量。
3. 有一些项目需求方为了决策，此时就需要一个大概的交付日期。把控能力强的项目经理，此时可口头给出粗估项目时间计划，但要注明：允许有时间误差(一般项目50%)，待完成“设计评审”后方可给出准确的时间计划。粗估的时间计划对需求方也很重要，他以需要对外汇报。

1. 项目经理确定项目组成员，确认是否有可投入的人力资源（研发、UI、前端、App、测试，及其它配合部门的人员）。
2. 有人力资源、需求通过评审、产品原型通过评审，达到可立项标准，可立项。
3. 项目经理维护TPAD项目需求状态，加项目成员进入TAPD需求。

项目经理发出《XXX项目立项通知》邮件，收件人项目干系人。

包含：《软件设计时间计划》、项目组成员。

1. 立项前确认有人力资源。（人力冲突时按优先级排）
2. 跨部门的人力要协调好。
   
   

我还是习惯在禅道使用“项目”来管理一次迭代。一次小项目就是一次迭代。

1. UI人员进行UI效果图设计，按计划时间交付。

1. 项目经理分解任务，产出"任务分工表"，可以是粗版，用于分配设计任务。
2. 开发人员领受设计任务，按分工表进行软件设计、数据库设计。

产出《XXX项目任务分工表》（粗略）

产出《XXX项目软件设计文档》

产出《XXX项目数据库设计文档》

1. 软件设计文档，用于后面的软件设计评审，内容不求多，求务实。要包含：表结构设计、接口设计、主业务流程、关键状态等部分。
2. 我们做的项目一般是在既有平台上快速迭代，不建议分为概要设计、详细设计。反而承接的外包项目、并且是大型新项目需要做概要设计、详细设计。别让设计文档成为工作负担，一切以能通过设计评审为目标。

1. 编写《测试用例》或《测试功能点》
   

产出《XXX项目测试用例》或《XXX项目测试功能点》

1. 较大的项目，新系统可编写《XXX项目测试用例》。
2. 较小的项目，要求很快上线的项目，可编写《XXX项目测试功能点》。
   

1. UI人员组织UII效果图设计评审会，参加人员可由项目经理招集。
   
2. 进行UI设计评审。

1. 产品经理对UI效果图的质量负责。
2. 项目经理自行把控是否组织UI设计评审会。
   1. 例如：小项目可省略此步。
   2. 例如：有3个以上新页面，建议组织UI-设计评审会，会议可大可小。

1. 项目经理组织软件设计评审会，参加人员可由项目经理招集。（人员：产品、测试、研发、架构、DBA），
2. 如果是新系统要申请服务器资源，可以叫运维人员参会。
3. 进行软件设计评审。

会前：发出《XXX项目软件设计评审邀请》邮件。

会后：产出《XXX项目编码任务分工和排期计划》，并发出邮件通知

1. 项目经理必须组织软件设计评审，重点评审，反复讨论，保证项目质量。
2. 根据情况可含测试人员、架构人员、DBA人员

1. 测试人员组织测试用户例评审会，参加人员可由项目经理招集。
2. 测试用例评审

会前：发出《XXX项目Case评审邀请》邮件。

会后：产出《XXX项目测试任务分工和排期计划》，并发出邮件通知

1. 测试经理对测试用例负责。
2. 项目经理自行把控是否测试用例评审会。

1. 项目经理分解任务，按《软件设计文档》形成最终的“任务分工表”，可以在之前“任务分工表”上做调整。分配开发任务到每一员开发人员。
2. 项目经理带领项目组成员，按《需求文档》、《软件设计文档》、效果图、静态页，进行软件开发工作。
3. 开发人员每天更新“任务分工表”中的进度。
4. 开发人员每天在TAPD维护对应任务

1. 《任务分工表》用于每日站立会议时，每个人讲述自已的工作进展。
   
2. 处理需求变更：
   1. 如果遇到需求变更，需求方要与项目经理进行沟通，必须由项目经理确认，并且邮件通知项目组成员(产品、开发、测试)。
   2. 项目经理一定要谨慎评估需求变更对项目的整体影响，若发现可能影响项目进度、项目质量，可拒绝或要求增加工期。一切以邮件为准。

前后端人员进行接口联调

开发人员-提测

1. 项目经理主导，合并需求分支到测试分支，解决冲突。
2. 项目经理主导，把程序布署到测试环境，保证能正常运行起来。
3. 测试人员在测试环境进行冒烟测试，通过后代表提测成功。

项目经理发出《XXX项目提交测试通知》邮件

测试人员发出《XXX项目Show Case通过》邮件 （冒烟测试）

1. 在测试环境冒烟测试通过后，表示提测成功，测试人员方才正式接手，项目进入测试阶段。
2. 当关联子系统较多时，通过冒烟测试是一个难点。

1. 测试人员按《测试用例》展开测试工作，一轮测试、二轮测试、三轮测试。
2. 项目经理组织CodeReview。
3. 开发人员修复bug。
4. 测试人员在TAPD维护bug，开发人员和测试人员及时维护bug状态。

测试通过后，测试人员发出《XXX项目测试报告》邮件。

1. 开发人员修复bug后要自测，不要未自测就丢给测试人员。
2. 一个bug反复ReOpen的，测试人员可报告给项目经理。

对于一般性功能上线，预上线业务验收工作为非必须项，但对于重大功能或项目，因影响范围及意义较大，为保障上线质量，经产品经理/项目经理评估需要业务部门协助验收的，由负责项目的产品经理通知需求提出人进行预上线业务验收。对于产品经理/项目经理评估需要业务预验收的项目，预验收不通过的不可上线。

1. 项目经理编写《上线计划》。
2. 项目经理组织上线计划评审会。
   
3. TAPD维护上线计划。

产出《XXX项目上线计划》

项目经理发出《XXX项目》上线计划、执行上线通知邮件

1. 《上线计划》包含：上哪些系统、上哪些配置、上那此SQL。
2. 是否要申请新服务器、新域名、新小程序、新SSL证书等。
3. 上线后是否要通知运营人员填充内容等等

当收到"执行上线通知"后，按《上线计划》执行上线动作。

上线当天下午5点封包

停止上线的标准：（2021-3-29号加入）

上线超过当天22点未完成的，就停止上线，已上的内容回滚。

说明上线组织不充分，复盘并检查，第二天再上。

上线的系统包含移动端小程序、App时，它们可以延时发布。

由需求提出人进行线上验收，所有功能上线均需要业务进行线上测试验收。
线上业务验收流程：
1）对于当天要上线的内容，产品经理通知业务部门，指定验收负责人，并配合产研部门做线上验收；
2）上线完成后，产品经理通知需求提出人进行线上验收；
3）需求提出人完成验收并通过后，在测试人员发出《XXX项目线上验证通过》的通知邮件基础上回复验收结论；
业务部门需做好线上业务验收的配合工作，当天上线内容当天需进行线上验收，以确保功能上线后的正常运行。
如上线当天因业务部门原因无法进行线上验收，需由一级业务部门负责人邮件发出无法验收说明，同时需要次日完成验收。对于不按规范进行验收的，默认视为业务验收通过。

项目经理组织项目总结会议，列出需要改进的方面。