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

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

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

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

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

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

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