敏捷转型，产品经理最难！

不管大家喜欢还是不喜欢，敏捷开发已经成为主流的开发模式。无论是从外部的竞争环境来看，还是从内部的流程改进角度来看，企业都应当全方位地拥抱敏捷。但敏捷转型是一个非常复杂的过程，中间会遇到各种各样的挑战。那么产品经理、项目经理、研发人员和测试人员这四种角色哪一种转型最难呢？我认为产品经理最难了。

因为产品经理的工作是整个敏捷开发的重中之重。从某种意义上来讲，产品经理是整个开发团队的发动机和方向盘。工作既需要有宏观视角，做好产品规划，又需要能够抓好细节，做好微观管理。所以敏捷开发模式下，用Product Owner这个单词来称呼产品经理这个职位，也是表达了对产品经理更高的要求。

那传统的产品经理转型为PO（Product Owner）都会面临哪些挑战呢?

首当其冲的就是思维方式的不同。

以前产品经理写需求文档，更像是在写说明文。通过各种不同的角度来描述将要开发的这个软件系统：比如要讲它开发的原因、讲它的功能模块组成、讲它里面的业务逻辑、画流程图、画原型图、定义交互规范、定义性能要求等等。敏捷开发模式下是用用户故事来作为沟通表达的工具。用户故事就需要有角色，有场景，有目的，还需要验收标准。这就更像是在写小说了。从我自己的理解来看，写需求文档更像是把系统当作一个静物来阐述，而用户故事视角更需要把系统当成一个可以交互的系统来看，阐述清楚不同的角色在这个系统里面可以做什么事情。这就需要有更高的抽象概括能力，以及非常清晰的逻辑表达能力。

随之而来的就是对文字表达能力要求的提高。

说明文和小说的这种对比没有那么精确，但意思是这个意思。写用户故事对PO的文字表达能力要求是更高了。一方面是用户故事的这种形式本身要求的。一个用户故事需要有角色，需要描述清楚要做的事情，需要解释原因目的。这就限制了用户故事不能用太多的文字，文字太多的话就很难套用这种模版。即使加上验收标准，也不宜太多。一个好的PO就需要能够精心地提炼文字，用简短易懂的文字将事情说清楚。这是一个高要求的能力。

用户故事是整个敏捷开发过程的核心，产品、开发和测试三种角色都是紧密围绕用户故事展开。所以从沟通的角度来看，也需要用简短易懂的文字，不能长篇大论。这样才有利于大家达成共识和对规模进行估算，平时站会沟通的时候也方便表述。

还需要对用户故事不断地做取舍，做决策。

传统项目管理方式下，产品经理把需求文档写好，然后交给研发团队研发。需求文档里面定义的功能都是要实现的，所以就一般就不需要做取舍。但在敏捷开发模式下面，产品交付都是增量性的交付。这就要求PO必须对需求进行优先级的排序，需要将用户故事拆细，然后做好产品的发布规划。这是一个持续不断的过程，需要产品经理不断地做决策，而且还是快速地做决策。能做决策是一个稀缺能力，要不然为啥有房谋杜断这个典故呢。做决策就需要权衡利弊，需要平衡各方面的诉求，还要应对各种的压力。做决策不是一件轻松的事情。能不能做决策是一个PO是否合格的关键标志。

综上，一位传统项目管理模式下的产品经理想要转型为PO，需要将产品拆分成一条条的用户故事，用精炼的文字将事情说清楚，然后能够根据各种因素作决策：做什么、不做什么、先做什么、后做什么。而且PO的工作还需要有提前量，需要提前梳理规划产品的业务逻辑和功能组成，尽量减少因考虑不清而导致的需求改动。所以我认为敏捷转型产品经理最难了。您认同吗？欢迎大家讨论交流。

禅道产品

核心功能

使用文档

帮助中心

关于我们

禅道社区

联系方式

北京、上海、深圳分部