2019年初，在和tech leads的闲聊中了解到开发团队得到了micro front-ends的技术改造立项。我知道前端自动化测试技术升级的机会来了。End-to-end test占比过大是彼时困扰测试团队的一大问题。当执行end-to-end testing出现问题时，追溯和定位问题源耗时耗力；end-to-end测试脚本的维护成本很高，自动化测试规模不断扩大。。
微前端的架构升级，意味着测试时不做页面全局加载成为可能。同时前端与服务端的进一步结偶，意味着UI测试与数据测试能更清晰地分离。经过技术选型和POC，一套用Cypress替换Selenium、component test + widget test + page test的UI端分层测试方案逐步成型。
这里无意详述技术方案，重点分享一下项目落地中的成功经验。作为一个技术变革型项目的负责人，不仅要深刻理解技术细节，把握技术改造方向，还需要留出更多的精力和智慧去推动团队成员践行你的技术理念。
项目包装
首先，给你的项目起名，让人好读好记的名字。避开诸如灯塔、磐石、Neptune等常见的项目名。在上文中提到的项目立项时，我花了一点时间设计了项目logo，并给项目所需的ppt、wiki空间等设计了母版。
在尔后的项目中，甚至见过项目负责人设计了一套以项目为背景的表情包。让项目的知名度迅速深入团队。
其次，一定要对推行的东西有一个清晰的认识。自己的认识清晰了，才能更好地说服其他人。为了验证自己的认识是否清晰，我会为项目创造一句slogan。在这里非常推荐“商业画布”的思路，对价值主张有准确的描述。也为即将到来的，来自各方的挑战做好准备。
获得自上而下的支持
虽然很多企业，包括互联网大厂宣传自己的组织风格是自小而上，执行为先的，我仍然坚信自上而下的信任和背书是技术改革获得成功的重要一环。管理层的信任，一定要落于实权。权利大小决定了你变革的范围。
获得团队的人事汇报权是最完美的情况。但很多时候，以项目生命周期而存在的项目负责人不能完全把控所有团队成员的汇报线。在这个自动化测试技术升级的项目中，需要牵引开发工程师们参与其中，还需要PMO的日常支持。这些职能团队不向我汇报，所以在立项时的一个重点就是从管理层处获得相关资源调动的权利，包括版本周期内申请到的资源规模、核心成员的精力投入占比等等。
布道+pilot
效果是说服人最好的方式，但对于一个全新的理念、从无到有的项目而已，“布道”是必不可少的阶段。不要指望全员宣讲会一劳永逸。技术革新往往伴随mindset change和流程改进，谨慎对待这些技术之外的东西，它们往往也会成为决定成败的关键因素。
在前期重要的宣讲中，除了尽心准备宣讲材料，我还会提前安排一两名“托儿”参会。确保宣讲过程有问有答，高效互动。当宣讲过程中，我们的核心观众（比如参加project pitch时的CTO）能帮我们回答“托儿”的提问，那么项目赢得认可的几率就很高了。
此外，不要贪多，以点带面。尤其是面向上百人团队的技术革新，前期多试点，逐步扩展。相信我，推广的速度并非线性，而是几何型上升的。
利益分享
最后请注意的是，变革的驱动力本质上就是利益。因此，多赢是优选方案，其次是利益互换。当我们在不遗余力地推进每个细节时，owner的地位不可替代。不用特别在意自身的存在感，适时分享credit，甚至主动让出一部分利益，会让整个团队更有凝聚力。
变革不易，善用智慧！
