产品交付流程总结
一、需求评估和接收
1、需求评估
工作描述：
- 需求讨论。
- 需求评估，2个部分，一是需求是否合理，二是需求优先级。
- 进入需求池，将已明确的需求放进需求池内，标明需求优先级。之后高优先级的需求，会优先进入技术可行性讨论阶段。
涉及部门：产品（主导）、业务部门/BOSS；
时间节点：V1.0版本提测-N1天；
关键产出：更新的需求池文档；
备注：战略层。
2、技术可行性讨论
工作描述：
- 将待可行性讨论的需求汇总，然后与技术进行讨论以确定实现方案。
- 定义需求，确定功能规格，不要求厚与详细，要求准确
涉及部门：开发（主导）、产品；
时间节点：V1.0版本提测-N2天；
关键产出：完成需求方案（UML+word）；
备注：范围层。整理需求池，提取完整的功能汇总。
3、接收需求
工作描述：
- 需求明确可行或者需求因为技术限制做了变动方案，这时候需要和需求方沟通确认，最终让需求方正式下达业务需求通知。
- 主要是需求描述（现状期望）、需求目的、需求预计上线时间等。
涉及部门：产品、业务部门/BOSS（主导）；
时间节点：V1.0版本提测-N3天；
关键产出：需求单（word文档）；
备注：范围层。将需求方案与业务部门/BOSS核对，确定正式需求单。
二、产品立项
1、视觉确认
工作描述：
- 交互设计，从需求单填充功能和内容
涉及部门：UI设计（主导）、产品、业务部门/BOSS；
时间节点：V1.0版本提测+N4天；
关键产出：视觉交互稿（概念）；
备注：结构层。
2、产品原型
工作描述：
- 根据视觉交互稿，提交修改后的V2.0高保真原型，便于交付UI
涉及部门：产品（主导）、UI设计；
时间节点：V1.0版本提测+N5天；
关键产出：V2.0 Axure 原型；
备注：框架层。
三、测试用例评审
1、参与测试用例评审
工作描述：
- 测试用例评审主要是QA针对于V2.0版本需求进行用例整理，以及解答QA和开发对于需求理解存在的细小疑问。
- 即使是细小的逻辑遗漏，在开发中发现时可能需要花很长时间才能进行修复。
涉及部门：产品、QA（主导）、开发；
时间节点：V2.0版本发布；
关键产出：测试用例文档（word+ecel）；
备注：查漏补缺，后续根据测试用例进行测试。
四、开发/测试沟通确认
1、开发和测试过程中沟通确认需求
工作描述：
- 这个阶段主要是进入到开发和测试阶段。
- 这个阶段主要是针对异常情况的确认和沟通。
- 前期需求明确的越清晰，这个阶段需要产品确认的异常情况会越少。产品可以利用这段时间进行下个版本需求的整理。
涉及部门：产品（主导）、开发、QA（主导）；
时间节点：V2.0版本开发/测试中；
关键产出：原型逻辑和需求文档完善；
备注：根据测试用例进行测试，修复异常情况，增加新需求。
2、风险评估
工作描述：
- 若前期需求足够清晰，那这个阶段主要是关注“人”，因为“人”这个因素会影响到事和时间，最终导致项目产生较大的风险。
涉及部门：产品（主导）、开发、测试；
时间节点：V2.0版本开发/测试中；
关键产出：项目进度表、产品自查表；
备注1：项目进度表是呈现项目进度情况，主要是关注开发/测试过程中的关键时间节点，避免因为这个环节的关键时间节点延期导致整个项目的延期。如果存在延期的话，那需要风险应对计划，是进行删减需求还是加班加点处理，这些都需要产品进行明确风险应对计划。
备注2：产品自查表，主要是产品在项目上demo后进行模拟自查，主要是明确产品交互符合期望，另外确认产品流程基本正常，避免上线后才发现产品不是自己想要的东西。
五、上线前准备
1、数据埋点
工作描述：
- 数据埋点主要是针对客户端产品进行，客户端产品的埋点需要在发版之前完成。
- 不过越来越多的数据分析工具已经支持事前无埋点，事后定义事件名。
涉及部门：产品（主导）、开发；
时间节点：V2.0版本提测+N7天；
关键产出：埋点事件列表；
备注：需要确认开发是否完成埋点，以及是否正确的进行埋点，避免开发出现漏埋点和错埋点的情况。
2、操作手册和FAQ
工作描述：
- 项目复杂度较高、跨业务部门多、影响业务主要工作的需求，在产品上线前，需要提供给不同的业务部门操作手册以及相关FAQ，避免产品上线后大量业务反馈不了解需求的情况。
涉及部门：产品（主导）、业务部门；
时间节点：V2.0版本提测+N8天；
关键产出：系统操作手册、FAQ文档；
备注：说明书。包含新手指引文档。
六、上线后收尾
1、上线内容通知
工作描述：
- 通知需求影响的各个业务部门产品上线的通知，特别是客服部门，另外在通知中提供系统操作手册和FAQ文档。
涉及部门：产品（主导）、业务部门；
时间节点：V2.0版本发布+1天；
关键产出：上线通知邮件；
2、数据分析及迭代方案
工作描述：
- 产品上线后需要进行数据分析，分析的目的是为了检验产品上线效果和发现存在的问题。
涉及部门：产品组（主导）、数据分析；
时间节点：V2.0版本发布+1天；
关键产出：数据分析报告、产品迭代方案；
备注1：数据分析报告需要结合业务数据和用户行为数据，而不能单一只看某一类数据。
备注2：通过数据分析，应该要发现产品的问题或者是可优化点，针对性的给到产品迭代方案，使得产品通过多个版本迭代达到最优的状态。
总结
1. 需求过滤：对于业务部门来说，需求都重要、都紧急，所以产品更应该以专业的角度评估需求合理性，敢于给业务部门提建议和说“不”。一味的委曲求全，并不会得到业务部门的尊重；反而向需求方展现出自己的专业性，更能得到业务部门的尊重。
2. 需求前置：上述N1、N2、N3……这些时间点虽然不确定，但是想表达的就是需求前置。至少有1个版本在进行中、1个版本已立项、1个版本需求大致已确认，这样的产品规划迭代周期对于产品来说，会是有条不紊的状态。
3. 持续性关注：主要是项目复杂度高且开发水平较弱、测试不熟悉业务的项目需要持续性关注，避免因为人的因素导致项目延期。
4. 跨开发组任务：为了避免项目延期的话，尽量让底层接口提前一个发布周期上线。（同样依赖于需求前置）
