我们的团队如何才能以尽可能低的摩擦力和尽可能的方式从"产品负责人"那里收集要求？

yada yada是目前尚无准则，无法发布或者企业需要做出关心质量的决策。我工作的产品是一个小组，已经取得了多年的成功。我只是想帮助他们提高一个等级。

基本上，我是一个6到7人的团队，只有一个产品负责人。她做得很好，但是在扮演几个不同的角色(我相信这在极小的团队中很常见)。通常会在零星的时间给出要求(通过电子邮件发送会议，面对面的讨论，会议等)。它们从未输入到系统中，有时这会导致功能缺少发行版，或者由于每个人都忘记了必要的功能而导致发行版被推迟。

如果我们处在类似的情况下，但是我们找到了解决此问题的方法，那么我很乐意听到。我很高兴编写代码来缓解这种情况，但是它不能成为产品负责人必须完成任何工作的网站。她非常忙，我们需要一些团队合作的方式来收集这些要求。

我目前正在考虑这样的事情：开发人员和团队成员收集在面对面会议中讨论的需求，并在Wiki页面上讨论的功能上写一些快速笔记。每当更新这些页面时，都会通知产品负责人，这是她的责任，以确保准确性。

优点：我们会记录一些功能。缺点：开发人员要承担通常不承担的责任。我在这里可以。我认为在这种情况下是团队合作。

当然，一旦这样做，我们就会发现产品负责人可能没有足够的时间来确保功能的准确性。最终，她负担太重了，我认为这将有助于证明这一事实，但我只需要能够首先引起人们的注意即可。

有什么建议吗？

P.S.她的时间非常有限，因此期望她在讨论后需要输入要求被认为是不合理的。她只有时间来讨论一次，然后继续前进。

解决方案

"开发人员和团队成员收集在面对面会议中讨论的需求，并写一些快速笔记"

从那开始。如果我们不做笔记，则只需做一个小小的改动即可。做笔记。稍后，我们可以将它们发布到Wiki或者创建功能待办列表，或者开始使用Scrum或者bugzilla或者其他工具。

但是，首先要进行一些小的更改。把东西写下来听起来像是我们没有做的事情，所以只要做到这一点，看看有什么改进和下一步可以做些什么。要敏捷。逐步工作。

尽管"产品所有者"的概念对我来说并不太明确，但我认为我在非常相似的情况下工作：客户非常忙碌，并且始终是开发需求的瓶颈。

从表面上看，在这种情况下，我们试图做的事情很明显，而且看似很简单：我们试图确保客户参与"只读/仅交谈"模式。不写。最小读数。大多在说话。

魔鬼当然很详细。因此，以下是有关我们流程的一些细节(无特定顺序)：

• 我们通常从记录问题陈述开始，这是需求的最终来源。实际上，有时候问题陈述是我们最初记录的全部内容，只是为了确保它不会丢失。注意：将问题陈述与需求区分开来很重要。尽管问题陈述有时清楚地暗示了某些要求，但总的来说，单个问题陈述可能会产生很多要求(每个要求都有自己的严重性和优先级)；此外，有时给定的需求可以为多种问题定义解决方案(通常只是部分解决方案)。记录问题陈述的主要原因之一(这与问题非常相关！)从语义上讲，它们在某种程度上"更贴近客户的皮肤"，并且比从它们得出的要求更稳定。我相信这些问题陈述可以使客户在有时间向开发团队提供反馈时，更轻松快捷地将其置于适当的环境中。
• 我们确实记录了所有需求(并将它们追溯到问题陈述中)，无论我们何时实施它们。优先级控制着实现需求的顺序。当然，它们还控制客户查看未完成需求的顺序。注意：包含所有要求的单一详细文档是绝对禁止的！所有要求和错误报告都放在"问题跟踪数据库"中。 (错误只是本书中出现问题的特例。)
• 我们始终尽力使"完成"每个需求(或者一组相关需求)所需的迭代次数最小化。理想情况下，客户只需要审核一次需求。每当第一次审核结果不充分(始终发生)，并且所涉及的要求足够复杂以至于需要大量文本和/或者插图时，我们确保客户不必重新阅读本书中的所有内容。刮。自上一个修订版以来，所有重要的更改/添加/删除都将突出显示。当问题或者需求保持未完成状态时，所有未解决的问题(主要是对客户的问题)都嵌入到文档中并突出显示。因此，只要客户有时间检查需求，他就不必召开会议并向团队提出问题。相反，客户可以先打开任何未完成的文档，查看他的确切要求，然后决定(对他而言)解决任何未解决问题的最佳方式和时间。有时，客户选择写电子邮件或者直接在问题文档中添加评论。
• 我们会尽力建立和维护官方领域的词汇表(即使它分散在文档中)。最重要的是，我们实际上迫使客户坚持使用该词汇表。注意：这是流程中最困难的部分之一，客户尝试不时"反抗"。然而，归根结底，每个人都同意这是使与客户的宝贵会议尽可能高效的唯一途径。如果我们曾经参加过一个小时的会议，而这个会议花了30分钟只是为了让大家都在同一页面上(再次)，那么我相信我们会很高兴有一个词汇表。注意：只要有可能，官方词汇的任何更改都会反映在该软件的下一个发行版中。
• 有时，可以通过多种方式解决给定的问题，如果不咨询客户，正确的选择就不明显。这意味着将有一个"需求菜单"供客户选择。我们记录了这样的"菜单"，而不仅仅是最终选择的要求。这似乎有争议，并且看起来像是不必要的开销。但是，每当客户(通常是几周或者几个月)突然遇到诸如"为什么我们这样做而不是那样做？"之类的问题时，这种方法就节省了大量时间。同样，使用需求文档的正确组织/格式隐藏"拒绝的分支"也没什么大不了的。无聊但可行。 :-)注意：在准备"需求菜单"时，重要的是不要过度使用它们。选择太多或者选择嵌套级别太多-下次审核可能需要比实际需要更多的客户时间。不用说，花在精心制作的分支上的时间可能完全浪费了。是的，在这里很难找到平衡(这很大程度上取决于总是匆忙的客户思考两个或者更多步骤并迅速采取行动的能力)。但是，我能说什么呢？如果我们确实想做好自己的工作，我相信一段时间后我们会找到适当的平衡点。 :-)
• 我们的客户是一个非常"视觉化"的人。因此，每当我们讨论任何重要的用户界面元素时，屏幕模型(甚至是轻量级的原型)通常都会非常有帮助。有时可以实时节省！注意：我们仅为客户提供屏幕模型，仅是为了促进讨论。开发人员也可以使用它们，但是它们绝不能替代用户界面规范！通常，有一些非常重要的UI细节是通过书面形式指定的(现在-主要针对开发人员)。
• 我们很幸运有一位具有非常技术背景的客户。因此，我们会毫不犹豫地使用UML图作为讨论辅助工具。各种UML图-只要它们能帮助客户更快地进入适当的上下文并停留在那里。当然，我在谈论需求级别的UML图。与实现级别的无关。我相信，即使不是很熟练的技术人员也迟早会开始研究需求级的UML图。我们只需要有耐心并知道在图表上放些什么。

显然，此过程的成本很大程度上取决于团队的分析和写作技巧，当然还取决于我们可以使用的工具。我必须承认，就我们而言，此过程似乎非常昂贵且缓慢。但是，考虑到非常低的错误率和非常低的"蒸气特征"率……我认为，从长远来看，我们将获得非常好的回报。

FWIW：根据Joel对软件产品的很好分类，该项目是"内部"项目。因此，我们有能力承担客户所能应付的敏捷性。 :-)

我们可能要注意房间中的HiPPO。最高薪人士的见解并不总是一件好事。我们倾向于将更多的精力集中在为开发人员提供出色的工具和支持上。这些事情做对了，消除了开发中的一些麻烦，从而使它变得更快，更有趣。这样，开发人员在工作量方面将变得更加灵活，并且可以适应最新的变更。

一键式测试和部署是从几个不错的开始。确保每个开发人员都可以在几秒钟内运行自己的软件堆栈，然后直接尝试想法。这样，开发人员便可以快速进行修订，或者沿他们认为有趣的旁路径运行，而这些路径通常是最成功的。所谓成功，是指根据系统中收集的，并可供所有相关人员使用的真实指标来衡量成功的程度。然后，所有者可以设置他们可能关心的指标，而不是他们自己不关心或者没有定义经验的要求。

当然，这取决于所有者和特定情况，但是我们发现度量标准比要求更容易讨论，并且开发人员也很擅长解释它们。一个典型的问题可能是客户似乎花了很长时间填充购物车，却没有继续结账。

1)市场营销要求可能是使结帐按钮变大和变红。 2)CEO的要求可能是直接带客户去结帐，因为CEO始终一次只能购买一件商品。 3)UI设计师的要求可能是在购物车的顶部放置第二个结帐按钮，在底部放置一个现有的结帐按钮。 4)开发人员的要求可能是一些Web 2.0 AJAX小部件，该小部件跟随鼠标指针在屏幕周围。谁是对的？

谁在乎...客户可能看到了可笑的交付成本，然后逃走了。但是将问题重新定义为度量标准而不是要求，开发人员突然对此产生了兴趣。开发人员不必与CMO进行10轮回合，按钮应该是红色的阴影。他可以整周使用Web 2.0，然后在星期一早上推出其他3个解决方案。每个人都可以进行48小时的现场部署，并且可以即时测量并报告购物车结账的速度。这些都没有任何区别，但是开发人员必须做好工作，并且业务将其重点转移到了他们销售的cr脚产品和交付价格上。

好吧，好的，因此该示例是人为设计的。为了确保项目规模小，团队经验丰富，热部署简单，提供即时回滚以及每个人都参与其中，有很多工作要做。我们想要达到的状态是不浪费开发人员的全部潜力，因此这就是为什么他们不仅要从一开始就参与其中，而且要参与成功的原因。首先从注册期间的点击数过高等问题开始，然后通过设计委员会进行处理，然后我们发现设计规范中的点击数实际上有所增加。无论如何，那是我们的经验。但是，请给开发人员一些自由，以便减少点击次数，我们实际上可能会像我们一样获得获得专利的解决方案。并不是说开发者在乎专利，而是它有优点，没有点击！