写点什么

产品负责人在敏捷团队中存在的理由

  • 2017-02-20
  • 本文字数:3587 字

    阅读完需:约 12 分钟

本文要点

  • 产品负责人在领导敏捷、scrum 团队中扮演着同等重要的角色。
  • 尽管很多公司宣称自己规范化地使用敏捷,但敏捷实际上一直是被误解的。
  • 产品负责人负责整个产品,而不仅仅负责功能、特性或是文档。
  • 产品负责人和产品经理可能大不相同。然而,根据 scrum guide 所述,scrum 团队根本没有产品经理,所以可能需要像对待利益相关者一样对待产品经理。
  • 产品负责人是服务型领导。

软件开发一直以来都是一项花费较多且存在风险的业务。Standish Group 在其 Chaos Manifesto 2013 中指出在调查期间,不到三分之一的项目按时且按预算成功完成。在 2015 年, Standish Group 一项研究的结果也显示了相同的数字,也就是说只有 29% 的项目被认为是成功的。这是什么造成的呢?

在业务发展迅猛的世界里,不可否认的是,每家企业都需要优秀的产品负责人。产品负责人负责控制混乱,管理风险,提前思考,扭转中断,解决利益相关者之间的冲突,并为他们支持的团队提供明确的方向。

从 2001 年以来,敏捷作为传统瀑布方法的替代方法出现,瀑布方法已被证明很难在现代软件工程中实施。但是,敏捷一直是被误解的

许多敏捷方法的新手试图通过将敏捷和瀑布方法结合,删除某些敏捷实践来实施,但他们却认为自己成功实施了敏捷方法。对于敏捷的常见误解之一是产品负责人在团队中扮演的角色,这也是本文的主题。

所以产品负责人的存在意义是什么?为什么会有这样一个职位存在?

谁是产品负责人(PO)?

简单来说,产品负责人就是拥有产品的人。他负责的是产品,不仅仅是功能、特性或是文档,他与整个产品相关。产品负责人是敏捷团队的决策者。用 Midtrans 公司CEO Ryu Kawano Suliawan 的话来说:“产品负责人就相当于小型 CEO。”他或她通过指导开发团队产出最大、最好的结果,对管理的产品的成功负最大责任。

产品负责人至少要完成这些任务:

  1. 在产品积压列表中创建可以理解的、可行的故事。
  2. 根据优先级调整产品积压列表中的故事完成顺序,以最好地实现设定的目标。
  3. 优化并最大化 scrum 团队的输出。
  4. 通过尽可能整理清楚团队内外事物来管理混乱。
  5. 帮助团队计划迭代。
  6. 参加所有 scrum 会议,尤其是站会和回顾会议。
  7. 为产品定义验收标准和 / 或关键性能指标。

产品负责人也可以选择完成通常由产品经理完成的任务。因为不是所有公司都同时拥有产品负责人和产品经理。

产品负责人职位描述中最重要的方面是,管理混乱。

产品负责人需要完成的重要任务

了解业务和团队

作为产品负责人,对于公司的业务和团队本身必须有深入的了解。因此,当需要修改一些业务需求或是对产品有新的改进的时候,要询问产品负责人完成这样事情的可能性,提供的解决方案是否能改善整体体验,比如是否可以帮助缩短时间等等,产品负责人还需要给出如何最好地解决问题的建议或方法。

做团队和利益相关者之间的桥梁

产品负责人最主要的工作是帮助团队和业务利益相关者直接沟通。在联系所有相关人员方面,他需要起到如虎添翼的作用。因此,产品负责人扮演敏捷团队中利益相关者的代理人是非常常见的。

然而,准确来说利益相关者扮演了什么角色呢?产品负责人可以代理利益相关者的这些角色:

  1. 管理角色
  2. 相关领域专家
  3. 终端用户
  4. 评估审计员
  5. 支持团队

其他相关的产品负责人角色

维护并准备积压列表

只要有产品,就有积压列表。在 Agile lingo 中,积压列表只是简单的待办事项。列表中的每一项都叫一个故事。每个故事都有类型,它可能只是零星事项,也可能是需要开发的功能。每个故事通过估计其难度(估计工作在 sprint 计划阶段由工程师完成)来“规划大小”,同样重要的是需要详细描述故事就绪阶段和完成阶段的标准。

在工程师可以开始处理故事之前,故事必须先放到积压列表中,并在 sprint 计划活动中被选为这个 sprint 的积压故事。因此,积压列表的优先级选择必须权衡以下方面:

  1. 客户价值(解决正确的问题)
  2. 业务价值(产生的收益)
  3. 技术价值(可以促进学习,减少风险,有牢靠的解决方案和智能工作流)
  4. 质量价值(缓解风险)

同样值得注意的是,利益相关者不应该强迫产品负责人承担故事。产品负责人必须充分评估故事,了解将故事包含在迭代中的风险。

设置并维护 sprint

如果你会说:“嗯好的,我们还有这么多故事要处理,但我们只剩下四个月了。所以我希望你们在这次 sprint 结束能完成四分之一的产品积压列表。”,那你就不是很好的服务型领导,而服务型领导是成为优秀的产品负责人需要扮演的关键角色。

重要的是要记住产品负责人永远不能在团队的讨论中表现出他或她的话语是最重要的、最值得关注的。他们甚至没有强制要求下个 sprint 要完成多少故事的权力。

然而,他有维护 sprint 的权力。所以在 sprint 中,产品负责人可以在和工程师团队协商之后,决定从当前部署计划中移除故事。产品负责人是团队中唯一决定什么可以得到部署的人。

比如说,如果这个功能需要其他团队的工作优先完成后才能开始处理,而其他团队还在处理这个功能,那么就理应不把这个功能包括进去。再举个例子,比如说一个功能所依赖的第三方产品还没实现,那也应该排除出去。

其他产品负责人经常要做的事

设计关键绩效指标(KPI)

利益相关者想知道产品取得了怎么样的成功。是否表现良好?这个产品如何帮助使用它的人?使用起来是否足够快?

产品负责人必须提供可测量的KPIs 列表,通过列表可以判断产品是否良好运行。产品负责人监控这些KPIs,并通过它们提供的反馈调整积压列表。

测试并验证需要部署的故事

一旦工程师将一个故事标记为准备测试,产品负责人就要负起该产品各方面被彻底测试的责任。他们需要在将该功能添加到部署包之前,努力找出不合常规的、奇异的问题和错误。他们需要和测试工程师以及用户代表一起工作,来保障测试。

保障有凝聚力的工作环境

嗯,很明显,她需要保证每个人正常工作,保证scrum master 有所帮助,保证工程师各司其职,保证团队是有凝聚力的和愉快的。这并非易事,而是必须有人认真处理并安排的工作。如果失败,团队也会失败,然后会一片混乱,失去了原来的工作效率。

发表发布日志

好的,那在每次部署之后,哪些功能得到了部署?发生了什么改变?新构建的产品会对客户和业务产生什么影响?如果可能的话,它怎么帮助事情变得更好、更快,并让工作变得更少?

建议产品负责人发表“发布日志”,或是简单地在公司内部或向外界发表发布的简单介绍。他可以使用Slack、Email 或whatnots 发布合适的发布说明。

分享产品会议

产品负责人可能需要做demo 演示产品如何运作。这就是为什么产品负责人要先自己测试产品,了解其局限性以及预期的性能等等是非常重要的。

招聘

团队的产品规模可能会扩大。在这种情况下,产品负责人需要和人力资源部门联络,咨询他想给团队添加一名新成员的事宜。

然而,决定是否要招聘某人不是由产品负责人决定的,而是由工程副总裁、CTO 或是其他类似角色决定的。产品负责人还要保证万一有人离开团队,团队工作不会中断,团队还能正常运作。

产品负责人 vs 产品经理

印度尼西亚工作目录网站 Karir.com 的 CTO Sky Kok 说,产品经理是更加以市场为中心的角色。他们通常和市场团队紧密合作,有时候直接和首席市场官合作。

传统上,产品经理负责的工作包括:

  1. 通过找寻新的方法提升产品整体体验开发业务案例。
  2. 认真倾听,扮演市场和客户的专家。不要负责寻找解决方案,因为这是工程团队的工作。
  3. 定义产品年度或季度的路线图。
  4. 管理产品的定价、销售和营销。
  5. 获取、购买或建立决策。

但是在 Scrum Guide 中没有提到产品经理,因此在采纳 scrum 的组织里,产品经理的角色可能更偏向于利益相关者。实际上,采纳 scrum 的团队可能根本没有产品经理这个职位,因此这个角色和解决方案部门、业务开发部门和产品负责人有所区别。

“作为产品负责人,我……”

你可能来自任何背景:

  1. 业务利益相关者
  2. IT 部门
  3. 业务分析师
  4. 产品经理
  5. 甚至是:新雇员

我曾经看到过来自以上列出的任何背景中的产品负责人对团队产生非常积极的影响。尽管传统来说,产品负责人更可能来自于业务分析团队,但是没有哪种背景会更加适合,要成为产品负责人的愿望都与想要采纳并接受相关的新挑战的愿望有关。

传统上,许多产品负责人拥有业务分析的背景是因为,业务分析团队通常介于技术和业务人员之间,所以他们对考虑中的产品有更多的认识。然而,只要你了解你期待的事情、你的存在意义,你完全可以相信自己能做好产品负责人,并实现以上提及的所有角色条件。

关于作者

Adam Pahlevi非常乐于生产可读的、高性能的代码。他在 Midtrans 公司做软件工程师,在空余时间中,他专注于 Tripisco 。他喜欢做什么?基本上来说,就是分享和结交朋友。他写过文章,远赴西班牙做过演说,并组织过聚会。当你在印度尼西亚的时候,可以与他联络。

查看英文原文 Product Owner Raison d’Etre in an Agile Team


感谢冬雨对本文的审校。

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

2017-02-20 16:472787
用户头像

发布了 218 篇内容, 共 71.8 次阅读, 收获喜欢 76 次。

关注

评论

发布
暂无评论
发现更多内容

缓存一致性设计思路

我爱娃哈哈😍

redis 缓存 缓存一致性

运维审计录像的作用是什么?用什么软件好?

行云管家

堡垒机 运维审计 审计录像

阿里高工纯手写的《分布式架构手册》仅仅一天GitHub就标星128K

Java你猿哥

架构 分布式 分布式架构

大咖力荐 |《中国企业软件研发管理白皮书》为什么值得看?

万事ONES

云服务是什么意思?有什么用?

行云管家

云计算 云服务

第二届“鼎新杯”数字化转型应用大赛申报通道正式开启

信通院IOMM数字化转型团队

数字化转型 鼎新杯

解决流水线瓶颈、提升编码效率的五个方法(上篇)

龙智—DevSecOps解决方案

ci cicd 持续集成 流水线

关于自托管环境,您了解多少?

龙智—DevSecOps解决方案

Atlassian Data Center

Postman Runner 使用指南

Liam

Java 后端 Postman 接口测试 API 开发

Linux 修改系统时间的两种方式

会踢球的程序源

Java Linux

OneCode 开源集成开发工具ESD功能介绍

codebee

开源 低代码平台

互联网工程师Java面试八股文及答案整理(2023最新版)

Java你猿哥

Spring Cloud springboot java面试 面经 JVM面试

RocketMQ 多级存储设计与实现

阿里巴巴云原生

阿里云 RocketMQ 云原生

解析单存储库:定义、优势与挑战

龙智—DevSecOps解决方案

谷歌 Monorepo Monolith 单储存库

打造安全无忧软件应用的十大最佳实践

龙智—DevSecOps解决方案

软件开发 软件开发安全

涅槃重生!字节大牛力荐大型分布式手册,凤凰架构让你浴火成神

Java你猿哥

架构 分布式架构 凤凰架构

优秀的pdf编辑器:Acrobat Pro DC 中文直装版

真大的脸盆

Mac PDF Mac 软件 PDF格式转换

实战分享丨 MySQL 与 Django 版本匹配相关经验

Java你猿哥

Java MySQL SSM框架 实战 Diango

ReentrantLock和Synchronized使用与区别,多线程安全问题

共饮一杯无

synchronized ReentrantLock 三周年连更

研究思考丨关于软件复杂度的困局

阿里巴巴云原生

阿里云 云原生 复杂度

【Linux】系统中安装Go环境

A-刘晨阳

Go Linux 三周年连更

Databend v1.1 版本发布!

Databend

【经验分享】硬件工程师需要知道的DFM可制造性设计

华秋PCB

工具 电路 PCB PCB设计 可制造性

PostgreSQL技术内幕(七)索引扫描

酷克数据HashData

数据库 postgresql

ElasticSearch 高级检索,按照顺序进行搜索

alexgaoyh

elasticsearch dsl 顺序搜索 高级检索 与或关系

某程序员哀叹:写几年代码,回头一看80%都没用,没法写上简历!

Java你猿哥

Java 程序员 面试 简历

分布式文件系统FastDFS

会踢球的程序源

Java fastdfs 分布系统

爆肝一月!527页文档详解SpringCloud微服务和分布式系统实践

Java你猿哥

数据库 分布式 SSM框架 微服务设计

技术分享 | 如何迅速将分布式政企应用转型为云原生微服务架构

IT科技苏辞

600+ 道 Java面试题及答案整理(建议收藏)

会踢球的程序源

Java 面试 java面试 应届生 Java八股文

SOA/ESB架构升级之路:从微服务到ServiceMesh,再到Sermant

IT科技苏辞

产品负责人在敏捷团队中存在的理由_文化 & 方法_Adam Pahlevi_InfoQ精选文章