技术管理进阶——团队一盘散沙,怎么破?

原创不易,求分享、求一键三连

最近有个粉丝问了一道大题

小钗,我最近空降到一个小公司做技术负责人,感觉团队士气很低,同学们要么有力无处使,要么常规摸鱼,这种一盘散沙的团队该如何带呢?

这道题我还真会!只不过这是一道大题,没那么简单,需要大家耐着性子读完,这里先给出解题思路:

  1. 直面问题,分析成因;
  2. 目标确定,合理分解;
  3. 梯队确定,奖善罚恶;
  4. 资源确定,粮草先行;
  5. 机制流程,抹平障碍;

接下来我们现身说法,依次分解。

直面问题,分析成因

顶层梳理

团队为什么会一团散沙,首先要有自己的基本判断,比如我们团队的问题是:

  • 团队合并

去年有一次比较大的团队合并,单就技术团队算是150+120的合并规模,正常情况,这种合并效果都不会太好,加上互联网寒冬,所以导致了第二个问题。

  • 大规模裁员

后疫情时代,降本增效成了很多公司的主题,与多数公司一样,我们进行了大规模的人员优化,半年优化量多达70%!

人员优化倒是完成了,而服务规模却未减少。单后端来说,当前103个服务无人维护;少数核心同学维护服务又超过70个,风险很大,却又无可奈何。

  • 人心浮动

几轮人员优化下来,剩下的同学不免人心惶惶,而这个时期负责人也难以打包票不会再发生,而且正常情况这时候应该有一波团队激励,但这次情况特殊,整个公司都锁死了,于是粮草也不足...

人的问题盘点完,还要盘点事的问题。

  • 双技术栈

团队合并导致的最大问题是两套技术体系,特别是后端完全是两个技术栈:Golang、Java,在后端整体人数受限的情况下,很难重用,直接导致战斗力减半!

  • 业务历史债

至此常见的业务历史债就不多赘述了,每个团队都有,就看严重程度了。

  • 总结

所以,双技术栈加上几波裁员情况下,30%团队要维护原来100%的业务,还没加薪,这个团队士气不低就奇怪了!

自己有了初步判断后,还得收集一线同学的想法。

基层视角

收集一线信息的方法比较简单,发一个调查问卷,再找几个关键人聊天即可:

  1. 你觉得当前团队最大的问题是什么;
  2. 你觉得产生这些问题的原因是什么;
  3. 你觉得该如何处理;

由此可以形成一个脑图:

技术管理进阶——团队一盘散沙,怎么破?

可以看到,一线同学看到的点跟我们的认知还是统一的:

  1. 历史债重;
  2. 激励不足;
  3. 氛围不好;
  4. 业务拉胯;
  5. 目标不清晰;
  6. ...

貌似这个比我们两年前遇到的问题更糟糕了:

技术管理进阶——团队一盘散沙,怎么破?

比较有意思的是,其中一些问题之前已经解决,但是过一段时间后又回来了,所以这个过程总是循环往复啊,那么如何解决呢?

目标是什么:选题

这里的选题,就是把自己的疑惑,将业务中碰到的问题,整理成一些课题,将这些课题指派给团队的“专家组”进行研讨,找到答案形成方案,选题的重点有二:

  1. 找准问题;
  2. 问题切割;

工作中问题很多,不能眉毛胡子一把抓,要发现主要矛盾是什么,要有优先级,所以一定要找准要解决的问题,集中资源解决;找准问题后要做问题切割,问题大了资源不足做不了,问题小了没有效果。

思考选题时要卷入足够的资源、足够的意见,但不要被轻易带偏,要有自己的坚持,自己的主见,选题能力就是战略能力。

所以,现在有那么多问题,我们要先解决什么,后解决什么,光说不练假把式,一起来实操下吧!

  • 粮草问题

俗话说得好,兵草未动,粮草先行,如果人心不稳,就算有明确的目标也没人想做,所以第一步是稳住人,众所周知,稳住人最好的办法是给他钱或者帮他成长能赚更多钱。

前面说了,今年情况特殊,想要加钱是比较难的,但比较难并非不能实现,只不过这种时候要站在公司角度思考问题:

  1. 我为什么要给你钱;
  2. 我应该给谁钱;
  3. 怎么证明这笔钱花得值;

公司事实上也不是一毛不拔的,毕竟还要维持运营,但公司需要识别谁是团队可用之才,并且需要证据链,这种时候由于屁股问题,不能听负责人的一面之词了,所以我们需要准备证据链,做两个事:

  1. 识别团队人才;
  2. 证明人才的ROI;

如何做呢,有一个简单的解法是,证明人才同等时间做的事情更多更好就行了,而高级程序员的效率相较初级程序员确实会高不少。

所以,我们这里第一个要实现的目标是:找出团队不可或缺的20%,并证明他们优秀,想办法说服公司给予激励

第二个目标是帮他成长,那么对应的梯队建设,上升通道以及人才运营机制需要重新设计并维护起来。

  • 目标问题

粮草只能暂时解决人才焦虑问题,远大的目标才能让所有人走得更远,关于目标问题有几个点要注意:

  1. 技术团队难以影响业务团队目标,所以不要妄图技术驱动业务
  2. 现阶段技术基建资源会很有限,所以不可能有太多资源投入技术基建
  3. 新的目标要可达成、有成就感、并且技术说了可以算;

总而言之,要让技术有尊严,最好能解决安全感问题,那么这只有一条路可以走:创造营收,甚至自己养活一部分自己!

如何做呢,这里有个“比较摆烂”的策略:

  1. 开展外包业务;
  2. 开展技术培训业务;

也不要看到外包就难受,如果跟业务方撕逼的时候真的将自己当外包团队,很多问题可以迎刃而解:别跟我扯犊子,什么排期我都行,只不过得加钱!并且,外公司都是这么给钱的!

这里有几个点:

  1. 搞定老板,让他同意;
  2. 真要外包,最多解决团队10%的人力成本就行,有个证明就行,不用占比太多;
  3. 搞培训的话,优先抓大学生,有好的苗子可以留下培养;

事实上把自己当外包团队是个很妙的想法,团队内部的关注点都会逐渐转移至:如何养活自己;团队外部对于一些不认可的业务方,便可以堂而皇之的降低其需求优先级了。

具体效果,等我试过后跟大家聊,这里有个一定要注意的点:不要把主业务搞崩了,注意尺度。

综上,这里可以给团队设定第三个目标:技术团队承担人力成本的10%!,具体赚的钱可以跟公司分账,具体怎么分要聊。

但是为了保证生存,依旧要有保证核心业务的目标,不然就真做成外包团队了...

  • 成长问题

前面提了一下成长问题,但公司级的上升通道建设,职级体系还是得有,如果公司这块不成熟,需要推动建设。

为什么职级体系很重要呢,因为升职一般伴随着加薪,所有人都看着的呢,需要规定做了什么工作可以获得什么成就。其实只要职级体系做得好,可以解决很大的问题。

团队需要做的是将培训和分享做起来,特别是针对Leader层的干训班,具体怎么做后面有介绍。

综上,第四、五个目标是将团队的职级体系搭起来,其次要把内部培训分享搞起来

  • 环境问题

解决了主观能动性和目标问题,接下来就要解决环境问题,要去实地考察当前环境中什么流程是多余的,什么是割裂的,多的流程要去掉,没有的流程要补,所以第六个目标是:核心机制流程补足

  • 总结

最后总结一下,为了解决我们的问题,我们提出了以下目标:

  1. 找出团队不可或缺的20%,并证明他们优秀,想办法说服公司给予激励;
  2. 梯队建设(职级体系+分享培训体系);
  3. 技术团队承担人力成本的10%;
  4. 核心机制流程补足;

接下来依次说说每个目标的实现思路。

人才识别

第一步依旧是要想办法要钱,这里第一个问题就是如何证明我优秀,这里的实操思路是:统计每个人每周/月完成了多少任务,步骤是:

  1. 周会、项目日会等会上提出待完成的任务;
  2. 将任务分给不同的人;
  3. 任务完成后,进行简单任务定级,存档;

任务一般是一周以内的工作,任务过大应该被设置为OKR,然后在OKR的基础下再分解任务,所以一个周期结束,可以看到所有人完成的任务以及完成了什么样的任务。

理想的情况下还可以对任务定价,那么一个人一个月赚了多少钱可以计算出来,最后任务赚来的钱/员工工资,ROI就出来了...

当你拿到所有人的所有任务,并可以细化到每个人的ROI去找老板聊天的时候,相信我,他首先会给你钱,其次会让你把这套工具复用到整个公司。

衍生一下,如果以任务为单位的形式运行的好的话,是可以算出业务方的需求价值的,如果业务方的需求没有外包的需求价值高,还可以反向PUA。

萦绕很久的效能度量问题,结果被市场经济运作下的外包模式解决了,我真的是醉了!

梯队建设

这里的梯队建设核心围绕着上升通道(职级体系)与分享培训体系展开。

上升通道首先必须拉着HR玩,让他定义清楚当前部门的职级,并且每年什么时候达成什么条件可以升级,升级后的匹配奖励是是什么,没有这个东西,大家都只能抓瞎!

关于团队成长还是首推三件事:

  1. CaseStudy;
  2. 干训班培训;
  3. 技术分享;

其中技术分享不多说,说下CS与干训班:

  • CaseStudy

针对平时工作中爆发的工程或组织问题,需要责任人写CS(CaseStudy)文档,每周二下午,相关人一起做复盘的机制,旨在杜绝类似问题产生。

关于如何做CaseStudy的文章,之前复盘时候介绍了,这里不展开。

  • 干训班

一路打怪(做项目、OKR)升级,如果”运气好“成为小leader,那么就进入了干训班辐射范围,干训班事实上更多是面向经理的”福利“,帮助经理建立管理认知的培训实践课程,比如就会涉及以下信息:

  1. 向上管理怎么做,如何拿到资源;
  2. 跨部门沟通的诀窍,我为什么要配合你;
  3. 从理论到实战的差距是什么;
  4. 如何用数据说话;
  5. 系统性解决问题,竖井效应与内卷;
  6. ...

这些培训一般由几种元素构成(不是每个案例都会完整覆盖):

事件案例 -> 案例分析 -> 观点阐述 -> 理论、机制形成 -> 讨论(辩论)

如果案例本身比较经典,再进一步会考虑:

要不要纳入团队机制 -> HowTo -> OKR -> 执行人 -> 形成团队案例 -> ......

每个公司案例不尽相同,大家不可完全套用。

营收思路

技术话语权弱,也是一个长时间萦绕心间的问题,其实想要话语权只需要做两件事:

  1. 带来营收;
  2. 证明自己跟营收有绝对联系;

之前我的想法是自己跨出圈子去做业务方,这样就能带来营收了,但是转念一想,这个其实只能证明我能带来营收,并不能证明技术团队能带来营收;而强行跟业务方拉关系,分他们的营收蛋糕,无异于低人一等,都不是好的解决方案。

但是,如果将自己作为外包团队,在市场经济下,似乎情况又有所变化,我们只需要说服老板:我们可以自己养活自己

接下来的操作就是,所有的业务方跟技术团队提需求,我们先说好一个需求多少钱,你如果不满意可以真的去找外包,这么一来的话,技术团队其实是处于公司的外包团队,我们可以选择不接有些需求:对不起,你那个需求太烂了,钱也少,我们不做,你去找外包吧

所以,我们是用自身的技术能力赚取服务费用,我们自己养活了自己,当然,不可避免可能会谈崩几次,导致赚钱的费用不足以覆盖所有技术的人力成本,这个时候就只有两个方案:

  1. 裁员;
  2. 接外包;

站起来肯定要付出一些代价,但越做越小肯定不是我们的初衷,所以真实的方案只有接外包一途,这里要注意:接外包不可太过

外包带来的营收不要超过团队的10%,或者能够保证不裁员就好,不要接太多,因为多少还是有点不务正业的,尝到甜头乐此不疲可能真的演变成外包团队,那不会是团队想要的。

至于如何接到外包,这个是个商务问题,大家自己去思考吧。

流程机制

大目标定了,如何让目标执行的更顺畅,这就需要流程机制的匹配了,比如:业务团队如何采买服务能力,如何定价,财务如何结算等等都需要有一套完整的流程,并且需要系统化!

也就是我们需要一套内部管理工具来匹配这些目标,我这里的思路是:实现了一套以任务为核心的OKR系统,具体系统如何,使用过后再拿出来分享吧。

结语

最后回到问题本身,如果当前团队一团散沙,首先要思考钱的问题,没钱的激励人们很难有启动的动力;

团队初步启动后要思考目标的问题,找准当前问题的核心,和当前环境最适合解决什么;

目标落定后要解决环境问题,匹配对应的流程机制,让目标更容易发生,具体到目标实现的时候,一定要注意目标切割,先打造小案例,实现小目标,激励大家的信心,一步一步,后续就会顺畅很多。

好了,今天的分享就到这。如果本文对你有帮助的话,欢迎点赞&评论&在看&分享,这对我非常重要,感谢🙏🏻。

想要更多交流可以加我微信

发表评论

相关文章