大型科技公司如何推进技术项目？为什么许多大型科技公司很少采用 Scrum？这背后不仅是项目管理方法的选择，更与团队自主权、工程文化、组织结构、开发者工具和人才密度密切相关。

项目管理是一个几乎人人都有强烈看法的话题，我也不例外。为了了解不同公司如何推进工程项目，我咨询了来自行业不同领域的人士。本文将讨论以下几个问题：

• 行业中的项目管理方法。 一项覆盖 100 多家公司的调查概览及主要结论。
• 大型科技公司如何管理技术项目。 大型科技公司的组织结构如何影响项目执行方式？
• 为什么大型科技公司很少采用 Scrum。 为什么如此流行的 Scrum 框架，在大多数大型科技公司中反而并不常见？不采用这种模式的公司，又能从中学到什么？
• 团队层面的项目管理应该如何开展。 我将分享一些个人经验。

在进入正题之前，我想先讲一个个人经历。它很好地说明了：项目管理方法固然重要，但有时候，我们很难准确判断它在项目成败中究竟占多大比重。

本文最初发表于某海外技术通讯。该通讯尤其适合高增长初创公司和大型科技公司的工程经理、高级工程师及以上级别的技术人员。订阅后，你可以每周在邮箱中收到类似文章。

某通信产品、Scrum，以及对真正重要之事的提醒

我在 2012 年加入某海外老牌通信产品团队时，公司已经全面推行 Scrum。所有工程师和产品人员都被安排参加一流的 Scrum 培训，授课者之一还是《敏捷宣言》的发起人。公司对 Scrum 投入巨大，并在几个季度内将所有团队都迁移到了这一方法论之下。

在这家公司内部，转向 Scrum 被视为一次成功转型。其旗舰级桌面应用的发布频率，从过去最多每季度一次，提升到每月一次。大多数团队每 2 到 4 周就能交付一次成果。团队成员轮流担任 Scrum Master，敏捷教练会定期介入并提供反馈，而刚刚完成收购的一家大型科技公司，也对这种交付速度的提升非常感兴趣。

然而，就在这家老牌通信产品转向 Scrum 和敏捷开发时，一位竞争对手正在以极高的执行力推进自己的战略：某新兴即时通信产品。尽管团队规模小得多，这款新产品却逐月蚕食市场份额，最终成为领先的即时通信平台。

与这家老牌通信产品不同，某新兴即时通信产品从未采用 Scrum 这类框架。早期员工透露，他们甚至从未讨论过 Scrum，并且有意识地避开繁重流程。这个新兴团队的执行力超过了老牌竞争对手，打造出更可靠的即时通信体验，并最终赢得了这场即时通信应用之争。

这个故事提醒我们：公司的成功与项目管理方法之间，并不总是存在直接对应关系。我并不是说项目管理方法不重要——它当然重要。但还有许多因素可能对结果产生更大的影响，比如公司的关注重点、领导方式、员工在缺少流程约束时如何协作，等等。

项目管理是一个复杂且不断变化的拼图中的一块。然而，它不是，也不应该是最终目标。它只是帮助团队更快达成目标的一种手段。

行业中的项目管理方法：不同公司如何推进工程项目

公司究竟如何推进项目？我做了一项调查，并收到了 100 多份回复。结果相当有意思。

如果要用一句话概括公司如何管理项目，那就是：视情况而定。 这并不令人意外。一家只有 5 名员工的初创公司，和一家拥有数千名员工、增长缓慢的非科技公司，取得成功的方式必然不同。即便同属大型非科技公司，有些公司会尝试新方法，另一些公司则会坚持沿用多年来被证明有效的做法。

我将受访公司划分为以下几类：

• 上市科技公司： 以技术为核心的上市公司，其中许多公司此前曾获得风险投资。
• 风险投资支持的成长型公司： 指已经完成 B 轮或更后期融资的初创公司。这类公司估值通常至少达到 3 亿美元，发展迅速，并往往计划在几年内 IPO。
• 风险投资支持的早期初创公司： 指处于种子轮、天使轮或 A 轮阶段的初创公司。这类公司通常仍在成长中，但商业模式尚未被充分验证。
• 非风投科技公司： 指未接受风险投资、也未上市的成熟科技公司。这类公司的增长目标通常不如风险投资支持的公司激进。
• 大型非科技公司： 指那些技术并非核心业务能力的上市公司或私营公司。
• 咨询公司： 提供软件开发服务的公司。

本次调查中，各类公司采用的项目管理方法大致如下：

• 没有“正式”的方法论： 在上市科技公司和风险投资支持的科技公司中较为常见。
• 计划、构建、交付： 上市科技公司和风险投资支持的科技公司中常见的做法。
• Scrum： 在大型非科技公司、非风投公司和咨询公司中较为常见。
• 看板： 几乎各类公司都有提及。
• SAFe，即规模化敏捷框架： 主要出现在大型非科技公司和非风投公司中。
• Shape Up： 一些风险投资支持的公司提到采用了这一方法。

调查也揭示了一些有趣的现象，其中一部分来自这个问题：

“从 1 分（非常不满意）到 5 分（非常满意），你对当前项目管理方式的满意度如何？”

以下是一些值得思考的观察。由于本次调查样本不具备统计意义上的代表性，因此这些结论需要谨慎看待。尽管如此，它们确实与我在行业中的观察相吻合。

在上市科技公司或风险投资支持的科技公司中，配备专职项目经理的团队，满意度通常较低。但在非风投公司和咨询公司中，也有一些受访者对项目管理方式非常满意，并明确表示专职项目经理正是他们满意的原因之一。

允许团队自主选择工作方式，在上市科技公司和风险投资支持的成长型公司中更常见。相比之下，大型非科技公司以及规模较小、未获得风投支持的公司，更倾向于要求公司内所有团队采用同一种工作方式。

团队自主性与高满意度似乎呈正相关。许多给出 4 分或 5 分的受访者都提到，自主性、自由度、灵活性，以及团队层面对质量的重视，是积极因素。

团队遇到的困难往往与具体方法论关系不大。受访者提到的问题包括缺乏愿景、优秀工程师流失、缺乏透明度、工具不足等。这些才是团队表现下滑的原因。对这些团队而言，单纯更换项目管理方法并不会解决问题，因为根源更深。

某款常见问题跟踪工具的提及大多带有负面色彩。在所有 13 次提到这款工具的反馈中，语境都是负面的。能够在不过度依赖这类工具的情况下完成工作，被一些人视为优势。此外，一家近期上市的高增长科技公司迁移到某款问题跟踪工具后，对工程师做了一项调查，结果显示其净推荐值（NPS）为 -83。这个数值低得惊人，意味着大量工程师并不推荐使用该工具。

不过，也有相反观点。一家稳定增长的上市科技公司的工程主管表示，他们的组织高度依赖某款问题跟踪工具，并将其作为知识引擎来使用。在他们看来，当整个组织全面采用这类工具后，它在大规模协作方面表现得很好。

对于国内研发团队而言，如果既希望保留大型科技公司强调的团队自主性，又希望让目标、客户反馈、需求清理、评审排期、开发、测试、发布和知识沉淀形成闭环，可以考虑使用 PingCode 这类智能化研发管理工具，让研发过程中的数据自然流转，而不是单纯把工具当作任务看板。

根据那些给出 1 分或 2 分评价的受访者反馈，效果不佳的项目管理方法往往具有一些共同特征。

工程师没有参与估算，却要承担估算结果。 这是一个常见痛点。在我看来，这是打击工程师积极性，甚至导致一些工程师离职的最简单方式之一，同时也会让管理层对团队实际产能形成错误认知。

即便配备了专职项目经理，需求变更仍然频繁发生。 需求变更本身并不一定是问题。有些团队需求变化频繁，但项目由工程师主导，团队也有能力应对。然而，当专职项目经理无法保护团队免受频繁需求变更影响时，受访者通常会认为这种做法非常糟糕。

团队没有自主权去改变失败的项目管理方式。 在所有团队都被要求遵循同一种方法的公司中，这一问题尤其突出。这是一种典型的指令式管理。它或许适用于几乎不需要创造力的岗位，但通常不利于打造高效的软件工程团队。当团队能够共同迭代，并根据自身需要调整流程时，满意度和生产力都会显著提升。

大型科技公司如何推进技术项目

大型科技公司在推进技术项目的方式上，与其他类型公司明显不同。为了了解这一点，我与一些知名上市科技公司的员工交流并收集了数据。它们的典型做法大致如下。

大型科技公司的工程项目通常有几个共同特点。

大多数项目由工程师主导。 项目负责人通常是技术负责人，或团队中承担领导职责的工程师。

团队可以自由选择项目管理方法。 许多团队采用类似 RFC 的规划流程，进行迭代开发，并在几周内完成交付。另一些团队则采用类似看板的方式，持续处理优先级最高的事项。

团队级项目通常没有专职项目经理。 多数这类公司会设置技术项目经理，即 TPM，但他们主要负责涉及多个团队、跨组织的大型项目。在某海外大型科技公司，技术项目经理与工程师的比例大约是 1:50。

即便在同一个组织内，不同团队的项目文档和流程也可能不同。 大多数团队都有某种形式的待办事项列表，并会根据团队需要定期召开站会，也会不时进行回顾会议。

一流的开发者工具是标配，并支撑短周期迭代。 许多团队直接在主干分支上工作，从持续集成与持续交付系统中快速获得反馈，并能立即与其他团队成员共享正在开发中的功能。

对于在大型科技公司工作过的人来说，这些内容大多并不陌生。然而，如果试图将这种做法照搬到一家更传统的公司，很可能会失败。原因在于，大型科技公司的组织结构深刻影响着团队如何执行项目，也影响着它们能够以何种方式执行项目。

大型科技公司的组织结构如何影响项目管理

要理解大型科技公司如何管理项目，我们需要先退一步，看看这些公司所处的环境。作者曾在另一篇文章中更深入地讨论过：海外科技行业对软件工程师的理解，与许多传统公司存在显著差异。

软件工程师和团队拥有更高自主权。 传统公司通常期望开发人员完成被分配的任务。而在许多海外科技公司中，开发人员被期望解决业务问题。两者差异巨大，并会影响每位工程师的日常工作。

公司需要的是充满好奇心的问题解决者，而不是只会执行指令的“流水线工人”。 一位积极主动的工程师所能创造的价值，远高于只会按部就班执行任务的人。抱持“流水线工人”思维的组织，往往更倾向于采用僵化、几乎不给解释空间的项目管理方式。

内部数据、代码和文档高度透明。 员工，且不仅仅是工程师，通常可以访问实时业务指标和数据源，编写自己的查询，并创建自定义报告。

工程师能够接触业务和业务指标。 公司鼓励工程师与其他部门互动，并与非工程职能建立联系。相比之下，传统公司往往会阻碍开发人员与其他业务部门直接沟通。

工程师之间倾向于点对点沟通。 传统公司更鼓励层级式沟通，而这会减慢信息流动，并降低决策速度。

公司会投资开发者体验，减少工程师的挫败感。 重视工程师快速解决问题的公司，往往会建立平台团队和内部工具团队，从而降低开发摩擦，也减少开发者流失。

更高的薪酬来自更高的杠杆。 那些能够高效利用工程师能力的公司，通常愿意支付接近甚至高于市场顶端水平的薪酬。

人才密度更高。 这些公司之所以能吸引并雇用能力强、积极性高的人才，正是上述因素共同作用的结果。由于它们以优厚薪酬和良好职业发展机会闻名，因此拥有庞大的人才池可供选择。

拥有充分授权和自主权的团队，是这类公司的基石，也是科技行业中许多公司之间的关键差异。

当然，大型科技公司内部并不是所有团队都能获得充分授权。但这些组织，以及一些具有前瞻性的初创公司，通常最接近于真正落实“最大化团队授权”的理念。

职责清晰的团队 是大型科技公司的另一项基础。每个由 5 到 15 人组成的团队，通常都有明确的愿景、使命，以及实现这一愿景所需的技能和自主权。例如，一个酒店产品团队的使命可能是：“为老年人打造世界一流的预订体验。” 一个产品平台团队的使命则可能是：“帮助各团队以近乎零成本的方式集成评分体验。”

以产品为中心的团队通常是跨职能团队，成员可能包括后端工程师、前端工程师、移动端工程师、产品经理、数据科学家和设计师。而以平台为中心的团队，往往不一定跨职能，也不一定局限于某个具体业务领域。

值得注意的是，尽管大型科技公司中的工程师会有高度专业化分工，但大多数资深软件工程师仍被期望能够承担范围较广的工程工作。面试流程也体现了这种偏通才的取向。

产品经理、项目经理与工程团队的分工

大型科技公司与许多其他公司的另一个重要区别，在于产品经理的角色，以及团队层面通常没有专职项目经理或产品负责人。

在这些公司中，产品经理负责定义团队战略，也就是“为什么做”；同时也参与明确执行战略的路径，也就是“如何做”。正如某海外大型社交平台公司的一位产品经理所说：

产品经理的职责，是弄清楚我们要玩哪场游戏，以及我们要如何赢下这场游戏。战略，就是选择我们要玩的游戏。它意味着找到值得投入的领域，并为如何赢得这场游戏提出一个有吸引力的愿景。执行，则是我们如何玩这场游戏。它指的是为了实现使命而采取的日常流程、决策和行动。

产品经理要确保团队始终聚焦在正确方向上。这意味着他们需要与业务团队、数据科学团队和设计团队合作，制定产品路线图、创建计划、确定优先级，并在必要时向上沟通。在大公司中，这本身就是一份全职工作。

在大型科技公司，产品经理通常并不负责项目管理。项目执行由团队负责，而团队负责人，通常是工程经理，则负责确保执行落地。

在充分授权和具备自主权的团队中，项目管理很少是自上而下的。每个团队情况都不一样，但我发现，让工程师轮流担任项目负责人非常有效。这有助于团队中的每个人提升领导力。订阅用户可以访问作者的《项目负责人期望》文档，这份文档已被许多团队借鉴并取得了不错效果。

缺少专职项目经理也会引出几个问题：工程师是否承担了过多项目管理工作？让工程师管理项目，是否是对工程师时间的有效利用？这些担忧都有一定道理。我的看法如下。

对于团队级项目，没有专职项目经理反而能简化流程，并加强团队成员之间的联系。 工程师项目负责人会尽可能减少流程，因为这符合他们自身利益。在与其他同样没有项目经理的团队合作时，他们也会直接与负责项目或产品的工程师建立联系。这种工程师之间的直接沟通，通常比通过多个项目经理层层转达更高效。

对于涉及多个团队、跨办公室、跨时区的复杂项目，领导这类项目对工程师来说几乎会变成一份全职工作。 大型科技公司会聘请技术项目经理来管理这些复杂且通常具有战略意义的项目，从而减轻工程师负担。

大型科技公司内部仍然存在专门的项目经理或项目主管。 他们通常负责面向外部的承诺和客户，例如大型合作项目中的项目经理；或者负责长期项目，例如合规项目。与技术项目经理不隶属于单一工程团队类似，这些项目经理或项目主管通常也没有固定对应的工程团队，而是与多个团队协作。

简单来说，大型科技公司中的简单项目通常由工程师负责，复杂项目则由技术项目经理负责。专职项目经理也可能负责长期项目或对外承诺较强的项目。

某海外大型社交平台公司的一位产品经理曾经精辟概括过：大型科技公司的产品经理角色，与许多公司中的项目经理或产品负责人，有着明显不同。

以产品为中心的环境，以及为什么放弃 Scrum

我在某海外老牌通信产品团队工作时，亲眼见证过一个 Scrum 团队彻底放弃 Scrum 的过程。

我刚加入该通信产品的 Web 团队时，我们采用两周一个迭代周期，并遵循标准 Scrum 流程。团队中既有软件工程师，也有专注质量保障的工程师，后者在公司内部被称为 SDET，即软件开发测试工程师。我们的发布周期是两周，但我们希望能更频繁地发布。

我们做的第一件事，是将质量保障真正纳入工程团队。在“旧模式”下，工程师完成开发后，会将代码提交到分支，更新问题单，并通知 QA 团队该问题单已准备好审核。QA 团队通常一两天后才会处理，进行验证；如果发现问题，再重新打开问题单。这带来了明显延迟。

于是，我们悄悄做了一项非正式调整：所有 SDET 都参与生产环境软件开发，所有软件工程师也都负责测试自己的代码。这样一来，我们不再需要等待数天才能获得反馈并推进发布。然而，双周迭代和繁琐的 Scrum 流程很快又成了新的瓶颈。

Scrum 阻碍了日常交付。 Scrum 的核心是迭代开发：在迭代开始时承诺任务，在迭代期间完成这些任务，并在迭代结束时演示成果。

对于一个快节奏的 Web 开发团队来说，这一流程显得很不自然，像是从外部强加进来的。我们很快转向更灵活的工作方式，采用类似看板的方法。我们不再关注迭代周期，也放弃了 Scrum 的大部分仪式。我们只关心两件事：现在正在做什么，以及接下来最该做什么。

基础设施和开发工具的完善，让许多 Scrum 仪式不再必要。 Scrum 仪式，例如向产品负责人演示、由产品负责人验收工作并最终交付，通常基于几个前提：

• 产品负责人是唯一能够判断工作是否符合规范的人。
• 产品负责人撰写规范，因此也由他们验证规范。
• 在最终验收完成之前，工作成果不会交付到生产环境。

但在我们的环境中，这些假设往往并不成立。我们编写的所有代码都有单元测试，必要时还有集成测试和端到端测试。我们通过功能开关发布代码，并分阶段验证，首先面向团队内部发布。许多“规范”或“问题单”也由工程师自己编写，因此工程师同样可以验证实现是否符合预期。持续集成与持续交付、功能开关和实验工具，为我们提供了比依赖产品负责人更快的反馈周期。

许多大型科技公司已经意识到，一流的基础设施和开发者工具会显著影响工程团队生产力。正因如此，这些公司通常会有 30% 到 40% 的工程师在平台团队工作。这也是许多海外大型科技公司大力投资平台团队的原因。有了现成且高质量的基础设施和平台，团队就能专注于核心目标，而无需花大量精力搭建基础设施或确保服务符合各项要求。

我对平台团队有过这样一些看法：

平台团队能够提升组织效率。
在快速增长和规模化阶段，平台团队至关重要。
然而，建立平台团队并不容易。从商业角度看，平台团队似乎没有直接意义。确实，对于小型组织，或者那些增长缓慢且现有结构运转良好的组织而言，平台团队可能没有必要。

团队中的每个人都非常清楚我们正在构建什么。我们的最终目标是发布某通信产品的 Web 功能。虽然这个目标由多个子项目组成，但团队整体目标很清晰。产品经理帮助我们制定高层战略，而工程师负责具体执行并全力推进。我们拥有足够自主权，可以逐步剔除 Scrum 中阻碍前进的部分。过了一段时间，剩下的流程已经完全不再像 Scrum 了。

超越 Scrum：大型科技公司的真正挑战

在与一些海外大型科技公司和知名互联网公司的工程师交流时，我发现他们中的大多数人从未使用过 Scrum。为什么？原因大致如下。

能力强且自主性高的人，不需要太多结构化约束，也能稳定产出高质量成果。 大型科技公司有能力吸引、承担并雇用这类人才。

充分发挥团队才能的关键，是赋予团队选择工作方式的自主权。 这一点适用于大多数工程领域。许多高绩效团队，尤其是拥有高素质人才的团队，最终都会趋向于类似“臭鼬工厂”的模式：高度自主、少官僚、重执行。

扩展工程组织，远不只是优化团队层面的流程。 这也是为什么大多数大型科技公司不会推行繁琐团队流程的另一个原因。这并不是说这些组织没有生产力挑战，而是说，大多数挑战并不能靠繁重流程解决。

这些公司真正需要应对的挑战包括：

开发者效率。 如何让工程师把更多时间用于编写真正推动团队目标的代码，而不是被基础设施问题或依赖问题困住？平台团队模式有所帮助，但这个话题还有很多值得深入讨论的地方。

偿还技术债和架构债。 所有大型科技公司都行动迅速，会快速响应新机会。但在这一过程中，公司常常走捷径，导致技术债和架构债积累。如何以合理方式将债务偿还融入日常运营，而不是每次都启动“大爆炸式”的技术债偿还项目？

与组织目标匹配的团队结构。 公司及其下属组织的目标经常变化。团队结构如何反映这些变化，同时尽量减少对团队凝聚力的干扰？

为创新和突发工作留出空间。 对那些被期待持续创新的团队来说，如何创造足够空间，让创新真正发生？

随着工程组织壮大，如何继续保持高效。 工程师越多，沟通成本越高，制定影响大多数工程师的决策也越困难。当组织规模翻倍后，如何仍能保持原有速度？哪些流程和结构选择，能让团队在不同规模下都保持敏捷和快速行动？

持久卓越。 如何在提升整个组织效率的同时，让工程师保持愉悦的工作状态，并让改进长期持续、产生复利？“持久卓越”这一概念来自某位海外工程管理作者关于高绩效团队的文章。

为 Scrum 辩护：哪些团队适合采用 Scrum

既然大多数大型科技公司都没有采用 Scrum 和其他类似方法论，是否意味着其他公司也应该效仿？这样想是错误的。

在许多情况下，转向 Scrum 是非常合理的，并且能显著提高生产力。前面提到的某海外老牌通信产品就是一个例子：这种转型确实帮助了公司。而无论它采用什么方法，那个新兴即时通信产品很可能仍会赢得消费者即时通信市场。

以下几种情况下，Scrum 可能是一种不错选择。

1. “什么都要接”的大杂烩团队

这类团队通常会发现，采用 Scrum 这样相对重量级的流程来管理利益相关者，是明智之举。

Scrum 能帮助利益相关者理解：正在进行的迭代不应被随意打断，新功能需求需要先进入梳理流程。由于迭代结构允许团队暂时忽略外部干扰，那些面临多个优先级冲突的团队，也能在更少干扰下推进工作。

“什么都要接”的团队在非科技公司中很常见，因为业务部门往往不了解工程团队如何运作。Scrum 可以帮助约束利益相关者，让他们理解软件开发流程，同时给工程团队留出执行空间。这种团队模式在早期创业公司中也很常见，因为公司通常只有一个工程团队，要负责所有功能开发。

在大型科技公司中，当产品团队承担过多职责时，也偶尔会出现这种“什么都要接”的团队。此时，转向 Scrum 这类能为团队争取空间的流程，通常是合理的。不过，由于这些团队往往拥有自主权和授权，它们也可能选择更新团队章程，让团队成员能够立即拒绝不属于团队职责范围的工作。

2. 新团队的形成期和冲突期

有心理学研究者提出过“形成期、冲突期、规范期、执行期”这几个阶段，用来描述团队发展过程。这个模型同样适用于大多数工程团队。

当新团队刚刚组建时，团队需要决定如何协作。与其让彼此尚不熟悉的团队成员从零开始制定流程，甚至完全没有流程，采用一套现成且规范化的 Scrum 方法，通常是更好的起点。如果团队成员对于“正确的工作方式”存在冲突或不兼容的意见，采用 Scrum 这样文档完善的方法也会很有帮助。

Scrum 的一个优点是，它将回顾会议内置在流程中。这使团队能够持续反思自己的工作方式。随着时间推移，那些拥有自主权去调整流程的团队，通常会逐步放弃自己不需要的繁重 Scrum 规则，并发展出一套更适合自身的工作方式。

3. 将发布频率从较低水平提升到几周一次

结合数周一个迭代周期，Scrum 能帮助团队提高发布频率，前提是发布周期不短于迭代周期。对于许多非数字优先型组织而言，这种加速本身就是巨大进步。

加快产品交付速度，是前面提到的某海外老牌通信产品在 2012 年转向 Scrum 的主要原因之一。转型前，团队每隔几个月才发布一次产品。转型后，每个团队每月可以发布一到两次。值得注意的是，那些后来交付频率进一步提高的团队，反而放弃了 Scrum，因为当迭代周期变得更短时，Scrum 流程的价值就明显下降了。

4. 需要统一项目进度报告的公司

对于那些将统一项目进度报告视为必要条件的公司来说，Scrum 和某类问题跟踪工具往往密不可分，而这类工具又常被认为是组织层面报告的强大工具。

我见过许多组织引入 Scrum，是因为领导团队希望更清楚地了解各个团队如何运转，并能精准识别哪些团队需要帮助。

统一报告机制，以及深入到团队层面的优先级分析，是某海外老牌通信产品的领导层在转向 Scrum 后看到的诸多好处之一。当时的一位敏捷教练曾分享，他们如何使用“草莓酱计量器”和“错误顺序计量器”。如果没有 Scrum 和相应的项目管理工具，这些做法很难实现。

“草莓酱计量器”用于识别进行中待办事项最多的团队。其灵感来自一条常被引用的管理学类比：“草莓酱摊得越开，就越薄。”“错误顺序计量器”则用于识别那些没有按照产品负责人组织指定的公司级待办事项优先级执行工作的团队。

我个人认为，在拥有充分授权团队的组织中，目标与关键成果（OKR）、关键绩效指标（KPI）以及清晰目标本身，远比为了汇报而强行套用 Scrum 这类僵化方法论更有效。然而，在缺乏授权、团队和个人缺乏自主性的组织中，Scrum 或许确实比其他方法更有效。

如果项目并非纯研发场景，而是涉及市场、销售、交付、运营、人事等多个部门的协作，那么团队也可以选择 Worktile 这类通用项目协作系统，将任务、项目、文档、目标、日历、甘特图、工时和审批等信息集中管理，减少跨部门沟通中的信息断点。

团队项目管理应该如何进行？

我们已经看到，不同发展阶段的公司往往采用不同方式推进项目，而大型科技公司通常不会强制采用单一方法。与此同时，大型科技公司也拥有大量组织层面的支持，使这种灵活性能够顺利运行。

团队项目管理方式应取决于具体情境。相关因素包括组织结构、团队成员、团队自主性、团队技能、竞争对手，以及公司所处环境是“战时”还是“和平时期”等等。

最后，我想留给大家以下几点思考。

迭代式变革通常优于“大爆炸式”变革。 一家欧洲科技公司长期苦于产品交付速度缓慢，于是聘请了一位新的工程副总裁。这位副总裁上任后的头几个月，就决定将整个公司的工作方式改为“无估算”模式。他们举办了一场大型活动，请来摇滚乐队，并隆重推出这一新工作方式。然而，接下来的几周和几个月一片混乱，公司最终又回到了原来的工作模式。

授人以鱼，不如授人以渔。 我的项目管理方法，是指导和培养团队成员，让他们成长为项目负责人。前期确实需要投入更多精力，但最终团队交付更多，成员成长更快，晋升更快，也更早成为工程领导者。在一个授权型环境中，这是我做过的最明智决定之一。订阅用户也可以访问我的相关蓝图文档。

指令式指导、辅导和引导，各有适用场景。 当一个人已经能够独立完成某项工作时，你仍然告诉他每一步该怎么做，那就是微观管理。但当他还无法完成时，这种指导就是支持。你需要根据对象当前能力，选择是直接指导、辅导，还是引导，并给予个人或团队足够空间。随着时间推移，你应该逐渐减少甚至完全停止直接指导。但一开始，你可能确实需要从指导做起。

决策者越少，决策速度越快。 如果一名工程师只需要和另一名工程师沟通就能做出决定，那么决策速度一定快于这样的链条：工程师先找项目经理，项目经理再找另一个项目经理，另一个项目经理再找另一名工程师，如此层层传递。

以报告为导向进行优化，实质上是在为低信任环境优化。 给高管层的报告当然重要。但如果为了报告而推行繁琐的项目管理方法，最终往往只会带来更多流程、更低信任，以及人们对报告机制的钻空子。

咨询顾问往往倾向于提供容易衡量的结果。 因为这是证明他们自身价值最简单的方式。如果这个容易衡量的结果本身就是一个好目标，那么聘请咨询顾问就是一项不错投资。但务必确保这个目标有意义，并且方向正确。

向直接竞争对手学习的价值常常被低估。 了解行动更快的竞争对手正在做什么，并尝试类似策略，是非常明智的做法。与竞争对手中的同行喝杯咖啡，不仅是极好的职业发展和人脉投资，也可能带来真正有价值的启发。

一些最优秀的工程师宁愿辞职，也不愿被过度管理。 尤其是在就业市场火热、跳槽相对容易的时期。我的调查问卷中有一条相关回复是：“最近，高管开始强制规定所有团队的工作方式，要求每个人都遵循同一种方法论。这导致很多工程师离职。”

我的建议是：从他人身上汲取灵感，不断尝试、迭代，最终营造一个高信任、积极向上的工作环境。我自己就是这么做的，并逐渐建立出一套完善的机制，帮助团队中的每个人成长。最终，团队、公司和我自己都从中受益。

常见问题

大型科技公司为什么很少采用 Scrum？

因为许多大型科技公司更强调工程团队自主权、工程师直接负责项目、短周期交付和强大的内部开发者工具。在这种环境下，很多 Scrum 仪式带来的价值会下降，团队往往会选择更轻量、更适合自身节奏的项目管理方式。

Scrum 是否不适合技术团队？

并不是。Scrum 对新团队、职责混杂的团队、发布频率较低的团队，以及需要统一项目进度报告的组织，仍然可能非常有效。关键不在于 Scrum 本身好坏，而在于它是否适合团队所处的组织环境和交付目标。

工程团队应该如何选择项目管理方法？

工程团队应根据团队成熟度、业务复杂度、成员自主性、发布节奏、协作成本和组织信任水平来选择方法。最重要的是，团队应有能力持续复盘和调整流程，而不是被迫长期遵循一种不再适用的方法论。