最近我们有一个项目，其中客户忙于巡回演出。随着通常的Scrum团队的成立，管理层决定任命我们的分析师为产品负责人，因为客户将无法积极参与。分析师是与客户紧密合作进行需求分析和规范起草的人。
客户没有时间审查前两个版本。一切进展顺利，直到客户看到了第三个版本。他对某些功能不满意，而这些功能是由临时产品负责人（我们的分析师）介绍的。
我们被告知要等到设计团队完成所有页面的模型化，然后客户检查每一页并批准继续工作。Scrum团队在那里，但没有冲刺-我们完成工作的方式几乎就像经典的瀑布方法一样。
任命Scrum团队成员或管理员为产品所有者是一个好主意吗？在没有客户/产品所有者参与的情况下，我们是否需要关注Scrum？
Answers:
仅仅几周前，迈克·科恩（Mike Cohn）在他的博客上写了有关结合Scrum主管理员和产品所有者角色的信息。 我认为我无法比他做得更好，但是我对他的帖子的简短总结是：
我认为带任何一支Scrum团队的成员并将其移交给产品负责人本身并没有错。但是您必须意识到，这就像是促销或内部转账。它会在团队中造成漏洞，需要填补该漏洞。也许团队可以“自我重组”来填补漏洞；也许它需要雇用一个新员工来填补空缺。
您的过程对我来说似乎很好。您没有详细描述它，但是至少要尊重角色（这很重要）。
但是，由于我掌握的一些细节，我可以在产品所有者级别上看到一些问题。
他/她应确保适当地通知客户进度。看起来他在外部与客户进行“瀑布”操作，而在内部与您进行“混乱”操作。
结果：由于客户为王，瀑布获胜。即使在这种情况下，客户也有责任。
您当前的团队（包括Scrum Master）应该专注于交付sprint待办事项。但是，产品负责人（分析师）应确保他/她的待办事项中的内容反映出客户的需求。她/他还应确保沟通良好，并让客户参与。
可能的解决方案：将您的产品负责人（分析师）发送到Scrum产品负责人课程，或使他（她）阅读（并理解）这本书：敏捷产品管理与Scrum。
Scrum最好与真正的客户合作。与不习惯迭代产品设计的客户打交道有两个真正的挑战。
带有空白纸的设计阶段往往很快就会出现在天空中，并且通常会在一些附带问题上深入研究，而在所需的核心功能方面则没有足够的深度。您确实需要一个稻草人来让客户分拆以使设计会议成功进行。通过一次只关注一个方面，您正在帮助客户学习迭代设计。
害怕的客户（就像您的经验一样）没有意识到敏捷项目作为流程的一部分会预期一定数量（受控）的返工。他们很难把握的是，随着产品开发的向前发展，“噢，我的天哪”的时刻将会减少。更重要的是，由于审核/计划周期之间的时间较短，因此大多数客户难以承受的部分是，“噢，我的天哪”一瞬间不需要大量的资金来解决。
管理客户的期望非常困难。它很好地平衡了客户的教育程度，适应程度，甚至学会说“不”。客户不能总是每周或每两周来一次。有时他们每个月只能来一次。没关系。只要向他们展示上个月您为解决他们的担忧所做的事情，然后专注于本月的工作，它将使该项目更加顺利进行。最重要的是，在客户缺席的情况下，您确实可以为某些问题提供合理的建议。确实需要有人熟悉客户要达到的目标。
理想情况下，产品所有者对项目具有一定程度的权限和知识。如果客户分配了一个较低级别的员工，而该员工随后在以后的阶段被裁定要求您几乎重新开始，则可能会发生同样的事情。
感谢您的帖子。我知道它已经很旧了，但是我认为您提出了一个很好的案例，这是我的$ .02：
问题1：在您的情况下，任命分析师为PO会严重短路Scrum框架。为什么？因为只有采购订单才能做出价值判断，投资回报率评估，优先级确定和决定性选择，这些决定是业务产生的，而不是技术产生的，甚至不是对产品的熟悉度。我确定你的高级。分析师在模仿PO方面做得非常出色，但最终不得不猜测来自PO的需求，价值和选择。ref http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/。除非您的分析师获得了客户的POA（不太可能），否则他们将无法在Sprint审查中接受或拒绝任何东西。
这种方法可行吗？是的，但是当您的客户不在时，需要进行全部职责转移。您客户的老板将需要同意代理，并且不会撤消任何合理的决定。听起来可能吗？您更有可能从客户的组织那里获得临时PO（这肯定没有缺点！）分析师使用临时PO进行操作，任何不正确的决定都将来自业务，从而保持团队角色的整洁。
问题2：“客户没有时间进行审查”。大问题（也是我最近遇到的一个问题）。必须存在PO才能接受产品。没有其他人可以“签署支票”。缺少PO意味着不满会在以后发生，可能会导致更多的返工，并失去信任。从根本上讲，我感觉到客户没有积极参与您的项目：没有时间进行日常陈述，没有时间回答问题，等等。
问题3：“我们被告知要等到设计团队完成模型制作后再进行”。现在完全脱离了混乱。进行样机的人应该是跨职能团队的一部分。我不能说这是否是由于管理层对Scrum缺乏了解或对您的第三个发行版产生了震惊的反应。
问题：您的Scrum管理员在哪里？SM通常会认识到角色冲突的风险和PO缺乏参与的风险，这都是要解决的障碍/危险。