在互联网公司，产品经理也充当项目经理的角色。每次产品迭代，都是一场战役，而在项目管理过程中风险无处不在，如果我们知道接下来会有哪些风险，那就可以提前准备做好预案，从而大大减少我们产品迭代上线时间的风险。
往往在项目管理的过程中，产品经理缺乏的是对项目有整体的全景认识，此时需要产品经理提前考量各种约束潜在风险，并且在一个个产品迭代过程中积累成体系的产品风险管理方案。针对于这样的方式做产品风险管理，可以大部分把风险降到最低值。
一、列出潜在风险
产品经理应该和技术负责人、运营负责人在项目初期阶段，把能想到的所有风险都列出来，先暴露风险并做好准备。
健康的产品迭代流程，风险系数是会随着产品迭代过程呈现递减趋势，可控性会提高很多。
风险点的挖掘可以从项目管理全路径去发现。项目管理是对人、财、物、时间的管理与协调，刚开始时可以从这四个纬度做简单的挖掘阐述。
在项目推进的过程中，核心的里程碑事件如果要依靠到项目外资源的交付，那么就要做好风险预案。如果外部资源交付出了问题怎么办，你的planB计划是什么。
如果某件事不确定是否有风险点，那么算作该事件有风险点。风险控制是要保证潜在的风险点不发生或者发生后的解决措施。
John非常贴心的为大家准备了互联网产品迭代常见的风险清单。（风险清单一定是在项目初期过程中提前给各组干系人须知，让每个项目组成员提前感知潜在的风险，直到产出对应的解决方案）
（这张图片求你们保存下）
二、风险应对策略
1.需求篇
在产品迭代的过程中，最怕出现了主要流程和核心逻辑调整，意味着技术前面预研和开发的项目全废了。这也是为什么在项目评审前需要加上技术预研的过程。另外有一说一，产品经理在产品设计的过程中一定需要把控好需求的过程。
秉承着三个原则：想清楚、说明白、动手快
第1个是一件事情能把它想清楚。任何一件事发生了，产品经理能不能想到它底层的原因是什么？它的根本是什么？
现在所有的电商平台，都想做直播电商。其实直播电商本质是品牌方对私域流量渴望的体现，直播为工具，电商为基础。直播电商重塑人货场：
人：从主动消费变为被动消费；（主播是谁很重要，是否有带货的潜质？）
货：实现去中间商，拉近产品原产地；（商品是否有吸引力，价格和质量决定商品能否卖出去）
场：“千里眼+顺风耳”的功能变成现实。（平台服务和直播体验以及下单流程就很重要）
第 2 个叫说的明白。因为产品是整条线的那个牵头人，如果一个产品人不能把你的想法这件事情的东西说明白，就是能力很差，不存在表达能力很差的产品经理。有一句话很经典，希望所有产品经理都能记住：
如果你不能用简单的话来完整表达你的产品/想法，证明你根本不了解/没思考清楚。
第 3 个是要有能力快速的去试。这个试包括但不限于把产品搞上线让用户/客户来用，也包括了可能做一个粗的原型，也包括了可能去做访谈，去做客户的沟通。
做好这三个步骤，迭代上线后很难出现无人问津的局面了。可能你就会问了，想清楚这件事极其的难，如果能想清楚事情，就不会出现这么多死掉/昙花一现的产品了。的确是，那我可能就会反问你了。你调研/拆解了多少竞品，梳理了多少他们的运营大事件。以及基于当时的环境为什么这么做？——这儿其实在他们的产品版本迭代记录中全部能找到。建议去看下你负责产品的竞品历史版本迭代记录。你会发现很多有意思的点。
落地回来到项目风险的点中，一定要对需求琢磨琢磨再琢磨。否则一切都是白搭。
2.团队协作篇
在《腾讯方法》这本书中，提到过一种团队协作方法，那就是建立团队协作任务故事墙。顾名思义，任务故事墙就是把团队中每个人的任务故事分解成一个个的小任务，然后贴在墙上，使得项目信息变得透明化和可视化，从而方便团队成员跟踪进度，提升协作效率。
如上图所示，一面简洁的故事墙制作起来其实并不复杂，最主要的元素大概就是以下四点：
“任务负责人”列：这一列主要就是把团队成员写上，比如产品、UI、前端、后端、测试等等。方便团队成员知晓每个任务的跟进负责人是谁。
“待办事项”列：还没有开始做的任务，负责人需要把当前版本的任务或者一些临时需求添加到“待办事项”列，方便团队成员清晰看到自己近期总共有哪些任务。
“进行中”列：正在进行中的任务，负责人需要把正在进行中的任务移动到“进行中”列，方便团队成员清晰看到自己正在进行的工作有哪些。
“已完成”列：已完成的任务，负责人需要把已完成的任务移动到“已完成列”，方便团队成员清晰看到自己已经完成的工作任务有哪些。
这四个元素就构成了一面团队协作故事墙，团队成员通过添加、减少、移动墙上的任务便签，就可以让整个团队清晰了解项目的进度状况。
那么，在每天站立会的时候，每个团队成员只需要站到故事墙前面，用语言讲解和移动便签相结合的方式向团队传达自己昨天做了哪些任务，已完成和未完成的哪些，今天又准备做哪些任务。
同时，要注意的是，对于各个成员之间相关度比较高的任务，负责人一定要及时向相关人员汇报进度，比如说已完成的情况下要及时告知后续相关人员应该怎么做。这样的话，整个团队成员就能够对每个任务走到哪一步有一个清晰的认知，也就有时间提前准备与任务相关的后续工作。
举例来说：后端在晨会上告知团队后端接口即将开发完成，那么就可以提示前端开发等下就可以对接口了。
当然，在这个过程中，每位成员还可以把自己工作中的一些想法和心得简单分享出来，提出自己的看法；或者说有什么困难，需要其他成员或者其他部门帮忙，也可以及时提出来。
当然里面还涉及到其他的问题，其实就是和相关的人去沟通清楚。事情最怕沟通，沟通过后，事情就怂了。
总结：回到根上来，产品迭代方案早期做好调研：明确用户需求和产品方向，减少后期的变动；早点准备技术调研，让资深技术人员根据项目实际情况做好最合理的技术选型。对常见的风险（需求不断新增，代码提测质量差，计划排期不准，变更记录不全未周知，发布流程不规范等），可以用对应的更完善的流程来缓和和预防问题的发生。
以下是专业项目经理给的方案：
规定在一个固定时间盒不接受新增需求：采用集中评审代码，安排多次代码评审，打通Jira和Git仓库做好功能跟进，扩大冒烟测试用例范围；
适当改变项目的功能范围，保证计划上线；计划排期充分考虑到节假日，学习、开会、评审等缓冲时间；
维护好公共的需求变更记录wiki页面， 建立项目各角色的聊天群组、邮件列表，任何变动及时周知干系人；
规范发布流程必备内容，包含Release note 、Code review报告 、功能测试报告 、异常测试报告（若有） 、性能测试报告（若有），另外要求开发负责人，开发，QA，DBA等重要干系人务必参与评审给出意见。
三、思考
我想以后对产品经理的能力要求越来越高。这并不是说考了个PMP证书就可以了。而是在执行的过程中深入到：这四步：定义产品、设计产品、研发产品和运营产品。
定义产品：首先要清楚你迭代的目的是服务于什么用户/客户，他们的使用场景是什么？总之需要清晰的梳理出：迭代的XX功能是为XX用户在XX场景下使用的。
设计产品：基于场景拆分用户的使用任务，任务再会拆分为功能和交互、内容和信息架构，最终把它呈现到界面上。
研发产品：主要指界面设计、技术研发，还应该有用户体验及可用性测试的部分。
运营产品：产品上线前后的基于产品的运营计划，产品的增长管理、市场营销、跟用户之间不断的互动过程。
希望能够帮到你。记得三连哦。（转发、评论、点在看）感谢了。
John为你准备了历史文章。真的建议小伙伴好好看看：（点击图片过去看原文）
联系客服
