3

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

 1 year ago
source link: https://www.cnblogs.com/yexiaochai/p/16490589.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

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

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

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

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

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

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

直面问题,分析成因

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

  • 团队合并

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

  • 大规模裁员

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

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

  • 人心浮动

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

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

  • 双技术栈

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

  • 业务历史债

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

  • 总结

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

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

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

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

由此可以形成一个脑图:

294743-20220718152050665-1092091806.png

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

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

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

294743-20220718152049946-1310559589.png

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

目标是什么:选题

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

  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. 系统性解决问题,竖井效应与内卷;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK