决，而并非一拥而上。由一个人来进行问题的分解，其他人给予他所需要的支持，以提高效率和生产力。
2.1协作成本
需要协作沟通的人员的数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果。所以并不是人越多越好，系统应该由尽可能少的人员来开发。
2.2成员差异
程序员最好的和最差的表现在生产率上平均为10：1;在运行速度和空间上具有5：1的惊人差异。
2.3团队组织关系
一个项目中的两种角色安排的三种可能的关系，他们是：
1）产品负责人和技术主管是同一个人。这种方式非常容易应用在很小型的队伍中，可能是三个或六个开发人员。在大型的项目中则不容易得到应用。原因有两个：
第一，同时具有管理技能和技术技能的人很难找到。思考者很少，实干家更少，思考者-实干家太少了。
第二，大型项目中，每个角色都必须全职工作，甚至还要加班。对负责人来说，很难在承担全部管理责任的同时，还能抽出时间进行技术工作。对技术主管来说，很难在保证设计的概念完整性，没有任何妥协的前提下，担任管理工作。
2）产品负责人作为总指挥，技术主管充当其左右手。这种方法有一些困难。很难在技术主管不参与任何管理工作的同时，建立在技术决策上的权威。显然，产品负责人必须预先声明技术主管的技术权威，在即将出现的绝大部分测试用例中，他必须支持后者的技术决定。要达到这一点，产品责任人和技术主管必须在基本的技术理论上具有相似观点;他们必须在主要的技术问题出现之前，私下讨论它们;产品责任人必须对技术主管的技术才能表现出尊重。
3）技术主管作为总指挥，产品负责人充当其左右手。这种组合可以使工作很有效。不幸的是它很少被应用。不过，它至少有一个好处，即项目经理可以使用并不很擅长管理的技术天才来完成工作。
2.4团队组成
在一个大型项目中，软件项目经理必须为成员良好的分工，组成有层次的结构。
1）系统结构师，从上至下地进行所有的设计。要使工作易于管理，必须清晰地划分体系结构设计和实现之间的界线，系统结构师必须一丝不苟地专注于体系结构。
2）首席程序员。他亲自定义功能和性能技术说明书，设计程序，编制源代码，测试以及书写技术文档。
3）程序职员。他负责维护编程产品库中所有团队的技术记录。
4）编辑、秘书。首席程序员负责产生文档。而编辑进行分析和重新组织，提供各种参考信息和书目，对文档多个版本进行维护以及监督文档生成的机制。
5）工具维护人员。测试人员。
3.团队交流
3.1手册、或者书面规格说明
手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节;同样的，它也是结构师主要的工作产物。随着用户和实现人员反馈的增加，规格说明中难以使用和难以构建实现的地方不断被指出，规格说明也不断地被重复准备和修改。然而对实现人员而言，修改的阶段化是很重要的——在进度表上应该有带日期的版本信息。
手册不但要描述包括所有界面在内的用户可见的一切，它同时还要避免描述用户看不见的事物。后者是编程实现人员的工作范畴，而实现人员的设计和创造是不应该被限制的。体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但是他不应该试图支配具体的实现过程。规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义