很多时候，产品经理们选择不去做产品负责人（PO, Product Owner）。他们谋划着由一个业务分析员或者产品分析员去“代理”产品负责人。当然，也是因为大部分关于产品负责人的书籍和培训都把他或者她当成是scrum团队的一个附属物：他们要做的只不过是写写用户故事和玩玩计划扑克，要按照INVEST原则而已。所有的这些关于产品负责人的定义都是从开发者的角度来的。
Scrum并没有定义如何使用产品backlog，或者是产品负责人应该做什么。而且，我也确实 认识有人没有用Scrum却在很好的写着用户故事来优化他们的产品管理工作。他们成为了很好的业务分析员，或者需求工程师。
将产品负责人的职责授权出去会进一步增加开发团队与客户之间的距离。我对Scrum Master的期望是他们能缩短这个距离。Scrum Master可以去教会业务如何行使PO的角色来做到敏捷。Scrum Master能帮助PO去理解如何抓住机会，去优化价值，如何与团队合作。在我看来，PO无论如何也不会因为要去做需求开发而变成业务分析员。
Scrum一直由（软件）开发领域来促进。我想这是为什么我们只会从我们的角度来看待PO的角色。我们能做点什么改进吗？我们从来没有在他们的角度来看过，对一个产品负责，考虑开发团队如何与PO协作来帮助PO把工作做得更好。
产品经理们和客户已经开始明白了。他们已经明白我们需要他们来帮我们把我们的工作做好。他们开始逃跑，只留下一个没有实质意义的PO的职位，叫产品负责人或者业务分析员。当然，这会直接修复瀑布的作法，使得在开发者和负责产品及其使用的人之 间加入了一个中间人。
产品负责人也不能是Scrum Master。他们都有各自不同的兴趣和习惯。改变他们的习惯是很难的。改变他们来让他们同时从两个角度看问题是不可能的。他们首先要学会用新的方法来把工作做得敏捷。
我将会引入一个新的课程，纯粹关注在如何让一个产品经理变得敏捷，来解决这个问题。他或者她可以使用Scrum或者是其它任何一个使用迭代式增量技术的方法，但是关键是要敏捷，价值驱动，并且看重机会-而不是仅仅坐在那里写用户故事。
作者:Ken Schwaber
原文地址：http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/
