做一名合格的项目负责人（四）：如何做好事故处理工作？

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

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

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

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

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

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

事故处理

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

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

既然已经发生，那么预期内的情况是什么？

既然如此，损失是什么？

以开篇的事故为例：

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

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

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

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

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

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

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

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

既然已经发生，那么预期内的情况是什么？「项目稳步推进，按计划可完成」

既然如此，损失是什么「团队信心与士气，因为时间过去了一半，有可能剩余时间不够」

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

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

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

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

冲突处理

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

照例以开篇故事为例：

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

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

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

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

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

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