注：图中虚线表示项目线，实线表示行政线。
这种模式很有趣的一点是同属一个软件部门的软件需求、开发、测试小组中，是由开发主管作为代表与项目接口，参加项目的各种会议。另一个突出的特点是此种模式分开了行政线与项目线。在行政线上，各小组在人力资源管理及专业技术上向开发经理汇报，但在项目线、工作进度与质量上，接口人向项目经理汇报，各技术小组向开发主管汇报。开发经理与项目经理并没有什么隶属关系，项目经理需要资源时需找开发经理，经理再安排主管进行传递与控制。
这种组织模式有哪些优点呢?在项目的接口上，只派出了开发人员为代表，可以减少接口沟通上的成本。但这其实是一把双刃剑，一方面从表面上看是可以减少各专业组直接与项目组其他专业组接口的开销，但开发代表是否可以代表需求与测试小组，参加项目会议回来信息传递是否能到位，是否了解需求与测试小组对项目的需求，都存在疑问。
再从反面分析，它存在哪些缺点？
测试主管在行政线上向开发经理汇报，测试主管会感到有一种特殊而微妙的感觉，在报告项目的测试结果时不带有色眼镜是不现实的。在项目线上，汇报进度与质量时，开发主管在某些方面会做一些过滤，不可能把最真实的项目质量情况反映给项目经理。当然，有色眼镜在原则上是有度数限制的，不能太离谱，否则产品到了用户手上再反馈回有严重问题，情况就不那么简单了。
在有紧急任务时，在开发经理的要求下，有一些测试资源常会去做协助开发的调试工作（例如，开发改一个问题，测试帮忙验证是否改好，常是验证用于突发解决用户端某些问题的临时版本）。
测试人员需充当多个角色，如软件部门的配置管理员，软件帮助文档、手册的编写者等。
测试小组在整个部门，乃至在项目中的影响越来越小，在测试人员中，有的人渴望转为开发人员，有的人想转为需求设计人员，随着时间的流逝，测试组织非但壮大不起来，反而可能消失。
综上所述，此开发模式适合于公司发展的初期，属于一种过渡的组织模式。接下来，介绍以项目经理为核心的测试组织模式的设计。
相关链接：
