现在的设计工作、软件工程已经变得非常的复杂，单人在这种任务面前已经变得无法胜任了。但是团队工作在解决这种大型工程的时候，又有一些什么样的问题呢？
1.维持一个软件工程的核心概念统一问题
当任务从单人转向多人，从内核逐渐分解到外围的时候，我们无法保证每个团队里面的人都知道他负责这一块工作到底是干什么的。这个时候，我们必须在整个团队的关键节点上的负责人知道这个节点往下的工作内容什么样的，允许的和不允许的，资源状况等等。最重要的是有一个核心的人员知道整个软件工程是用来做什么的，并且开启整个软件工程的风格习惯等等。如果缺少这么一个核心人员，整个软件工程会在多方的扯皮中承受爆炸性的需求扩张，最终离工程的目标越来越远。
2.团队工作的成本是要比单人的成本要高的问题
当把一项复杂的任务分配给一个团队进行工作的时候，整个任务的总时间要比分配给个人的时间要长。原因是任务分解需要花费时间，然后将每一项任务分配出去的时候需要讲解和核实任务接收人是否明白任务内容，接下来是任务的验收和集成测试。这些时间是团队工作中存在的，需要管理上进行控制。用技术观点来描述这种情况是，单人任务是单进程；团队任务是多线程，团队任务虽然可以提高资源利用率，缩短计算时间，但是需要面临线程上同步、互斥等问题。为了解决团队工作问题，也需要像多线程的机制一样，每一次对竞争资源的申请和占有必须遵循明确的线程竞争规则。
3.如何保证团队工作的完整性
在设计方面需要有一名主设计师，主设计师负责维护整个工程的一致性和完整性，他手下的设计师团队需要帮助他在各种分支上完成设计工作。例如一些非常经典的产品，乔布斯的苹果手机。然后整个软件工程的核心才会一直扩展到外围功能的设计，然后打包分解，最终实施。想一想开发人员、管理人员的角色，放置到真个软件工程的体系中，你会明白现在做的工作处于什么位置，离整个工程的核心有多远。
4.协作在什么时候更有效
通常说人多力量大，但是很少有人去思考可以保证力量更大的环境和条件是什么样的。当对于一个模糊的目标进行设计或者是开辟出新的可行性方案的时候，协作要比个人有效地多。因为每个人切入设计问题的方面是不一样的，最终产生的方案也可能是不一样的。越多的问题和方案会不断对模糊目标描述，逐步清晰。在软件工程中，对软件工程的目标、设计方案一般采取协作方式，这种方式要比单人更加的有效。因为这种目标的不确定性，有可能会导致事实上两个完全不同的工程最终走向同质化竞争的道路，直到某种强力的终止条件出现。在审计评审上，引入协作，引入更多的专业人士，可以帮助解决设计中一些问题。这些问题一般是因为社会化大分工导致各个专业领域逐渐隔阂，很少有机会可以了解另一个领域出现的问题。这些跨领域的问题有助于推动设计方案在可行性道路上走的更远。
5.不可以采用协助这种方式的场景有哪些
整个工程在维持其一致性和完整性的时候是不可以采用协作的。例如乔布斯在明确智能手机这个工程的完整性的时候。
6.两人结队是种非常奇特的组合
前提是两个人可以相互配合，达到默契。在岗位人员流动速度非常快的时候，这个通常都是问题。
7.请多多注意细节，远离学院派
因为学院派接触到的理论是足够的多，但是在面对具体问题的时候，却容易忽视真实环境的约束条件。大学的教程里面给出的情况通常是理想状态，化简掉了外部的约束条件。真实的是教程里的东西很少有不需要改动就可以使用的情况，例如瀑布模型，我肯定不会告诉你，公司里的某些文档是后来做完代码之后补上去的。