产品开发组是为了组织起来制造人们会买的一个产品。组织产品开发组的第二个目的是拥有不断地制造产品的能力。为了达到这些目的，产品开发组一般组织成功能型的团队或项目型的团队。特别是在软件工程中，很多时候很难在产品开发组和SQA之间划分界限。
背景：什么是软件工程?
为了方便讨论开发组和SQA组之间是合并在一起，还是划分开来，让我们先来看一下软件工程涉及的任务：定义需求、设计和实现产品并进行测试、产品验证、发布。软件工程的目的是：通过制造人们会购买的产品来为公司赚钱。
软件工程人员必须判断对于顾客来说什么是质量，定义如何制造产品（产品开发流程），设计、实现、测试和发布产品。另外，软件工程师必须能够从前一个项目中犯的错误学习。
很多组织对质量的定义只是对缺陷的度量。然而，这是很有限的定义。为了真正地定义质量，我们还需要考虑功能、可用性、可靠性、性能和配套支持。把项目的质量定义好了，才能更加精确地制定流程和权衡项目。
软件工程角色
我们来看看软件开发和软件质量保证人员的角色。软件开发人员定义需求、设计和实现产品，并最低限度地验证产品是否满足需求。开发人员经常使用功能规格、设计文档和原型来帮助定义需求。当开发人员设计和实现代码时，他们编写详细的设计文档、编写代码，编译并进行单元测试。开发人员也会通过集成测试来验证产品。
软件质量保证人员，产品的验证者，定义产品的测试需求、设计、实现和验证测试，验证产品符合需求。SQA工程师使用测试规格和测试场景设计来帮助定义测试和产品需求。当SQA工程师设计、实现和验证测试时，他们会编写详细的测试场景、编写测试脚本代码或测试用例、编译并验证测试代码。他们通过系统测试来验证产品满足需求-系统地测试产品的所有功能。
在这两个过程中有明显的相似之处：都定义需求，设计和实现产品或测试代码并验证他们的开发活动。产品开发人员的输出专注于可交付的产品-发布的代码。产品验证者的输出专注于不交付的产品-保留的（测试）代码。
但是也有很多不同之处：开发人员倾向于专门的领域-他们理解和开发产品的一个相对窄的领域。SQA工程师倾向于拥有更全面的视角-他们理解产品的整体并收集数据以理解产品的状态。因此，即使过程很类似，工作的专注点有较大的区别。
专注点的不同往往导致技术技能的不同，特别是在测试区域。单元测试开发需要产品代码的知识，对代码覆盖的理解并指导怎样衡量。集成测试需要明白配置管理系统并知道如何正确地集成产品。另外，集成测试需要有系统的架构知识，从而恰当地整合这些基本的测试。系统测试除了需要不同的技术外，系统测试开发还需要产品和代码的知识，用于发现和测试错误集中的区域。
既然软件产品开发的目的不仅仅是制造一个产品，而是重复成功地制造更多的产品。我们能否利用这些开发和验证之间的相似过程来组织软件产品开发呢？
功能型产品开发组织
如果产品开发是以功能型来组织的，开发人员、SQA、文档人员、工具、发布工程师都是独立的小组。一般会有比较多的开发人员或开发小组，所以开发组就默认地拥有了产品开发方法论。开发人员定义他们做什么，其他小组的职责是什么，开发人员是产品开发的驱动力量。一般SQA组拥有的是验证和发布过程。SQA定义测试什么和什么时候测试，发布的标准是什么。
这种功能型的组织的好处是：
1、 产品的创作者和测试者至少在技术贡献方面是独立的。
2、 经理知道如何培养这个组织
问题是：
1、 SQA很迟才参与到项目周期中
2、 即使选中的是一个全面的项目领导，也很难有动力去改进产品开发过程
3、 缺乏跨组织功能的指导和增长
功能型经理，授权的团队
在这个模型下，还是会划分功能区域：开发经理、SQA经理和他们的职员。管理层拥有方法论、工具、过程问题。团队拥有产品开发、文档和验证过程。目的是在一个大的项目组中创建一个小的项目组，然后允许技术贡献者选择最合适自己的角色。
这跟传统的矩阵型管理类似，但是传统的矩阵型管理由经理为项目组指定角色。授权型的项目组为每一个项目组成员选择合适的角色。
项目组成员定义他们自己的角色，怎样工作。经理在有问题时进行指导。也会有集中的组，如果他们为不同的组工作的话，例如工具开发组。
这种组织的好处是：
1、 项目组把问题系统地考虑、系统地解决。
2、 经理能更容易保持项目历史记录
3、 这使得人们更容易进行职业培训。能者多劳，不能者少做点。
4、 项目组成员可以在整体的产品开发流程中正确地定义工作-他们能用适合他们自己的要求的方式定义如何使用流程
问题是：
1、 不够稳定，因为不能满足很多经理的控制要求
2、 经理可能会偷懒不去记录全体的历史
3、 如果管理层对角色定义有太多的输入，技术贡献者可能会被归类成一种角色
4、 这对于小团队不实用（30人以下）
自我组织的产品组
自我组织的产品组由经理作为项目领导。管理层的作用是职业培训、为项目组争取好的项目。
