大型科技公司如何推进技术项目为什么许多大型科技公司很少采用 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 本身好坏而在于它是否适合团队所处的组织环境和交付目标。工程团队应该如何选择项目管理方法工程团队应根据团队成熟度、业务复杂度、成员自主性、发布节奏、协作成本和组织信任水平来选择方法。最重要的是团队应有能力持续复盘和调整流程而不是被迫长期遵循一种不再适用的方法论。