互联网发展到今天已经有些年头了，特别是大公司的技术体系建设十分完备，甚至达到了润物细无声的地步，这也导致了很多同学背靠体系，认为很多事情是“理所当然”的，但出来到中小型公司后却发现一片狼藉很难适应，但就我这几年的工作经历，一篇狼藉可能才是常态......

所以，中小型公司去大公司捞人，多半是想让他们协助建设相对完善的技术体系，而多数人是没有能力推动体系化建设的，更多是骂两句傻逼，最后悻悻离开，而导致这个问题的根本原因是什么呢？

根本原因如前文所述是基建与业务投入比例问题，中小型公司只能在技术基建投入合适的份额，这个份额多半就是一个CTO加几个架构师的钱，再多就要失衡。

所以无论从资源投入还是时间窗口，中小型公司的技术建设只能以小步快跑，局部翻新的策略进行，其中要讲究时间点要拿捏火候，想要一口吃个胖子的人多半活不下去。

之前我们说了技术基建的投入应该在20%以内，今天来讨论如何做技术基建规划。

规划技术发展方向绝对不是无脑造轮子，更不是虚无缥缈的事情，要讲究一个标准、两个原则：

决策上强调投入产出比之外，还须强调战损意识。战损即个人、团队的时间精力消耗是不可回收的消耗，比如团队花一周时间完成了一个项目，这个项目上线之后发挥了预期作用，即合理战损；

如果项目没有发挥预期作用，甚至没上线或者上线失败，即无理战损。要强调 100%资源投入 = 100%合理战损 + 0%不合理理战损。

然后是两个原则：

原则一是基础，原则二是指导方向，因为多数时候效率和质量是互斥的，所以当两者间有冲突时，要看当前团队的主要痛点是效率问题还是质量问题，总的来说：

举个例子，团队之初，都是小项目开发，不会有什么效率问题，稍微关注下质量即可，但随着时间推移，小项目变成大项目；多个大项目串联成项目矩阵，于是错综复杂的系统就出现了。

以文中粉丝案例来说，他接手的是一个“老旧”技术团队，面对的是年代久远的系统，就会出现一个现象：团队中个体素质都很高，随便拉出去开发一套新项目都是一把好手，但在体系内就是效率低、质量差。

这就是典型环境拖累个人的情况，个人虽然能力不错，但还不足以解决环境问题，这里需要影响力更大，资源更多的一号位做系统性治理，这个系统性治理，就是我们所谓的技术发展方向规划。这样说太虚，下面举个例子。

两年前刚接手团队时候情况与粉丝案例类似，这个时候可以不用急着做技术规划，因为大家都没信心，当时技术团队最迫切的问题是一个系统老是出BUG：

工作台是医生经纪人的重要工作工具，从上线以来BUG不断：

该系统小规模优化10多次；大型优化2次，结果依旧不理想。

面对业务方不停的谩骂，相关技术人员锅多不压身早已躺平，破罐子破摔，这种情况下什么技术规划都没用，直接成立项目组让技术能力过硬的小孙任Leader开始诊断，三大问题逐渐浮出水面：

1）组织建设问题

2）质效问题

3）工程问题

看似一个独立项目的问题，其实是整个技术体系的问题，技术系统就很容易引起蝴蝶效应，面对如此问题该怎么做呢，答案是一规划二甩锅三拿资源：

技术Leader首先需要快速诊断团队问题，并提供基本解题思路以及人员部署，这是其一；

而后技术Leader可以以新人之姿，大骂技术垃圾，将所有的锅尽量往前任头上丢，赢得业务方部分谅解，并承诺两个月调整周期，为团队取得时间窗口；

最后技术Leader需要向老板要一些额外预算，用以成功后激励众人，提升团队信心，老板不给可以立军令状，因为第一个问题不能解决，那就可以提前滚蛋了。

技术有部署，时间有窗口，事后有激励，一个小而美的成功案例就形成了，小团队有信心了，自然就会影响大团队，这个时候便可以进行第二轮设计了。

如果仅仅是在各种小战役上玩策略，那么整体实力永远不可能提高，所以小案例成功后大家士气正高，就应该趁热打铁扩大战果追求系统性升级。

既然是系统性解决方案，就要有系统性的过程，这里我的思维与前B站Leader基本一致：

mission -> SWOT -> 目标 -> Context -> Structure -> tradeoff(ROI) -> 定赏罚标准 -> HowTo -> BestPractice -> 结果验收 -> 复盘反思

具体实操方面依旧是先做大量有用信息输入，形成此图：

再做系统性分析，找出当前的核心问题：

最终，从人事物方面可以做的事情也就出来了：

再进一步就是对四个大方向设立四个S级的OKR，确定技术选题再挑选负责人不断推动执行即可，下面再举个复杂点的例子。

在某种情况会出现公司合并的场景，公司合并会带来技术体系的合并，这可能导致很大的难题：

真可谓是神仙打架啊！好在合并后人员还算充裕，可以各自安好，但去年行业不景气，技术侧也不好过，结果就是100人不到的团队要维护这个体系，而且还有进一步萎缩的风险，我真的是佛了！

不考虑业务熟悉度、团队稳定性，单这个技术体系就很令人头疼了...

技术人员减少了，而服务规模未减少，在人员急剧减少的情况下需要从工程建设、团队管理、服务资源、需求控制等四方面进行降本增效的规划且同时还要稳固团队来保障业务稳定增长，所以怎么做呢？

团队合并、多技术栈、历史悠久，加上人员一大波流失，所有负面条件都占齐了，什么都想要注定什么都失败，所以可以得到第一个结论：

翻新老楼显然不可能

好消息是，合并回来的业务产品也走的差不多了，所以暂时做保守维护即可，新业务全部使用未来规划技术体系。所以这里的整体思路是：

维持老系统，重开新局

具体几个大决策是：

之所有做这些决策是因为资源确实有限，另外老业务年久失修，熟悉的人也不在了，没有更好的办法，就当不破不立，先破后立吧！

光是你想还不行，至少还得说服老板与产品！

这其实是一次向上汇报，可以用这个汇报结构：

比如说明问题严重性，不要光说现在有多少服务，每个人维护了多少个服务，做张表出来，技术栈问题也是：

问题清晰了，后续工作会更好继续。但由于专业性，最终他们的关注点会留到概览的项目列表，所以你需要清楚告诉他们：

具体到每个项目怎么做，他们听不懂也不会感兴趣了......

统一云服务，大家都不会有什么问题；

统一前端技术栈，前端React和Vue学习成本较低，所以也问题不大；

但统一后端技术栈，比如让Java同学转golang这就很有点困难了，但是资源不足的情况下，比如后端技术只有30人，如果还是一半一半的话，人员根本没有流动的可能，那么团队也早晚要崩，这个情况怎么办呢？方案也很简单：

1）柔性转移

如果时间窗口充裕的情况下这个是比较好的策略，具体操作是好的项目用你想要的技术栈去做，并且匹配奖励，有奖惩激励，自然就会流动起来。

2）硬性转移

如果迫不得已，上层也需要做决策，承担相应风险，做硬着陆。

所有的技术规划都是权衡利弊后的决策，有决策就有得失，这个时候坚持就好。

最后回到粉丝问题本身，大家首先要有个预期：中小型公司的技术建设多半就是很差，然后作为技术负责人的职责是系统性的提升团队战斗力，如果没有这个认知，事情是没有办法做好的，具体到方法论层面：

mission -> SWOT -> 目标 -> Context -> Structure -> tradeoff(ROI) -> 定赏罚标准 -> HowTo -> BestPractice -> 结果验收 -> 复盘反思

是一个很不错的选择。