做一个更加优秀的产品负责人

无论是谁，只要曾经在一个成功运作的敏捷项目中待过一段时间，就无法否认产品负责人（在 XP 中是“客户”）与开发团队的协作决定了项目的成败。Peter Stevens 为如何当好产品负责人提了一些建议。

无 可置疑，产品负责人在敏捷团队中的任务是相当艰巨的。要做好本职工作，他们需要一边积极参与敏捷开发团队中的工作，与团队紧密协作，一边还要一直关注、投 入自己的领域（每天的日常工作）。所以产品负责人会做的很辛苦，往往最后会对自己在团队中的工作效率造成影响，而团队也因此遭殃。

Peter Stevens 最近写了篇文章，想办法帮助产品负责人意识到当发现自身问题的时候到哪里去寻找答案，也为他们如何做好本职工作提了一些建议。

Stevens 指出了四种现象，当任一现象发生的时候，都表明产品负责人跟团队的关系出现了问题，需要调整：

• “小鸡测试”：如果团队不把产品负责人当做他们的成员，那么很可能产品负责人的所作所为让团队感觉不舒服。
• “Sprint 失败，无法交付”：这个问题可能是由于迭代故事导致的，而这又可以回溯到与产品负责人的协作问题。
• “谁来负责？”：许多产品负责人向团队发出指示而导致的问题。
• “你的团队在敷衍塞责”：缺少跟产品负责人面对面的沟通，团队缺少动力。

Steven 继而为产品负责人提出了三条建议，帮助他们改善与团队的关系，增加默契：

1. 全心投入。按规矩行事。
   完全投入到 Scrum 的所有仪式中去，包括每日立会和回顾。在立会和回顾中与大家保持平等的身份。和其他人一样回答同样的问题。倾听。不要滥用权势。你可 能应该在一两个 sprint 中保持缄默，从而建立信任。这样可以帮助你更好的了解团队，了解怎样帮助他们取得成功。他们也可以更好的理解你的问题，应对挑 战。
2. 一言九鼎
   在每个 sprint 计划会议上，你都会跟团队达成一致。你要履行约定。不要在 sprint 还在执行的时候就给团队多派工作。不要朝令夕改——敏捷并不是意味着缺乏远景目标。保护团队不受公司的干扰。没错，这是 Scrum Master 的工作，不过你的防护级别要高一些。
3. 团队需要你的时候，你不要无暇抽身
   准时参加会议，不要中途退场。给自己留出足够的时间，用来满足团队需要。如果你的时间不够，那就把影响你投入项目的原因找出来。做交付计划的时候，要考虑到一些特殊的日期，例如假日、交易会等等重要的事件，这样就能不在项目的关键阶段缺席。

笔者并不想多说赘余的话，但还是应该强调一下，虽然 Stevens 表达观点的时候用的是 Scrum 的词汇，但是它们同样适用于没有用 Scrum 的场合。如果你在采用 XP 实践，那把“产品负责人”换成“客户”，把“sprint”换成“迭代”，效果也是一样的。

这个世界上的产品负责人啊，你觉得这篇文章靠谱吗？你的亲身经历跟Stevens 的建议吻合么？

查看英文原文： Being A Better Product Owner