一篇观点挺中肯的推文,关于开发测试人员那比例
“开发测试人员比例” 是个结果数据,而非目标数据。
一场球靠猛将严防死守是赢不了的,城门失守只是概率问题
团队目标一致为先为重,过程指标好商好量。利益看远,良性协同
。。。
m
👍
快被挑战死了?有没有啥可以回怼的案例?
问:目的是什么?(指向 KPI or OKR 吗?)文章里有提到 “试问别人家因为做了什么,拥有了什么条件,最终才做到这样的比例?”
如果心平气和的可以聊聊,最后大家都会务实地评估现状,不再纠结于这个 “结果指标”
道理还是得讲。听不听看人了。
开发谈比例,QA 拿质量数据 “兄 dei er,这提测通过率,写 bug 的效率降不下来啊”,话到这份上真变成互怼 意义不大了
有什么好比的,干的活不一样,业务复杂度不一样,能力不一样,工资不一样,基础设施也不一样。
好多公司看到个斑点就以为豹子长这样,生搬硬套的,真的烦。
别人开发把很多测试活都干了,你们公司开发改个 bug 都特么爱改不改的,比比比,XJB 比。
纠结开发测试比的,就像是那种说一百人天的工作找 100 个人一晚上就能上线了的领导言论!
永恒的 battle 话题 开发测试比我习惯于把它作为表象指标,目的是去深挖根因指标。
类比一个场景,领导说:团队士气不高啊!(表象)小 A 立马给出方案,评价、团建、团餐云云。深挖下可能是加班太多、人手不够、招聘不顺、市场符合技能要求的人选不够(根因)。所以还得深度思考下。
提出质量体系概念啦,引入 cmmi 或六西格玛概念给他,开发测试比有啥好说的嘛