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