12月的第二场直播我们邀请到了深耕产品领域10年+，具备丰富项目实践与管理经验的@毛毛老师，曾负责从0 到 1 搭建商品力模型、商品质量体系及交易系统重构等大型产品项目；对于业务经营、产品规划、架构设计、产品功能、用户体验、项目协同有着深刻的思考与洞察。本文为直播内容整理，内容有删改。
大家好，我是毛毛老师，有十年的互联网产品经验，过去在百度和阿里巴巴分别工作过5年，做过C端产品算法、策略方面的产品和B端产品，身上关键词主要是O2O电商以及新零售。
首先讲下本次分享的三个w：第一个w是为什么要看这次分享？很多公司12月份是项目规划以及成果回顾的关键时期，把课程设置在这个时间节点，向前看是可以帮助大家去夯实项目管理的基础，迎接未来的挑战，向后看是做一个成果回顾。
相信很多产品经理、项目、交互设计、PMO或是业务的同学在回顾过程中，PPT里一定都是秀肌肉的，对外展示获得了多少的用户量、GMV和转化收成等，但也希望这时大家能够对内修炼自我能力；
第二个w 是可以从这次分享学到什么？本次分享会通过一些实战案例来帮助大家梳理知识链路，会从项目阶段去看每个阶段常见问题是什么？然后配合真实的案例进行原因的拆解，最终形成一条实战解法的知识链路；
第三个w 是怎么样学？这对大家来说挺关键的，所以希望大家在学的时候，能够结合自己过往的经验去思考，然后把它内化成为自己的能力。
上面图片里的这些问题，大家在过去的项目经历中是不是都遇到过？
项目延期、老板叫停、元旦和春节假期，甚至有些项目在立项之初就受阻了，然后需求迟迟不能锁定等，这些问题大家或多或少都会遇到过，当遇到这些问题时第一反应是不是慌张、害怕、紧张逃避？这里是想跟大家分享两句话：接纳问题和拥抱问题。
接纳问题是指需要接受一个事实：就是每个项目都有问题。这个跟生活一样，没有完美的生活，也没有完美的项目，每个项目一定都有问题，这才是正常的；
第二是拥抱问题，如果项目是成长过程，那问题就可以理解成是成长的捷径，我曾经遇过一些非常优秀的产品经理，在遇到问题时展现出来的状态，是处理整个工作中状态最好的时刻，会让人感觉他们是天生的问题解决者。这个成长决定对于个人来说是一种成长，因为会学会独当一面，对于团队来说更是如此，如果是朝夕合作的团队，发现问题的过程也是帮助去发现短板并且补齐短板的过程。
写这两句话是希望大家能够放松心态，接纳问题，拥抱问题。
本次课程一共有四部分：第一部分是拆解项目问题发生的常见原因；第二到第四部分会按照项目事前、事中、事后的时间流去讲事前怎么避免？事中怎么应对？事后怎么复盘？
一、为什么以为万无一失，问题还是会发生？
首先进入到第一个环节—常见原因的分析，先看上面这张矩阵图，不知大家是否有超大型项目的实战经验，比如说双11的大促或者是全新的从0到1的整个业务链路流程。
在大型项目中会有非常多的常见相关人员，竖向是每个职能的划分：有产品、研发、设计、运营、业务等；横向是指在大型项目中，一般都会有个总PM，相关域有产品经理、后端、前端、设计、测试、运营等，然后各种各样的业务对接人、一线操作人员、运营人员，绿色区域是项目涉及到的用户、老板、PMO，有的项目还会购买第三方服务，比如云服务等。
这张图是整个大型项目里常见的相关人员，大家会发现有一个关键词就是人多，这其实就是项目问题会发生的源头，因为项目本质上是由一个个的个体组成的群体，当这些个体需要变成一个群体去做整体交付时，就一定会有问题。所以先来拆解，从个体和群体角度分别去看：个体为什么会发生问题？群体会发生什么问题？
首先看个体，个体原因无非是本能和经验两件事情，所谓本能就是人的本能，人类的本能就是逃避问题，但墨菲定律表明逃避是没有用的，你想到的问题一定会发生，逃避反而会后置风险，加剧问题发生的可能性，甚至是影响。
第二点是经验，经验分为能力不足和经验过度两种情况，经验能力不足可能在初级的产品经理或者是项目管理的人员身上会经常发现，它没有很好的短频快解法，需要去积累或学习一些比较成熟的项目管理经验。
在随着自身成熟度的累积时，也要避免太过依赖经验，因为经验迁移是人类发展史上非常提升效率的方式，过去遇到一个问题，未来遇到一个问题，都可以用同样的解法去做，就不需要再去创新解法，从而提升效率。
但要知道问题发生的项目背景、人往往是不同的，过度依赖过往的经验是一个负向的迁移，这可能也会是导致问题的一个原因。个体原因相对比较简单，接下来重点讲群体原因。
群体原因归纳下来一共有三个方面：一是群体之间的认知偏差；二是群体各个个体里面的Owner意识缺失；三是项目计划的问题。
在讲认知偏差原因时，先用两个案例带大家走一下思考链路，首先大家想象自己坐在一个圆桌前，圆桌有三方：一个是需求方，就是提出需求的业务或运营同学，第二个是研发同学，第三个是PM。
第一个案例是大家坐在一起，要做的项目叫做交易提效，大家可以想象在这个交易流程中，要去做一些业务链路的缩减或者是交互的提升等；第二个项目是CRM销售管理系统，这里的CRM更偏向的是销售后台管理工具，需要上线一个销售在CRM系统中的新下单链路，要求是12月29号上线，接下来就来看下在这个流程中大家的认知偏差到底有多大。
首先在第一个案例里，当大家在谈论所谓的项目收益时，需求方大概率会想：我需要一张每日产出的结果报表，包含GMV、 交易转化提升等，甚至他可能连表的颜色都已经想好了；研发心里面想的是：数据埋点；PM心里想的是：上线之后让研发写sql拉个数就好。
这就是在谈论监控收益这件事情时，如果你没有聊，每个人心里面想的事情都是不一样的。
认知偏差是什么？所谓12月29号上线，需求方心里面想的是：12月29号当天，早上九点上班的时候，全国三千名一线销售都要用新工具去完成整个线索到关单的链路，而且要体现在当年年度的销售GMV里；对于研发来说：29号上线是指在24点前完成上线，30号开小流量，节后再去开全量跑历史数据；PM心里想的是：29号先上线但不开权限，30号小范围试跑，节后再收集反馈和问题。
从这两个案例中可以看出，在讨论同一句话时，每个人位置不同心里面想的事情是完全不同的，这是第一点群体原因认知的偏差；
第二是Owner意识，有一部非常经典的三个和尚动画片：一个和尚有水吃，两个和尚可以分着挑水吃，三个和尚没水吃，人越多Owner意识越淡。还有个核心问题就是执行和责任往往是分开的，最接近风险的那些执行人员却不对风险负责，所以这是第二个比较大的原因；
第三是项目计划的原因，上方这张图是从百度搜的比较经典的PPT，你觉得这是一个好的项目计划吗？这里先卖个关子，在第二部分时再详细讲解，这张图里面是几个时间节点，Q1到Q4，然后有MILESTONE和主题，我们先进入第二个环节，下面再讲这张图。
二、如何消除认知偏差，保证风险前置？
如何在事前进行避免是非常关键的，总结下来一共有三大应对策略：第一是消除认知偏差；第二是多方专家坐在一起评估风险；第三是制定合理的项目计划。
消除认知偏差有几个关键词分别是拉通、明确、纪要。还是用上面提到的CRM链路要12月29号上线的案例，看怎样用这三个关键词去消除认知偏差：
第一个关键词拉通，也就是充分的沟通，在这个案例中，每一个角色脑子里思考的东西都不一样，要做的就是把大家脑子里面的东西摊到台面上来。举例来说，销售脑子里想的年终绩效考核，这是非常影响项目执行和风险的一个点，需要摊在台面上来说；研发脑子里想的是节前上线有风险；PM脑子里想的是这个链路要怎么试跑以及整个培训的推广计划，可能还有怎么样去分解处理Bug、发布禁止窗口等，所有这些点都需要充分的沟通；
第二个关键词明确，所谓明确就是要精准定义，当说12月29号上线这个字眼的时候，希望大家脑子里面是一条时间链路，不是单单上线两个字那么简单。所谓上线，往前走有测试、产品验收、业务验收；往后走，上线后怎么去试跑、推全、历史数据是否要重刷、业务的计算规则等，脑子里是需要明确所有的东西，要有一个精准的定义，而不是模糊说一句12月29号上线这么简单；
第三个关键词纪要，这个比较简单：口说无凭要记下来。这里给大家一些示意：开会该怎样去记录事情？什么时间做什么事情？然后让相应的同学分别去跟进。
这个就是第一大应对，就是要消除大家的认知偏差，关键词是拉通、明确、纪要。
第二个应对是多方专家评估风险，这里总结一个原则，叫做“全透露”原则：人要找全、问题要聊透、风险要暴露。这里有个Tips 是争论等于风险的前置，和谐等于风险的后置，千万不要担心害怕所谓多方专家评估风险，好像是圆桌会议上开始争吵的环节，越是往前争论，风险越小。
接下来通过一个案例来说明“全透露”原则应该做？
假设自己是一个首页的产品经理，要为一个O2O平台做首页的改版，这是一个社区化的改版，改版的目标是通过社区化去提升用户的频次和时长。为了让大家更直观的理解，上面我放了张点评截图，改版之前是很简单的10大金刚、广告位、商家或团购列表，改版之后，除了上面固定部分之外，下面全部变成内容feeds流。假定在这样一个项目中，怎么去用“全透露”原则？
第一，人要找全，这里提供一个三边法则，所谓三边就是第一边资源方、第二边需求方、第三边相关方。用大白话来说，就是谁要的这个需求、谁投入这个需求以及谁被这个需求影响。
在三边法则里，我并不担心大家会漏掉资源方，因为读这篇文章的大多数都是资源方，大家都不太可能会漏自己，但是你可能会漏需求方，需求方你可能不太会漏那些每天在耳边叫唤的人，对于C 端需求来说，希望大家能够永远铭记的是用户是很重要的需求方，所有涉及到用户的风险一定要放在第一位。
另外一个可能会被遗漏的就是相关方，拿首页例子来说，比如一些垂直业务，原来在10大金刚里会占一个位置，但因为整个首页的改版变得没有流量；还有销售KA，原来卖给头部商户的广告位也会受到影响；以及涉及到内容的会有风控和法务，一些涉及到黄赌毒或者擦边球的内容，他们一定要进来看。
所以通过三边法则，希望大家能够把人先找全。
第二，三个原则分别是问题要聊透、风险要暴露。这里有三个可以直接拿来实操的解题链路：
- 理解每一个角色方的出发点；
- 出发点和出发点，理解每一个人的出发点后，在出发点和出发点之间就会有碰撞；
- 因为这些碰撞就可以很容易找到问题和风险。
带入到首页案例去看，设计的出发点关键词：全新、创意、前沿；前端的出发点关键词：成本、复用、性能；社区运营因为是整个项目需求方的提出者，所以更关注整体点击率、用户的时长、首页管理效率；在风控和法务的脑子里面，风险和法规是关键词；然后垂直业务心里面想的是位置在哪里？导流会不会受到影响？
因为有了这些出发点的碰撞，问题和风险评估自然而然就来了。首先从设计层面看比如老板不同意设计的审美怎么办？体验是否太过颠覆？从研发的角度来说是不是有性能、成本的风险？
从用户的体验角度来说，是不是要提供一个旧版的入口？是不是要进行一个AB测试才能上线新版首页？从内容的视角出发，出现擦边球的内容怎么办？这也是一个风险；从垂直业务的角度看，影响导流或者是KA商户的广告位拿掉影响整个营收怎么办？
通过这个案例，就可以看到人要找全、三边法则、问题要聊透、要理解每一个方面的出发点，同时风险要暴露，要把这些风险点及时传导给给老板、相关方等。
第三个应对是制定合格的项目计划，项目计划的三要素：时间、人物、交付，做项目计划本质上是把风险去拆分的过程，把大项目通过项目计划变成子环节。这个时候每一个子环节都是一个小项目，每一个子环节所指定的人物和交付，都是一个小小的Owner王国，能够大大提升每一个环节的各个细微角色的Owner意识，所以这是项目计划的核心诉求，是帮助项目的Owner，同时也帮助去拆解到具体的每一个小的Owner。
再来看回上面提到的项目计划（图1）是一个好的计划吗？首先看三要素：时间、人物、交付。从时间来说，这么粗的颗粒度Q1到Q4 ，再往后很难保证交付；第二人物，这里完全没有提到谁要负责这件事情；第三交付，仅有MILESTONE不叫交付,所以这个项目计划并不是一个非常优秀的项目计划。
合格的项目计划图是怎样的呢？这里用甘特图的模板（图2）来说明，但并不是每一个项目都要用这么复杂的形式去做，可以通过一个个列表，或是在钉钉、飞书等聊天软件里面列任务，形式无所谓，但要记住一定得有交付时间人物。
上面这张图，首先交付非常明确，每一个任务、职能、需求、设计、开发、测试，需要做什么样的交付，后面的点是每一个域或是每一个大环节下面的子环节，反正就不停地拆树状图，把任务交付的颗粒度细到最小颗粒度；
其次是时间，它的开始和结束时间都非常明确，不是一个简简单单的箭头就过去了；第三个是人物，它有人物和依赖关系，比如说A 需求可能依赖某一个需求，所以这张图是一个相对比较完美的项目计划图。
再看图1,它更适合跟老板汇报，因为它是Roadmap，不是项目计划，在这一点上大家一定要分清楚Roadmap和项目计划是不一样的。Roadmap是总结时给老板给大家看的，而项目计划是真的能够帮助你真实要用的东西。
接下来讲事中应对的环节，事中应对就是你已经做了很多事前的避免工作了，但是意外事情还是发生了，怎么办？
三、如何完成复盘成长，避免重蹈覆辙？
在接下来的部分，毛毛老师详细讲解了当问题发生时如何快速采取措施，做好应急管理和如何完成复盘成长，避免重蹈覆辙。
囿于篇幅有限，想要观看完整视频的朋友可扫描下方海报的二维码添加会员学习顾问@小熙老师的微信（微信号：qdxyx520）并备注“毛毛”，即可获得观看链接。
四、本月直播预告
本次会员直播课程，毛毛老师为大家详细讲解了如何做好项目风险管控及应急问题处理，希望大家都有所收获~
每周三/四晚上8点，起点课堂会员平台都会邀请一线的互联网产品、运营实战派专家，与大家分享最新的产品行业动态、运营玩法和干货知识。