组织中所有的问题都可以最后归结为人的问题。很多时候我们期望流程和工具能够解决这些问题，然而如果忽视了团队中个体的需求、动机和互动方式，那么再正确的流程和再好的工具也无济于事。因为流程和工具无法发现人、培养人、激发人。
真正的团队效能来源于团队之间以及成员之间的协同合作、有效沟通和共同目标。因此，在构建和优化团队时，我们需要将关注点放在团队本身，坚持“团队优先”的原则。
为什么要聚集于团队？
嵌入式系统涉及的技术领域广泛且复杂，包括硬件、固件、驱动、软件等。一个团队中的成员可能各自专长于某一技术方向，但一个有凝聚力的团队能够充分利用每个成员的专长，同时弥补彼此的短板，从而在整体上具备更全面的技术能力。因此，一个有凝聚力的团队的表现要远远超出个人的集合。
有些嵌入式团队依赖于某几个技术骨干，他们能力很强、效率很高。但缺乏人才梯队的团队并不是一个健康的状态。几年前，一则关于10倍工程师能力的推文在社交媒体上引发了广泛的讨论。投资人Shekhar Kirani在Twitter上提出了这一观点：“有些工程师能以一当十，创业者如果有幸有这些人加盟，那么成功率就能够大幅提升。”虽然有些人赞同这一观点，但更多的人则是以讽刺的方式表达了不同的看法。
Thoughtworks技术雷达认为与10倍工程师相比，更应该关注10倍团队：
在过去的几个月中，10倍工程师一词受到了密切的关注。一个广泛传播的推文讨论在实质上建议公司应原谅反社会和破坏性的行为，以留住被认为个人产出巨大的工程师。幸运的是，许多人在社交媒体上都嘲笑了这个概念，但是“明星开发者”的刻板印象仍然普遍存在。根据我们的经验，伟大的工程师不是因为个人产出而是因为能在优秀的团队中合作而诞生。打造一支混合不同经验和背景，但成员才华横溢的团队，并为团队合作、学习和持续改进提供良好的助力，这会是更行之有效的方式。这些10倍团队行动起来更快，弹性也更强——而无需屈从错误的行为。
《敏捷革命》中也提到同样的观点。耶鲁大学的乔尔·斯波尔斯基（Joel Spolsky）教授把学生的成绩和花费的时间做了对比。发现最快的学生和其他同学的速度相比是10:1。最快的学生是其他同学的10倍。然而，一项涉及3800个项目的研究发现，团队之间的差别比个人之间的差别大得多。最好的团队可以在1周内完成任务，但最慢的团队不是花费10周，而是花了2000周。这就是最差团队和最好团队的差别。所以如果你聚集于团队能力，就算是让最差的团队达到中等水平，效率也会有惊人的提升。
什么是团队优先？
团队优先意味着组织不仅鼓励团队追求远大的目标，还给予其充分的自主性。这样的团队能够自我组织、自我管理，他们有能力决定如何工作并获得所需的授权。
团队优先还意味着要充分考虑团队的认知负载、协作方式、沟通成本和人员能力等。只有把每个人看作生态中的一份子，产生内驱力，提供机会，提升能力，才能真正激发团队的潜力，推动团队走向卓越。
在团队内部，团队成员也要有团队优先的意识，意味着团队成员将团队需求置于个人需求之上，能够：
- 聚焦于团队目标。
- 保证讨论和调研事项走上正轨。
- 在开始新工作之前帮助其他成员解决阻塞事项。
- 辅导新团队成员和缺乏经验的成员。
- 高效参加团队活动（周会、站会等）。
- 避免陷入“谁赢谁输”的争论，与此相反，乐于探索新的选项。
要做到团队优先，可以从团队规模、团队生命周期、责任心、限定边界、降低认知负载和共享知识入手。
小团队更容易建立信任和紧密的合作关系
有研究发现，高度信任的团队是驱动创新和实验的源泉。如果信任缺失，或者由于组织变大而不断降低，交付的速度和安全将受到影响。
团队规模对信任度有直接影响。亚马逊著名的“两张比萨”团队理念强调了小团队的效率与协作优势，而Scrum框架所推荐的团队人数也倾向于5-9人。这些数字背后的原理都可以用邓巴数字来描述。邓巴发现15是一个人可以信任人数的极限，而其中只有5个人能获得深入了解和信任。一旦人数超过9人，信任就会开始崩塌。
团队人数的增加，也会增加沟通成本。你可以简单测算一下人数与沟通渠道的关系。只要把团队人数乘以“团队人数减1”，然后再除以2就行了。对人数为n的团队，它的沟通渠道数量=n(n-1)/2。比如，如果团队有5个人，那么团队的沟通渠道是10条；如果有9个人，沟通渠道是36条；而10个人的沟通渠道会有45条。过多的沟通渠道将超过了人脑的承受能力，我们根本不知道别人正在做什么。沟通成本也急剧增加，例如简单的会议可能从几分钟增加到数小时。
建立长期稳定的团队以达到高效能状态
除了团队规模，高信任度的团队还取决于团队的生命周期。
团队需要花时间磨合以形成生产力。Tuckman模型描述了团队在四个阶段上的表现：
- 组建期：团队刚刚建立。
- 激荡期：解决最初的个性和工作方式上的差异。
- 规范期：共同演进标准工作方式。
- 执行期：达到高效能状态。
在高度信任的组织中，几个月换一个团队可能不是大问题。例如在Thoughtworks，团队通常按项目临时组建。由于大家具有相同的价值观和做事方法，所以能够很快形成生产力。但在大多数传统组织，人们需要3个月，甚至更长时间的磨合来形成生产力。
因此，组建长期的产品团队始终优于短期的项目团队。项目是临时的，具有明确开始时间和结束时间，生命周期通常比较短。而产品是长期存在的。如果6个月的项目结束就调换团队，并不是一个好选择。反而保持稳定的产品团队能够维持团队的凝聚力和生产力。
另一种方法是Allan Kelly在他的《Project Myopia》中提到的，让“工作流向团队”。团队应该保持稳定，而非一成不变，仅在必要的时候进行偶尔的调整。
团队为产品负责
一个为产品负责的团队，其核心优势在于集体的力量和协作的精神，而不是依赖于单一的个体。这样的团队通过共同的目标和责任，将个体的能力凝聚成强大的整体，从而能够更好地应对挑战和实现卓越的成果。团队成员彼此信任、互相支持，在共同成长中不断提升团队的战斗力。这种团队文化不仅有助于产品的成功，还能为企业和组织创造持久的价值。
每个产品都应该拥有一个唯一的负责团队，做到责任明确、不分散。这种安排避免了多个团队之间可能出现的责任推诿或工作重叠，从而提高了工作效率和产品质量。当问题出现时，该团队能迅速做出反应并找到解决方案，因为他们对自己的产品了如指掌，也对其成功负有全部责任。这种责任制促使团队成员更加专注、投入，以确保产品的成功和满足市场需求。通过明确的责任划分，企业能够更有效地管理资源，推动产品不断创新和进步。
团队应该拥有自主性。这意味着在既定的边界内，团队能够自主决策、自我组织，从而灵活应对各种挑战，高效推动任务的完成。这种自主性不仅提升了团队的责任感和积极性，也促进了成员之间的协作与创新。
设计系统边界，降低团队认知负荷
如果一个团队的认知负荷过高，例如任务过多、负责的系统复杂度过高，团队成员可能会面临过大的信息处理和决策压力，降低了自主性。这会导致团队工作效率下降，成员难以集中精力完成任务，甚至可能引发工作质量下降和错误率增加。这种连锁反应可能会导致团队效能走入恶性循环。因此，合理管理团队的认知负荷对于提高团队效率和确保工作质量至关重要。
采用团队优先原则时，团队的职责应该与团队的认知负荷相匹配。这意味着要限制团队负责系统的大小和复杂度。
可以将系统按领域划分，每个领域再划分为简单、复杂、非常复杂等级别。一个团队可以负责一个复杂领域或者多个简单的领域。对于非常复杂的领域应该由专门的专家团队负责或者进一步拆分成多个领域。
隐性知识显式化
在团队中，隐性知识的显式化对于促进团队能力成长至关重要。隐性知识是指难以用言语表达的技能、经验，这种知识难以传承和分享，限制了团队能力的提升。
我们在一些嵌入式团队发现，产品的需求非常复杂，但由于历史原因，没有完整的文档，只有个别骨干掌握了较完整的信息。这些存在于骨干大脑中的隐性知识如果不显式化出来，就不利于团队的能力成长。
通过将隐性知识显式化，即将其转化为明确、可传播的知识，例如分享经验、将其文档化，建立知识库，团队成员可以更好地理解和掌握这些知识，从而更好地积累和利用经验，提高工作效率和质量。同时，显式化也有助于增强团队的协同效应，促进成员之间的相互学习和共同成长。
总结
在嵌入式系统领域，由于涉及的技术领域更加广泛且复杂，包括硬件、固件、驱动、软件等，如何打造高效能团队，团队设计至关重要。本文强调了采用“团队优先”的原则，提升10倍个人能力很难，但提升10倍团队能力是完全可能的。通过关注团队规模、建立长期稳定团队、限制团队的系统边界、降低团队认知负荷，以及将隐性知识显式化逐步，团队可以更好地应对技术挑战，提高工作效率，最终推动整个团队走向卓越。
