职业经验 关于工程效率团队的一些漫谈

Martin · July 26, 2019 · Last by mark replied at July 27, 2019 · 1072 hits



共收到 4 条回复 时间 点赞

很稳

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

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

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

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

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

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

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

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

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

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up