Jeff Patton 关于敏捷产品所有权决定问题的谈话

  • Shane Hastie
  • 姚佳灵

2018 年 4 月 1 日

话题:文化 & 方法

看新闻很累?看技术新闻更累?试试下载 InfoQ 手机客户端,每天上下班路上听新闻,有趣还有料!

在最近的敏捷印度大会上,Jeff Patton 发表了主题演讲,对敏捷开发实现产品所有权的方式提出了挑战。他认为,产品管理这门学科在“产品所有者(Product Owner)”这个 Scrum 术语创造出来之前就已经存在,并且其在大多数敏捷组织中的应用方式在一定程度上也打了折扣。

他说:

敏捷开发已经并正在搞砸产品管理。敏捷开发解决了软件开发中的很多问题,公司利用它不断地交付可工作的软件,且比起从前更能做出预测。但是,他们开发的软件不一定更好,或者在市场上更成功。因为我们需要做的东西是让一个产品成功,而不是融入敏捷开发。事实上,严格遵守常见的敏捷实践甚至会产生更糟糕的产品。

他指出,常见的敏捷开发方法在敏捷运动之前就已经忽略了很多产品管理纪律。他觉得“产品人员不喜欢敏捷开发,因为他们和客户没交流”。作为客户代理的产品负责人不是一个有效的角色,导致产品不符合客户的需要。他说,在产品管理界和大多数常见的敏捷方法之间已经产生了裂痕,有很多人(包括他自己)正在倡导把产品管理纪律纳入到敏捷之中。

他表示,利用敏捷开发的组织需要关注一些重要的事情,以确保他们开发的产品更成功,并且符合客户的需要。

  • 停止专注于更快地交付软件;停止把重点放在故事点数和速度上,因为重要的不是交付速度,而是帮助人们解决问题。
  • 确定预期的结果(对客户的利益)和所开发产品应该具有的影响(由于客户成果,对我们组织长期可持续的利益),并度量它们。当然要有产出(必须开发出产品),但是你应该关注的是结果和影响。

他质疑目前开发团队被业务的其他领域视为供应商的现状,当要购买的产品已经完整地描述并开发完成,在和另一个组织进行商业谈判,这种客户 / 供应商的关系是成立的,但是,如果指定者和生产者都为同一个组织工作,那么这就是件“你能做的最愚蠢的事情”了,因为它会导致产生不符合客户需要的劣质产品。这个模式被塞进了敏捷开发中,也即产品负责人代表“业务”,并被期望去了解到底需要创建和优先处理什么东西;而团队对时间、成本和范围负责。这实际上就在产品负责人和团队之间建立起了这么一种客户 / 供应商的关系。

他把这种方式和产品管理做了对比,产品管理是要求产品经理把各种各样的观点融合在一起,和团队一起工作,确认解决问题的最佳方法,从而生成有价值、有用和灵活的可持续产品。产品经理带领拥有所需全部技能的跨职能团队来交付产品;这包括工程、用户体验、市场营销、法律和合规、安全、质量保证以及竞争分析。

他认为产品负责人的角色是没有意义的,因为“团队拥有产品,而非某个人”。

产品经理需要接受这么一个事实,他们在探索产品需求的过程中得到的无数想法可能是错的,大多数新产品想法失败了,大多数产品的内置功能是没有用到的,因此,与其试图定义需求细节,不如把需求表示成假设,像“我们相信,如果我们提供有这样特征或能力的人,那么他们会得到这种好处,会对我们组织有这样的影响”,然后,团队确认他们如何测试假设、建立某样东西,允许他们在可能的最短时间,用尽可能小的成本去验证或宣告作废。如果证明是对的,他们就会进一步细化这个功能;不然,他们就放弃它,接着探索下一个假设。

这种假设驱动的方法要求产品经理和他们的团队不要局限于创建过程,他们要走出去,到客户使用产品的环境中去和客户交流,他们要深入了解客户体验,设身处地地体会他们的痛点。

他以 5 个关键建议的总结结束了他的谈话:

  1. 最大限度地减少产出,而最大化结果和影响并加以度量。
  2. 产品所有者和产品经理领导跨功能的核心产品团队,让整个团队参与产品决策。拥有产品的是团队。
  3. 就你的产品投入产出进行沟通。用小的成本(实验、测试和学习活动)消除你重大开支中的不确定性。
  4. 每个人必须和客户进行面对面的交流以建立同理心和获得洞察。
  5. 探索工作是团队工作。要为之做计划,保持其可见,对其进行回顾反思。

阅读英文原文 : Jeff Patton on Fixing Agile Product Ownership


感谢冬雨对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

文化 & 方法