适用于中小型团队的产品交付流程

本文来源于我所在公司的产品交付流程,比较适用于其他中小型团队。目的主要是介绍一下产品交付过程中涉及到的几个关键步骤,大家可以参考本文并结合自己团队的实际情况,进行查漏补缺。


本文目录:

第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:通过数据分析,应该要发现产品的问题或者是可优化点,针对性的给到产品迭代方案,使得产品通过多个版本迭代达到最优的状态。

总结

以上主要是适用于中小型团队的产品交付流程,其中以下几点大家也需要额外关注的:

1.需求过滤,对于业务部门来说,需求都重要、都紧急,所以产品更应该以专业的角度评估需求合理性,敢于给业务部门提建议和说“不”。一味的委曲求全,并不会得到业务部门的尊重;反而向需求方展现出自己的专业性,更能得到业务部门的尊重。

2.需求前置,上述N1、N2、N3......这些时间点虽然不确定,但是想表达的就是需求前置。至少有1个版本在进行中、1个版本已立项、1个版本需求大致已确认,这样的产品规划迭代周期对于产品来说,会是有条不紊的状态。

3.持续性关注,主要是项目复杂度高且开发水平较弱、测试不熟悉业务的项目需要持续性关注,避免因为人的因素导致项目延期。

4.跨开发组任务,为了避免项目延期的话,尽量让底层接口提前一个发布周期上线。(同样依赖于需求前置)



以上是基于我们公司现有的产品交付流程进行整理汇总,可能存在一定的局限性,仅供参考,欢迎大家多交流学习!

你可能感兴趣的:(适用于中小型团队的产品交付流程)