产品型组织如何做好项目管理：跨团队协作、依赖关系与风险控制

理想情况下，产品型组织由一组松耦合、自主协作的团队组成。这些团队能够快速响应用户明确提出的需求，也能够洞察并回应用户尚未清晰表达的潜在需求。

然而，有些业务机会并不能由单一团队独立完成，而是需要多个团队协同交付。如果跨团队项目管理不当，这类机会可能带来收入损失、客户不满以及团队资源浪费。我们将组织为把握这类机会而发起的协调性工作称为“项目”。本文将通过一个失败项目的案例，分享产品型组织在项目管理、跨团队协作、依赖关系管理和风险控制方面的实践经验。

为什么产品型组织中的项目管理如此困难？

采用产品模式运营的组织，通常会建立长期稳定的产品团队。这些团队集构思、构建与运营于一体，围绕持续存在的业务问题开展工作，并持续为客户创造价值。

随着时间推移，这类组织会不断消除价值流中的浪费，逐步形成一种能够减少跨团队协调成本的组织结构，并最终演进出与之匹配的模块化系统架构。采用这种运营模式的组织，通常也会拥有与其技术架构相匹配的组织结构：小型团队各自负责明确的业务领域，维护并运营支撑产品功能或业务能力的系统。

但在现实中，组织有时会遇到一些新的业务机会，需要在多个业务领域同时构建新的能力和功能。这类机会通常必须通过跨团队协作才能真正实现价值。我们将这类工作中的组织协调称为项目管理。

对于产品型组织而言，项目，也就是那些需要多个团队协同才能交付客户价值的工作，往往是一项真正的挑战。原因主要包括：

第一，很难准确识别为了实现项目价值，需要对当前运营模式做出哪些改变。

第二，项目可能会挑战产品团队中常见的自主文化。因为在多个工作流之间开展协作时，项目通常需要一定程度的交付流程标准化。

第三，适用于单一产品团队的领导方式，未必适用于项目层面。在项目层面，多个团队拥有不同优先级，却需要围绕共同目标保持一致并承担责任。

根据我们的经验，产品型组织中既有成功的项目，也有失败的项目。下面这个虚构案例，基于我们在实际工作中遇到的问题，展示了在这类组织中协调跨团队工作的困难。

案例：一家数字优先银行如何推进跨团队项目

海外某家现代金融科技公司成功打造了一家数字优先银行，主要服务于日常交易场景中的个人消费者。作为一家初创企业，该公司一直按照敏捷原则运营，并在发展过程中不断扩展其企业文化和技术架构。

目前，该公司的产品部门约有 200 名员工，组织结构类似海外某些公司所采用的小队模式，由多个小队和团队组成，并与底层模块化产品架构保持一致。

经过数月用户调研后，这家银行意识到，自己已经具备向一个新客户群体——企业客户——提供服务的良好条件。基于这一洞察，公司决定组织相关团队，并计划在数月内推出这项新服务。

公司从现有产品团队中选出了三位负责人来统筹这项工作：一位设计负责人、一位技术负责人和一位产品经理。几个月来，三人共同开展调研、制定计划，并明确第一阶段交付的具体内容，最终形成了最小可行产品（MVP）的用户旅程定义和概要故事地图。

该 MVP 包含一个新的企业账户产品。用户能够以企业客户身份登录，并查看企业账户的交易记录。在确定 MVP 用户旅程后，三人小组识别出需要参与交付的现有产品团队。

这些团队都是公司典型的产品团队：自主、自我管理，并各自拥有成熟的交付方式。有些团队采用结构化敏捷流程，会根据产品路线图拆分史诗和用户故事，并进行估算；另一些团队则更倾向于将目标拆解为较小的任务，并以相对宽松的方式定义和推进工作。

为了维护组织的自组织文化，三人小组选择分别向各个产品团队展示产品愿景，让他们自行决定需要做出哪些改变，才能满足新客户群体的需求。

然而，由于各团队的交付方式并不一致，三人小组无法提前识别每个高层级用户故事背后隐藏了多少依赖关系。项目结束后，为了总结经验，团队开展了一次回顾，试图找出他们所面临挑战的根本原因。以下是他们的发现：

• 运营模式没有根据价值流的变化做出调整。由于三人小组不想挑战自组织文化，交付团队只围绕各自负责的局部客户价值流进行优化，而没有从整体价值流角度进行优化。
• 组织领导层难以及时获取项目进展信息，因此无法有效发挥影响力来帮助项目推进。
• 进度更新主要聚焦于各个交付团队的状态，而不是围绕满足客户需求的整体解决方案展开。这使团队错失了协调和聚焦的机会，也未能充分认识到自身工作对项目整体的贡献。
• 风险管理被视为一项隐性任务，默认由各交付团队自行处理，而不是作为项目层面的明确工作来管理。这导致交付过程中出现了许多意外情况，并影响了交付日期。
• 团队之间缺乏有效的依赖关系管理和跨团队协作，导致交付团队之间产生紧张关系，工作氛围恶化，个人士气也受到影响。
• 项目领导团队没有根据实际情况调整沟通方式。团队和领导层对项目背景与目标缺乏充分理解，却误以为所有人都已经掌握了完成工作所需的信息。
• 由于上述问题叠加，团队整体的积极性和责任感都受到了影响。

产品型组织中项目管理的最佳实践

上述案例虽然是假设情境，却反映了产品型组织在面对跨团队协作和项目型机会时普遍遇到的挑战。本文接下来的部分，将介绍一些我们在类似项目中成功运用过的策略、实践和原则。

从项目启动开始，为成功交付做好准备

项目启动阶段提供了一个天然契机，可以通过一系列重点研讨会，帮助团队和项目为成功交付做好准备。

在项目启动结束时，业务利益相关者和团队成员都应该清楚理解：这个项目是什么，为什么重要，自己在项目中的角色是什么，项目将如何交付，以及首个版本的大致范围是什么。

在项目启动阶段投入时间，是一种有效的风险缓解措施。相比交付日期延误数月后再付出代价，前期对齐显然更具成本效益。我们建议预留时间开展一系列研讨会，以达成以下目标：

• 让所有利益相关者就“需要做什么”以及“为什么要这样做”达成一致，包括对当前运营模式所需做出的任何改变。
• 制定一致的工作方式、协作仪式和最佳实践。
• 将业务背景、技术背景和客户背景传递给所有相关团队。
• 通过明确每个人的角色、职责和动机，在团队之间建立信任。
• 为团队内部形成同理心和相互理解奠定基础。
• 识别交付过程中存在的风险、依赖关系、假设和复杂性。

对于研发团队而言，项目启动后的目标拆解、客户反馈收集、需求清理、评审排期、开发测试、发布上线和经验沉淀，往往需要在同一个管理链路中持续流转。此时，借助 PingCode 这类智能化研发管理工具，可以帮助团队把研发管理过程自动化、数据化和智能化，减少跨工具、跨团队协作中的信息断点。

为实现上述目标，项目启动周的议程可以参考如下安排：

选择适合跨团队项目的领导风格

不同组织的产品部门，其现有文化未必能够自然适应项目交付所需的紧迫感和流程标准化程度。因此，作为解决方案推动者的项目负责人，可能需要根据项目需要调整自己的领导风格。

例如，情境领导模型能够很好地描述不同领导状态下常见的沟通方式。在理想情况下，自组织产品团队的领导者通常会积极参与，并赋能团队成员。然而，项目往往需要改变运营模式，并可能挑战产品团队原有的自组织方式。因此，领导者可能需要调整领导风格，并投入比以往更多的时间来澄清目标、明确方向和建立一致认知。

除了改变沟通方式，项目负责人还需要确保团队对支持新运营模式所需的各项变化承担责任。责任分配矩阵，例如 RACI 矩阵，是沟通责任和问责关系的常用工具。它可以帮助团队成员清楚理解，在维护流程标准、参与关键项目会议以及承担项目职责方面，组织对他们有哪些期望。

认真管理项目依赖关系和交付风险

在项目交付过程中，团队之间的依赖关系十分常见。这种现象也被称为待办事项耦合，因为多个团队需要分别交付同一解决方案中的不同组成部分。

主动管理这些依赖关系的一种有效方式，是在项目交付早期开展解耦活动，尽量降低各团队待办事项之间的耦合度，使团队能够更加自主地交付成果。

例如，为了降低案例中产品团队之间的待办事项耦合，项目团队可以决定在前几个迭代周期内集中精力构建一个“可运行骨架”。如果持续交付能力已经成熟，这个骨架可以部署到生产环境，并通过功能开关控制对外可见性。这样，后续项目进度更新就可以聚焦于骨架的演进：随着各产品团队不断添加更多细节和更深入的功能，这个骨架也会逐步丰满。

下面是一个发布计划示例，展示了骨架构建团队在产品路线图中的位置：

在上述示例中，可运行骨架覆盖了完整的 MVP 用户旅程，但对用户界面精细度的投入很少。此外，所有 API 集成都使用模拟数据进行硬编码。

可运行骨架的目的并不是直接供客户使用，而是帮助产品团队在各自交付待办事项之前，先解决团队之间最基本的耦合问题。同时，一旦可运行骨架搭建完成，所有团队都可以持续集成代码，从而降低后期集成风险。

项目交付过程中还会面临许多其他风险。因此，在正常迭代周期中积极开展风险管理，对项目成功至关重要。主动风险管理并不总是标准产品交付周期的一部分，正如上面的案例所示。因此，领导团队需要保持足够的纪律性，才能在整个交付过程中持续推动风险识别、跟踪和缓解。

制定清晰的项目沟通策略

项目管理中的大量协调工作都发生在沟通环节。沟通的主要目的包括：

• 确保所有相关利益相关者都了解项目情况，并有机会提出问题和疑虑。
• 促进团队间沟通，帮助缓解交付瓶颈。
• 将交付过程中遇到的障碍及时暴露给项目领导团队，使其能够介入并帮助解决。

鉴于项目需要大量沟通，项目领导层应制定清晰而有力的沟通策略，并建立能够满足不同利益相关者群体需求的沟通渠道。例如，一个有效的沟通策略可以如下所示：

用可视化制品提升项目信息透明度

可视化制品，例如实体项目墙，可以成为展示项目信息的重要载体。它不仅有助于关键利益相关者了解项目状态，也有助于整个公司快速获取项目信息。

项目墙起初可能只是一个孤立举措。但如果定期更新，并围绕项目墙展开讨论，它就能逐渐培养新的组织习惯和协作规范。实体项目墙还有一个额外好处：它能够促进团队之间的协作和责任感。此外，项目墙还能帮助公司其他员工在无需预约会议的情况下快速了解项目，并由此激发更多有价值的问题。

在远程协作或多团队并行推进的场景下，实体项目墙也可以被线上协作空间补充或替代。例如，团队可以借助 Worktile 这类通用项目协作系统，把任务、项目、文档、日历、甘特图、审批等信息集中起来，让不同角色都能在同一空间中了解项目状态和推进节奏。

一个项目进度墙可以参考如下结构：

理想的项目进度墙应包含足够信息，使查看者能够一眼了解项目状态。从上面的例子可以看出，攻坚小队已经完成工作并解散，而各交付团队正在推进各自的交付任务。其中某个团队需要帮助，以提前排除未来可能出现的障碍。

为项目管理设立明确角色

我们认为，在任何需要多个团队协作交付价值的项目中，项目管理的规范性对确保成功都至关重要。

当然，具体的角色定义和职责划分取决于组织环境和项目复杂度。因此，我们更倾向于使用“解决方案负责人”这一称呼，而不是“项目经理”。但从根本上说，项目需要有人负责整体健康状况，并持续关注以下战略要素：

• 持续确保各团队之间保持一致。
• 确保团队与外部利益相关者之间沟通顺畅。
• 保持关键项目信息及时、准确、可见。
• 管理项目层面的依赖关系和风险。

务必确保所有相关人员都清楚了解该角色的职责。最好在项目启动会上就明确说明。

我们在产品型组织中引入解决方案负责人时发现，一个常见风险是：产品团队成员和解决方案负责人可能会承担相互重叠的职责，从而降低双方效能。如前所述，解决方案负责人应专注于项目的战略层面，而不是深入接管相关团队的具体产品交付任务。

下面的 RACI 矩阵展示了不同角色之间的职责划分：

注：RACI 中，R 表示负责执行，A 表示最终负责，C 表示被咨询，I 表示被告知。

需要注意的是，解决方案负责人与产品交付领导者、交付团队之间应保持清晰的职责边界。

结论：产品型组织需要有意识地管理跨团队项目

如前所述，一旦组织识别出某个需要跨团队协作的项目，就必须相应调整运营模式，才能真正为客户创造价值。

本文列举了一些有助于项目成功的策略、实践和原则，包括项目启动、领导风格调整、依赖关系管理、风险管理、沟通策略和角色设计。但并不存在适用于所有情境的万能方案。无论你选择采用哪种机制，都应与项目参与者建立有效的反馈循环，以便在必要时持续学习、调整和改进。