诸如Scrum和XP之类的敏捷方法都依赖于紧密合作的关系以及与客户（即为软件付费并打算使用该系统的人）之间的持续交互。 该团队与代表客户利益的人一起工作，而不是编写和查看详细的规范并通过签字和委员会来工作，以定义业务功能并确定需要完成的工作以及何时进行。 采用这些方法的关键问题之一是找到合适的人扮演客户（XP）或产品所有者（Scrum）的重要角色。 我将两个术语互换使用。

团队与客户一起审查他们的工作，客户回答他们所遇到的任何问题，并设定团队的方向和优先级，并确保团队专注于对业务重要的事情，拥有和管理需求积压，编写验收测试并确定何时真正完成该软件。

团队的成功在很大程度上取决于客户或产品负责人的水平，他们的知识和经验，对项目的承诺，他们如何制定决策以及这些决策的良好程度。 迈克·科恩（Mike Cohn）在他的《 敏捷成功》中解释说，产品负责人必须是：

• 致力于团队并可以回答问题，在团队需要时获得团队所需的信息；
• 业务专家：他们不仅必须了解领域，而且还需要了解对业务战略上重要的内容以及对用户社区重要的内容；
• 团队内部和团队外部的良好沟通者；
• 一个好的谈判者，以便他们可以平衡团队的需求和不同利益相关者的需求；
• 被授权–他们必须能够代表客户做出决定–并且他们必须愿意在需要时做出权衡和艰难的决定。

有效的产品负责人还必须注重细节，以便他们能够理解和解决功能的细节，并编写功能验收测试。 他们应该了解软件开发的基础知识，至少要了解哪些是可行的，什么是不可能的，很难做到的，什么是不可能的以及为什么的界限，以便他们可以理解技术上的依赖和技术上的风险。 他们至少需要了解Scrum或XP的规则-对它们的期望以及如何玩游戏。

他们应该了解项目管理和风险管理的基础知识。 因为最终，产品负责人是决定做什么和不做什么的人。

产品负责人是产品经理，项目经理和业务分析师，他们合而为一。

哦，还有……他们还需要 “通过选择进行协作”，“在所有事情上都敏捷”和……“有趣且合理”。

一次在两个地方

产品负责人必须与团队紧密合作，并与团队的工作保持联系，以确保他们可以继续前进。 但是产品负责人还必须继续参与业务，以了解正在发生的事情和重要的事情。 他们必须既面向内（与团队合作，计划，举行评审，参加会议，确定优先次序，帮助管理积压，定义需求，回答问题和澄清信息）和面向外 （与项目的发起人和与系统的用户一起，确保企业了解项目中正在发生的事情，并确保他们了解业务优先级，竞争地位和业务趋势，以及何时发生任何变化以及这如何影响项目。 他们必须同时在两个地方，如果开发团队和企业不在同一地点，这实际上是不可能的。

产品负责人和政治

团队与产品负责人的关系以及产品负责人在其自身组织中的位置和影响中都存在政治风险。 产品负责人必须与团队和企业内部进行政治互动，试图增进团队和项目的利益，调和不同利益相关者之间的冲突，试图使利益相关者保持并保持联盟，建立联盟。 他们的成功以及项目的成功取决于他们解决这些问题的能力。

Scrum认为产品负责人不仅具有奉献精神和才华，而且与企业的战略重点以及一线员工的关注和需求保持联系； 但是它还假定产品负责人将始终把企业的利益置于自身利益之上。 但是一个好的产品负责人通常是一个雄心勃勃的产品负责人–他们对项目感兴趣，认为这是一个发展事业的机会。 项目影响变化，每变化都会有赢家和输家。 产品负责人的成功确实存在使他们与业务中其他重要利益相关者发生冲突的真正风险–通过专注于使他们的产品负责人感到高兴，团队可能会在组织的其他地方与敌人为敌。

一个客户还是多个客户？

产品负责人不仅决定什么是重要的事情以及将要完成的事情，还负责项目的预算，并对项目的成功负责。 根据Ken Schwaber的《 用Scrum进行敏捷软件开发》（Scrum的原始定义），产品所有者是“对该项目负有正式责任的人”，如果该项目失败或脱离正常，则是“ to之以鼻”。

期望一个人承担所有这些责任和如此多的工作是不现实的。 这是太多的责任，太多的风险和太多的工作。 对于许多产品负责人而言，这不仅仅是一项全职工作，还与敏捷价值观直接矛盾，敏捷价值观将人置于第一位，并强调团队的现实工作时间和可持续发展的步伐。

自敏捷开始以来，这一直是一个问题：在C3初始阶段（第一个XP项目）启动几个月后，客户代表由于倦怠和压力而辞职，无法更换，因此该项目最终被取消。

Scrum 仍然要求产品负责人角色必须由一个人扮演。

鉴于另一项基本的敏捷原则是：与他人一起工作的人共同做出更好的决策（ “人群的智慧” ），这没有道理。 如果为真，那么为什么一个人做出关于优先级，项目方向和愿景的关键决定？

XP的幕后工作人员最终认识到，客户这个简单的想法对一个人的要求太多，需要由客户团队分担工作量和责任。 客户团队意味着您将获得多角度，具有不同专业和经验的人们的优势，并且在回答问题和制定决策方面获得更多帮助。 它更具可持续性和实用性。

但这有其自身的一系列问题：

• 开发团队必须调和客户团队中能力上的差异，理解上的差异，不同的优先级，偏见和政治冲突以及个人冲突。
• 必须花更多的时间明确地保持客户团队本身的同步。 错误，误解和掉球的机会更多。
• 仍然必须有人负责，做出重要的决定-迈克·科恩（Mike Cohn）所说的“在这里停下来”的人。 开发团队必须知道，客户决策不会在客户团队中被压倒，以便他们能够致力于完成工作。

维护中的客户

维护和增强功能（大多数人将在其中度过很多职业）将显示产品所有者理念的其他问题。 首先，要让一个有才干，有干劲和无私的人来代表客户参加一个高调的战略发展项目是很难的。 对于较小的项目或正在进行的维护工作，要获得接近相同水平的承诺和才能的工作要困难得多。 具有这种知识和能力的人员可能正在运行或支持业务的某些重要部分，而不是回答问题并帮助维护团队确定问题的优先级。

而且，如果您有幸找到一个好的人，就很难留住他们–与项目不同，维护工作没有明确的结束日期，因此团队将需要习惯在不同的时间与不同的客户一起工作。不同的工作风格，不同的议程和不同的优势。

产品负责人应充当客户的唯一声音。 但是对于生产系统，您更有可能拥有太多的声音，太多的具有不同优先级和需求的人，全都为业务的不同部门工作，与团队中的不同人交谈，试图获得他们所需要的东西或要完成。 或对于某些旧的旧系统，您可能会遇到相反的问题–没有人想要获得系统或其数据的所有权，没有人知道足够的信息或不想对制定业务决策负责。

成为自己的客户

所有这些挑战并不意味着您不能使用Product Owner模型-显然，许多团队都以一种或另一种方式关注Scrum和XP。 但是您需要认识到这种方法的局限性和风险，并准备进行填写。

例如，许多在不同位置（尤其是在与企业不同的时区工作）的开发和维护团队都依赖客户代理：业务分析师或团队中的其他人可以帮助履行部分客户角色，然后工作与业务人员一起帮助回答问题并确定要求和优先级。 它不像直接与企业合作那样高效，但是有时别无选择。

甚至强大的客户有时也需要帮助。 许多ScrumMaster和产品负责人找到了更公平地分担责任并互相帮助的方法。

Scrum Master或团队负责人或高级开发人员或高级测试人员，无论在团队中扮演技术领导角色的人，都可能必须介入并在客户不可用，工作过度，无法工作时进行填写跟上，当他们不了解，什么时候他们没有资格做出决定，或者什么时候他们不在乎。 调和技术和业务要求以及不同利益相关者的需求，并进行技术和业务权衡以及长期和短期权衡。 与业务利益相关者进行沟通。 跟踪未解决的问题和未解决的问题，并尝试从业务中获取帮助。 为客户编写验收测试–敏捷团队的一个普遍问题是，业务方面没有人愿意帮助编写验收测试，但是如果做错了事，他们愿意加入团队。

准备以这种方式犯下更多的错误–您将不得不使用不完善和不完整的信息，有时您必须做出最佳猜测并加以利用，并且您将错取要求和优先级。 测试您可以做的所有事情，并尽快将产品投入业务，并准备好接受负面反馈。 与强大而忠诚的客户之间，您可能无法与企业建立起密切的关系。

这是一个折衷，但是这是许多团队别无选择的必要折衷。 正如迈克·科恩（Mike Cohn）在“扼杀oke咽的谬论”中指出的那样，最终是团队失败，而不仅仅是客户。