一个人还是一个团队？如何根据技能、依赖关系和风险确定项目的最小配置

研究并不支持 “团队越小越好” 或 “团队越大产出一定越多” 这样的简单规则。

一项发表于 2023 年的元分析汇总了 208 个独立效应和 21,435 个团队。总体来看，团队规模与任务绩效之间的关系接近于零，但不同情境之间存在很大差异。作者指出，任务复杂度和协调需求等因素会改变团队规模所产生的影响。 [4]

另一项针对复杂危机地图任务的实验也同时发现了大团队的收益与成本：随着团队规模扩大，协作增加，但个人投入方式也发生变化。在这项具体实验中，规模最大的团队优于同等数量独立工作的个人。但这并不能被当作适用于所有工作的普遍公式。 [5]

实际结论很简单：人数应由工作的性质决定，而不是由一个神奇数字决定。

2020 年 Scrum Guide 将 Scrum Team 描述为规模较小、跨职能并能自主管理工作的团队。指南还指出，这样的团队通常为 10 人或更少。 [3]

这是 Scrum 情境中的 有用指导，但不是适用于所有项目、服务、行业和交付方式的普遍法律。

建筑项目、营销活动、安全评估、金融系统和小型信息网站的需求完全不同。不能把一个数字直接套用到所有这些情况。

英国 Service Standard 要求数字服务团队具有多学科能力，并能够获得适当范围的技能。它还指出，团队配置应取决于当前阶段需要实现什么目标。 [1]

另一份 GOV.UK 指南说明，团队规模和所需角色会随着服务建设阶段变化。 [2]

由此可以得到一个实用原则：

先梳理工作和责任，再确定所需技能，最后才把这些要求分配给具体的人。

如果项目范围不清楚，就无法合理确定团队配置。

至少写清楚：

• 要产出什么结果，
• 哪些内容属于范围，
• 哪些内容不属于范围，
• 最重要的质量要求是什么，
• 时间和预算限制是什么，
• 谁负责验收结果，
• 团队只需要交付解决方案，还是也要持续运营。

“做一个应用” 与 “设计、开发、保护、部署并运营一个应用一年” 对工作覆盖的要求完全不同。

不要立即填写职位名称，先列出实际必须完成的工作类型。

对于数字服务，可能包括：

• 理解用户需求，
• 设计解决方案，
• 构建用户可见部分，
• 构建服务器端逻辑和集成，
• 测试，
• 安全，
• 无障碍，
• 部署和运营，
• 协调范围与决策。

其他类型的项目会有不同列表。

GOV.UK 指出，构建并运营数字服务的团队需要广泛能力，包括用户需求、设计、构建、测试、安全、部署和持续运营。 [2]

并不是每项所需技能都意味着团队内必须有一位全职人员。

可以把每个领域分成：

持续需要 - 经常使用，并直接影响日常决策。
阶段性需要 - 只在特定阶段或检查点需要。
外部可用 - 如果响应时间和责任足够明确，可以由其他人或其他团队提供。

GOV.UK 明确允许团队在需要时获得专业知识，而不要求专业人士一定是常驻团队成员。 [1]

这种方式经常可以在不失去重要专业能力的情况下，避免人为扩大团队。

两个人合在一起可能拥有全部所需技能，但如果所有工作都排在一条狭窄的依赖链上，仍然可能是糟糕的配置。

检查：

• 哪些任务可以并行，
• 哪些任务必须等待其他任务，
• 谁做出的决定会阻塞后续工作，
• 项目依赖哪些外部团队或供应商，
• 哪些地方一个人的缺席会同时停止多个领域。

GOV.UK 将管理对其他团队的依赖关系列为构建数字服务所需能力之一。 [2]

当多个团队共同负责一项服务时，还需要在团队之间协调计划和进度。 [8]

有些必要的专业能力不会出现在产品功能列表里，但缺少它们可能代价很高。

根据项目不同，可能包括：

• 安全，
• 数据保护，
• 无障碍，
• 法律或行业要求，
• 可靠性，
• 数据迁移，
• 与关键系统集成，
• 团队以前没有使用过的技术。

GOV.UK 建议在项目需要时能够获得专业知识，同时指出团队配置也应反映当前阶段风险最高的假设。 [1]

这并不意味着每一种风险都必须设置一个独立的全职岗位。它意味着 必须有具备相应能力的人承担明确责任，并真正能够影响决策。

一个人可能会设计、开发、测试和部署，但这并不表示他能够在任何期限内同时完成所有这些工作。

PMI 关于资源规划的材料强调，应把技能、可用性、成本和经验与项目需求进行匹配。 [7]

对每个人检查：

• 实际可以投入多少时间，
• 哪些任务会争夺同一个人的注意力，
• 哪些工作必须并行，
• 时间表是否假设了在多种工作之间进行不现实的频繁切换，
• 上线之后是否仍然需要有人运营解决方案。

有技能却没有足够时间，并不等于完整覆盖了项目。

最小配置也应考虑连续性。

问自己：

• 如果关键人员无法工作会怎样，
• 是否只有一个人理解解决方案中的关键部分，
• 决策和知识是否被记录，
• 是否有人可以接替最重要的工作，
• 在人员缺席期间项目能否安全暂停。

不是所有小项目都需要完整备份。在周期短、风险低的项目中，有意识地接受这种风险可能是合理决定。

但在关键项目中，同样的单人依赖可能无法接受。

项目并不需要为每一个角色名称安排一个不同的人。

如果一个人确实具备所需技能、有足够的可投入时间，并且不会造成不可接受的风险，他可以负责任地覆盖多个领域。

例如，在小型项目中，一个人可以同时负责界面设计和实现。在另一个项目中，一个人也可能同时负责业务分析和范围协调。

不要仅仅因为 “总得有人来做” 就把责任合并。只有当一个人能够以所需水平完成两项责任，并且拥有足够时间时，这种合并才合理。

当以下条件同时成立时，一个人可能就是合理配置：

• 范围小且定义清楚，
• 所需技能确实在这个人的能力范围内，
• 任务不需要大量并行工作，
• 外部依赖有限，
• 风险可以接受，
• 期限与实际可投入时间匹配，
• 没有替代人员的风险被有意识地接受。

例如，小型信息内容、简单分析、一次性咨询，或者在熟悉环境中的有限实施。

最终仍然取决于具体范围。仅仅贴上 “小项目” 的标签，并不能自动得出答案。

当以下情况出现多项时，采用团队就更有依据：

• 所需技能范围对一个人来说过于宽泛，
• 许多工作必须并行进行，
• 期限短于现实可行的顺序执行时间，
• 项目有大量依赖关系和接口，
• 风险需要独立专业知识，
• 解决方案必须一边建设一边运营，
• 一个人会成为整个项目的关键单点，
• 责任覆盖多个明显不同的专业领域。

在这些情况下，补齐缺失的能力比单纯增加人数更重要。

增加人员会扩大可用知识和潜在产能，但也可能增加依赖关系、工作交接以及协调决策的需要。

Journal of Systems and Software 上一项关于软件项目的研究发现，团队规模、生产率、工作量和时间之间的关系很复杂，并不总符合直觉预期。 [6]

关于团队规模的元分析同样表明，结果取决于任务情境以及团队协作过程产生的成本。 [4]

因此，正确的问题不是 “还能加多少人？”，而是 “增加的下一个人，是否消除的真实项目限制大于其新增的协调成本？”

并不是每项重要能力都必须每天留在团队中。

常驻参与 更适合这样的情况：这个人经常做决定、其工作与其他领域有大量依赖，或者需要快速响应。

阶段性支持 可能足够用于只在特定时间点需要专业知识的情况，例如审查、咨询、风险评估或专业验收。

有一个前提：可用性必须是真实的，而不是名义上的。应明确：

• 谁负责，
• 什么时候可以响应，
• 预期响应时间是多少，
• 可以做哪些决定，
• 发现问题后要怎样处理。

如果只有“可以联系专家”这样的名义安排，却没有明确责任，在组织图上可能很好看，在真实项目中却未必有效。

假设目标是上线一个在线预约系统。

方案 A：用于验证想法的简单原型
范围有限，没有支付或特别敏感的数据，目标是与一小组用户验证流程。一个能力较全面的人可能能够覆盖设计和实现，并在需要时获得阶段性咨询。

方案 B：包含账户、支付和集成的公开服务
专业化、测试、风险、依赖关系和并行工作都会增加。由多人组成的团队会更加合理。

方案 C：持续运行并要求快速响应问题的服务
除了建设，还需要运营、监控、故障响应和知识连续性。足够支持上线的配置，未必足够支持长期稳定运营。

总体产品类型相同，但 不同范围、风险和运营模式会产生不同的团队需求。

1. 从现成的职位列表开始，而不是从需要完成的工作开始。

2. 默认每个角色都必须对应一个不同的人。

3. 只看技能，不看实际可投入时间。

4. 只加人，却没有减少依赖关系和瓶颈。

5. 因为某些风险能力不会产生可见功能，就把它们忽略。

6. 让多个关键领域依赖一个人，却没有有意识地接受这项风险。

7. 把项目开始时的配置视为直到结束都不能变化。

GOV.UK 明确指出，服务开发的不同阶段会需要不同的团队规模和角色。 [2]

这个原则在公共服务之外同样合理：

• 早期可能需要更多研究和问题定义，
• 实施阶段，交付和测试能力的重要性会上升，
• 上线前，安全、质量和运营准备可能需要更多投入，
• 上线后，开发与运营之间的比例会变化。

最小配置取决于阶段和范围，而不是一个从项目开始到结束都固定不变的数字。

对每个重要领域记录五项内容：

工作领域 - 必须做什么？
技能 - 需要哪些知识和能力？
责任 - 谁做决定并对结果负责？
可用方式 - 这项能力是持续、阶段性还是外部提供？
缺失风险 - 如果缺少这项能力或相关人员不可用，会发生什么？

之后再分配具体人员。

如果一个人覆盖多行，检查其时间和依赖关系。如果一行需要多个人，确认原因是产能、独立控制，还是并行工作。

1. 每一个必需的工作领域都有明确负责人吗？
2. 每一项关键责任都有具备适当能力的人承担吗？
3. 有人承担多个角色吗？其实际时间真的足够吗？
4. 项目是否需要当前配置无法支持的并行工作？
5. 是否已经识别对其他人员、团队和供应商的主要依赖？
6. 重要风险是否能够获得正确的专业知识？
7. 一个人缺席是否可能让整个项目停下来？
8. 如果范围包括上线和运营，当前配置是否不仅能建设，也能完成这些工作？
9. 是否已经确定哪些能力可以阶段性使用，而不需要常驻？
10. 是否设定了在范围或阶段发生变化后重新评估配置的时点？

团队设计不应从这个问题开始：

“这种项目通常需要多少人？”

更好的顺序是：

结果 -> 工作 -> 技能 -> 依赖关系 -> 风险 -> 实际产能 -> 人员。

如果按照这个顺序检查后，一个人确实能够完整覆盖全部需求，那么一个人可能就是正确选择。

如果缺少技能、时间、独立检查、连续性或并行工作的能力，就需要增加人员，或者建立可靠的专业支持。

目标不是最小的团队。目标是能够在所需风险和质量水平下，现实地交付目标结果的最小配置。

[1] GOV.UK Service Standard - Have a multidisciplinary team
打开来源

[2] GOV.UK Service Manual - Set up a service team at each phase
打开来源

[3] The Scrum Guide, 2020 - Scrum Team
打开来源

[4] Bernerth, Beus, Helmuth, Boyd - The more the merrier or too many cooks spoil the pot? A meta-analytic examination of team size and team effectiveness, Journal of Organizational Behavior, 2023
打开来源

[5] Mao, Mason, Suri, Watts - An Experimental Study of Team Size and Performance on a Complex Task, PLOS ONE, 2016
打开来源

[6] Rodríguez, Sicilia, García, Harrison - Empirical findings on team size and productivity in software development, Journal of Systems and Software, 2012
打开来源

[7] Project Management Institute - Solving The Resource Puzzle
打开来源

[8] GOV.UK Service Manual - Running more than one service team
打开来源

方法说明： 部分来源讨论数字公共服务，部分讨论 Scrum Team、项目管理，或者团队与软件开发研究。本指南只在每个来源实际支持的范围内使用其内容。确定最小配置的 7 步方法是对这些原则的编辑性综合，并不是上述任何机构发布的正式标准。