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