本文来源于我所在公司的产品交付流程，比较适用于其他中小型团队。目的主要是介绍一下产品交付过程中涉及到的几个关键步骤，大家可以参考本文并结合自己团队的实际情况，进行查漏补缺。
本文目录
第1步：需求评估和接收
第2步：产品立项
第3步：测试用例评审
第4步：开发/测试沟通确认
第5步：上线前准备
第6步：上线后收尾
第1步：需求评估和接收
工作一：需求评估
工作描述：
- 需求讨论，需求方描述现状和表达期望，产品进行引导，结合场景进行需求描述，使得在需求前期能考虑到各种场景，一方是避免场景遗漏和未满足情况；另外一方面结合场景可以较快的识别需求真伪。
- 需求评估，涉及到评估2个部分：一是需求是否合理；二是需求优先级。
- 进入需求池，将已明确的需求放进需求池内，标明需求优先级。之后高优先级的需求，会优先进入技术可行性讨论阶段。
涉及部门：产品（主导）、业务部门；
时间节点：V1.0版本提测-N1天；
关键产出：更新的需求池文档；
备注：进入需求池前需要进行需求筛选和优先级初步判断，这个环节也依赖于数据分析，通过数据来判断需求场景多大、影响面多广，从而综合的进行需求筛选和优先级确定。
工作二：技术可行性讨论
工作描述：将待可行性讨论的需求汇总，然后与技术进行讨论以确定实现方案。这里需要产品初步评估什么样需求需要进入技术可行性讨论阶段，避免增加无效的讨论。技术可行性讨论的结果主要是需求能否实现、实现成本。
涉及部门：开发（主导）、产品；
时间节点：V1.0版本提测-N2天；
关键产出：完成需求方案（原型、流程图）；
备注：这个环节前提是产品和开发明确好技术实现方案，之后产品才需要完成原型逻辑、流程图以及相关数据统计模型。
工作三：接收需求
工作描述：需求明确可行或者需求因为技术限制做了变动方案，这时候需要和需求方沟通确认，最终让需求方正式下达业务需求通知。主要是需求描述（现状期望）、需求目的、需求预计上线时间等。
涉及部门：产品、业务部门（主导）；
时间节点：V1.0版本提测-N3天；
关键产出：需求单（word文档）；
备注：在需求单下发之后，产品上线之前，若存在需求变更，则需要需求方提供相应的需求变更单。
第2步：产品立项
工作一：视觉确认
工作描述：主要是涉及到C端产品相关视觉，需要产品和业务部门共同进行确认，产品主要是确认原型上元素和交互，视觉是否已经呈现。业务需要确认现有视觉是否优化调整。
涉及部门：UI设计（主导）、产品、业务部门；
时间节点：V1.0版本提测+N4天；
关键产出：视觉交互稿
工作二：项目启动会
工作描述：V2.0版本项目启动会，主要是确定V2.0版本有哪些需求、预计上线时间以及各个关键节点时间。
涉及部门：UI设计、产品（主导）、QA、开发；
时间节点：V1.0版本提测-N5天；
关键产出：V2.0版本需求列表、接口定义列表、需求任务；
备注1：当产品兼顾项目时，需要给开发进行需求任务新建，若是跨开发组任务，则需要将跨组项目进行关联。
备注2：底层接口提前上线，目的是跨组项目风险性较大，底层接口提前上线可以在一定程度上减小项目延期风险。
备注3：业务数据统计也属于需求范围，提前告知数据统计逻辑，有利于开发进行表结构设计，避免上线后无法有效的通知到业务数据。
第3步：测试用例评审
工作一：参与测试用例评审
工作描述：测试用例评审主要是QA针对于V2.0版本需求进行用例整理，以及解答QA和开发对于需求理解存在的细小疑问。即使是细小的逻辑遗漏，在开发中发现时可能需要花很长时间才能进行修复。提前进行测试用例评审的目的是：让开发更清楚需求、减少因为需求逻辑不清晰导致的项目延期风险。
涉及部门：产品、QA（主导）、开发；
时间节点：V1.0版本发布+N6天；
关键产出：测试用例文档；
备注：主要是需求缺漏补充和影响面确认，以及对接口定义列表进行二次确认。
第4步：开发/测试沟通确认
工作一：开发和测试过程中沟通确认需求
工作描述：这个阶段主要是进入到开发和测试阶段，这个阶段主要是针对异常情况的确认和沟通。前期需求明确的越清晰，这个阶段需要产品确认的异常情况会越少。产品可以利用这段时间进行下个版本需求的整理。
涉及部门：产品（主导）、开发、QA（主导）；
时间节点：V2.0版本开发/测试中；
关键产出：原型逻辑和需求文档完善；
备注：如果产品是兼顾项目工作，则在开发和测试阶段仍需要关注项目整体进展，这个阶段是产品上线主要阶段，风险较大。
工作二：风险评估
工作描述：若前期需求足够清晰，那这个阶段主要是关注“人”，因为“人”这个因素会影响到事和时间，最终导致项目产生较大的风险。
涉及部门：产品（主导）、开发、测试；
时间节点：V2.0版本开发/测试中；
关键产出：项目进度表、产品自查表；
备注1：项目进度表是呈现项目进度情况，主要是关注开发/测试过程中的关键时间节点，避免因为这个环节的关键时间节点延期导致整个项目的延期。如果存在延期的话，那需要风险应对计划，是进行删减需求还是加班加点处理，这些都需要产品进行明确风险应对计划。
备注2：产品自查表，主要是产品在项目上demo后进行模拟自查，主要是明确产品交互符合期望，另外确认产品流程基本正常，避免上线后才发现产品不是自己想要的东西。
第5步：上线前准备
工作一：数据埋点
工作描述：数据埋点主要是针对客户端产品进行，客户端产品的埋点需要在发版之前完成。不过越来越多的数据分析工具已经支持事前无埋点，事后定义事件名。
涉及部门：产品（主导）、开发；
时间节点：V2.0版本提测+N7天；
关键产出：埋点事件列表；
备注：需要确认开发是否完成埋点，以及是否正确的进行埋点，避免开发出现漏埋点和错埋点的情况。
工作二：操作手册和FAQ
工作描述：项目复杂度较高、跨业务部门多、影响业务主要工作的需求，在产品上线前，需要提供给不同的业务部门操作手册以及相关FAQ，避免产品上线后大量业务反馈不了解需求的情况。
涉及部门：产品（主导）、业务部门；
时间节点：V2.0版本提测+N8天；
关键产出：系统操作手册、FAQ文档；
第6步：上线后收尾
工作一：上线内容通知
工作描述：通知需求影响的各个业务部门产品上线的通知，特别是客服部门，另外在通知中提供系统操作手册和FAQ文档。
涉及部门：产品（主导）、业务部门；
时间节点：V2.0版本发布+1天；
关键产出：上线通知邮件；
工作二：数据分析及迭代方案
工作描述：产品上线后需要进行数据分析，分析的目的是为了检验产品上线效果和发现存在的问题。
涉及部门：产品组（主导）、数据分析；
时间节点：V2.0版本发布+1天；
关键产出：数据分析报告、产品迭代方案；
备注1：数据分析报告需要结合业务数据和用户行为数据，而不能单一只看某一类数据。
备注2：通过数据分析，应该要发现产品的问题或者是可优化点，针对性的给到产品迭代方案，使得产品通过多个版本迭代达到最优的状态。
总结
以上主要是适用于中小型团队的产品交付流程，其中以下几点大家也需要额外关注的：
- 需求过滤：对于业务部门来说，需求都重要、都紧急，所以产品更应该以专业的角度评估需求合理性，敢于给业务部门提建议和说“不”。一味的委曲求全，并不会得到业务部门的尊重；反而向需求方展现出自己的专业性，更能得到业务部门的尊重。
- 需求前置：上述N1、N2、N3……这些时间点虽然不确定，但是想表达的就是需求前置。至少有1个版本在进行中、1个版本已立项、1个版本需求大致已确认，这样的产品规划迭代周期对于产品来说，会是有条不紊的状态。
- 持续性关注：主要是项目复杂度高且开发水平较弱、测试不熟悉业务的项目需要持续性关注，避免因为人的因素导致项目延期。
- 跨开发组任务：为了避免项目延期的话，尽量让底层接口提前一个发布周期上线。（同样依赖于需求前置）
以上是基于我们公司现有的产品交付流程进行整理汇总，可能存在一定的局限性，仅供参考，欢迎大家多交流学习！
爱盈利-运营小咖秀(www.aiyingli.com) 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容；是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台；
想了解更多移动互联网干货知识，请关注微信公众号运营小咖秀（ID: yunyingshow）
