测试组织模式之二

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

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

2、 以项目经理为核心的扩展模式

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

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

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

在用这种管理模式完成项目测试任务的过程中，我也曾遇到过一些尴尬的事情。

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

2          技术平台积累不理想，技术平台积累的优先级永远低于项目任务的优先级。对于项目而言，目标很清楚，就是按时按质做出产品，提交公司生产、销售去赚钱。而对于技术部门而言，需考虑人力、技术成本。如果做完一个项目，没有一定的积累，再做同一个类似的项目时，人力、技术投入的成本有增无减，这是技术部门管理的失败。居以此，开发经理肯定会把这些担子压到各技术主管头上，要求技术主管在带领各技术小组完成项目任务的同时，必须考虑技术平台化的思路。提出要求：一个项目完成后，在下一个类似项目开始时，能全部复用或部分复用之前项目的成果，如需求架构，代码模块，测试方案或用例等。但在实际操作时，常会有一种身在江湖身不由已的感觉，为什么呢？在项目内工作时，项目的质量、进度永过远都是优先级最高的，在项目任务紧的情况下，首先考虑的是如何解决目前的问题，如新增了需求，必须先把测试方案与用例准备好，开发提交版本后，可以正常测试。对于此功能点，日后其他项目会不会用，及用在什么场合来不及考虑那么多。同开发设计一样，正在实现的设计或模块，首先考虑能满足本项目，如果再需要考虑满足日后其他项目，那么需考虑接口的封装或其他技术，需要较长的时间。

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