很稳

文中提到一个点，做出来的工具没有落地使用，所以价值不大。但从后面的规划看，好像没提到与之合作的团队的声音？

有试过和其它团队一起沟通，以一种合作的方式来进行工程效率工具/平台的建设吗（比如前期需求目标确认，喊上合作团队的同学一起参与；每部分功能完成后，都邀请合作团队试用）？有轮岗到业务团队一起去完成一次业务项目，从中感受下业务团队的痛苦点吗？如果没有，那很多时候并不好抓住最痛的痛点，因为看问题的角度并不一样。

个人建议，可以尝试参考腾讯的《不测的秘密 精准测试之路》里面的模式，业务组一个同学 + 工程效率组一个同学 + 一个 leader 级人物一起合作，大家朝着一致的目标，完成一次效能提升。

对文中开头所讲的，有些个人的理解，如下：

• 工具也好、自动化也好，开展之前的价值度量，这是在动手前需要明确的，如果只是讲提升效率，我感觉这不属于价值度量，因为工具、自动化本身自带效率提升的 buff，更多的关注的是效率提升背后的东西，它的持续性，同时效率提升转化成了什么。

• 价值度量之后，是围绕着某个问题在某些场景下的解决方案设计，最终的工具、自动化只是一种解决问题的对外表现形式，真正的难点是解决方案设计是否真的解决痛点，甚至是类似场景下的痛点，以便推广是更具普适性。如果一上来就着手工具开发，容易忽略工具、自动化功能实现背后的真正痛点。工具、自动化本身最大的挑战不是实现，而是它的持续性，一个东西做出来，持续的时间越长，收益越高。然而往往有些工具的使用成本、维护成本太高，导致它很 “短寿”，自然也很难体现出它的价值。

• 最后，摸索出适合本地化的工程效率组与业务组的合作模式，度量双方的价值产出，明确双方职责。在此之前基建很重要（基础的自动化、工具链平台建设），否则会发现没有一定基建的基础上很多东西，难以落地或者开展成本很高。

• 最后技术栈尽量统一，工具、自动化开发设计、代码尽量规范。

个人认为，工程效率的团队没有多少资源，没有按照正常的业务一样配置人员，比如没有专职的产品，而且论能力可能测试开发不如开发，这些是因为内部产品的优先级比较低，投入不够，投入和产出是成正比的。