在职场中，我们经常会遇到紧急情况，需要立即处理问题而暂时搁置责任归属的讨论。然而，这种处理方式可能会导致问题重复发生，对个人和组织都造成伤害。"秋后算账"这一机制的建立，就是为了确保在紧急情况处理完毕后，能够回过头来审视问题，找出根源，并制定改进措施。本文将探讨如何建立有效的"秋后算账"机制，以及它对于提高工作效率和组织发展的重要性。

前言

不知你是否遇到过这种情况：

“先别分是谁的责任了，客户那边很着急，我们先处理问题吧。”

“这件事情确实是我这边有些问题，但我们业务还得往下，你想想办法吧。”

然后，你被说的哑口无言，不得不开始处理了起来。

不处理吧，那就是导向不对，会被扣上帽子；

处理了，那就是在妥协和让步，下次还会有类似的事情。

吃亏永远在后端。

一、

问题出现了，先解决问题，到底对不对？

处理紧急事情，解决当前问题，肯定是对的。

那明明是对的，为什么接到这件事情时，会这么别扭，会这么难受呢？

因为缺少了“秋后算账”的机制。

这是一个什么机制？简单点讲，可以这样理解：

“事情紧急，那我先处理了，把客户那边安抚好了，我再回头找你算帐。”

我们工作里，往往少了这个算帐的环节。

无非有两点原因，导致我们没有去“算帐”：

事情已经处理完，碍于面子，也不想上纲上线再去提。

觉得自己提了，好像也不能改变什么，想想也就算了。

于是，边一路忍着忍着，把不爽和郁闷都憋到了自己心里。

不要觉得这件事情，只是自己受委屈了，它对整个组织都是一种伤害。那这样会组织造成什么不好的风气和影响？

有这么两点：

第一点，以后只需要拿着“客户优先”的尚方宝剑，就可以推进任何事情。

第二点，这类事情对前端人员没进行惩罚，未能形成约束。在他们的认知里，这件事情是没有成本的，未来还是会继续这样干。

慢慢地，只要出现了问题，那就找人擦屁股，只要嘴上说这是客户紧急，那就会有人解决，也不需要考虑成本。

这不仅对个人、对组织而言也是莫大的伤害。

二、

怎么建立“秋后算账”的机制？

这个机制，很像复盘，但又不全是复盘。

复盘，有些时候，我们会更喜欢让大家围绕着自己去找问题，进行改进；

算帐，更多是，发起方觉得对方有哪些问题，希望进行改进。

整个流程，大概是这样的：

第一步，把整个事件进行记录，什么背景下、什么时间点、哪个客户/事件、需要我做什么事情、每个步骤是怎么做的，以陈述的方式记录下来。

第二步，在记录的事件里，找到问题所在，是哪个环节出错了，导致需要自己做出妥协的。

第三步，定改进举措，怎么减少未来再发生这类的情况。

第四步，召开会议，多部门、多团队之间握手签字，对问题和改进举措要认可。

看起来，是不是很简单？但是还是有蛮多细节的。

展开一个最近发生的例子，背景是这样的：

在公司里软件开发要走敏捷流程，即用户需求是产品经理写完，接着到设计师画交互稿，然后到开发组长写系统需求，最后开发同事开始做设计、写代码。

每个下游成员会有一周时间间隔，即产品经理写完需求，设计师有一周时间出设计稿。如果运转健康，会滚轮式滑动，需求轮转了起来。

但最近的一个迭代，用户需求延期了一周，交互稿延期了两周，但发布时间却没有更改。

原因是，这个迭代对市场很重要，已经承诺了发布时间，不能更改。

那为什么需求、设计稿要延期呢？产品经理给的理由是，这个迭代比较复杂，需要考虑的比较多，所以花的时间超出预期了。

那怎么办？

最终，就是逼着开发工程师们加班加点去把功能实现了。

过程中，因为交互稿没出来，导致有些需求白做了，在相互推诿。

产品经理说，我已经和设计师说了要改，结果没改，这不是我想要的。

简单总结，有两点问题：

需求延期，但承诺市场的时间没有调整。

需求敲定，但多方没有确认，导致出现了改动遗漏。

作为研发工程师，就很无奈了，也是两点：

留给研发的时间更少了，不确定性强，倒逼着走。

需求没定好，导致返工，浪费资源。

后面是怎么解决的？

针对这件事情，研发走了一次“秋后算账”的流程，把现状做了一遍陈述，然后加了一些具体改进的措施，像设计稿要进行定稿，需要三方会签。

产品经理对界面布局、设计进行确认，确保是自己想要的样子，研发工程师对技术进行确认，确保是效果是可以达成的。

过程中，如果觉得界面价值传递有问题，那产品经理要出来扛主责，如果是研发承诺了，但实现不了，那研发要扛主责。

后来，相关会议纪要也有人去关注和回复，这类事情基本上就没发生了。

三、

为什么“秋后算账”机制很重要？

前面已经有初步提过，紧急事情处理更多聚焦当下，而秋后算账更多聚焦未来。

如果未来的事件不能减少，那过一段时间，未来就会变成当下，将有永远处理不完的问题。

并且，你的职级越高，这个机制越是重要。

为什么？

因为，职级高意味着你的业务范围会更广，

过去做软件开发，你可能只是负责写好代码，看护好这个模块的代码质量，

而当你负责整个产品的研发时，你会发现产品里的代码组成会来自多个部门，业务要成功，你除了做好产品研发，还要关注销售、市场。

如果不能建立起机制，就会发现，整个大盘里，你能掌控的事情很少，你很难去带动业务成功。