不管大家喜欢还是不喜欢,敏捷开发已经成为主流的开发模式。无论是从外部的竞争环境来看,还是从内部的流程改进角度来看,企业都应当全方位地拥抱敏捷。但敏捷转型是一个非常复杂的过程,中间会遇到各种各样的挑战。那么产品经理、项目经理、研发人员和测试人员这四种角色哪一种转型最难呢?我认为产品经理最难了。
因为产品经理的工作是整个敏捷开发的重中之重。从某种意义上来讲,产品经理是整个开发团队的发动机和方向盘。工作既需要有宏观视角,做好产品规划,又需要能够抓好细节,做好微观管理。所以敏捷开发模式下,用Product Owner这个单词来称呼产品经理这个职位,也是表达了对产品经理更高的要求。
那传统的产品经理转型为PO(Product Owner)都会面临哪些挑战呢?
首当其冲的就是思维方式的不同。
以前产品经理写需求文档,更像是在写说明文。通过各种不同的角度来描述将要开发的这个软件系统:比如要讲它开发的原因、讲它的功能模块组成、讲它里面的业务逻辑、画流程图、画原型图、定义交互规范、定义性能要求等等。敏捷开发模式下是用用户故事来作为沟通表达的工具。用户故事就需要有角色,有场景,有目的,还需要验收标准。这就更像是在写小说了。从我自己的理解来看,写需求文档更像是把系统当作一个静物来阐述,而用户故事视角更需要把系统当成一个可以交互的系统来看,阐述清楚不同的角色在这个系统里面可以做什么事情。这就需要有更高的抽象概括能力,以及非常清晰的逻辑表达能力。
随之而来的就是对文字表达能力要求的提高。
说明文和小说的这种对比没有那么精确,但意思是这个意思。写用户故事对PO的文字表达能力要求是更高了。一方面是用户故事的这种形式本身要求的。一个用户故事需要有角色,需要描述清楚要做的事情,需要解释原因目的。这就限制了用户故事不能用太多的文字,文字太多的话就很难套用这种模版。即使加上验收标准,也不宜太多。一个好的PO就需要能够精心地提炼文字,用简短易懂的文字将事情说清楚。这是一个高要求的能力。
用户故事是整个敏捷开发过程的核心,产品、开发和测试三种角色都是紧密围绕用户故事展开。所以从沟通的角度来看,也需要用简短易懂的文字,不能长篇大论。这样才有利于大家达成共识和对规模进行估算,平时站会沟通的时候也方便表述。
还需要对用户故事不断地做取舍,做决策。
传统项目管理方式下,产品经理把需求文档写好,然后交给研发团队研发。需求文档里面定义的功能都是要实现的,所以就一般就不需要做取舍。但在敏捷开发模式下面,产品交付都是增量性的交付。这就要求PO必须对需求进行优先级的排序,需要将用户故事拆细,然后做好产品的发布规划。这是一个持续不断的过程,需要产品经理不断地做决策,而且还是快速地做决策。能做决策是一个稀缺能力,要不然为啥有房谋杜断这个典故呢。做决策就需要权衡利弊,需要平衡各方面的诉求,还要应对各种的压力。做决策不是一件轻松的事情。能不能做决策是一个PO是否合格的关键标志。
综上,一位传统项目管理模式下的产品经理想要转型为PO,需要将产品拆分成一条条的用户故事,用精炼的文字将事情说清楚,然后能够根据各种因素作决策:做什么、不做什么、先做什么、后做什么。而且PO的工作还需要有提前量,需要提前梳理规划产品的业务逻辑和功能组成,尽量减少因考虑不清而导致的需求改动。所以我认为敏捷转型产品经理最难了。您认同吗?欢迎大家讨论交流。
敏捷转型,产品经理最难!
参与讨论
未登录
回复:
热门评论
敏捷开发
共发表30篇
最近内容
-
竞品分析6步法
2024/07/08产品经理
-
通过Scrum实现最大生产力的5种方法
2024/06/20敏捷开发
-
敏捷转型,产品经理最难!
2024/06/17敏捷开发