前段时间有个粉丝问了一个问题：
互联网发展到今天已经有些年头了，特别是大公司的技术体系建设十分完备，甚至达到了润物细无声的地步，这也导致了很多同学背靠体系，认为很多事情是“理所当然”的，但出来到中小型公司后却发现一片狼藉很难适应，但就我这几年的工作经历，一篇狼藉可能才是常态...
所以，中小型公司去大公司捞人，多半是想让他们协助建设相对完善的技术体系，而多数人是没有能力推动体系化建设的，更多是骂两句傻逼，最后悻悻的离开，而导致这个问题的根本原因是什么呢？
根本原因如前文所述是基建与业务投入比例问题，中小型公司只能在技术基建投入合适的份额，这个份额多半就是一个CTO加几个架构师的钱，再多就要失衡。
所以无论从资源投入还是时间窗口，中小型公司的技术建设只能以小步快跑，局部翻新的策略进行，其中要讲究时间点要拿捏火候，想要一口吃个胖子的人多半活不下去。
之前我们说了技术基建的投入应该在20%以内，今天来讨论如何做技术基建规划。
技术发展方向
规划技术发展方向绝对不是无脑造轮子，更不是虚无缥缈的事情，要讲究一个标准、两个原则：
- 一个标准：技术发展结果要看ROI；
决策上强调投入产出比之外，还须强调战损意识。战损即个人、团队的时间精力消耗是不可回收的消耗，比如团队花一周时间完成了一个项目，这个项目上线之后发挥了预期作用，即合理战损；
如果项目没有发挥预期作用，甚至没上线或者上线失败，即无理战损。要强调 100%资源投入 = 100%合理战损 + 0%不合理理战损。
然后是两个原则：
- 原则一：技术发展方向必须围绕效率、质量、体验，三者之一展开；
- 原则二：技术发展方向必须解决当前实际痛点；
原则一是基础，原则二是指导方向，因为多数时候效率和质量是互斥的，所以当两者间有冲突时，要看当前团队的主要痛点是效率问题还是质量问题，总的来说：
- 对于业务：效率>=质量>体验；
- 对于技术：质量>=效率>体验；
举个例子，团队之初，都是小项目开发，不会有什么效率问题，稍微关注下质量即可，但随着时间推移，小项目变成大项目；多个大项目串联成项目矩阵，于是错综复杂的系统就出现了。
以文中粉丝案例来说，他接手的是一个“老旧”技术团队，面对的是年代久远的系统，就会出现一个现象：团队中个体素质都很高，随便拉出去开发一套新项目都是一把好手，但在体系内就是效率低、质量差。
这就是典型环境拖累个人的情况，个人虽然能力不错，但还不足以解决环境问题，这里需要影响力更大，资源更多的一号位做系统性治理，这个系统性治理，就是我们所谓的技术发展方向规划。这样说太虚，举个例子：
案例·单点突破
两年前刚接手团队时候情况与粉丝案例类似，这个时候可以不用急着做技术规划，因为大家都没信心，当时技术团队最迫切的问题是一个系统老是出BUG：
面对业务方不停的谩骂，相关技术人员锅多不压身早已躺平，破罐子破摔，这种情况下什么技术规划都没用，直接成立项目组让技术能力过硬的小孙任Leader开始诊断，三大问题逐渐浮出水面：
- 组织建设问题
- 管理单点凸显，上下锁死，Leader无力推进，执行左右横跳；
- 一米五九问题严重，关键人凋零；
- 组织执行力跟不上；
- 质效问题
- 产品质量低下并且研发质量意识不足；
- 项目流程混乱，文档基无沉淀；
- 业务单点问题严重，整体业务意识偏低；
- 工程问题
- 历史包袱过重，工程建设停留在两年前；
- 现有数量级一定会有性能问题，更不能满足10倍增长；
- 非单系统问题，单系统优化好，但依赖的系统依旧会有问题，所以整体依旧不稳定；
看似一个独立项目的问题，其实是整个技术体系的问题，技术系统就很容易引起蝴蝶效应，面对如此问题该怎么做呢，答案是一规划二甩锅三拿资源：
技术有部署，时间有窗口，事后有激励，一个小而美的成功案例就形成了，小团队有信心了，自然就会影响大团队，这个时候便可以进行第二轮设计了。
系统性升级
如果仅仅是在各种小战役上玩策略，那么整体实力永远不可能提高，所以小案例成功后大家士气正高，就应该趁热打铁扩大战果追求系统性升级。
既然是系统性解决方案，就要有系统性的过程，这里我的思维与前B站Leader基本一致：
技术规划方法论
- 充分学习和读懂业务，想清楚要做到什么目标，想清楚怎么匹配业务的发展趋势，进而计算清楚需要具备哪些技术系统、技术设施和技术能力；
- 盘一盘，手上有哪些资源，可以借用哪些资源；
- SWOT，查漏补缺和完善细节。注意充分收集一线信息；
- tradeoff & ROI，什么模块适合Tech-redefine、什么模块适合投多少资源、什么模块适合借力、什么模块适合花钱买；
- 定好目标，定好关键人，想清楚事项依赖、人员协作和组织结构，做好OKR & KPI，明确定性和定量标准。可以根据一线反馈及时更新；
- 过程中，随时讨论落地路径和方法论，确保战术符合战略及动态解读；
- 参考最佳案例和做出最佳案例，微创新；
- 结果验收，以单点打透为目标，以细节完成度为评分标准，务求极致；分清楚职位角色、自然人，赏优罚劣，予以公平的认可和正确的引导；
- 对于执行同学，态度、战术执行力度、参与度和实操过程中起到的作用是主要评估内容；负责指挥目标或结果的Manager & Leader，首要标准仍然是最终目标或结果的好坏，执行上的要点是更好、更坏这种程度上的差别；
- 复盘反思。
实操案例
具体实操方面依旧是先做大量有用信息输入，形成此图：
再做系统性分析，找出当前的核心问题：
最终，从人事物方面可以做的事情也就出来了：
再进一步就是对四个大方向设立四个S级的OKR，确定技术选题再挑选负责人不断推动执行即可，最后再举个复杂点的例子：
案例·团队合并&技术规划
在某种情况会出现公司合并的场景，公司合并会带来技术体系的合并，这可能导致很大的难题：
- 两个团队初期规模300多人，当前两个APP同时维护；
- A团队使用腾讯云；B团队使用阿里云；
- A团队后端技术栈为Java；B团队后端技术栈是golang，还有部分php；
- A团队APP体系之前可能放弃治疗了，居然使用的是原生+Flutter+Hybrid；B团队使用的原生+RN；
- 前端体系Vue、React都在用...
- ...
真可谓是神仙打架啊！好在合并后人员还算充裕，可以各自安好，但去年行业不景气，技术侧也不好过，结果就是100人不到的团队要维护这个体系，而且还有进一步萎缩的风险，我真的是佛了！
技术人员减少了，而服务规模未减少，在人员急剧减少的情况下需要从工程建设、团队管理、服务资源、需求控制等四方面进行降本增效的规划且同时还要稳固团队来保障业务稳定增长，所以怎么做呢？
宏观诊断
团队合并、多技术栈、历史悠久，加上人员一大波流失，所有负面条件都占齐了，什么都想要注定什么都失败，所以可以得到第一个结论：
好消息是，合并回来的业务产品也走的差不多了，所以暂时做保守维护即可，新业务全部使用未来规划技术体系。所以这里的整体思路是：
具体几个大决策是：
- 统一云服务；
- 统一DevOps等基础服务；
- 统一前后端技术栈；
- 其中一个APP只维护不迭代，有大的迭代就集中所有力量，全部推翻重来；
之所有做这些决策是因为资源确实有限，另外老业务年久失修，熟悉的人也不在了，没有更好的办法，就当不破不立，先破后立吧！
说服老板
光是你想还不行，至少还得说服老板与产品！
- 让他们知道你有多难，那只会同情你不会支持你；
- 告诉他将会获得什么好处，那么结果会有所不同；
这其实是一次向上汇报，可以用这个汇报结构：
比如说明问题严重性，不要光说现在有多少服务，每个人维护了多少个服务，做张表出来，技术栈问题也是：
问题清晰了，后续工作会更好继续。但由于专业性，最终他们的关注点会留到概览的项目列表，所以你需要清楚告诉他们：
- 到底要做哪些事；
- 做这事有撒好处；
- 做这事有撒成本；
- 做这事有撒风险；
具体到每个项目怎么做，他们听不懂也不会感兴趣了...
卡点·技术栈合并
统一云服务，大家都不会有什么问题；
统一前端技术栈，前端React和Vue学习成本较低，所以也问题不大；
但统一后端技术栈，比如让Java同学转golang这就很有点困难了，但是资源不足的情况下，比如后端技术只有30人，如果还是一半一半的话，人员根本没有流动的可能，那么团队也早晚要崩，这个情况怎么办呢？方案也很简单：
- 柔性转移
如果时间窗口充裕的情况下这个是比较好的策略，具体操作是好的项目用你想要的技术栈去做，并且匹配奖励，有奖惩激励，自然就会流动起来。
- 硬性转移
如果迫不得已，上层也需要做决策，承担相应风险，做硬着陆。
所有的技术规划都是权衡利弊后的决策，有决策就有得失，这个时候坚持就好。
结语
最后回到粉丝问题本身，大家首先要有个预期：中小型公司的技术建设多半就是很差，然后作为技术负责人的职责是系统性的提升团队战斗力，如果没有这个认知，事情是没有办法做好的，具体到方法论层面：
mission -> SWOT -> 目标 -> Context -> Structure -> tradeoff(ROI) -> 定赏罚标准 -> HowTo -> BestPractice -> 结果验收 -> 复盘反思
是一个很不错的选择。
好了，今天的分享就到这，喜欢的同学可以四连支持：
想要更多交流可以加微信群：