大型科技公司都是怎么管理项目的？

来源 ｜ 36kr 

分享 ｜ 领导者养成笔记「ID：GoToLead 」            

对于项目管理这个话题，大多数人都有强烈的观点，我也不例外。为了回答不同公司是如何进行项目管理的，我开始向整个行业寻求帮助。在本期当中，我们将介绍：

• 科技行业的项目管理方法。我们会对涉及 100 多家公司的调查进行概述，并总结关键要点。

• 科技巨头的项目管理。他们是怎么做的？科技巨头的组织设置会如何影响项目的执行方式？

• 科技巨头不用 SCRUM（迭代式增量软件开发过程）。为什么大多数大型科技公司都没有这个流行的框架，这对于不用这种模式运营的公司有什么启示？

• 你的团队应该如何做项目管理？我会分享我的个人看法。

在开始之前，先讲一个本人的故事，来说明为什么有时候很难说清楚项目管理方法的重要性。

Skype、Scrum 以及重要事项提醒

2012 年，当我加入 Skype 时，这家公司已经全方位接受了 Scrum。在一位敏捷宣言创始人的推动下，所有的工程师和产品人员都接受了一流的 Scrum 培训。在几个季度内，Skype 让所有团队都采用了这种方法。

Skype 把朝着 Scrum 的转型看作是一种成功。Windows 的这款旗舰应用的发布频率，开始从每季度发布一次变成了每月发布一次。大多数团队每 2到 4 周就能完成一次交付。团队会轮换敏捷大师（Scrum Master）的角色，敏捷教练也加入进来为团队提供反馈，而刚刚收购 Skype 的微软也表现出兴趣，想从加快交付速度中汲取灵感。

不过，当 Skype 向 Scrum 转型时，一个竞争对手正在无情地推进，这个对手就是 Whatsapp 。虽然 Whatsapp 要小得多，但每个月都在蚕食 Skype 的市场份额，并逐渐变成了领先的通信平台。

与 Skype 不同， Whatsapp 对类似 Scrum 这样的框架从来都不在意。早期员工曾经分享过他们的做法，说他们从来都不讨论这种东西，还刻意无视所有的重量级流程。Whatsapp 在执行上超越了 Skype，开发出比 Skype 更可靠的聊天体验，并最终赢下了聊天与通信应用的战斗。

这个故事提醒我们：公司的成功与项目管理方法的成功未必总是相关的。我不是说项目管理不重要：当然重要。但还有其他一些因素可能会对结果产生更大的影响，比方说关注点、领导方法、即便在没有流程的情况下大家都是怎么工作的，等等。

项目管理是难题的一部分，这个难题很复杂且不断变化。不过，它不是，也不应该是最终目标，而只是更快实现该目标的推动力。

行业的项目管理方法

各家公司都是怎么管理项目的？我进行过一项有 100 多个回复的调查。结果很有趣。

简而言之，公司的项目管理方式是“看情况”。不应该对此感到奇怪。与员工上千、成长缓慢的非科技公司相比，只有 5 人的新生初创企业的成功方式不会一样。就算是大型非科技公司的部门，有些也会尝试新方法，而有的则坚持多年来一直做得不错的同样事情。

不同的公司是怎么管理项目的？调查结果概览。

我根据以下类型对公司进行了分类：

• 上市科技公司：以技术为核心的上市公司。其中很多之前都拿过风投融资。

• 风投支持的扩张期初创企业：拿到 B 轮及以后轮次融资的初创公司。这些公司的估值一般至少为 3 亿美元，而且发展势头迅猛，通常会在几年后 IPO。

• 获风投的初创企业：拿到种子前、种子轮或 A 轮融资的初创企业。这些一般是成长型公司，商业模式还不太成熟。

• 不拿风投的科技公司：未获得风投且未公开交易的成熟型科技公司。这些公司的增长目标往往没有拿风投的那些公司那么激进。

• 大型非科技型公司：不以科技为核心功能的上市公司和私营公司。

• 咨询公司：提供开发服务的公司。

公司在本次调查中使用的方法是：

• 没有“正式”的方法论：这种在上市和拿风投的科技公司当中很常见。

• 计划、开发、交付：在上市和风投型科技公司中很常见。

• Scrum：在大型非科技公司、非风投型公司和咨询公司中比较常见。

• 看板：所有公司都提到过这种方法。

• SAFe （规模化敏捷框架）：大型非技术型公司和非风投型公司提到过。

• Shape Up：少数风投型公司提到过。

这项调查还有一些有趣的发现，其中部分与以下问题有关：“你对当前的项目管理方法满意程度如何，范围在 1（不满意）到 5（非常满意）之间？”

值得思考的洞察如下。鉴于调查在样本量上不具代表性，我建议大家对这些洞察要谨慎些。尽管如此，这些观察结果我本人可以确认。值得思考的洞察如下。鉴于调查在样本量上不具代表性，我建议大家对这些洞察要谨慎些。尽管如此，这些观察结果我本人可以确认。

• 在上市的科技公司或者拿风投的科技公司，拥有专职项目经理的团队的满意度一般比较低。不过，不拿风投的公司和咨询公司那里，部分受访者对项目管理却是非常满意的，并称这些人正是他们满意的理由。

• 在上市的科技公司以及拿风投的扩张期科技公司，允许团队自行选择工作方式更为常见。大型非科技型公司以及小型非风投性公司更有可能要求公司内的所有团队都采用同样的做法。

• 团队自主权和高满意度似乎具有相关性。很多满意度自评为 4 分或 5 分的人都提到了自主、自由和灵活性，并且认为把质量优先放在团队层面是非常好的。

• 团队遭遇困境往往与方法无关。遭遇困境的原因有缺乏远见、优秀工程师离开、缺乏透明度或工具很糟糕等。对于这些团队来说，改变方法论不会有帮助，因为存在更深层次的问题。

• JIRA 被提到的主要都是负相关：JIRA 被提到了 13 次，全都是这种情况。被调查者认为不用 JIRA 也能完成工作。还有，有一家高增长的科技公司最近刚刚 IPO，然后他们开始改用 JIRA。结果，在对工程师进行调查时，对 JIRA 的净推荐值（NPS）为-83。这个数字低得惊人，这意味着 83% 的工程师反对 JIRA。作为对比，我们再看看一家稳定增长的上市科技公司的情况。该公司的工程负责人表示，自己的组织严重依赖 JIRA，并且把它当作自己的知识引擎。从他们的情况来看，一旦组织完全接受之后，JIRA 其实是非常适合大规模协调的。

根据评分为 1 或 2 的受访者的说法，效果不佳的项目管理方法有以下几个共同点：

• 团队原本承诺让工程师参与估算，但最后却没有兑现，这是常见的痛点之一。在我看来，这是让工程师失去动力的最简单办法之一——甚至会导致部分人出走——同时也会让工程师对团队能取得什么样的成就产生错误认识。

• 工程师很难接受需求变更，就算专门的项目经理都很难接受。虽然有些团队确实会面临需求变化很大的情况，但在这些团队里，最后做项目，处理需求变更的往往是工程师。如果专职项目经理不能保护团队免受需求变更影响，受访者就会认为这种项目管理方法很糟糕。

• 如果项目管理的办法是失败的，但团队没有改变做法的自主权的话，他们的满意度也会比较低。这种类型的回应一般出现在要求所有团队都遵循相同做法的公司里面。这是命令式领导方式的一个例子，虽然这种方法对于几乎不需要创造力的角色比较适用，但用这种做法很难建立起一支高绩效的软件工程团队。如果团队可以自行迭代，并按照自己的方式改变工作流程时，满意度和生产力就会提高。

大型科技公司是如何管理项目的

大型科技公司执行技术项目的方式上有所不同。我找了一些知名的上市科技公司的人，跟对方交流，收集了相关数据。以下是他们完成工作的惯用方式：

科技巨头如何执行工程项目。常用方法：由于每支团队都可以自行选择工作方式，因此每个工程团队采用的方法可能会有所不同，甚至不同的项目都不一样。

科技巨头的工程师在项目执行方式上有以下几个特征：

大多数项目都是由工程师领导：要么是技术主管，要么是团队有一位工程师牵头。

• 团队可以自由选择他们采用的项目管理方法。很多团队采用类似 RFC （Request for Comments，征求意见）的规划流程，迭代开发，并在几周之内交付所有内容。有的团队采用的流程更类似于看板，用来处理最高优先级的项目。

• 团队级项目没有专职项目经理。这些公司大多都有技术项目经理（TPM），这些 TPM 会介入涉及多支团队或跨组织执行的大型项目。在 Uber 这里，TPM 与工程师的比例大约是 1:50 。

• 即便是在同一家组织里，项目管理工件和流程也会因团队而异。大多数团队都会有项目积压，在团队认为合适的时候会定期举行站立会议，还会时不时对项目进行复盘。

• 在这些地方，一流的开发者工具是必须的，而且在较短的迭代周期里面它们也发挥着重要作用。主分支有很多团队在做，他们会从 CI/CD 系统获得快速反馈，并且可以马上与其他团队成员共享自己正在开发的功能。

对于曾在大型科技公司工作过的人来说，这其中大部分的内容应该都很熟悉了。不过，如果你试图到一家更传统的公司复制同样的方法，很可能会失败。这是因为大型科技公司的组织结构极大地影响了团队可能以及实际的执行方式。

科技巨头的组织结构对项目管理的影响

为了了解大型科技公司是如何管理项目的，我们不妨退后一步，看看这些公司大部分是什么样的运营环境。

• 软件工程师和团队的自主权。传统公司开发者的期望是完成分配的工作。在类似硅谷的公司里，开发者的期望是解决业务存在的问题。这是一个巨大差异，影响着每一位工程师的日常生活。

• 好奇的问题解决者。积极进取的工程师的影响力可以轻易就达到数倍于“工厂工人”的效果，因为后者只做安排给他们的事情。如果一个组织的员工态度比较像工厂的工人，在方法上就会偏向于更重量级的项目管理方法，故意留下很少的解释空间。

• 内部数据、代码以及文档透明度。员工（不仅仅是工程师）一般都可以访问实时的业务指标以及数据源，编写自己的查询并创建自定义报告。

• 可以接触业务和业务指标。鼓励工程师与企业的其他部门互动，并与非工程师建立关系。相比之下，在传统公司，开发者往往不大可能与其他部门互动。

• 工程师之间往往是三方沟通的方式。传统公司鼓励层级沟通，这会减缓信息的流动，并导致决策速度变慢。

• 投资于不那么令人沮丧的开发者体验。对工程师解决问题很在意的公司会迅速建立各种平台团队，从而减少开发者体验的流失。

• 用更高影响力证明更高薪水的合理性。工程师利用得好的公司可以开出接近市场顶薪或高于市场顶薪的薪水。

• 所聘用人才的素质。综合上述种种因素，这些公司雇用的是高素质、积极性高的人。他们的人才池底子很厚实，因为公司以丰厚的薪酬待遇和可观的职业发展机会而闻名。

获得充分赋权和自主性的团队是所有这些公司的基石。这也是科技行业的公司之间的关键区别。

虽说并不是大型科技公司的所有团队都能获得充分授权，但这些组织，还有具有进步思维的初创企业，他们最有可能实施确保团队尽可能获得赋权的做法。

有明确所有权的团队是科技巨头的另一个建构块。每一支 5-15 人的团队都会有自己明确的愿景和使命，并且具备执行的技能和自主权。对于酒店产品的产品团队来说，他们的使命可能是“为老年人打造世界级的预订体验”，或者对于产品平台团队来说，他们的使命可能是“让团队几乎不费吹灰之力即可整合评级体验”。

产品导向的团队往往由跨职能的团队成员组成，比方说包括后端开发者、前端开发者和/或移动工程师，团队成员往往还有产品经理、数据科学家和设计师。平台导向的团队往往不是跨职能的，或者与特定领域有关。

请注意，尽管工程师具备高级的专业知识，但在科技巨头这里，他们对大多数经验丰富的软件工程师的预期是，应该能选择范畴很广的工程工作，而且他们的面试过程也体现出这种对通才的要求。

产品经理：是，项目经理：否

科技巨头与其他公司还有一个奇怪的区别，那就是他们有产品经理这个角色，但是没有专门为团队服务的项目经理或产品负责人。

在这些公司，产品经理的角色负责定义团队的战略——也就是“为什么”，以及执行该战略的步骤——也就是“怎么做”。正如 Facebook 的产品经理 Will Lawrence 所说那样：

产品经理的角色是弄清楚我们在玩什么样的游戏，游戏应该怎么玩。战略就是选择我们玩什么游戏。战略就是寻找值得投资的领域，并为我们如何赢得这场游戏创造一个令人信服的愿景……执行是我们玩游戏的方式。执行是我们为实现使命制定的日常流程、做出的决策和行动。

产品经理确保团队继续做对的事。这意味着要与业务、数据科学以及设计合作，设计路线图、制定计划、确定工作优先级，并在需要的时候向上反映问题。在大公司，这本身就是一份全职工作。

在很多情况下，科技巨头的产品经理并不负责项目管理。团队负责执行，团队的负责人（一般是技术经理）会负责实现这一目标。

对于获得赋权和自主权的团队，管理项目很少是自上而下的。每个团队都会有所不同，但我发现，在工程师之中轮换项目领导角色取得了巨大成功，这可以帮助团队的每个人增强领导力。

缺乏专职项目经理会引发几个问题。工程师负责项目管理会不会超负荷？管理项目对于工程师来说是不是时间最好的利用方式？在我看来，所有这些都有可能存在问题。

• 对于团队级的项目而言，没有专职项目经理最终可简化流程，并加强个人关系。工程项目负责人会尽量少引入流程，因为这符合他们的利益。当与其他团队合作时（也是在没有项目经理的情况下），他们还将为其他工程师领导项目或拥有产品建立关系。这种工程师与工程师之间的沟通要比同时通过多个项目经理进行沟通更有效。

• 复杂项目往往涉及多个办事处和时区的多支团队，领导这样的项目将是某位工程师的全职工作。科技巨头会聘请技术项目经理（TPM）来管理这些复杂的，而且往往是战略性的项目，从而减轻工程师的负担。

• 科技巨头里面仍然存在专职的项目经理（Program Managers 或 Project Managers）。这些角色主要与面向外部的承诺和客户（比方说负责苹果合作伙伴关系的项目经理）或长期计划（比如合规计划）有关。就像 TPM 不会分配给单支工程团队一样，这些项目经理或产品经理也一般不会有自己的工程团队，而是会跨多支团队工作。

大型科技公司如何管理项目。简单项目一般由工程师领导。复杂项目一般由技术项目经理牵头。专职项目经理也可能会负责时间更长的计划。

Facebook 产品经理 Ben Erez 的下面这条推文总结了科技巨头的产品经理角色与公司的项目经理或产品负责人的不同之处：

当产品经理已经超过1年，我一条工单/任务都没创建过。这里的产品经理的关注重点是愿景、战略与合作关系，没那么关心项目管理和任务。这样很好。

以产品为中心的环境以及弃用 Scrum

在 Skype 工作时，我亲眼目睹了 Scrum 团队是如何从入手到放弃的。我刚加入 Skype for Web 团队时，我们一开始进行了为期两周的 sprint（编者注：Scrum 项目管理方法的一个常规、可重复的、较短的工作周期），并且是按照惯常的 Scrum 流程走的。我们也有软件工程师以及专注于 QA 的工程师，叫做测试开发软件工程师，或者在微软内部叫做 SDET。不过，我们的交付速度是每两周一次，但我们希望加快交付速度。

我们做的第一件事就是让 QA 成为工程的一部分。在“旧世界”里，工程师会完成自己的工作，检查自己的分支，更新工单，然后让 QA 知道自己已经准备好，可以接受审核了。QA 会在一两天后拿到这张工单，对工程师的工作进行审核，如果发现问题，就重新打开这张工单。整件事情拖得很长。

我们悄悄做了一个非官方的改变，那就是让所有的 SDET 也开发生产软件，这样所有的软件工程师都要测试自己的代码了。现在，我们不再需要花几天的时间等待反馈，然后再将代码交付生产了。不过，两周一次的 sprint 以及无数的 Scrum 仪式又成为了下一个问题。

Scrum 每一天都会妨碍我们的交付。Scrum 的整个想法都是围绕着 sprint，开始阶段提交任务，在 sprint 期间处理这些任务，并在最后阶段演示我们所做的事情。

整个过程感觉很不自然，就像是将任务强加到一支原本行动快速的 web 团队身上一样。我们很快转向了一种更流畅的工作方式，也就是看板。我们不再关心 sprint，并放弃了 Scrum 附带的大部分仪式。我们只关心是不是知道我们现在正在做什么，以及我们接下来要做什么。

基础设施和开发者工具消除了对许多 Scrum 仪式的需求。Scrum 的一些仪式，比如向产品负责人演示、签发工作然后交付什么的，基于的是以下一些假设：

• 产品负责人是能够可靠地验证工作是否符合规范的人。

• 规范是产品负责人编写的——因为是他们在验证这一点。

• 在签字完成之前，工作不能交付给生产。

可是，在我们的环境下，这些假设往往存在缺陷。我们写的代码全都是进行过单元测试的，而且在需要的时候都会做集成测试和端到端测试。我们采用功能标志（feature flags）技术发布代码，并用分阶段推广来验证，而且从面向团队试运行开始。许多“规范”——或工单——也是由工程师编写的，这些人可以验证它们是否按预期工作。与依赖产品负责人的做法相比，CI/CD、功能标志以及实验工具让我们的反馈周期更短。

许多大型科技公司已经认识到，一流的基础设施和开发者工具对工程团队的生产力会产生怎样的重大影响。这就是为什么 30-40% 的技术人员经常在平台团队工作，这也是 Uber 对平台团队投入很大的原因。借助随时可用的一流基础架构和平台，团队可以专注于自己的核心工作目标，而不用弄清楚如何设置基础设施，或者如何让服务兼容。我对平台团队的部分看法如下：

平台团队提高了组织效率……当你在扩张和快速扩张时，这种团队是必不可少的……不过，这样的团队要想部署到位却没那么简单。从商业角度来看，平台团队没有什么意义。当然了，平台团队对小型组织毫无意义，或者对于那些增长不大而且结构良好的组织也没多大用处。

团队的所有成员都非常清楚我们在开发什么。我们的最终目标是发布 Skype 的 web 功能。这种做法由几个子项目组成，但团队对大局都很清楚。产品经理帮助从较高层面制定了战略，我们的工程师则接手要完成的工作。我们获得了充分赋权，把妨碍我们前进的 Scrum 要素给剔除了出去。慢慢地，剩下的流程根本就不能代表 Scrum了。

超越 Scrum

在与 Facebook、 Whatsapp 、Google、Netflix 以及类似组织的工程师交谈时，大部分人从来都没用过 Scrum。为什么？因为以下几点：

• 有能力、自主性强的人不太需要结构来产生可靠、高质量的输出。而大型科技公司既可以吸引这样的人，也能雇得起、养得起这些人。

• 通过让团队自由选择管理方式来利用高影响力团队。大多数类型的工程都是这样的。为什么许多拥有高素质人才的高绩效团队最终会采用臭鼬工厂式的自治？这是有充分理由的，这种模式减少了官僚主义。

扩充工程组织要经历的流程远远超出团队级流程的范畴，这是大多数大型科技公司都不主动去推动重量级团队流程的又一个原因。这并不是说这些组织在生产力方面没有遇到挑战，但那些挑战中大部分都不是重量级流程可以解决的挑战。这些公司面临的挑战包括：

• 开发者的生产力问题。工程师怎么才能花更多时间去写代码，好实现团队的目标，而不是陷入到基础设施问题或解决依赖关系问题？

• 偿还技术债务和架构债务。所有大型科技公司都在快速行动，并对新机遇迅速做出响应。但这种思路使得公司经常走捷径，导致留下技术债务和架构债务。怎么用合理的方式偿还这笔债务？让偿还债务成为日常流程的一部分，而不是非得搞一个“一次性”的技术债务偿还项目？

• 与组织目标相匹配的团队结构。公司和子组织的目标会不时发生变化？团队结构如何反映出这些变化，同时尽量减少对团队凝聚力的破坏？

• 要为创新和意想不到的工作留出闲置时间。对于预期要进行创新的团队，如何制造空闲时间来实现这一目标？

• 工程团队规模不断壮大，该如何跟上步伐。公司的工程师越多，沟通或做出影响大多数工程师的决策所需的开销就越大。在规模翻倍后，组织怎么才能保持跟原先一样的速度？有哪些与组织规模无关的流程和结构选择可以让团队保持敏捷和快速行动？

• 保持卓越。整个组织如何才能提高吞吐量，同时工程师也能保持快乐，改进如何才能持续足够长的时间来产生复合效应？

  
  

为 Scrum 辩护

就因为大多数大型科技公司都放弃 Scrum 等做法，是不是其他公司也得放弃类似做法？未必。

在许多情况下，换成 Scrum 还是非常有意义的，而且会带来生产力的提升。Skype 是一个例子，换用 Scrum 确实帮助了公司。其实不管 Skype 用了什么方法，消费级呼叫市场还是要被 Whatsapp 拿下的。

以下这几种情况 Scrum 可以成为不错的选择：

1. 对于别人把什么东西都扔给自己的“万金油团队”（kitchen sink teams，别人把什么东西都扔过来，什么都得做的团队）来说，往往会发现用像 Scrum 这样的重量级流程来管理利益相关者是一种好用的技巧。用了 Scrum 之后，利益相关者将接受教育，他们将会明白， sprint 是不能中断的，而且他们提出的功能请求需要整理。由于 sprint 这种结构为团队提供了无视这些干扰的空间，所以存在优先级冲突的团队可以在更少的干扰下执行任务。

在企业不了解技术运作方式的非科技型公司这里，“万金油团队”恰恰是典型代表。Scrum 可以帮助控制利益相关者，并对他们开展软件开发过程的教育，同时还可以为工程团队提供执行的空间。这种团队在早期创业公司当中也很常见，所有东西都得靠一支技术团队去做。

科技巨头偶尔也会有“万金油团队”，一般是在产品团队承担了过多责任的时候。不管是什么情况，转移到像 Scrum 这样的流程还是有意义的，因为这可以为团队提供喘息的空间。不过，由于团队获得了赋权，有自己的自主权，他们往往会更新自己的团队章程，因此团队成员对于不是自己的工作可以马上说不。

2. 新团队的“组建”和“风暴”阶段。心理学家布鲁斯·塔克曼（Bruce Tuckman）用 “形成、风暴、规范和执行”（orming, storming, norming, and performing） 的概念描述了一个团队在一个项目中所经历的心理发展的四个阶段。这个模型对大多数技术团队都适用。

组建新团队时，需要决定工作方式。相比较于彼此不熟悉的团队成员提出自定义流程，或者根本就没有流程，用像 Scrum 这样的现成方法几乎总是更好的选择。如果团队成员对什么是“正确的工作方式”有互相冲突的、不兼容的意见，那么用像 Scrum 这样有据可查的方法也很有用。

Scrum 的好处在于复盘是整个流程的一部分。复盘可以让团队反思自己的工作方式。慢慢地，可以自主改变工作风格的团队通常最终会放弃不需要的重量级的 Scrum 规则，然后形成定制的工作风格。

3. 将交付频率提高到每几周一次。Scrum 加上为期数周的 sprint 可以帮助团队提高交付频率（但不能超过 sprint 的频率）。对于许多非数字优先的组织来说，这种类型的加速就已经是巨大胜利了。

加快交付速度是 Skype 在 2012 年转用 Scrum 的主要原因之一。在过渡到 Scrum 之前，团队每隔几个月才交付一次。用了 Scrum 之后，每支团队做到了每月交付一到两次。请注意，对交付频率要求更高的团队最终还是决定放弃 Scrum，因为缩短 sprint 周期对这个流程没有意义。

4. 必须有统一的项目进度报告的公司。Scrum 和 JIRA 往往是一起出现的，没有比 JIRA 更好的组织级报告工具了。我观察到许多组织在引入 Scrum 时，均期望领导团队对团队有更多的了解，并能够发现需要帮助的团队。

统一的报告，优先级能深入到团队级别，这也是 Skype 领导层在转向 Scrum 后看到的好处之一。当时在 Skype 担任敏捷教练的 Chris Matts 分享过他们是如何实施 Strawberry-Jam-O-Meter （用来识别积压事项最多的团队的报告）以及 Wrong-Order-O-Meter（用来识别处理顺序不对的团队）的，如果不是所有团队都用 Scrum与 JIRA 的话，这是很难做到的：

Strawberry-Jam-O-Meter 用来识别积压事项最多的团队。灵感来自 Jerry Weinberg 的‘草莓酱定律’（果酱涂的面积越大，就会变得越薄）。Wrong-Order-O-Meter 则是用来识别处理事项的次序不对的团队。

我个人的观点是，如果组织给团队赋权的话，相较于为了报告而推出像 Scrum 这样的死板做法，用目标和关键结果（OKR）、关键绩效指标（KPI） 来协调团队要好得多。不过，如果组织不给团队赋权，也就是团队和个人没有自主权的话，Scrum 可能比其他方法更有效。

应该如何管理团队？

我们已经看到处于不同阶段的公司往往会用不同的方法来管理项目，而大型科技公司通常不要求采用单一的方法，不过大公司有很多组织性支持来让这个过程发挥作用。

该如何管理团队要取决于你的背景。相关因素包括组织结构、一起工作的人员、这些人的自主权和技能、竞争对手，现在是 “战时”还是“和平时期”等等。

以下一些想法我会留给你作为思考的食粮。

• 迭代变更往往比“大爆炸”更有效。一家在交付方面非常慢的欧洲科技公司聘请了一位新的工程副总裁。新官上任三把火，此人刚到没几个月就将整个组织转移到 NoEstimates 方法。他们组织了一场大型活动，聘请了一支摇滚乐队，并推出了新的工作方式。结果接下来的几周和几个月完全是一团糟，组织只好让一切都恢复原状。

• 授人以渔需要做的工作要多于授人以鱼。我的项目管理方法是指导和教导我的团队成员成为项目负责人。这种做法前期要做的工作要多很多，但结果是团队交付的东西也更多，人员成长更快，晋升更快，而且与同行相比能更快地成为工程领导者。这种方法是我在赋权环境下做出的最佳决定之一。

• 指导（directing）、辅导（mentoring）和教练（coaching）各有其作用。指导就是准确地告诉别人怎么做某件事，当别人自己能做的时候这就是微管理。但是，当别人不能自己做时，这就是一项支持性活动。要根据你是提供指导、辅导还是当教练来选择你的做法，要给别人和团队留出空间，当然也要看他们的能力。慢慢地，提供指导的情形会越来越少。但是你可能需要从提供指导开始。

• 参与决策的人越少，决策速度就越快。如果工程师只需要与工程师交谈来做出决定，这样的决策速度肯定要比与项目经理交谈，后者再与另一个项目经理交谈，后者又要找另一位工程师交谈，或者再与什么人交谈快得多。

• 在低信任的环境下针对报告进行优化。在执行层的报告很重要。但是，如果你推出的项目管理办法为了拿到报告而增加繁重流程的话，那么流程就会复杂化，信任度会降低，别人会为了生成你想要的报告而想办法作弊。

• 顾问往往会偏向提供容易衡量的结果，因为这是证明自身价值最简单的方法。如果易于衡量的结果是好目标的话，就可以让顾问成为一项很好的投资。只需确保这是一个有价值的目标，并且方向正确。

• 向直接竞争对手学习的好处被低估了。了解行动迅捷的竞争对手正在做什么，并且试着做类似的事情，其实是非常聪明的做法。请竞争对手的同行喝杯咖啡，这可能是一项很棒的专业和关系投资，甚至还会激发你的灵感。

• 最优秀的工程师有的宁愿辞职也不愿被微管理，尤其是在就业市场火爆，而且很容易换工作的时候。我的调查里面就有人回复了这么一句话：“最近，C 阶高管开始规定所有团队都要按照同样的方式工作。这导致很多工程师离开。”

他山之石可以攻玉。我建议从其他人那里获得灵感，不断实验、迭代，营造一个人人受到激励的高信任环境。我就是这样做的，也是按照这样的宗旨来搭建结构，帮助团队的每个人成长的，这是为了三方的利益：团队、公司，也包括我自己。

《领导者管理笔记》读者群开放，如你致力于提升领导力

请加（微信：Tapmadou）进群

@THE END

文章来源 ：领导者养成笔记「ID：GoToLead 」，转载请公众号回复“转载”

版权说明 ：我们尊重原创者版权，除我们确实无法确认作者外，我们都会注明作者和来源。在此向原创者表示感谢。本文所用视频、图片、文字如涉及作品版权问题，请第一时间告知，我们将根据您提供的证明材料确认版权立即删除内容；本文内容为原作者观点，并不代表本公众号赞同其观点和对其真实性负责。