产品经理如何用敏捷思维管理项目

0 评论 1141 浏览 1 收藏 7 分钟

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

一、谈敏捷: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 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!