本文是敏捷开发产品管理系列的第七篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理），也是敏捷开发团队管理系列（拟）中的一篇。
目的
在之前的《Product Servant》一篇中曾经提到，作为产品经理或产品总监，都应该有自己的方式来根据市场和用户情况来管理产品的走向，其中前者更倾向于具体的功能，而后者则更倾向于市场方向的竞争力；前者要求细节，后者要求高度。那么，这两个人到底谁是传统意义上的Product Owner呢？
另一个常常被问到的问题是：“我们只有一个产品经理，而有20多个开发人员，这一个产品经理能忙得过来吗？”
再有一个问题则是：“PO只在迭代开发会上沟通需求，还是在迭代开发期间仍然与团队在一起？”
还有一个问题则是：“PO在最后的评审会上才看到结果，万一发现问题需要改正，是否会为时过晚？”
又有一个问题则是：“可以让客户代表参加计划、评审活动吗？”
……
这些诸多问题，都指向一个答案：“一个PO很难完成其所应履行的各种职责，我们需要一个PO团队。”
结构
PO团队整体上是一个上下分级、内外疏密的团队。
所谓上下分级，就是说一定要有产品总监层面的人员参加，以便把控整个产品的走向。这种把控的结果，是能按照商业步调形成大的版本计划。
若失去这种大的方向，就很难真正“按优先级排序”，因为真正的优先级，来自于对盈利性产品的持续盈利能力、新产品的价值判断发展方向等商业目标的追求，而不是技术上的优先级。
在总监层面的工作完成后，产品经理会在具体版本、计划、需求开发、评审、发布等工作中将商业目标落实到开发工作中。从时间上，保证产品进度符合商业步调，从空间上，保证产品需求符合目标客户群。
在大型的PO团队如游戏的策划团队（常常占总人数的1/4）中，还会有三层结构：主策划（产品总监）-策划组长（产品经理）-策划人员（产品助理），负责一小部分故事的编写与跟进（跟进活动见下文）。
所谓内外疏密，则是在开发过程中由客户、市场、销售、产品、开发、售后等综合角度审视产品。
比如游戏公司常常邀请运营部门或发行商参与产品的管理，消费电子则会邀请分销商、售后部门等，目的是提供第一手的反馈。
产品研发团队的代表也常常参加PO团队，来帮助PO团队把握产品演进的技术路线。研发团队代表还会从整个商业路线图中勾勒出技术路线图，来判断是否以及在何种程度上“为未来做准备”。（在《智慧敏捷系列》中曾经提到，准备太多会浪费；准备太少会返工。）
产品经理在整个过程中扮演穿针引线的作用，即作为各方的Servant，向上提供决策依据，向下提供目标指引，向外提供产品支持，向内提供用户需求。
活动
除了常见的需求优先级排序、计划会讲解故事、评审会评审需求之外，整个PO团队还有很多工作，下面按照工作的大小、层次列举一下。
- 产品初期
- 产品总监：设定商业目标和路线图
- 日常工作
- 产品经理：制定发布计划，形成和描述故事
- 研发团队的代表：制定技术路线图
- 迭代前
- 产品经理：优先级排序，选择下个迭代的待开发列表（Willing List），选择故事群，制定迭代目标
- 产品经理/研发团队的代表：预估故事，协助拆分故事
- 迭代中
- 产品经理/产品助理：负责细化需求，跟进需求的完成情况（渐进式评审，见下）
- 评审会
- 产品总监/产品经理：评审需求完成情况，提出意见，重新排序
某些PO团队参与开发过程的活动，请参考：http://blog.csdn.net/cheny_com/article/details/6905291
渐进式评审
所谓渐进式评审，又叫跟进人制度，是为了防止迭代最后一天的评审会上发现了问题，由于第二天就想发布了所以来不及改正，因而将评审改为每一个故事完成，都进行一次评审，若需要改正则提前进行。
一般需要以下实践配合：
1. PO团队人数较多，且有层次，能为每个故事设定跟进人，负责解释和验收这个故事。
2. 配合MoSCoW方法，按优先级逐个完成故事，若M、S类型的故事评审后需要改进，则可能牺牲后面的W类型工作。
3. 中期评审会。有些团队在为期30天的迭代的第20天左右，会开一个预评审会，以完成2中提到的工作。
点击下载免费的敏捷开发教材：《火星人敏捷开发手册》
3584
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
