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

在事故发生之前，尽量采取避免措施，但一旦事故还是发生，要有智慧地运用方法解决事故，并且能够采取对策避免让类似问题再次发生。事故处理事故，指发生于预期之外的，已经造成损失的事件。阶段性目标是处理事故，达成原定目标，任何与拯救当前结果弱相关的事暂不考虑。出现事故时，项目负责人是需要第一时间站出来的。唯有通过机制和共识，才是有效降低事故发生的概率。

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

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

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

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

事故处理

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

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

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

以开篇的事故为例：

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

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

啥？时间过去一半了，现在说完不成？你这不是坑我吗？
你这个人太不靠谱了，你当时怎么估的
完不成等于连交付都没做到，一定会影响自己的绩效考核，还有晋升
我要找你老大说说和个事去

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

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

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

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

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

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

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

冲突处理

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

照例以开篇故事为例：

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

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

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

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

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

这些专业知识，分散在员工个人脑中，既包括用户的、市场的、行业的、政策的知识，也包括企业内部运行机制的、文化价值观的、以及企业内其他人的工作内容和个人能力风格偏好等属性。这些专业知识，就是企业的核心竞争力来源。
员工在个人岗位的工作中持续获得和积累的知识，起初都是个人专有的知识，但如果通过语言文字转换为显性知识，就可以被传播，成为企业的共同知识。

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

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

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

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

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

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

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

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

避免事故再次发生

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

以开篇故事为例：

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

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

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

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

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

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

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

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