17 技术升级落地需要天时、地利、人和
你好，我是宋涛，目前在携程商旅事业部担任CTO，今天我们来聊聊技术升级如何落地的问题。
从技术到管理的成长过程中，我们时不时地会有对技术进行升级改造的冲动，尤其是在刚刚接手某个系统或者团队的时候，这种感受会更加强烈。
技术升级面临的问题
我3年前被携程集团委任带领ToB业务技术团队时，就面临着这种挑战。当时携程集团的C#转Java的技术升级项目已经进入收尾阶段，而ToB业务（携程商旅）的进度明显落后，有超过100个核心系统还在运行原有技术栈。
进一步了解后，我发现已经完成的Java代码也普遍存在规范不统一，测试及监控严重缺失等问题，需要投入大量研发才能解决。与此同时，商旅系统还面临功能缺失、业务数据不一致、业务需求积压等挑战。
最终，我们花了18个月完成了技术升级，在这个过程中做了大量的权衡、规划、沟通、协调和实施的工作，回头想想确实一路走来不容易，不是在填坑就是在踩坑的路上。很多管理者或早或晚都会经历技术升级这个过程，所以我想把我的经验分享出来，希望帮助你以可控且高效的方式规划并完成技术升级。
天时：顺应团队整体发展需要
技术部门是大业务团队的一部分，在进行大大小小的技术升级时，不可避免地要影响到当前业务的交付速度。作为一个技术管理者，在规划技改项目时要顺应团队整体发展需要，尽量做到顺势而为。
在提出技术升级之前，首先要想清楚它的必要性和紧迫性。可以问自己三个问题：
- 为什么要技术升级？
- 为什么要现在做这个升级？
- 技术升级对业务有什么影响？
然后尝试向一个非技术部门的同事解释。如果这个同事能听得懂并且基本同意你的观点，那么你和其他业务伙伴沟通时，获得理解和支持的可能性会增加很多。
就像前面我们提到的C#转Java项目，由于当时集团对旧技术栈的支持在弱化，新旧技术栈的兼容问题触发了两次较大的业务故障，以故障复盘作为切入点，通过多次讨论，技术和业务部门就项目的启动达成了共识。这个方法对于小的技改项目同样适用，如果技术人员能把“提升代码质量”或者“提升架构”等技改原因，换成用户体验或者业务指标等更通俗直接的表述，更容易得到非技术部门的支持。
这个方法也可以帮助技术管理者避免一些认知上的盲区。举例来说，技术人员本身会有在技术上精益求精的追求，当看到一些好的技术方案或工程实践时，会比较关注技术升级带来的好处而忽视业务和新技术的契合度。如果结合我们上面提到的问题思考，你就会发现技术升级的主要原因就是缺少某技术，而目标也是实现该技术，那说明这个技改规划可能没有体现出来对业务的思考。
地利：根据资源与现状规划升级范围
当技改的方向和必要性达成共识之后，作为技术负责人，要认真评估团队的现状以及可以调动的资源，权衡项目的规模和实施方式。
首先，要对项目的范围进行取舍，哪些做，哪些不做。对于项目的边界，特别是不准备去做的内容可以用“No-Goals”的形式明确下来。这样，如果有不同看法，也能尽早得到反馈。
其次，对于项目要坚持的技术标准和目标，可以以“非功能需求”（Non-Functional Requirements）的形式进行定义，包括广泛采用的性能、可用性、安全、数据一致性等维度的量化指标。这些举措可以一定程度上降低了项目延期交付的风险，防止项目执行过程中升级范围不断扩大，要求不断提高。
比如在转Java项目中，我们在项目规划阶段就列出了影响业务的核心系统，并将其作为技改对象，而以内部管理、配置为主的离线系统，由于工作量大，业务影响小而排除在项目范围之外。
另外，在实施上要做到规划先行，把大的项目分割成更为可控的“里程碑”。在我们的实践中，发现4～6周作为一个里程碑比较适合，每个里程碑要有明确的可交付目标。“可交付”表现在组件架构明确，功能协议完整，可以生产环境部署和测试（初期里程碑可以对业务逻辑大幅简化，甚至直接返回Dummy Response验证流程）。每个里程碑要认真复盘进度、质量等方面的调整，并可以对原有规划进行及时调整。
人和：制定合理的规范
项目的顺利完成，最终要依靠团队成员的努力及合作，因此技术负责人要为团队成员制定出合理的规范。
首先要注意的是根据团队成员的技术水平与熟悉度来制定技术规范和要求。同样以转Java项目为例，由于整个团队对Java技术栈的熟悉度不足，项目初期预留了足够的时间引入业界留下的Java编程规范以及配套的生态，包括规范培训和认证，以及基于Sonar的源代码扫描系统，保证了代码风格的基本统一以及通用中间件的推广。
在推广初期，团队可以花较多的时间做 Group CodeReview，让大家有机会去学习、讨论不同的代码实现方式并选择合适的标准。而在技术规范相对统一后，Group CodeReview的频率和规模可以适当缩减。
在推广新的技术规范的过程中，要注意避免因为要求太高导致落地中的形式主义。新的规范和工程实践无疑会加重一线团队的学习和实施压力，所以在推广过程中很可能存在走样变形的情况。
我们在推动单元测试覆盖的过程当中，使用JaCoCo系统来计算单元测试的覆盖率。后来和一线团队的沟通中发现，因为补写单元测试代码的工作量太大，一些一线开发为了不影响重要的发布节点，而编写无效测试代码来“欺骗”JaCoCo检测，例如只测试不验证。当这种现象在一线团队当中蔓延之后，之前所做的很多技改努力就失去了意义。因此，设定合适的标准并切实跟踪一线员工的反馈对技改项目的成功非常关键。
另外一个挑战是有些任务需要多团队配合，缺少合适的管理。在项目管理上，多人负责往往意味着无人负责。在团队还没有培养起来高度的信任和配合的情况下，这种有复杂依赖的任务最好明确单一的Owner来界定责任和权威。
比如在我们的技改当中，存在一套新的接口需要切换一千多处调用的情况，这些调用方分属不同的团队，缺少明确的切换计划，调用方和被调用方在实现方式上也有较大的分歧（被调用方希望大幅优化接口协议，而调用方希望能够尽量保持兼容）。最终，直接指定新接口的Owner作为切换任务的总Owner，而伴随着看问题角度的转变，新Owner积极在新接口里添加门面层（Façade模式）加速完成了切换任务。
小结
技术升级和改造，是系统提升和业务发展的一条必由之路。而这条路是否能够顺利走通，需要管理者全方位思考升级时机、资源协调、团队建设等多个维度的事情，并通过和业务达成共识，明确升级范围，统一规范，确定项目Owner等方法保证最终的成功。
总结成一句话就是技术升级需要“天时、地利、人和”，结合实际情况来判断，不可盲目跟风。
思考题
技术升级过程中经常会遇到各种各样的阻碍，尤其是和其他部门的沟通上，那么问题来了，我们应该如何说服其他部门支持技术升级呢，欢迎你在评论区留下自己的见解，也欢迎你把这节课分享给需要的朋友。
- yanger2004 👍（3） 💬（0）
需要具有win-win思想，在劝说的过程中明确把benefit说清楚，short term可能会有effort，但是long term的优势和利益要强调并明确沟通
2022-12-12 - 石云升 👍（1） 💬（0）
最好的方式是根据现存的问题去切入，而且最好是业务问题。如果还能算一些经济账那就更好了。切记跟其它业务部门讨论技术细节，真没必要。
2022-12-17 - 石云升 👍（0） 💬（0）
我自己经历的都是小公司，所以每次技术上的升级，都是基于现存的业务问题去规划的。小公司资源本来不多，产品也不确定能不能获得市场认可，规划太大不仅浪费资源，而且会导致产品迭代变慢。所以，对技术升级来说，长期和短期是需要平衡的。这个平衡没有标准，我自己的做法是，尽量抽象，让业务灵活可扩展。实在不好平衡，那么要更侧重业务。因为，只有活下来才有机会。
2023-01-29