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