小钗,我最近空降到一个小公司做技术负责人,感觉团队士气很低,同学们要么有力无处使,要么常规摸鱼,这种一盘散沙的团队该如何带呢?
这道题我还真会!只不过这是一道大题,没那么简单,需要大家耐着性子读完,这里先给出解题思路:
直面问题,分析成因;
目标确定,合理分解;
梯队确定,奖善罚恶;
资源确定,粮草先行;
机制流程,抹平障碍。
接下来我们现身说法,依次分解。
一、直面问题,分析成因
1、顶层梳理
团队为什么会一团散沙,首先要有自己的基本判断,比如我们团队的问题是:
1)团队合并
去年有一次比较大的团队合并,单就技术团队算是150+120的合并规模,正常情况,这种合并效果都不会太好,加上互联网寒冬,所以导致了第二个问题。
2)大规模裁员
后疫情时代,降本增效成了很多公司的主题,与多数公司一样,我们进行了大规模的人员优化,半年优化量多达70%!
人员优化倒是完成了,而服务规模却未减少。单后端来说,当前103个服务无人维护;少数核心同学维护服务又超过70个,风险很大,却又无可奈何。
3)人心浮动
几轮人员优化下来,剩下的同学不免人心惶惶,而这个时期负责人也难以打包票不会再发生,而且正常情况这时候应该有一波团队激励,但这次情况特殊,整个公司都锁死了,于是粮草也不足……
人的问题盘点完,还要盘点事的问题。
4)双技术栈
团队合并导致的最大问题是两套技术体系,特别是后端完全是两个技术栈:Golang、Java,在后端整体人数受限的情况下,很难重用,直接导致战斗力减半!
5)业务历史债
至此常见的业务历史债就不多赘述了,每个团队都有,就看严重程度了。
6)总结
所以,双技术栈加上几波裁员情况下,30%团队要维护原来100%的业务,还没加薪,这个团队士气不低就奇怪了!
自己有了初步判断后,还得收集一线同学的想法。
2、基层视角
收集一线信息的方法比较简单,发一个调查问卷,再找几个关键人聊天即可:
你觉得当前团队最大的问题是什么;
你觉得产生这些问题的原因是什么;
你觉得该如何处理;
由此可以形成一个脑图:
可以看到,一线同学看到的点跟我们的认知还是统一的:
历史债重;
激励不足;
氛围不好;
业务拉胯;
目标不清晰;
...
貌似这个比我们两年前遇到的问题更糟糕了:
比较有意思的是,其中一些问题之前已经解决,但是过一段时间后又回来了,所以这个过程总是循环往复啊,那么如何解决呢?
二、目标是什么:选题
这里的选题,就是把自己的疑惑,将业务中碰到的问题,整理成一些课题,将这些课题指派给团队的“专家组”进行研讨,找到答案形成方案,选题的重点有二:
找准问题;
问题切割;
工作中问题很多,不能眉毛胡子一把抓,要发现主要矛盾是什么,要有优先级,所以一定要找准要解决的问题,集中资源解决;找准问题后要做问题切割,问题大了资源不足做不了,问题小了没有效果。
思考选题时要卷入足够的资源、足够的意见,但不要被轻易带偏,要有自己的坚持,自己的主见,选题能力就是战略能力。
所以,现在有那么多问题,我们要先解决什么,后解决什么,光说不练假把式,一起来实操下吧!
1、粮草问题
俗话说得好,兵草未动,粮草先行,如果人心不稳,就算有明确的目标也没人想做,所以第一步是稳住人,众所周知,稳住人最好的办法是给他钱或者帮他成长能赚更多钱。
前面说了,今年情况特殊,想要加钱是比较难的,但比较难并非不能实现,只不过这种时候要站在公司角度思考问题:
我为什么要给你钱;
我应该给谁钱;
怎么证明这笔钱花得值;
公司事实上也不是一毛不拔的,毕竟还要维持运营,但公司需要识别谁是团队可用之才,并且需要证据链,这种时候由于屁股问题,不能听负责人的一面之词了,所以我们需要准备证据链,做两个事:
识别团队人才;
证明人才的ROI;
如何做呢,有一个简单的解法是,证明人才同等时间做的事情更多更好就行了,而高级程序员的效率相较初级程序员确实会高不少。
所以,我们这里第一个要实现的目标是:找出团队不可或缺的20%,并证明他们优秀,想办法说服公司给予激励。
第二个目标是帮他成长,那么对应的梯队建设,上升通道以及人才运营机制需要重新设计并维护起来。
2、目标问题
粮草只能暂时解决人才焦虑问题,远大的目标才能让所有人走得更远,关于目标问题有几个点要注意:
技术团队难以影响业务团队目标,所以不要妄图技术驱动业务;
现阶段技术基建资源会很有限,所以不可能有太多资源投入技术基建;
新的目标要可达成、有成就感、并且技术说了可以算;
总而言之,要让技术有尊严,最好能解决安全感问题,那么这只有一条路可以走:创造营收,甚至自己养活一部分自己!
如何做呢,这里有个“比较摆烂”的策略:
开展外包业务;
开展技术培训业务;
也不要看到外包就难受,如果跟业务方撕逼的时候真的将自己当外包团队,很多问题可以迎刃而解:别跟我扯犊子,什么排期我都行,只不过得加钱!并且,外公司都是这么给钱的!
这里有几个点:
搞定老板,让他同意;
真要外包,最多解决团队10%的人力成本就行,有个证明就行,不用占比太多;
搞培训的话,优先抓大学生,有好的苗子可以留下培养;
事实上把自己当外包团队是个很妙的想法,团队内部的关注点都会逐渐转移至:如何养活自己;团队外部对于一些不认可的业务方,便可以堂而皇之的降低其需求优先级了。
具体效果,等我试过后跟大家聊,这里有个一定要注意的点:不要把主业务搞崩了,注意尺度。
综上,这里可以给团队设定第三个目标:技术团队承担人力成本的10%!,具体赚的钱可以跟公司分账,具体怎么分要聊。
但是为了保证生存,依旧要有保证核心业务的目标,不然就真做成外包团队了...
3、成长问题
前面提了一下成长问题,但公司级的上升通道建设,职级体系还是得有,如果公司这块不成熟,需要推动建设。
为什么职级体系很重要呢,因为升职一般伴随着加薪,所有人都看着的呢,需要规定做了什么工作可以获得什么成就。其实只要职级体系做得好,可以解决很大的问题。
团队需要做的是将培训和分享做起来,特别是针对Leader层的干训班,具体怎么做后面有介绍。
综上,第四、五个目标是将团队的职级体系搭起来,其次要把内部培训分享搞起来。
4、环境问题
解决了主观能动性和目标问题,接下来就要解决环境问题,要去实地考察当前环境中什么流程是多余的,什么是割裂的,多的流程要去掉,没有的流程要补,所以第六个目标是:核心机制流程补足。
5、总结
最后总结一下,为了解决我们的问题,我们提出了以下目标:
找出团队不可或缺的20%,并证明他们优秀,想办法说服公司给予激励;
梯队建设(职级体系+分享培训体系);
技术团队承担人力成本的10%;
核心机制流程补足;
接下来依次说说每个目标的实现思路。
三、人才识别
第一步依旧是要想办法要钱,这里第一个问题就是如何证明我优秀,这里的实操思路是:统计每个人每周/月完成了多少任务,步骤是:
周会、项目日会等会上提出待完成的任务;
将任务分给不同的人;
任务完成后,进行简单任务定级,存档;
任务一般是一周以内的工作,任务过大应该被设置为OKR,然后在OKR的基础下再分解任务,所以一个周期结束,可以看到所有人完成的任务以及完成了什么样的任务。
理想的情况下还可以对任务定价,那么一个人一个月赚了多少钱可以计算出来,最后任务赚来的钱/员工工资,ROI就出来了...
当你拿到所有人的所有任务,并可以细化到每个人的ROI去找老板聊天的时候,相信我,他首先会给你钱,其次会让你把这套工具复用到整个公司。
衍生一下,如果以任务为单位的形式运行的好的话,是可以算出业务方的需求价值的,如果业务方的需求没有外包的需求价值高,还可以反向PUA。
萦绕很久的效能度量问题,结果被市场经济运作下的外包模式解决了,我真的是醉了!
四、梯队建设
这里的梯队建设核心围绕着上升通道(职级体系)与分享培训体系展开。
上升通道首先必须拉着HR玩,让他定义清楚当前部门的职级,并且每年什么时候达成什么条件可以升级,升级后的匹配奖励是是什么,没有这个东西,大家都只能抓瞎!
关于团队成长还是首推三件事:
CaseStudy;
干训班培训;
技术分享;
其中技术分享不多说,说下CS与干训班:
1、CaseStudy
针对平时工作中爆发的工程或组织问题,需要责任人写CS(CaseStudy)文档,每周二下午,相关人一起做复盘的机制,旨在杜绝类似问题产生。
关于如何做CaseStudy的文章,之前复盘时候介绍了,这里不展开。
2、干训班
一路打怪(做项目、OKR)升级,如果”运气好“成为小leader,那么就进入了干训班辐射范围,干训班事实上更多是面向经理的”福利“,帮助经理建立管理认知的培训实践课程,比如就会涉及以下信息:
向上管理怎么做,如何拿到资源;
跨部门沟通的诀窍,我为什么要配合你;
从理论到实战的差距是什么;
如何用数据说话;
系统性解决问题,竖井效应与内卷;
...
这些培训一般由几种元素构成(不是每个案例都会完整覆盖):
事件案例 -> 案例分析 -> 观点阐述 -> 理论、机制形成 -> 讨论(辩论)
如果案例本身比较经典,再进一步会考虑:
要不要纳入团队机制 -> HowTo -> OKR -> 执行人 -> 形成团队案例 -> ......
每个公司案例不尽相同,大家不可完全套用。
五、营收思路
技术话语权弱,也是一个长时间萦绕心间的问题,其实想要话语权只需要做两件事:
带来营收;
证明自己跟营收有绝对联系;
之前我的想法是自己跨出圈子去做业务方,这样就能带来营收了,但是转念一想,这个其实只能证明我能带来营收,并不能证明技术团队能带来营收;而强行跟业务方拉关系,分他们的营收蛋糕,无异于低人一等,都不是好的解决方案。
但是,如果将自己作为外包团队,在市场经济下,似乎情况又有所变化,我们只需要说服老板:我们可以自己养活自己。
接下来的操作就是,所有的业务方跟技术团队提需求,我们先说好一个需求多少钱,你如果不满意可以真的去找外包,这么一来的话,技术团队其实是处于公司的外包团队,我们可以选择不接有些需求:对不起,你那个需求太烂了,钱也少,我们不做,你去找外包吧。
所以,我们是用自身的技术能力赚取服务费用,我们自己养活了自己,当然,不可避免可能会谈崩几次,导致赚钱的费用不足以覆盖所有技术的人力成本,这个时候就只有两个方案:
裁员;
接外包;
站起来肯定要付出一些代价,但越做越小肯定不是我们的初衷,所以真实的方案只有接外包一途,这里要注意:接外包不可太过。
外包带来的营收不要超过团队的10%,或者能够保证不裁员就好,不要接太多,因为多少还是有点不务正业的,尝到甜头乐此不疲可能真的演变成外包团队,那不会是团队想要的。
至于如何接到外包,这个是个商务问题,大家自己去思考吧。
六、流程机制
大目标定了,如何让目标执行的更顺畅,这就需要流程机制的匹配了,比如:业务团队如何采买服务能力,如何定价,财务如何结算等等都需要有一套完整的流程,并且需要系统化!
也就是我们需要一套内部管理工具来匹配这些目标,我这里的思路是:实现了一套以任务为核心的OKR系统,具体系统如何,使用过后再拿出来分享吧。
结语
最后回到问题本身,如果当前团队一团散沙,首先要思考钱的问题,没钱的激励人们很难有启动的动力;
团队初步启动后要思考目标的问题,找准当前问题的核心,和当前环境最适合解决什么;
目标落定后要解决环境问题,匹配对应的流程机制,让目标更容易发生,具体到目标实现的时候,一定要注意目标切割,先打造小案例,实现小目标,激励大家的信心,一步一步,后续就会顺畅很多。
如果字段的最大可能长度超过255字节,那么长度值可能…
只能说作者太用心了,优秀
感谢详解
一般干个7-8年(即30岁左右),能做到年入40w-50w;有…
230721