摘译自Gergely Orosz的文章How Big Tech Runs Tech Projects and the Curious Absence of Scrum,这篇文章写得非常接地气。

调查结果

• 拥有专职项目经理的团队在上市或风险投资的科技公司中的满意度通常较低。
• 团队自主性越高满意度似乎也越高。
• 苦苦挣扎的团队通常用什么方法都解决不了问题。
• 对JIRA 的评价大多带有负面关联。

效果不佳的项目管理方法具有以下几个特点：

• 工程师不参与项目时间估算
• 需求不断变化
• 没有自主权来改变失败的项目管理方法

大型科技公司如何运行项目

• 工程师领导大多数项目：要么是技术主管，要么是团队中的工程师带头。
• 团队可以自由选择他们使用的项目管理方法。许多团队采用类似 RFC 的规划流程，迭代构建，并在几周内交付。其他团队使用更多类似看板的流程，在那里他们处理最高优先级的项目。
• 团队级项目没有专门的项目经理。这些公司中的大多数都有技术项目经理 (TPM)，他们介入涉及多个团队或跨组织的大型项目。在优步，TPM 与工程师的比例约为 1:50。
• 即使在同一组织中，项目管理工件和流程也因团队而异。大多数团队都有项目积压，在团队认为合适的情况下每隔一段时间做一次站立会议，并时不时地进行回顾。
• 在这些地方，一流的开发人员工具是必不可少的，并且在短迭代周期中发挥着重要作用。许多团队在主要分支上工作，从 CI/CD 系统获得快速反馈，并可以立即与其他团队成员共享他们正在处理的功能。

授权和自治的团队是所有这些公司的基石。它们也是科技行业许多公司之间的主要区别。

不需要项目经理

Big Tech 与其他所有人之间另一个奇怪的区别是产品经理的角色，以及缺乏致力于团队的项目经理或产品负责人。

这些公司产品经理的角色是定义团队战略——“为什么”——以及执行该战略的步骤——“如何去做”

产品经理确保团队继续做正确的事情。这意味着与业务、数据科学和设计合作，以构建路线图、制定计划、确定工作优先级并在需要时进行升级。在大公司，这本身就是一份全职工作。

有了授权和自治的团队，管理项目很少是自上而下的练习。每个团队都会有所不同，但我发现在工程师之间轮换项目领导角色方面取得了巨大成功，帮助团队中的每个人增强了他们的领导力。

缺乏专职的项目经理的几个问题

工程师是否对项目管理负担过重？管理项目是否可以很好地利用工程时间？所有这些都是可能的，这是我的看法。

• 对于团队级别的项目，没有专门的项目经理最终会简化流程并加强个人关系。工程项目负责人将尽可能少地添加流程。
• 对于跨越不同办公室和时区的多个团队的复杂项目，领导这样的项目是工程师的全职工作。大型科技公司聘请技术项目经理 (TPM) 来管理这些复杂且通常具有战略意义的项目，从而减轻工程师的负担。
• Big Tech 中仍然存在专门的项目经理或项目经理。它们通常与面向外部的承诺和客户（例如 Apple 合作伙伴关系的项目经理）或长期运行的计划（例如合规计划）相关联。与 TPM 不分配给单个工程团队的方式类似，这些项目经理或产品经理也不倾向于拥有一个工程团队，而是跨多个团队工作。

以产品为中心的环境和放弃 Scrum

Scrum 妨碍了每天的运输。Scrum 的整个想法围绕着 Sprint，在 sprint 开始时提交任务，在 sprint 期间处理这些任务，并演示我们在最后所做的事情。

这个过程感觉不自然，就像是强加给一个快速移动的网络团队一样。我们很快就转向了一种更流畅的工作方式，采用了看板方法。我们不再关心 sprint，并且放弃了 Scrum 带来的大多数仪式。我们只关心知道我们现在在做什么，以及我们接下来要做什么。

在与 Facebook、Whatsapp、Google、Netflix 和类似组织的工程师交谈时，他们中的大多数人从未使用过 Scrum。为什么？这是因为以下几点：

• 有能力、自主的人需要较少的结构来产生可靠、高质量的输出。大型科技公司能够吸引、负担和雇用这些人。
• 通过给予他们选择如何运作的自由来利用有能力的团队。对于大多数类型的工程来说都是如此，并且有充分的理由说明为什么臭鼬工厂的自治模式和减少官僚主义，是许多拥有高素质人才的高绩效团队最终遵循的。

思考:

• 你需要做决定的人越少，你做决定的速度就越快。
• 针对报告进行优化就是针对低信任度环境进行优化。执行级别的报告很重要。但是，如果您推出的项目管理方法为了报告而增加繁重的流程，那么您将获得更多流程、更低的信任度，并且人们会玩弄您试图生成的任何报告。
• 一些最优秀的工程师宁愿辞职也不愿接受微观管理

编者体会:周一,周五都开会去了,哪有时间写代码。居然还有Spring Review prepare这样的会。