曾经备受关注的 Scrum敏捷管理为何不受大厂欢迎了？

科技巨头是怎么运行工程项目的？常规方法：各个团队可以灵活选择自己的工作方式，所以即使是在同一个项目之内，各工程团队使用的方法仍然千差万别。
 
科技巨头的项目执行思路拥有以下几个基本特征：
 
工程师主导大部分项目：牵头的要么是技术主管，要么是团队中的工程师。
 
团队可以自由选择项目管理方法。多数团队采用类似于 RFC 的规划流程，持续迭代 build，并在几周内完成所有内容的交付。也有一些团队使用 Kanban 那类流程，即先从优先级最高的工作入手。
 
团队层面不设专门的项目经理。这类科技巨头中，大多只设置技术项目经理（TPM），他们同时介入多个团队或跨部门运行的大型项目。以 Uber 为例，TPM 与工程师的比例约为 1：50。
 
项目管理工件和流程往往因团队而异，即使在同一企业内也是如此。大多数团队都面临项目积压问题，所以他们会在合适的时候举办“站”谈会，并时不时对现状进行集体评估。
 
提供一流的开发者工具，而且强调更短的迭代周期。很多团队专注于处理主分支，从 CI/CD（快速集成 / 快速部署）系统中获取反馈，并立即与其他团队成员共享手头的功能。
 
如果大家也在科技大厂工作过，那对以上提到的情况应该都很熟悉。但千万别想着直接把这些照搬到传统企业当中——大概率要彻底失败。毕竟科技巨头中的团队运作方式是由其组织结构决定的，没有这样的底层依托，后续执行根本就无从谈起。
 
四、科技大厂的组织结构如何影响项目运行
 
为了理解科技大厂如何管理项目，我们不妨后退一步，聊聊他们的常规运营环境是什么样子。
 
软件工程师和团队拥有自主权。传统企业的开发人员只需要完成分配到的工作，但在技术大厂里，开发者的任务是主动解决业务中存在的问题。这就是巨大的差异，也让两种工程师有了完全不同的日常工作体验。
 
工程师是好奇的解决者，而不是麻木被动的人力资源。积极上进的工程师能够产生数倍于“普通工人”的价值，二者的区别就是前者能主动发现问题、而后者只会按指令办事。所以如果企业中的工程师大多是后一种状态，那重量级项目管理方法更适合，也就是削减灵活空间、多提明确要求。
 
内部数据、代码和文档的高透明度。包括工程师在内，大厂的所有员工往往都能随时访问业务指标和数据源，编写自己感兴趣的查询指令并创建自定义报告。
 
接触业务和业务指标。鼓励工程师们跟其他部门的同事开展互动，特别是与非工程师建立联系。相比之下，传统企业往往只关注开发者与开发者、业务人士与业务人士间的沟通。
 
通过三角沟通实现工程师间的交流。传统企业更强调同层级沟通，这会减慢信息传播速度、降低决策效率。
 
愿意花钱改善开发者体验。技术巨头往往愿意帮工程师们解决问题，因此会迅速建立各种平台团队，尽可能提供更好的开发者体验。
 
薪酬更高，人才更得施展。因为能充分运用工程师们的聪明才智，所以技术大厂一般能开出等同、甚至超过行业顶尖水平的用人成本。
 
人才素质更强。以上因素结合起来，体现为科技巨头坚持雇用素质强、更有上进心的人才。因为求职者众多，所以大厂可以用丰厚的薪酬和广阔的职业发展机会优先选择。
 
放权和自主，已经成为科技巨头们的发展基石，也成为科技行业中决定孰强孰弱的关键所在。虽然科技大厂