合纵：把技术语言翻译成人话，用事实数据说话

架构重构是大动作，持续时间较长，会占用一定研发资源（开发、测试），不可避免会影响业务功能开发，因此要真正推动一个架构重构项目启动，需要花大量精力进行游说和沟通——这里不是指办公室政治，而是要和利益相关方沟通好，让大家对重构达成一致共识，避免重构过程中不必要的反复和争执。一般技术人员谈架构重构时会搬出一堆技术术语：可扩展性、可用性、性能、耦合、代码很乱……但从实际经验看，和非技术人员这样沟通，效果如同鸡同鸭讲——技术人员说”可扩展性太差、改都改不动”，产品人员可能想”和扩胸运动有关吗，不就是找个地方写代码嘛”；技术人员说”可用性才3个9，业界都是4个9”，项目经理可能想”3个9和4个9不就是差个9嘛，和可用有什么关系”；技术人员说”A业务和B业务耦合”，运营人员可能想”A、B业务本来就是互相依赖的呀，耦合为什么不合理呢”。这并非嘲笑非技术人员不懂技术，而是说明有些技术术语本身就不容易理解，跨领域沟通时很难达成一致共识。除此以外，沟通中还常遇到”凭感觉而不是凭数据说话”的问题——比如只说”系统耦合导致开发效率很低”，没有数据也没有样例，其他人员很难有直观印象。因此沟通协调的关键是：把技术语言转换成通俗语言，以事实说话、以数据说话。具体做法上，以M系统为例，把”可扩展性差”转换成”版本开发速度很慢，每次设计都要考虑是否影响门户、是否影响其他业务”，并收集一个月的版本情况数据：有的版本设计阶段讨论1-2周、开发只有2天，一个月才做4个版本，最极端的一个版本讨论2周、开发2天、又等了1个月才和门户系统一起上线——这组数据一亮出来，项目经理和产品经理都被吓到了。以S系统为例，没有直接说”可用性是几个9”，而是整理线上故障次数、每次影响时长、影响用户数、客服反馈意见，再拿其他系统的数据做对比，无论产品、项目还是运营人员，都能一眼看出系统可用性确实有问题。