开发生和测试生有时候会纠结于“开发和测试人员比例”这个指标。今天，我们就来看看这个话题。 第一，不要以手段为目的。“开发人员和测试人员的比例”是结果数据，不是目标数据。 马常说，我不在乎钱！帮助了广大中小企业成功，自然赚钱了。 这是凡尔赛，不是吗？这里帮助中小企业成功是“目标”，目标达成后，就有了赚钱的“结果”。 如果以赚钱为目标，可以找很多手段，比如淘宝多拿提成，天猫自营和商家PK，好的物流都给自己。 不会有淘宝生态的改善。原因很简单:目标决定路径的选择。 “都是耍流氓更别说前提条件了” 回到专业场景，开发人员和测试人员的比例关系到组织优化，这是成本控制的借口。 它是一个借口，因为它经常被断章取义。 “你看人家公司开发和测试比例是5:1”“行业平均水平是3:1。我们还没有达到标准。” 没有，我只是不提别人拥有的R&D工具链的完备性、组织协同的成熟度等背景信息。 其实一句话就能反驳“别人家做了什么，有什么条件才最终做到这样的比例？”我想学习别人的成功经验。 “虚心求教！当然，理性探讨问题，深挖本质，寻求最优解，才是我们的初衷。无聊的大嘴枪一文不值。 二、保质保量按时交货的目标是什么？上至R&D最高领导，下至一线学员，报到时，核心只说一句话:我今年的目标是保质保量按时交付。 按功能润色，比如:R&D经理增加“领导xx团队”，“保证xx系统质量满足要求，迭代周期缩短到xx，需求吞吐量增加到xx” 一线同学可以说，“在按计划交付的前期，bug量减少xx。” 符合SMART标准的目标看起来不会太错。 正确的目标达到了，随之而来的结果也不会太差。 真的是这样吗？比如和开发人员、测试人员比，那就不一定了。 影响因素客观正确，主干路径方向正确。 是先填坑修路，还是用生命去冲锋陷阵？是遍地开花，还是分工合作？分三步走，还是一步走？我们的发现策略、组织和节奏还有待商榷。 这里我将重点介绍我认为影响开放测试比例的重要因素:系统/产品成熟度、在研系统数量、技术架构稳定性、并行迭代量分别与业务响应、资源分配、基础实力、节奏控制有关。 * *“系统/产品成熟度”* *直接决定了如何解决业务端的需求接受姿态。 技术人员一定不能接受所谓的临时需求，产品经理也不希望自己精心打磨的产品面目全非。 * *“正在研究的系统数量”* *是R&D团队的战术打法问题。 是自主研发筒仓系统，还是统一接入平台？更多的是一个有产品的游戏，是对技术策划能力的考验。 * *“技术架构稳定性”* *是检验技术实力最重要的因素。 分层架构、SOA、微服务、V型解耦组合、服务粒度，既考验业务的弹性支撑，又有预见性和埋伏性。 * *“并行迭代量”* *串行效率通常很高，因为它简单且容易出错，从而避免了返工。 有一句话:返工是最大的资源浪费。 并行操作是在需求交付和吞吐量的压力下进行的。 对流程规范、职责分工、人员责任意识等协作能力有要求。 三。解决方案:最多一个QA负责一个系统，兼顾责任备份。 这是人员配备准则，也是底线。 下游处理不了上游的问题，同时下游沉重的资源很容易导致上游的懈怠。 像“反正QA是有的，测试前随意测试”这样的情况，会加重恶心循环。 所以一些还处于MVP原型阶段的项目，没有配备QA，对客户影响不大，模型还不清晰，需要灵活性，弱化流程约束。同时，一个合格的开发人员要保证自己交付的代码质量。 既然，做下游QA同学不是办法。 一场比赛不是靠一个勇猛的士兵防守就能赢的，城门失守只是概率问题。 所以，做“最痛苦的人”，身体感受最强，视野全面。 应该承担推动改进的责任，这就是为什么QA工作职责一般包括优化R&D流程。 可以采取的措施有:强制合适的迭代节奏，约定需求移交窗口、发布窗口，控制迭代周期，拆除需求粒度的技术框架。稳定的公共模块技术系统产品化迫使系统产品化走向成熟，交付业务可以独立使用，产品拆包后可以组合使用。因此，在短期内发现R&D团队人员比例没有变化，但具有弹性，从应急人员的角度来看具有很大的协调感，可以有更多的经验来专注于专业能力的提升。 在很长一段时间里，团队可以承担更多的需求(产品)R&D，而R&D测试的比率肯定是提高了。 最后说句公道话:团队目标一致，优先级第一，过程指标好，量好。 长远利益，良性协同 反正我退休了，一起跳广场舞。 -END-关注“知行圆桌派”公众号ID:iamrlaoj，和老J以朋友的身份聊职场、道德管理、质量效率、八卦、修行、时间。