营出凝聚力
赢得团队心

项目黄了半程才懂:责任分配从来不是把活拆出去那么简单

去年深秋的一个晚上,我盯着客户发过来的第7封投诉邮件,办公室的空调吹得人后颈发僵。

距离项目正式上线还有7天。客户那边说,跨表拉取的订单数据和后台统计的数对不上,差了整整12%。我把项目组所有的人拉到会议室,把需求文档翻得哗啦响,问谁负责这个数据校验的逻辑。

没人说话。

前端的小伙子说,他只负责把页面上的数字渲染出来,逻辑是后端的事。后端的开发说,他只写了取数的接口,校验规则是产品要定的。产品经理摊手,说他当时在文档里写了“数据要准确”,没具体写校验规则,他以为开发会考虑到。测试的小姑娘更委屈,说测试用例里根本没提跨表一致性校验,她怎么测。

就这么个小功能,卡了整整三天,最后整个项目延期一周,被客户扣了三成尾款。

那是我做团队管理快8年的时候,第一次认认真真坐下来想,我之前做的所谓“责任分配”,到底是个什么东西。

我之前对责任分配的误解:把“领了活”当成“担了责”



说实话,之前我开项目分活的会,流程特别简单:把需求列在白板上,大模块拆成几块,谁能做就给谁,说完就散会。我总觉得,只要把大模块的事指到具体人头上,剩下的小细节大家会自动补位——毕竟都是一起共事两三年的老搭档,这点默契总该有吧。

现在想起来都拍大腿。

没有唯一负责人的责任,本质上等于没有责任。

我之前最常说的一句话就是“这个事相关的同事多跟进下”,听上去是动员大家补位,实际上这句话抛出去,就等于把责任扔到了空气里。谁是“相关的人”?跟进到什么程度算完?出了问题找谁?全是糊涂账。

上次复盘的时候我算了下,我们团队之前出的所有线上问题,有接近六成,根源都在这种“糊涂账”上。要么是大家都觉得别人会做,要么是大家都觉得这不是自己的事,等问题爆出来,所有人都有委屈,所有人都没责任。

项目会上围在白板前拆分需求的真实办公场景
项目会上围在白板前拆分需求的真实办公场景


后来我改了规则:所有责任,必须落到“唯一的第一负责人”



那次踩完大坑之后,我把之前的分活规则全推翻了。现在我们拆责任的时候,再也不说“大家配合”“相关同事跟进”这种虚话。哪怕是再小的一个功能点,只要是项目里要交付的内容,必须指定一个唯一的第一负责人。

注意,是唯一的。

我之前试过让两个开发一起负责一个模块,觉得两个人互相搭把手效率高,结果上线的时候出了个验证码失效的bug,两个人都说是对方负责测的,扯了快半小时。现在我们的规则是,哪怕一个模块有三个人一起做,也要明确一个第一负责人——出了问题先找他,他来协调内部的分工,他对最终的交付结果负全责。

有次拆数据模块的需求,我拉着负责这块的小伙子,对着文档一条一条过,过到“跨表数据一致性校验”那一条,我停下来问他:“这条你认吗?认的话我就写你名字,不认我们现在找能认的人,别等上线了扯。”

他当时愣了两秒,说之前以为这是测试的事。我就跟他掰扯:“测试是帮你验功能能不能用的,不是帮你做功能的。你是这个模块的第一负责人,你得确保从开发到上线全链路是通的,你觉得这个事归测试,我们现在就把测试的负责人拉进来一起对,直到两个人都掰扯清楚谁干哪部分,谁对最终结果负责。”

那天我们对着那一条需求,聊了快20分钟,终于把边界划清楚了。后来这个模块上线到现在快一年,没出过一次数据不一致的问题。

需求文档上标注唯一负责人名字的手写批注特写
需求文档上标注唯一负责人名字的手写批注特写


最容易漏的责任空白:那些“没人觉得是自己事”的衔接环节



刚开始改规则的时候,我以为把每个模块的负责人定好就万事大吉了,结果没出俩月,又踩了个新坑。

销售签了个新客户,把合同甩给交付团队就去跑下一个单了。等交付团队进场做需求调研的时候,客户说当时销售承诺了三个免费的定制功能,现在要上线。交付的人翻遍了合同,半字没提,找销售问,销售说“当时就是随口答应下,你们做了不就完了”。一来二去,客户觉得我们不讲信用,闹着要解约。

这事给我提了个醒:模块内部的责任好分,两个岗位衔接的地方,才是最容易出现责任真空的地方。你想啊,产品觉得需求给开发就完事了,开发觉得代码写完给测试就完事了,测试觉得报告交运维就完事了,运维觉得系统上线就完事了——那中间谁来接那个棒?谁来确保上一个环节的信息,完完整整传到下一个环节,没有漏,没有错?

后来我们专门在拆责任的环节,加了个固定动作:所有参与项目的人,对着整个项目的流程节点走一遍,每到两个岗位衔接的地方,就停下来问三个问题:上一个环节的输出是什么?下一个环节谁接?接了之后要在多久内反馈信息对不对?如果信息漏了,谁来追?

就拿销售对接交付这个环节来说,现在我们定的规则是:销售签单之后,必须拉着交付的第一负责人,坐下来把所有跟客户聊过的承诺,不管是合同里写的还是没写的,一条一条过。交付的负责人作为接棒人,要把这些内容全部列到交付启动文档里,签字确认。之后如果有漏的承诺,不管是销售没说,还是交付没记,第一责任人是交付的那个接棒人——因为他是接这个活的,他有责任把所有信息捞干净,而不是等着别人把饭喂到他嘴里。

刚开始大家都嫌麻烦,尤其是跑外的销售,说天天在外面陪客户,哪有空坐下来跟你一条一条对。结果试了三个月,因为衔接问题导致的客户投诉,直接掉了八成。

说实话,刚开始我也怕大家反感,觉得我是在给大家加考核,出了问题要找背锅的。后来有个老开发跟我说,其实这样反而轻松——以前总怕莫名其妙接了不属于自己的活,现在责任划得清清楚楚,不是自己的事可以直接推,不用因为怕得罪人硬扛,也不用因为信息差背锅。

哦对,这点我之前真没想到。

责任从来不是用来惩罚人的。是用来给大家划边界的。你知道自己该扛什么,不该扛什么,不用猜,不用怕,不用在出问题的时候互相扯半天皮。

昨天跟之前的老领导吃饭,他说现在他们团队分活还是老样子,开个会把活一甩,等项目出问题了再坐下来追责。他说“你们年轻人就是事多,搞那么复杂干嘛”。

我没接话。

毕竟谁没为了省那半小时的分活时间,熬几个通宵补过漏子呢。谁没在项目复盘会上,因为一句“我以为是他做的”,跟同事红过脸呢。

责任分配这事,从来不是把活拆出去就完事了。你多花半小时把边界划清楚,把每个节点的负责人定明白,把那些容易漏的衔接环节盯紧,后面能省出来的时间,够你多喝三杯茶,多陪孩子逛两次公园。

对吧。
免责声明:市场有风险,选择需谨慎!此文仅供参考,不作买卖依据。如有侵权请联系删除。
文章名称:项目黄了半程才懂:责任分配从来不是把活拆出去那么简单
文章链接:https://tuanjian1.com/changdi/896.html