如何在产品模式组织中管理项目

在开始时投入时间，为项目成功奠定基础

项目的开始提供了一个自然的暂停点，可以在其中运行集中式研讨会，为团队和项目成功奠定基础。在项目启动结束时，业务利益相关者和团队成员应该了解该举措及其重要性、他们在其中的作用、交付方式以及第一个版本的范围。在像这样的项目启动中提前投入时间是针对数月交付延迟的适当风险缓解措施。我们建议留出时间来运行一系列研讨会，以提供以下成果

• 让所有利益相关者就需要做什么以及为什么要做达成一致（包括对当前运营模式的任何更改）；
• 定义一致的工作方式、仪式和最佳实践；
• 与所有参与的团队分享业务、技术和客户背景；
• 通过明确个人的角色、责任和动机来建立团队之间的信任；
• 为在团队中建立同理心和理解奠定基础；
• 重点关注交付过程中存在的风险、依赖关系、假设和复杂性。

以下是一个旨在解决这些问题的启动会议时间安排示例：

选择适合项目的领导风格

根据组织的不同，产品部门的当前文化可能无法接受程序交付所需的紧迫性和流程标准化程度。因此，作为解决方案倡导者的项目领导者可能会发现，他们需要根据计划的需要调整自己的领导风格。

例如，情境领导模型提供了一种有用的描述，说明了不同领导状态下的一些常见沟通风格（参见侧边栏）。在理想状态下，自组织产品团队的领导者将参与并授权他们的团队。但是，由于该项目可能需要改变运营模式，从而挑战所涉及的产品团队的自组织性质，因此领导者可能需要调整自己的风格，并比平时花更多时间进行澄清和定义。

除了改变他们的沟通风格外，项目领导者还需要让团队对支持新运营模式所需的那些变化负责。一个常用的工具来传达责任和问责制是责任分配矩阵（参见 RACI 矩阵侧边栏）。类似的东西可以帮助团队成员了解他们在维护流程标准和参加关键项目会议方面对他们的期望。

认真管理依赖关系和风险

团队之间的依赖关系（称为积压耦合）在项目交付中很常见，因为多个团队将负责交付解决方案的不同离散部分。主动管理这些依赖关系的一个好做法是在项目交付之前，用旨在解耦各个团队积压的活动来提前加载项目交付，以使团队能够更自主地交付。

例如，为了减少我们示例中产品团队之间的积压耦合，项目团队可能会决定将其前几个迭代用于围绕构建一个步行骨架（参见下图 7）进行集中工作。假设有一个成熟的持续交付设置，步行骨架可以部署到生产环境中，并在功能标志后面，使未来的项目进度更新能够专注于步行骨架的演变，因为产品团队添加了更多保真度和范围深度。以下是一个发布计划示例，显示了步行骨架集中团队在产品路线图中的位置。

在我们上面的示例中，步行骨架将包含整个 MVP 用户旅程，但几乎没有投入时间来提高用户界面的保真度。此外，所有 API 集成都将被桩化，任何数据都将被模拟和硬编码。步行骨架的意图不是供客户使用，而是让产品团队之间相互耦合的工作在团队继续交付自己的积压之前得到解决。此外，一旦构建了步行骨架，它就允许所有团队持续集成他们的代码，从而降低了后期集成的风险。

项目交付将存在许多其他风险，因此，在正常的迭代周期中积极管理风险对于成功至关重要。积极的风险管理并不总是标准产品交付周期的一部分（如上面的示例所示），因此领导团队可能需要一些纪律才能在整个交付过程中保持势头。

制定强大的沟通策略

项目管理中的大部分协调工作都花在沟通上，以便

• 确保所有相关利益相关者都得到通知，并有机会提出问题和提出问题；
• 促进团队之间的沟通，以帮助缓解交付中的瓶颈；
• 将障碍暴露给项目领导团队，以便他们能够帮助缓解这些障碍。

由于项目中需要进行这种沟通开销，因此项目领导层应该寻求制定一个强大的沟通策略，其中包含满足每个利益相关者群体需求的接触点。以下是一个沟通策略示例

投资于有助于信息辐射的可视化工件

诸如物理项目墙（参见下图 9）之类的视觉工件可以用作项目的信息辐射器，不仅有利于关键利益相关者，而且有利于整个公司。

项目墙在开始时可以被视为一个孤立的计划，但通过保持其最新状态并强制围绕它进行对话，也可以创建新的组织习惯和纪律。物理墙的一个有趣的额外好处是它们可以促进团队之间的协作和问责制。此外，项目墙可以通过让公司中的其他人快速获取信息，而无需与任何人安排时间，从而帮助他们提出问题。

理想的项目墙包含足够的信息，以便一目了然地提供状态更新。从上面的示例中，我们可以看出集中团队已经完成了工作并解散，交付团队现在正在处理他们的可交付成果，其中一个团队需要一些帮助来消除未来的障碍。

不要害怕为管理项目定义明确的角色

我们认为，项目管理的纪律对于确保任何涉及多个团队协作和协调以交付价值的计划成功至关重要。但是，实际的角色定义和职责将取决于组织环境和项目复杂性，因此我们更愿意将此角色称为“解决方案倡导者”，而不是项目经理。从根本上说，需要有人负责计划的整体健康状况，将他们的工作重点放在以下战略要素上

• 持续确保团队之间的一致性；
• 确保团队和外部利益相关者之间的沟通顺畅；
• 保持相关和关键信息新鲜；
• 管理项目依赖关系和风险。

重要的是要确保该角色的职责对所有相关人员明确，最好是在项目启动时。我们在产品模式组织中引入解决方案倡导者时观察到的一种风险是，产品团队成员和解决方案倡导者最终可能会承担重叠的职责，从而降低了两个角色的有效性。如前所述，解决方案倡导者应该专注于项目的战略方面，而不是专注于所涉及团队的战术产品交付任务。以下 RACI 矩阵显示了角色之间职责的分离

请注意解决方案倡导者和产品交付领导层和团队之间的问责制分离。