事故处理分析心得体会（做一名合格的项目负责人）

在事故发生之前，尽量采取避免措施，但一旦事故还是发生，要有智慧地运用方法解决事故，并且能够采取对策避免让类似问题再次发生。

这篇也是这个系列的最后一篇，我们就直入主题吧！

铲事的本质就是处理事故及与之相关的冲突。作为一名互联网从业者，这三个问题是很典型的“事故”。下面，我们将以这几个案例展开谈谈这个话题：

1. 具体的事项，别人给你排期了。做到一半说：之前排的有问题，搞不完，那怎么办？
2. 和销售确认完毕的需求，上线时候不认账了，说不是他们想要的，那怎么办？
3. 你的下属负责的产品方案上线了，但是被老大发现有影响使用的bug，那怎么办？

事故处理

事故，指发生于预期之外的，已经造成损失的事件。

把这个概念进行拆解之后会得到两个话题，它是我们对事故进行分析的关键性因素。他们分别是：

• 既然已经发生，那么预期内的情况是什么？
• 既然如此，损失是什么？

以开篇的事故为例：

具体的事项，别人给你排期了。做到一半说：之前排的有问题，搞不完，那怎么办？

我尝试复盘一下我刚入行时的心里故事：

啥？时间过去一半了，现在说完不成？你这不是坑我吗？

你这个人太不靠谱了，你当时怎么估的

完不成等于连交付都没做到，一定会影响自己的绩效考核，还有晋升

我要找你老大说说和个事去

对于心理素质不是特别好的同学（当年的我）来说，脑袋里面一瞬间爆出非常多看起来有理，但实则屁用没有的想法。我管这种情况叫「上头」。

个人判断力此时完全被情绪左右，情绪像一只失控的野兽在你的大脑中横冲直撞。我判断这时候80%的执行动作都是走形和无效的。所以我建议悬崖勒马，先回答这两个问题：

• 既然已经发生，那么预期内的情况是什么？「项目稳步推进，按计划可完成」
• 既然如此，损失是什么「团队信心与士气，因为时间过去了一半，有可能剩余时间不够」

对于前者来说，很自然的找出我们当时的计划，按照时间进度挨个确认工作量。弄清楚哪些任务已经完成，哪些任务在进行中，哪些任务还未开始。描述中的“搞不完” 在具体哪个部分。换言之，先算清楚账。你现在需要的是事实，而不是那些判断。

对于后者来说，接着确定的事实推出解决方案。是需求复杂实现成本太高需要简化，还是技术实现方案不合理要调整，或是单纯项目组生产力不够需要补充人手。阶段性目标是处理事故，达成原定目标，任何与拯救当前结果弱相关的事暂不考虑。

无论出现多大，多严重的事故，首先要控制好情绪，在上头时主动关闭本能回路。作为项目负责人，项目组发生的任何事故，你都是第一责任人。事情推进结果不到位，本质上管理者都难辞其咎。出现事故时，项目负责人是需要第一时间站出来的。无论与你的相关性强与弱，大或小，你都需要第一时间组织这件事。这并不是让你上去抗雷，主动分锅（那是回顾会议时的重点），而是作为事故进入处理阶段的推动者。盘清楚事实要比立即行动重要得多。

事故需要被解决，处理不好事故的项目负责人是失职的。

冲突处理

我们知道了什么叫事故。这部分的分析，你只需要料理好自己便足够过关。可是当你面对协作上下游中带着情绪的合作伙伴时，情况就变得更加复杂了。这时候，到直面冲突的阶段了。

照例以开篇故事为例：

和销售确认完毕的需求，上线时候不认账了，说不是他们想要的，那怎么办？

这是很典型的冲突场景。我服务过的团队中，产品和销售基本上都会出现冲突，产品抱怨销售提需求不考虑用户体验，销售嫌弃产品做事上帝视角，听不进去意见。

产品同学为需求实现负责，为用户提供符合产品水准的方案；销售同学为商业化负责，为用户服务让产品创造更高的商业收入。

问题来了，这两个岗位的终极目标是一致的，为什么还会有分歧呢？

我认为冲突发生的因素有很多，但在企业中，分歧大多数来自于专业知识方面。（来自俞军老师的观点）

这些专业知识，分散在员工个人脑中，既包括用户的、市场的、行业的、政策的知识，也包括企业内部运行机制的、文化价值观的、以及企业内其他人的工作内容和个人能力风格偏好等属性。这些专业知识，就是企业的核心竞争力来源。

员工在个人岗位的工作中持续获得和积累的知识，起初都是个人专有的知识，但如果通过语言文字转换为显性知识，就可以被传播，成为企业的共同知识。

专业知识在组织内积累的越多，企业的共同知识就越多；企业积累的共同知识越多，企业内组织效率就越高。说白了，就是大家互相信任，有足够的默契。

曾经有同学跟我打趣说，我在公司开会发言时出场频次最高的词汇就是“共识”。我提议的“共识”便是上文说的共同知识。

有同学会说以上说的我都同意，可为什么要通过冲突的方式来建立共识呢？

我个人的观点是，在职场中我们很难要求每个协作成员都能毫无保留地讲出自己真实的感受。作为员工，大多数时候会有多一事不如少一事的“和尚敲钟”心态。与其说大家相敬如宾不疼不痒地“用片儿汤话”沟通，冲突和分歧或许能更加深彼此了解，有效帮助彼此思考，建立共识。让结果更有保障。

当然，冲突也要讲方式方法，我的建议是：

1. 冲突的目的是产生结论，而非扩散情绪
2. 创造无负担表达观点的氛围
3. 实事求是，对事不对人是一切的前提
4. 用追问和质疑开始进入话题，就事论事保持职业

虽说和气生财，但是一团和气一定会降低大家对于高标准的坚持和对项目的严肃程度，适当的冲突是有利于互相监督的，有利于问题被更全面地考虑。

因此，不要害怕冲突，而要有智慧地运用冲突。

避免事故再次发生

遇事能铲事仅仅是及格的，因为本质上我们还是停留在单点的维度上，进行着应激性的行动。作为一名项目负责人，我建议你可以提升自己的视角，拔高眼界，把注意力放在如何不让类似问题再次发生上。

以开篇故事为例：

你的下属负责的产品方案上线了，但是被老大发现有影响使用的bug，那怎么办？

在一个交付团队中，功能的上线是一定要经过“需求>>设计>>研发>>测试>>验收”的研发过程的。

小型团队没有专职的测试，也会让产品或者研发兼职进行测试。如此就是为了保障纸面需求也可落地，可上线的功能。

当老大发现影响使用的bug，首先要做的就是定位问题，对方案进行调整，尽快完成修复方案的发布。我们是不是要思考一下，既然已经有研发过程依然出现影响使用的bug原因呢？

我们往下追查一下，场景如下：

• 测试未发现该问题「测试环节失误，需要更新自己的checklist，加强业务知识的学习」
• 测试发现该问题，未按照产品方案进行技术实现「测试环节失误，研发环节失误，需要增加产品与研发的沟通和阶段性确认，加强交付过程管理」
• 测试发现该问题，已按照产品方案进行技术实现，与pm确认后要求按照当前方案实现「测试环节无误，研发环节无误，产品环节失误，需要增加与下属的产品方案评审环节，加强产品方案质量管理」

以上每个环节都可以衍生出一系列可落地的机制。出现事故可以口头批评，可以事后总结，但单点的问题是无法一劳永逸得到解决的。唯有通过机制和共识，才是有效降低事故发生的概率。

项目负责人不单单要解决问题，更要善用机制，做到不让问题再次发生。

一些唠叨

面对超纲

很多时候职场里事故的背景信息都像是漂浮在海面上的冰山，不可见的大多数隐藏在水平面以下。在你缺少情报时，员工层面卡脖子的问题，有可能根本不在管理层的关注范围内。

我猜测认真读我文章的人还是以中层管理者和一线执行层同学为主。在推动很多事的时候还是先明确自己员工的身份。我是个典型内控型人格的选手，认为只要自己努力就可以推动很多事情发生。但是事儿也分你铲得动的和铲不动的，有些事儿铲不动硬推反而会让自己的处境更糟糕，不利于自身的职场发展。（具体的自己意会）

遇见超纲问题，如实同步给你的老大，交给他处理会更合适。

直面情绪

面对计划外的事故，没有情绪是不可能的，有情绪才是人类的真实反应。你可能会沮丧，会愤怒，会失望。但作为项目负责人，处理事故及与之相关的冲突是你的工作，且你不能带着情绪工作。

首先接受已经发生的一切，情绪该发泄发泄，心态该调整调整。总之要让自己处于双商在线的状态再去直面事故。如果仍处于上头状态，我建议啥事都别做。否则大概率进入越做越错，重复犯错的愚蠢境地。

前篇文章中提到过，我们正常驾车行驶，但也无法确保别人不会违反交规。做好自己，希望你可以一直保持“职业”状态。

关于确认自己是否处于上头状态，我曾经做了个梳理，适合我个人。分享给大家，方便自查与自省：

1. 对至亲开始不耐烦
2. 情绪波动大，一会儿开心一会儿低沉
3. 非常高频地说脏话且脏话的目标对象有所指
4. 影响生活计划的完成
5. 出现超出正常范围的额外消费

总结

老话里说“没事不惹事，有事别怕事。”

能做到铲事也只是项目负责人的基本功。能理清事故缘由，头脑冷静地处理，找到事故解决的方案，可以打65分。能推动不让事故再次发生的机制，可以给到85分。所以铲事的能力不值钱，不让事故再次发生的能力才值钱。我从这其中获益良多，希望你也是。

我知道很多人看到这个标题就想学到一些秘籍能应对日常的工作。没错，这是个“有效率”的选择，就像我们都喜欢看干货文章一样。可是真正把计划，执行，信息同步做到位了。好的结果不都是水到渠成的吗。即便出现不可抗力的事故，那也是一份宝贵的经历。相较于事故，我更愿意称之为挑战。

在职场中，我一直主张用结果证明自己，多做事，少做局（不知道为啥好像有人就很热衷这个）有意义的事很多，你的时间很宝贵，学习和成长才是人生中最重要的课题。

「关于成长」做一名合格的项目负责人系列完结，谢谢大家的观看！

作者：Lil_Sun，公众号：maxiwenfine

本文由 @ Lil_Sun 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

,