近年来，敏捷开发成为了企业的首选，也成为了不少从业者的标配，产品经理也不例外。那么产品经理该如何用敏捷思维管理项目？本文进行了总结分析，一起来看看吧。

一、谈敏捷：IT 行业的新常态

近年来，敏捷开发成为众多企业的首选，到了几乎成为从业者的标配。敏捷方法不仅帮助企业在多个方面构建竞争优势、扩大价值，而且以其思维框架和行动指南的特性，在复杂的软件开发项目中尤其发挥重要作用。

在不断变化的 VUCA 环境中，企业为了生存和发展，急需通过快速试错，以最小的成本迅速寻找到价值点 , 很多企业为了生存，都在尝试敏捷转型，把企业内部的项目管理方式转换成产品管理的模式，引入了新的职位，即产品经理 （Product Owner， 简称 PDO）。

二、敏捷与项目管理：一个复杂的关系

引入敏捷的企业在培训中常将其与传统的瀑布模型对比，说明在何种情景下敏捷模式更为适用。然而，仅了解敏捷与瀑布模型的不同并不足以应对所有情形。敏捷起源于复杂的软件开发管理领域，其关注的 " 产品 " 通常是为了解决业务问题而开发的 IT 功能。对于多数制造业而言，" 产品 " 则是他们向客户交付的实物，如药品、汽车或手机等。

值得注意的是，敏捷在 IT 部门可能被解读为对项目需求的一种响应方式，而非纯粹的产品管理。这通常反映了企业的历史背景、员工能力、经营特性及组织结构等方面的局限。

1. 敏捷与传统项目管理的必要性

虽然现代企业中敏捷方法包含了诸如站会、规划会议、迭代评审和回顾会议等丰富的元素，甚至定义了多种角色如敏捷教练或产品经理，但这并不意味着可以完全废弃传统项目管理方法。

2. 传统项目管理的不可替代性

应用范围的广泛性：并非所有项目都适合采用敏捷方法。例如，组织一场结婚典礼、建造跨海大桥或举办脱口秀比赛等，这些项目由于其特定的需求和结构，可能更适合采用传统项目管理方法。

宏观与微观的不同维度：项目管理注重宏观战略，明确目标、资源限制和具体的时间框架；而敏捷则聚焦于具体的操作和战术层面，如实施细节和用户反馈。

成熟度和交付保障：传统项目管理方法因其成熟度高和能够保障最终的交付效果，被广泛接受和应用。与此同时，许多企业在探索敏捷转型过程中可能会遇到挑战，因为在软件开发管理中不存在所谓的万能 " 银弹 "。

通过以上对比和讨论，我们可以看出，虽然敏捷方法极具吸引力和实用性，但传统项目管理依然不可或缺，两者在现代企业管理中应当相辅相成。

三、案例分享

案例 1：缺少关键的干系人

我在一家汽车制造企业的 IT 部门工作，该部门已推行敏捷转型多年，我们已经围绕产品为中心定义并开展工作。最近，业务部门启动了一个项目，涉及两个不同部门的产品 A 和产品 B。这两个产品需要集成来满足新的业务需求。

项目审批后，产品 A 和产品 B 的经理开始制定各自的 backlog 和 planning。然而，某日产品 A 的 PDO 报告称，产品 B 的 PDO 提出了一个新的需求，这超出了我们团队的职责范围，且现有资源无法满足，需要引入产品 C 的支持。遗憾的是，最初的需求分析中并未考虑到产品 C。

在问题被指出后，我被召集来寻找解决方案。两个团队的敏捷主管已被通知，视此为一个需解决的障碍。我的建议是召集一个项目启动会议，包括业务代表和所有相关的 IT 产品经理。在会议中，我们需要明确项目目标、识别所有关键干系人、澄清依赖关系和管理潜在风险，以便达成共识并共同探讨可行的解决方案。

案例 2：前端开发的高保真原型图问题

在另一个案例中，公司批准了一个战略项目，虽然项目规模不大，但业务部门对此非常重视。由于项目紧迫且业务部门内部管理分散，需求澄清进展缓慢。

为加速开发进程，产品经理（PDO）与前端团队（FT）沟通，希望他们开始基于部分已确认的高保真原型图进行开发。然而，FT 拒绝开始工作，他们坚持按照敏捷规范操作，需要 PDO 确认全部高保真原型图后才能进行。

这一争议在我威胁进行 " 投诉 " 后得到了解决，FT 同意开始开发已确认的部分。此案例揭示了双方在理解对方需求和工作方式上的差异。若 PDO 能在项目开始时召开一个项目启动会，向所有相关方明确项目背景、管理层期望及潜在风险，这种误解和延误本可以避免。

本文由 @红杉阁学者 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议