快捷搜索:  汽车  科技

测试和开发哪个工作量大(谈开发测试人员比例)

测试和开发哪个工作量大(谈开发测试人员比例)。。。“业界平均水平3:1,我们没达标啊”“开发测试人员比例”是个结果数据,而非目标数据。马爸爸常说:我不看钱!帮助了广大中小企业成功,自然赚到了钱。很凡尔赛是吧,这里的帮助中小企业成功是“目标”,而目标达成后有了赚钱这个“结果”。如果把赚钱作为目标,可以发现手段很多,比如淘宝抽佣更多,天猫自营与商家PK,做好的物流都给自家。就不会有整个淘宝生态的日趋完善,原因很简单:目标决定路径的选择。“不提前置条件的定论都是耍流氓”。回到专业场景,开发测试人员比例关乎组织优化层面的问题,说白了就是成本控制的一种借口。之所以说是借口,是因为很多时候是被断章取义。“你看人家公司开发测试比5:1”,

作者| Mr J

来源| 知行圆桌派(ID:iammrlaoj)

开发同学与测试同学有时候针尖对麦芒,纠结于“开发测试人员比例” 这个指标,今天我们来扒一扒这个话题。

勿把手段当目的

“开发测试人员比例”是个结果数据,而非目标数据。马爸爸常说:我不看钱!帮助了广大中小企业成功,自然赚到了钱。很凡尔赛是吧,这里的帮助中小企业成功是“目标”,而目标达成后有了赚钱这个“结果”。如果把赚钱作为目标,可以发现手段很多,比如淘宝抽佣更多,天猫自营与商家PK,做好的物流都给自家。就不会有整个淘宝生态的日趋完善,原因很简单:目标决定路径的选择。

“不提前置条件的定论都是耍流氓”。回到专业场景,开发测试人员比例关乎组织优化层面的问题,说白了就是成本控制的一种借口。之所以说是借口,是因为很多时候是被断章取义。

“你看人家公司开发测试比5:1”,

“业界平均水平3:1,我们没达标啊”

。。。

发现没有,只口不提比人家拥有的研发工具链的完备程度,组织协同能力的成熟度等背景信息。其实,一句话就能反驳 “试问别人家因为做了什么,拥有了什么条件,最终才做到这样的比例?”,再补一句 “我想学习别人家的成功经验。” 以显得虚心求教的样子

。当然,理性的讨论问题,深挖本质,寻求最优解是我们初衷,无趣的大嘴炮毫无价值。

测试和开发哪个工作量大(谈开发测试人员比例)(1)

保质保量且按时交付

那目标是什么?上到研发一把手,下到一线同学,述职的时候核心只说一句:我今年的目标是保质保量按时交付。按职能润色一下,比如:

研发管理者加上 “带领xx团队”,“保证xx系统质量符合要求,缩短迭代周期到xx,增加需求吞吐至xx”。

一线同学则可以说 “按计划交付的前期下,bug 量降低xx”。

符合SMART原则的目标看上去就不会太错。正确的目标被达成了,伴随结果不会太差。真的是这样吗?比如开发测试人员比,那还不一定。

影响因素

目标正确,主干路径方向是正确的。

细节上是先填坑修路,还是玩命冲锋?

是一股脑的全上,还是分拨分工?

是走三步歇一下,还是一步一歇?

我们发现策略、组织、节奏还待商榷。这里重点扒一下我认为影响到开测比的重要因素:

  • 系统/产品成熟度
  • 在研系统数量
  • 技术架构稳定性
  • 并行迭代量

分别涉及到业务响应、资源配置、底座实力以及节奏控制。

“系统/产品成熟度” 直接决定如何处理业务侧的需求接纳姿势。技术人想必都不接所谓的临时需求,产品经理也不想自己的精心打磨的产品形态面目全非。

“在研系统数量” 是研发团队的战术打法问题。是独立研发筒仓式系统,还是上平台统一拉通?更多地是与产品的博弈,技术规划能力的考验。

“技术架构稳定性” 是最考验技术能力的一项因素了。架构分层、SOA、微服务、V型解耦与组合,服务粒度拿捏,既考验业务灵活支撑,又要有远见,埋伏笔。

“并行迭代量” 串行效率通常高,是因为简单、不容易出错,从而避免了返工。有句话说:返工是最大的资源浪费。并行运作则是在需求交付吞吐胁迫下地发挥。对流程规范、职责分工、人员责任意识等协同能力有要求。

我的解法

至多1个QA负责1个系统,兼顾职责备份。这是人员配置原则,也是底线。下游解决不了上游的问题,同时,下游重资源容易造成上游的懈怠。出现“反正有QA在,提测前随便测测” 此类情况更会加剧恶心循环。所以,对于有些尚处于MVP阶段做原型的项目就不配置QA,对用户影响小、模式尚不清晰需要灵活性、弱化流程束缚;同时,一名合格的开发同学应该对自己交付的代码有质量保障。

既然,作为下游的QA同学死扛也不是办法。一场球靠猛将严防死守是赢不了的,城门失守只是概率问题。所以,作为“最痛的人” 体感最强烈,视野也较全面。应该担起驱动改善的职责,这也是为什么QA岗位职责里一般都有优化研发流程这一趴。

可以采取手段有:

  • 倒逼合理的迭代节奏,约定需求移交窗口、发布窗口、控制迭代周期、需求粒度拆解
  • 技术架构稳定,沉淀稳定的公共模块
  • 技术系统产品化
  • 倒逼系统产品化成熟,交付业务自主使用以及产品开箱即用组合使用

从而,短期发现研发团队人员配比没有变化,但具备韧性,应对突发事件

人员角度,有很棒的协同体感,能有更多的经历专注专业能力提升。长期,团队可以承接更多需求(产品)研发,开发测试比有一定的提升。

最后,公道的提一句:团队目标一致为先为重,过程指标好商好量。利益看远,良性协同。反正退了休,都在一起跳广场舞。

-END-

猜您喜欢: