里也有一些团队没那么宽松的授权空间，但总体来看，他们都更强调从需要解决的问题出发、让执行团队拥有充足的施展舞台。
团队归属性明确是科技巨头的另一大特征。在这里，每个由 5 到 10 人组成的团队都有清晰的愿景和使命，也掌握着必要的技能和自主权。如果产品团队的任务是开发酒店服务，那他们就可以将目标设定成“为老年群体提供全球最佳的预订体验”；对于产品平台团队来说，任务则可能是“以几乎零成本方式帮助其他团队整合评级体验”。
以产品为中心的团队，往往由跨职能部门的多位成员组成，具体涵盖后端、前端和 / 或移动工程师。团队中还经常有产品经理、数据科学家和设计师的身影。但与之对应，以平台为中心的团队往往不是跨职能团队，或者跨越范围没那么广泛。
请注意，尽管工程师们拥有更高级别的专业知识，但在科技大厂中，多数经验丰富的软件工程师其实是有挑选工作方向的自由的。大厂面试已经反映了这种对于通才的高度重视。
五、放弃“不切实际”的 Scrum
我曾亲眼见证 Scrum 团队是怎么在 Skype 项目中一步步放弃 Scrum 框架的。当初刚加入 Skype for Web 的工作时，我们进行过为期两周的冲刺，遵循的也是常规的 Scrum 流程。团队里也有软件工程师和 QA 工程师（在微软叫测试中软件开发工程师，简称 SDET）。但是，我们的发布速度只能做到每两周一次，再难寸进。
所以我们首先想到的就是把 QA 纳入到工程中来。在传统流程中，工程师先完成自己的工作、检查分支成果、更新工单，再交给 QA 加以审查。QA 那边要过一、两天才能拿到工单并审查内容，如果发现问题，就再开一张新工单把情况反馈回来。总之，整个过程相当迟钝缓慢。
因此，我们悄悄做了一点非官方的调整，要求所有 SDET 都参与生产软件的构建，同时要求所有软件工程师都要负责测试自己编写的代码。现在，我们不需要在交付生产之前傻等好几天的代码审查结果了。然而，两周一次的冲刺和无数 Scrum 工作又带来了新的麻烦。
Scrum每天都在阻碍交付。Scrum 的基本思路就是以冲刺为中心，在冲刺启动时做出任务承诺，在冲刺期间处理任务，并在冲刺结束时演示实际成果。
但这个过程相当别扭，感觉像是被一只无形的手赶着快速前进。所以我们很快转向了另一种更流畅的工作方式，这就是 Kanban 方法。我们不再关心冲刺、也放弃了 Scrum 提出的那些条条框框，转而专注于自己当前正在做什么、接下来又要实现什么。
基础设施和开发者工具也帮助我们摆脱了种种 Scrum 琐事。具体有哪些琐事？向产品负责人演示开发成果、签收确定再交付之类。但这里其实包含一些并不靠谱的假设：
产品负责人未必能准确验证出工作成果是否符合规范。
产品负责人负责编写验证规范，但因为第一条就不确定，所以他们编写的规范当然也未必可靠。
在等待签收的过程中，成果还是没法及时被纳入生产流程。
反正在 Skype，上面三个问题确实严重影响了功能发布。我们编写的所有代码都通过了单元测试，甚至在必要时接受了集成和端到端测试，那还要产品负责人再验证一遍干什么？我们的代码都附有功能标签，也用分段发布的方式逐一验证完成。所以，大部分由工程师自己编写的“规范”和工单压根没有必要。CI/CD、功能标签和实验工具已经带来了快得多的反馈周期，没必要让产品负责人这一环拖慢整个节奏。
不少科技大厂也意识到一流的基础设施和开发者工具，将给工程团队的生产力带来多么重大的影响。因此，30% 到 40% 的工程人员长期驻扎在平台团队，Uber 也在内部平台研发上投入巨资。
凭借这些随时可用的先进基础设施和平台，各团队能够专心完成自己的核心工作目标，完全不必分神于如何设置基础设施、或者保障服务兼容性。下面分享我个人对于平台团队的一点愚见：“平台团队的作用是提高组织效率。在规模快速扩大的过程中，平台团队将发挥不可或缺的作用。但问题是，平台的价值并不直观，平台团队在商业角度看似乎缺乏意义。确实，对于规模较小的组织，或者那些增长速度不快且原有结构运行顺畅的组织，平台团队确实没什么存在感。”
另外，团队全员都很清楚我们在构建什么。我们的最终目标是发布 Skype 的 Web 版本，整个项目由多个子工程组成，但过程中团队对大局方向一直非常明确。产品经理协助制定宏观战略，我们的工程师则接手有待完成的任务。我们主动清除了那些不利于工作效率的 Scrum 要求，并发现剩下的那些要求已经跟 Scrum 没什么关系了。
六、超越 Scrum
在与 Facebook、WhatsApp、Google、Netflix 等类似组织的工程师交流时，我发现大多数受访者压根没用过 Scrum。为什么会这样？原因有以下几点：
