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

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

敏捷与否，关键在人。

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

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

以产品为中心的环境以及弃用 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 阶高管开始规定所有团队都要按照同样的方式工作。这导致很多工程师离开。”