【产品】TOB项目工作流程—产品篇

自上次总结项目流程已经3个月了，目前工作节奏放缓了一些，是时候分享一些工作细节了，希望可以对没有工作经验的产品们一些提示，当然感谢各界大佬沟通交流~
今天把产品主线流程介绍下，至于工作细节先不过多赘述，没错，再给自己挖坑慢慢填吧~

流程需要按项目实际调整

其实根据客户和项目的特点，整个工作的流程都会或多或少的受到影响，毕竟金主爸爸最大。

• 有的产品功能需求明确的，有的就是和你玩儿概念；
• 有的客户能按照你提供的交付节奏走的，有的就是不停的催催催，恨不得今天提想法明天就上线的；
• 有的客户对产品有明确想法，无关的需求就找到其他厂家拆分解决，有的客户对产品没啥明确定位，有需求就让你做，最后产品十分臃肿还是个四不像；
• 有的客户相关干系人关系非常明确，需求逐级反馈评审就可顺利通过，有的干系人关系纷繁复杂，各种帮派斗争导致产品需求与设计迟迟不能拍板确认；

实在太多种场景了，没法一一描述出来，想说的是特别是和在比较复杂的项目中，的确会存在诸多无奈，但心中要有一定的大局观，如果项目不能按照正常的流程走，后面的损失和代价可能会更加惨重，这个要做平衡。当然正常的流程也需要更新换代，根据项目实际做迭代调整。

明确项目目标

在前期商务过程中，大多项目合同上是有验收标准的，一切工作都要围绕着核心目标展开。运营商的主要分为CAPEX和OPEX，CAPEX即资本性支出；OPEX指的是企业的管理支出，即运营成本。CAPEX是比较省心的，相比较来说交付物比较明确，如果是运营项目那就是个耗时耗心力的活儿了。

需求管理

项目的需求多数来自客户或用户，也有来自内部的，包括产品、测试等。由于大家比较擅长说一句话的需求，让客户给你写需求文档多数是不存在的情况，所以这时一定要有产品需求池，方便记录各方需求并按照优先级排期设计开发。这个优先级是一定一定要得到客户认可的，除非开发的功能你以后不会写到工时中并且客户对交付节奏没意见。格式可参照下图：

• 需求方描述就是客户的一句话需求，一定要写清楚需求背景目标，而不是客户的建议，一般客户的建议和需求场景还是有距离的，还是需要评审后得出的；
• 状态可分为未开始/需求澄清/开发中/测试中/验收中/已交付/挂起/关闭；
• 如果需求提出方不是很多，可以去掉提出部门字段；
• 需求对接人由项目经理(或产品总负责人)选定，承担起需求从生到死全过程的跟踪，在项目成长期一两人是顾不来蜂拥而至的需求；
• 由于公司研发内部使用禅道管理，所以对应禅道上的需求编号记录下来，方便查看实际研发状态；

注意客户和用户两者的不同，可能存在最终使用的用户不是直接能对接到的客户，这种情况对于需求的确认带来阻碍，大大增加了最终交付返工的风险。所以一定要做好需求沟通确认，尽量让客户组会让用户参与需求评审确认环节，可用流程图、原型等形式让用户更好的理解产品交付后的效果，并在定版后发送邮件给各方确认。

需求分析与设计

在需求初步评审合理后，一般是进入需求分析及详细设计环节。

但也存在谨慎的局方让你先把工时发出来确认的，担心项目预算出现啥问题，所以这时候就需要对产品需求做初版分析，将大块的交付点列举下，再与研发等相关方沟通，估算工时以回复客户。

需求可大可小，复杂的需求需要多方多轮讨论，渐进明细的。所以即使再缩短工期也需要初版评审和详细版需求评审。

1. 需求负责人了解需求背景情况后，评估初版评审时间（按照需求大小而定，一般最多不超过2个工作日），需要输出与讨论范围如下（以下是本人参与项目常用分类方式）：

• 功能-新增类需求：梳理需求背景与目标，梳理业务流程、任务流程、功能结构、信息结构，输出页面交互原型，整理待客户/开发组/数据组确认问题列表；

• 功能-优化类需求，梳理需求背景与目标，输出修改点，整理待客户/开发组确认问题列表；

• 数据类需求，梳理需求背景与目标，输出修改点，整理待客户/数据组确认问题列表；

  根据问题类型找到首次评审的人员范围，如功能实现类与开发沟通；数据实现类与数据口径组沟通；
  如果实现层面都没问题，就与客户/用户组会沟通，业务逻辑及原型设计（一些比较高层的客户会出高保真设计进行沟通）是否合理，哪些需要明确具体细节设计的，需求负责人需要跟踪落实相关问题确认（控制在1.5工作日以内）。
  如果整体设计疑义较大，就需要优化修改后再次组会确认；如果改动较小则可直接到下环节。

2. 结合与各方初版讨论后的结果，优化原型设计，编写详细需求说明书，评估详细评审时间（控制在1.5工作日以内）
3. 将详细需求说明书发送邮件(或发到客户群中)，如没有回复则提醒客户查看，直到有人回复确认（一定要有耐心，真的存在翻脸不认账的客户，如果你们关系相当好客户忽略此步）；
4. 与项目经理确认需求评审时间，将详细需求说明书发到内部群中（至少提前讨论时间0.5工作日），参会人员一般包括需求组、设计组、开发组、数据组、测试组、运维组等人员；
5. 需求评审会介绍需求内容，就各方问题进行解答。
   a. 如果有需要外部确认的问题，需求负责人记录下与局方沟通确认，并将结果补充需求文档中，同步到工作群中。
   b. 如果各方没有问题，则将需求提交禅道，并与研发确认计划交付时间

参与研发过程中

设计

很多公司都配有专业的设计人员，她们对产品最终的交付样式负责。但有的公司这块工作也是放到了产品身上。为了让交付后产品风格保持一致，并且尽量减少各方工作量的前提下，整体设计优先考虑开源的框架（如Vant2或若依等）。如果业务场景不满足的情况下，需要公司内部搭建自己的设计规范，形成统一风格的组件库，当然针对一些特殊页面会出高保真设计图，以便于后期前端开发。
设计评审环节会针对业务需求、产品整体风格、开发实现难度等角度确认。没有问题后会同步到原型工具上，墨刀或者蓝湖等。

开发

在实际研发过程中，仍然存在诸多细节在前期评审没有注意到的，这时就会存在开发人员与需求负责人确认实现逻辑，可能有前端有后端，可能会持续整个研发过程中。多数的问题是可以解答的，但也存在需要客户/用户确认的情况，这时需要进行有效沟通，并将详细描述补充需求文档中，并同步工作群中。

测试

针对较为复杂的需求，需要提前参与到交付测试环节，同样可以留意经常出现的问题，再后面需求确认或产品优化等部分有针对性的优化。

交付验收及培训

代码更新生产后，一般需要测试人员在生产环境再做一轮测试，因为会存在生产与测试环境的数据不一致，短信等外部网络接口不通等情况，造成某些功能在测试无法测试或者效果不同。同时产品也需要进行业务测试，一般在没有阻断性问题的前提下就会交付客户和部分用户做业务测试（需要提供操作指引）。
对于新功能或改造比较大的功能，在交付正式推广使用是需要做产品培训的。准备材料包括用户操作手册、操作视频。培训形式有现场培训（疫情期间基本取消了）、线上会议培训。培训前需要了解培训群体，最好有名单保证这些人可以正常使用产品，跟着培训内容一同操作。还需要结合不同场景介绍使用流程，表述清楚功能特色与实现效果等。当然培训后组群交流，还可以创建线上文档，方便记录用户使用问题或优化需求。产品后期运营是非常重要的，有迭代更新的功能才更有生命力。

功能交付后记得更新各类文档状态，形成需求闭环管理。

相关文章：【产品】产品迭代各部门工作全流程（5年工作经验都在这了=.=）