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

神译局·2022年07月05日 13:44

公司用什么样的项目管理方式要“看情况”。

神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。

编者按：现代企业正日益以项目为中心开展各种运营，围绕着项目管理也诞生了各种方法论和工具。究竟哪些才是好用的？别人有哪些经验教训？尤其是每天都有大量项目开展的大型科技公司是怎么管理项目的呢？他们的经验对你适用吗？本文予以揭秘，文章来自编译，篇幅关系，我们分两部分刊出，此为第一部分。

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

科技行业的项目管理方法。我们会对涉及 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 不会分配给单支工程团队一样，这些项目经理或产品经理也一般不会有自己的工程团队，而是会跨多支团队工作。