级别越高,越要学会“秋后算账”

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

图片

前言

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

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

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

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

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

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

吃亏永远在后端。

一、

问题出现了,先解决问题,到底对不对?

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

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

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

这是一个什么机制?简单点讲,可以这样理解:

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

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

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

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

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

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

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

有这么两点:

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

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

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

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

二、

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

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

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

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

整个流程,大概是这样的:

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

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

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

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

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

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

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

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

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

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

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

那怎么办?

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

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

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

简单总结,有两点问题:

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

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

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

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

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

后面是怎么解决的?

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

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

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

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

三、

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

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

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

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

为什么?

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

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

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

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

本文由人人都是产品经理作者【鹏鹏的工作日记】,微信公众号:【鹏鹏的工作日记】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。