3.3 测试管理中的隐形指挥棒：测试组织模式的设计

很多公司都宣称，员工是最重要的资产。在测试管理中，关于测试团队的管理同样是一件重要方面。人是万物之灵，每个人都有自己独特的一面，如何才能让员工充分发挥自己的潜能为公司服务，在个人的职业生涯发展道路上更顺畅，同时也给公司带来更多的效益，最终达到一个双赢的目的，这是职场人士及公司经营的共同目标。

测试团队的管理是测试管理的基础，不同的组织模式，决定着测试团队在公司及在项目中的位置。测试的组织模式就像一根隐形的指挥棒，而指挥官则是公司的管理层。下面就以测试组织的不同模式为切入点，与读者分享不同的测试组织模式设计将带来不同的境遇，实际操作中设计适合公司当前发展的组织模式即为上策。

3.3.1 以开发为核心的组织模式

不同公司由于规模或产品的复杂度等的不同，采取的组织管理模式也不同。不同的组织模式，决定着测试团队在项目中的不同地位，本节介绍“以开发为核心的组织模式”的设计。

1.以开发为核心的基础模式

以开发为核心，测试是开发队伍中的一部分，如图3-4所示。测试负责人向开发经理汇报，多见于规模不大的一些小公司。在这种组织中，开发工程师除了负责设计的实现外，还需参与编写需求，或者需求直接由开发主管，甚至是开发经理编写，即某些开发人员承担着双重或多重的角色。例如，开发经理也是项目经理，带着大家一起做一个项目，在公司的发展初期常会有这种情况。

2.以开发为核心的扩展模式

随着公司的发展壮大，项目的开发需求增加，上面的模式已不足以支持多项目并行开发的需求，需要把某些工作从某些身兼数职的人身上剥离出来，独立成立某专业组，使分工变细，更明确，更清晰。于是如图3-5所示的以开发为核心的组织扩展模式出现了。在此模式中，成立了项目管理组、软件需求组，软件需求组向开发经理汇报，项目管理组通常向更高一级，如总监级汇报。

这种模式很有趣的一点是同属一个软件部门的软件需求、开发、测试小组中，是由开发主管作为代表与项目接口，参加项目的各种会议。另一个突出的特点是这种模式分开了行政线与项目线。在行政线上，各小组在人力资源管理及专业技术上向开发经理汇报，但在项目线、工作进度与质量上，接口人向项目经理汇报，各技术小组向开发主管汇报。开发经理与项目经理并没有什么隶属关系，项目经理需要资源时需找开发经理，经理再安排主管进行传递与控制。

这种组织模式有哪些优点呢？在项目的接口上，只派出了开发人员为代表，可以减少接口沟通上的成本。但这其实是一把双刃剑，一方面从表面上看是可以减少各专业组直接与项目组其他专业组接口的开销，但开发代表是否可以代表需求与测试小组，参加项目会议回来信息传递是否能到位，是否了解需求与测试小组对项目的需求，都存在疑问。

再从反面分析，它存在哪些缺点？

● 测试主管在行政线上向开发经理汇报，测试主管会感到有一种特殊而微妙的感觉，在报告项目的测试结果时不带有色眼镜是不现实的。在项目线上，汇报进度与质量时，开发主管在某些方面会做一些过滤，不可能把最真实的项目质量情况反映给项目经理。当然，有色眼镜在原则上是有度数限制的，不能太离谱，否则产品到了用户手上再反馈回有严重问题，情况就不那么简单了。

● 在有紧急任务时，在开发经理的要求下，有一些测试资源常会去做协助开发的调试工作（例如，开发改一个问题，测试帮忙验证是否改好，常是验证用于突发解决用户端某些问题的临时版本）。

● 测试人员需充当多个角色，如软件部门的配置管理员，软件帮助文档、手册的编写者等。

● 测试小组在整个部门，乃至在项目中的影响越来越小，在测试人员中，有的人渴望转为开发人员，有的人想转为需求设计人员，随着时间的流逝，测试组织非但壮大不起来，反而可能消失。

综上所述，此开发模式适合于公司发展的初期，属于一种过渡的组织模式。接下来，介绍以项目经理为核心的测试组织模式的设计。

3.3.2 以项目经理为核心的组织模式

首先介绍以项目经理为核心的基础模式，然后再介绍其扩展模式。如图3-6所示，它是一种典型的以项目经理为核心的团队管理模式，开发小组与测试小组并存，隶属于项目经理领导。这使笔者想起建筑工程队的包工头，或许不太合适，但二者有相似之处。这种模式对于项目经理来说是有利的，项目经理不管你是什么专业方向，对他来说都是资源和工具，是完成公司交给他这项任务的必需工具，他只关注本项目的进度与质量，而各技术专业组的技术积累、人员培养等则超出他的管理范畴，但对公司来说，是需要考虑这些方面的，员工成长需要项目作为历练的平台。那么这种模式下的明显弊端需要如何弥补呢？这就需要如图3-7所示的以项目经理为核心的扩展模式。

在此扩展模式中，出现了开发经理，在行政线上他管理着软件需求、开发与测试小组这3个小组的人力资源使用情况。在项目的进度及质量上各技术小组单独向项目经理汇报。季度或年终绩效考核时，项目经理及开发经理分别在不同的管理方向对各技术小组进行评价。

此种以项目经理为核心的管理模式中，资源稳定，整个项目团队凝聚力高，大家都在为着同一个目标而努力，那就是把项目做好，按时按质地将研发出的产品交给公司。如果项目经理的号召力强，有魅力，能把项目的内外关系处理好，又能赏识团队，在到达不同阶段的里程碑后，及时表扬项目成员，如举行适当的庆功会，犒劳员工等，项目不成功都难。

对于测试来说，相对以开发为核心的组织模式，错误报告和其他测试信息直接向项目经理汇报，有机会说真话了，测试主管与开发主管是同级的，测试组织的声望更高了。但仍属同一个开发经理管辖，意味着仍需竞争同样的集中资金与预算。

在用这种管理模式完成项目测试任务的过程中，笔者也曾遇到过一些尴尬的事情，大致有如下几点。

● 资源利用率不够高效。由于给项目的资源是固定的，即一旦某位工程师加入此项目，需要到本专业任务结束或项目结束后才能离开项目，对于某些特殊情况还需项目经理同意后才能释放资源。而实际上，在整个项目的开发过程中不同阶段的不同技术组的任务量是不同的，比如在项目后期，主要是解决Bug使版本稳定，需求及开发人员相对工作量较少，此时有些人员完全可以加入到其他项目中。但通常，项目经理是不会同意释放资源的，此时，即使是开发经理也很无奈。

● 技术平台积累不理想。技术平台积累的优先级永远低于项目任务的优先级。对于项目而言，目标很清楚，就是按时按质地做出产品，提交公司生产、销售去赚钱。而对于技术部门而言，需考虑人力、技术成本。如果做完一个项目，没有一定的积累，再做同一个类似的项目时，人力、技术投入的成本有增无减，这是技术部门管理的失败。

● 双重考核的尴尬。项目经理在拿到公司对项目的考核结果后，根据项目完成情况，把各种等级标准分到各技术组。各技术主管完成各技术组的一级考核后，发给项目经理进行二级考核，最后发给行政线经理，即开发经理进行最后的评定。由于开发经理没有实质性的项目结果包（或许可以理解为奖金包），评定更多的是流于形式，但也不排除出现残酷的一面，本来可以被项目经理定为“A”的工程师，被开发经理站在其他角度调整为“B”或“C”。

3.3.3 独立的测试组织模式

在独立的测试组织模式中，如图3-8所示。项目经理、开发经理和测试经理并行，测试组织具有真正意义上的独立，具有权威的地位。测试资源与预算再也不用与开发一起合计，被调去支持开发调试的救火工作不属于测试部门，而是开发部门内部的事。当项目增加时，可以根据需要自由增加人力、技术的预算。向上汇报时，除了可以如实汇报外，你还可以根据产品的质量状态提出有建设性的意见或建议，管理部门会用完全开放的心态听取来自测试状态的报告，测试在研发系统中的影响力较大，是测试组织管理的最佳模式。

此种模式对测试独立性、权威性来说是最好的，意味着在行政线上测试团队在独立的测试部门范围内工作，对应的开发团队及项目管理团队也在自己的部门中工作，为了一个项目，大家并肩协作。此种情况的模式有一个显著特点，那就是测试人员是对测试部门负责，一个人可以同时服务于多个项目。也就是说，对于项目来说，资源是不固定的，这对于技术平台化积累是很有效的。

在测试组织的管理模式上，还可以根据公司的不同情况进行调整。但是，无论采用哪一种模式，大家都知道“天上是不会掉馅饼的，地球上没有天堂”，公司是要通过销售产品来赚钱的。当项目进度紧，发布版本必须要在某一天拿出来时，质量屈服于进度的牺牲是一个永远存在的遗憾。在项目中常表现为开发在拼命地改Bug，而测试没有完成充分验证，版本已顶不住市场的压力便匆匆上线了。