技术升级落地需要天时、地利、人和

今天分享携程商旅事业部 CTO 宋涛老师关于技术升级的经验。

从技术到管理的成长过程中，我们时不时会对技术进行升级改造的冲动，尤其是在刚刚接手某个系统或者团队的时候，这种感受会更强烈。

技术升级面临的问题

1. 原有技术栈非常老旧，与新技术栈兼容性差，不好维护。

2. 整体编码规范不统一，有些业务代码无人懂。

3. 测试及监控严重缺失等。

4. 功能缺失，业务数据不一致，业务需求积压。

携程最终花了 18 个月才完成技术升级，在这个过程中做了大量的权衡、规划、沟通、协调和实施的工作。

天时：顺应团队整体发展需要

技术升级是一件大事，不仅影响到线上业务的使用，也会影响到当前业务交付的进度。作为技术管理者，在规划技术项目时要顺应团队整体发展需要，尽量做到顺势而为。

在提出技术升级方案之前，首先要想清楚它的必要性和紧迫性。可以问自己三个问题。

1. 为什么要做技术升级？

2. 为什么要现在做这个升级？

3. 技术升级对业务有什么影响？

然后尝试向一个非技术部门的同事解释。如果这个同事能听得懂并且基本同意你的观点，那么你和其他业务伙伴沟通时，获得理解和支持的可能性会增加很多。一般来说，跟业务部门沟通的时候，尽量把技术改进指标改成跟业务相关的指标。这样更容易获得部门的支持。

这个方法也可以帮助技术管理者避免一些认知上的盲区。技术升级不仅仅是技术的事，而是应该跟业务契合。

地利：根据资源与现状规划升级范围

当技术改进的方向和必要性达成共识之后，作为技术负责人，要认真评估团队的现状以及可以调动的资源，权衡项目的规模和实施方式。

首先，要对项目的范围进行取舍，哪些做，哪些不做。对于项目的边界，特别是不准确去做的内容可以用“No-Goals”的形式明确下来，这样，如果大家有不同看法，也能尽早得到反馈。

其次，对于项目要坚持的技术标准和目标，可以以“非功能需求”的形式进行定义，包括广泛采用的性能、可用性、安全性、数据一致性等维度的量化指标。这些举措可以一定程度上降低项目延期交付的风险，防止项目执行过程中升级范围不断扩大，要求不断提高。

另外，在实施上要做到规划先行，把大的项目拆分为一个个可控的里程碑。在我们的实践中，发现 4~6 周作为一个里程碑比较合适，每个里程碑要有明确可交付的目标。“可交付”表现在组件架构明确，功能协议完整，可以生产环境部署和测试（初期里程碑可以对业务逻辑大幅简化，甚至直接返回 Dummy Response 验证流程）。每个里程碑要认真复盘进度、质量等方面的调整，并可以对原有规划进行及时调整。

人和：制定合理的规范

项目的顺利完成，最终要依靠团队成员的努力和合作，因为技术负责人要为团队成员制定出合理的规范。

首先，要注意根据团队成员的技术水平和熟悉度来制定技术规范和要求。在推广新的技术规范过程中，要避免因要求太高导致落地中的形式主义。新的规范和工程实践无疑会加重一线团队的学习和实施压力，所以在推广过程中可能存在走样变形的情况。因此，要切实跟踪一线员工的反馈。

其次，有些任务需要多团队配合，缺少能完全决策的管理者。在项目管理上，多人负责往往意味着无人负责。在团队还没有培养起来高度的信任和配合的情况下，这种有复杂依赖的任务最好明确单一的 Owner 来界定责任和权威。

我的心得

我自己经历的都是小公司，所以每次技术上的升级，都是基于现存的业务问题去规划的。小公司资源本来不多，产品也不确定能不能获得市场认可，规划太大不仅浪费资源，而且会导致产品迭代变慢。所以，对技术升级来说，长期和短期是需要平衡的。这个平衡没有标准，我自己的做法是，尽量抽象，让业务灵活可扩展。实在不好平衡，那么要更侧重业务。因为，只有活下来才有机会。

在和业务部门沟通时，要少讲技术指标，少讲技术细节，多讲业务指标和经济指标。不要想着教会对方理解技术上的难点和细节，没必要。

文章链接：技术升级落地需要天时、地利、人和

课程链接：

​

编辑切换为居中

添加图片注释，不超过 140 字（可选）

《技术领导力实战笔记 2022》学习笔记 Day 14