测试提前发现风险，为什么绩效常常不如开发
这事太常见了，测试在评审阶段喊出需求漏洞，上线前排掉一个致命隐患，结果季度绩效出来，开发拿A，测试拿B。问题出在哪绩效体系天然偏向看得见的产出开发写一个功能，老板打开页面就能看到，日活涨了转化率升了，这些数据直接贴在OKR上，谁都看得见。测试测出一个bug，老板看不到，他只看到系统没崩，而系统没崩在他眼里是本该如此你提前发现了风险避免了事故，但事故没发生，所以没人知道你避免了什么。绩效评价的是你做了什么，不是你阻止了什么。阻止了坏事不等于做了好事，在绩效表上就是一行空发现风险的时候越早，价值越难被确认需求评审阶段你提出一个逻辑漏洞，产品改了PRD，开发避免了一次返工。整个链条没有人注意到你的贡献，因为事情还没开始做，漏洞还没变成bug，大家觉得只是改了一下文档。一周后系统顺利上线，没人会回头说幸好测试当时提了那个问题如果同样的风险等到上线后再被发现，那就变成了一次P0故障，这时候你的价值才被看见。但问题是你是提前发现的，所以你的贡献被归零了一个更扎心的现实测试发现风险的能力越强，系统就越稳，系统越稳，老板就越觉得测试没什么事。你把活干得太漂亮，反而让自己显得多余开发不一样，开发写得越快需求做得越多，产出越明显。开发的价值是累加的，测试的价值是隐性的，前者的曲线向上走，后者的曲线横着走那测试怎么破局别只发现风险，要把风险翻译成老板听得懂的语言。发现一个需求漏洞，别只说这里有问题，要说如果不改上线后可能出现XX事故影响XX用户，修复成本是现在改的十倍。把隐患翻译成潜在损失，老板才能看见你的价值另一个办法是量化你阻止了多少事。季度末统计一下你提前拦截了多少bug避免了哪些返工省了多少人天。开发写完成了10个需求，你写拦截了8个可能导致线上事故的风险，避免了约XX小时的返工成本。数据摆出来，绩效会说话的最后说句实话测试提前发现风险这个事，在大部分公司的绩效体系里确实吃亏。这不是你不够好，是游戏规则偏向看得见的手。能做的不是抱怨规则，是学会把你的贡献从隐形变成显性会干不会说，永远吃亏。会干也会说，才能拿回你该拿的绩效
发布于 四川
1
评论
赞
未登录
友善发言
评论
加载中
