requirements - 低摩擦最小要求收集

Question

我们的团队如何以尽可能低摩擦但可用的方式从我们的“产品负责人”那里收集需求？

现在这是指导方针 - 没有无法完成或业务需要做出决定它关心质量的决定的帖子，yada yada。我工作的产品是一个成功多年的小团体。我只是想帮助他们提高一个档次。

基本上，我在一个 6 或 7 人的团队中，只有一个产品负责人。她做得很好，但同时兼顾了几个不同的角色（我相信这在极小的团队中很常见）。通常会在零星的时间给出要求（电子邮件会议、面对面的讨论、会议等）。它们永远不会进入系统，有时这会导致功能缺少发布或发布被推迟，因为每个人都忘记了必要的功能。

如果您处于类似情况，但您找到了克服此问题的方法，我很想听听。我很高兴编写代码来帮助缓解这种情况，但它不能是产品负责人必须访问才能完成任何事情的网站。她非常忙，我们需要某种方式作为一个团队一起工作，以收集这些要求。

我目前正在考虑这样的事情：开发人员和团队成员收集面对面会议上讨论的需求，并就 wiki 页面上讨论的功能写一些简短的笔记。每当这些页面更新时，产品所有者都会收到通知，然后确保准确性成为她的责任。

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

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

那么有什么建议吗？

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

Answer 1

尽管“产品负责人”的概念对我来说有点模糊，但我认为我的工作环境非常相似：客户非常忙碌，总是成为开发需求的瓶颈。

从表面上看，我们在这种情况下尝试做的事情是非常明显和看似简单的：我们尝试确保客户参与“只读/只谈”模式。没有写作。最低阅读量。主要是说话。

当然，魔鬼在细节中。所以，这里有一些关于我们的流程的细节（没有特别的顺序）：

• 我们经常从记录问题陈述开始，这是需求的最终来源。事实上，有时我们最初只记录问题陈述，只是为了确保它不会丢失。

  注意：区分问题陈述和需求很重要。尽管问题陈述有时清楚地暗示了一些要求，但一般来说，一个问题陈述可能会产生一大堆要求（每个都有自己的严重性和优先级）；此外，有时给定的需求我定义了多个问题的解决方案（通常只是部分解决方案）。

  记录问题陈述的主要原因之一（这与您的问题非常相关！）是语义上它们有点“更接近客户的皮肤”并且比源自它们的要求更稳定。我相信，只要客户有时间向开发团队提供反馈，这些问题陈述就可以更轻松、更快捷地将客户置于适当的环境中。

• 我们确实记录了所有需求（并将它们回溯到问题陈述），无论我们何时实施它们。优先级决定了要求的实施顺序。当然，它们还控制客户审查未完成需求的顺序。

  注意： 包含所有要求的单个胖文件是绝对禁止的！所有需求都与错误报告一起放在“问题跟踪数据库”中。（错误只是我们书中问题的一个特例。）

• 我们总是尽量减少“最终确定”每个需求（或一组相关需求）所需的迭代次数。理想情况下，客户应该只需要审查一次需求。

  每当第一次审查结果不充分（总是发生），并且所讨论的要求足够复杂以至于需要大量文本和/或插图时，我们确保客户不必重新阅读所有内容划伤。自上一个修订版本以来的所有重要更改/添加/删除都将突出显示。

  虽然问题或需求仍处于未完成状态，但所有未解决的问题（主要是向客户提出的问题）都嵌入到文档中并突出显示。因此，只要客户有时间审查需求，他就不必召集会议并向团队征求问题；相反，客户可以先打开任何未完成的文档，看看他究竟期望什么，然后决定（对他而言）解决任何未完成问题的最佳方式和时间。有时客户选择写一封电子邮件或直接在问题文档中添加评论。

• 我们尽最大努力建立和维护官方领域词汇（即使它分散在文档中）。最重要的是，我们实际上迫使客户坚持使用该词汇。

  注意：这是流程中最困难的部分之一，客户不时会尝试“反抗”。然而，归根结底，每个人都同意这是使与客户的宝贵会议尽可能高效的唯一方法。如果你曾经参加过 30 分钟的一小时会议，只是为了让每个人都在同一页面上（再次），我相信你会喜欢有一个词汇表。

  注意：只要有可能，官方词汇中的任何更改都会反映在软件的下一个版本中。

• 有时，一个给定的问题可以通过多种方式解决，如果不咨询客户，正确的选择并不明显。这意味着将有一个“需求菜单”供客户选择。我们记录了这样的“菜单”，而不仅仅是最终选择的要求。

  这可能看起来有争议，并且看起来像是不必要的开销。但是，每当客户（通常是几周或几个月后）突然提出诸如“为什么我们这样做而不是那样做”之类的问题时，这种方法可以节省大量时间。此外，使用适当的需求文档组织/格式来隐藏“被拒绝的分支”并不是什么大不了的事。无聊但可行。:-)

  注意：在准备“需求菜单”时，不要过度使用它们是非常重要的。太多的选择或太多的选择嵌套级别 - 下一次审查可能需要比实际需要更多的客户时间。不用说，花在精心设计的分支上的时间可能完全被浪费了。是的，在这里很难找到平衡（这在很大程度上取决于总是匆忙的客户提前两步或多步思考并快速完成的能力）。但是，我能说什么呢？如果你真的想把工作做好，我相信一段时间后你会找到合适的平衡点。:-)

• 我们的客户是一个非常“视觉”的人。因此，每当我们讨论任何重要的用户界面元素时，屏幕模型（甚至是轻量级原型）通常都非常有用。有时可以节省时间！

  注意：我们专门为客户制作屏幕模型，只是为了方便讨论。开发人员也可以使用它们，但它们绝不会替代用户界面规范！通常情况下，有一些非常重要的 UI 细节会以书面形式指定（现在 - 主要针对开发人员）。

• 我们很幸运有一位技术背景非常好的客户。因此，我们毫不犹豫地使用 UML 图作为讨论辅助。各种 UML 图——只要它们能帮助客户更快地进入正确的上下文并留在那里。

  当然，我说的是需求级别的 UML 图。与实施级别的无关。我相信即使不是很技术的人也迟早会开始挖掘需求级别的 UML 图。你只需要耐心并且知道在图表上放什么。

显然，这种过程的成本在很大程度上取决于团队的分析和写作技巧，当然也取决于您可以使用的工具。我必须承认，在我们的案例中，这个过程似乎相当昂贵且缓慢。但是，考虑到非常低的错误率和“蒸汽特征”的低率......我认为，从长远来看，我们会得到很好的回报。

FWIW：根据Joel 对软件产品的分类，这个项目是一个“内部”项目。因此，我们可以负担得起客户可以处理的敏捷。:-)

Answer 2

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

从那开始。如果你不做笔记，只需做一点小改动。做笔记。稍后，您可能会将它们发布到 wiki 或创建功能积压或开始使用 Scrum 或 bugzilla 或其他东西。

然而，首先，做一些小的改变。写下来听起来像是你没有做的事情，所以就这样做，看看有什么改进以及下一步可以做什么。敏捷。增量工作。

Answer 3

您可能要小心房间里的 HiPPO。最高薪人士的意见并不总是好的。我们倾向于更多地专注于为开发人员提供出色的工具和支持。这些事情做对了，可以减少开发中的一些麻烦，让它变得更快、更有趣。然后，开发人员在工作量方面更加灵活，并且更容易接受最新的更改。

一键式测试和部署是一些不错的开始；确保每个开发人员都可以在几秒钟内运行自己的软件堆栈并直接尝试想法。然后，开发人员能够快速进行修订或沿着他们觉得有趣的小路走下去，而这些小路通常是最成功的。我所说的成功是指基于系统中收集的真实指标衡量的成功，并随时可供所有相关人员使用。然后，所有者可以设置他们可能关心的指标，而不是他们不关心或没有定义经验的需求。

当然，这取决于所有者和您的具体情况，但我们发现指标比需求更容易讨论，而且开发人员也非常擅长解释它们。一个典型的问题可能是，客户似乎花了很长时间填充他们的购物车，但没有继续结账。

1）营销要求可能是使结帐按钮更大更红。2) CEO 的要求可能是让顾客直接结账，因为无论如何 CEO 一次只能购买一件商品。3) UI 设计师的要求可能是在购物车顶部放置第二个结帐按钮以及在底部放置现有的结帐按钮。4) 开发人员的需求可能是一些 Web 2.0 AJAX 小部件，它跟随鼠标指针在屏幕上移动。谁是对的？

谁在乎...客户可能看到了可笑的交付成本并逃跑了。但是将问题重新定义为度量，而不是需求，开发人员突然变得感兴趣。开发人员不必与 CMO 就按钮应该是什么红色阴影进行 10 轮讨论。他可以整周都在玩他的 Web 2.0 东西，然后在星期一早上匆忙解决其他 3 个解决方案。每个人都可以实时部署 48 小时，并且会立即测量和报告购物车到结账率。这些都没有任何区别，但是开发商必须做好他们的工作，并且业务将重点转移到他们销售的蹩脚产品和他们在交付时衡量的价格上。

好吧，好吧，所以这个例子是人为的。那里有很多工作来确保项目规模小、团队经验丰富、热部署简单、提供即时回滚以及每个人都参与其中。我们想要达到的状态是开发人员的全部潜力不会被浪费，这就是为什么他们不仅从一开始就参与其中，而且还参与到成功中。从注册时点击量过高这样的问题开始，通过设计委员会运行，我们发现点击量在设计规范中实际上上升了。无论如何，那是我们的经验。但是给开发者一些自由来减少点击次数就像我们所做的那样，您实际上可能最终获得了专利解决方案。并不是说开发人员关心专利，而是它有优点——而且没有点击！