关于开发测试人员比例
点击“知行圆桌派”关注∆ 不定期早上11:45推送
勿把手段当目的
“开发测试人员比例”是个结果数据，而非目标数据。马爸爸常说：我不看钱！帮助了广大中小企业成功，自然赚到了钱。很凡尔赛是吧，这里的帮助中小企业成功是“目标”，而目标达成后有了赚钱这个“结果”。如果把赚钱作为目标，可以发现手段很多，比如淘宝抽佣更多，天猫自营与商家PK，做好的物流都给自家。就不会有整个淘宝生态的日趋完善，原因很简单：目标决定路径的选择。
“不提前置条件的定论都是耍流氓”。回到专业场景，开发测试人员比例关乎组织优化层面的问题，说白了就是成本控制的一种借口。之所以说是借口，是因为很多时候是被断章取义。
“你看人家公司开发测试比5:1”，
“业界平均水平3:1，我们没达标啊”
。。。
发现没有，只口不提比人家拥有的研发工具链的完备程度，组织协同能力的成熟度等背景信息。其实，一句话就能反驳 “试问别人家因为做了什么，拥有了什么条件，最终才做到这样的比例？”，再补一句 “我想学习别人家的成功经验。” 以显得虚心求教的样子。当然，理性的讨论问题，深挖本质，寻求最优解是我们初衷，无趣的大嘴炮毫无价值。
保质保量且按时交付
那目标是什么？上到研发一把手，下到一线同学，述职的时候核心只说一句：我今年的目标是保质保量按时交付。按职能润色一下，比如：
研发管理者加上 “带领xx团队”，“保证xx系统质量符合要求，缩短迭代周期到xx，增加需求吞吐至xx”。
一线同学则可以说 “按计划交付的前期下，bug 量降低xx”。
符合SMART原则的目标看上去就不会太错。正确的目标被达成了，伴随结果不会太差。真的是这样吗？比如开发测试人员比，那还不一定。
影响因素
目标正确，主干路径方向是正确的。
细节上是先填坑修路，还是玩命冲锋？
是一股脑的全上，还是分拨分工？
是走三步歇一下，还是一步一歇？
我们发现策略、组织、节奏还待商榷。这里重点扒一下我认为影响到开测比的重要因素：
系统/产品成熟度
在研系统数量
技术架构稳定性
并行迭代量
分别涉及到业务响应、资源配置、底座实力以及节奏控制。
“系统/产品成熟度” 直接决定如何处理业务侧的需求接纳姿势。技术人想必都不接所谓的临时需求，产品经理也不想自己的精心打磨的产品形态面目全非。
“在研系统数量” 是研发团队的战术打法问题。是独立研发筒仓式系统，还是上平台统一拉通？更多地是与产品的博弈，技术规划能力的考验。
“技术架构稳定性” 是最考验技术能力的一项因素了。架构分层、SOA、微服务、V型解耦与组合，服务粒度拿捏，既考验业务灵活支撑，又要有远见，埋伏笔。
“并行迭代量” 串行效率通常高，是因为简单、不容易出错，从而避免了返工。有句话说：返工是最大的资源浪费。并行运作则是在需求交付吞吐胁迫下地发挥。对流程规范、职责分工、人员责任意识等协同能力有要求。
我的解法
至多1个QA负责1个系统，兼顾职责备份。这是人员配置原则，也是底线。下游解决不了上游的问题，同时，下游重资源容易造成上游的懈怠。出现“反正有QA在，提测前随便测测” 此类情况更会加剧恶心循环。所以，对于有些尚处于MVP阶段做原型的项目就不配置QA，对用户影响小、模式尚不清晰需要灵活性、弱化流程束缚；同时，一名合格的开发同学应该对自己交付的代码有质量保障。
既然，作为下游的QA同学死扛也不是办法。一场球靠猛将严防死守是赢不了的，城门失守只是概率问题。所以，作为“最痛的人” 体感最强烈，视野也较全面。应该担起驱动改善的职责，这也是为什么QA岗位职责里一般都有优化研发流程这一趴。
可以采取手段有：
倒逼合理的迭代节奏，约定需求移交窗口、发布窗口、控制迭代周期、需求粒度拆解
技术架构稳定，沉淀稳定的公共模块
技术系统产品化
倒逼系统产品化成熟，交付业务自主使用以及产品开箱即用组合使用
从而，短期发现研发团队人员配比没有变化，但具备韧性，应对突发事件
人员角度，有很棒的协同体感，能有更多的经历专注专业能力提升。长期，团队可以承接更多需求（产品）研发，开发测试比有一定的提升。
最后，公道的提一句：团队目标一致为先为重，过程指标好商好量。利益看远，良性协同。反正退了休，都在一起跳广场舞。
-END-