项目又延期了？可能是第三类需求惹的祸

作者： Mike Cohn

译者：李洁（Jerry Li），CSP，CSM，Scrum中文网资深敏捷顾问和培训师，敏捷教练文章源自IT老刘-https://itlao6.com/4935.html

链接：https://www.mountaingoatsoftware.com/blog/the-three-types-of-requirements文章源自IT老刘-https://itlao6.com/4935.html

在讨论项目需求时，认识到实际上存在三类需求，是极其重要的。文章源自IT老刘-https://itlao6.com/4935.html

第一类需求是已知需求（known requirements）。这些是用户告诉我们的需求。多年来，需求分析人员们已经练就了良好的项目已知需求收集技术：用户访谈、故事编写研讨会、开放式问题等等。文章源自IT老刘-https://itlao6.com/4935.html

然而，我们都会犯错。我们提出的问题并不总是正确的，用户有时也会漏考虑事情，用户访谈或许会打点折扣，故事编写研讨会或许会出现用户缺席的情况。文章源自IT老刘-https://itlao6.com/4935.html

第二类需求，是那些在我们访谈用户时没能获取到的需求，即项目的疏漏需求（overlooked requirements）。它们和已知需求同样重要，但不知为何我们疏漏了它们，可能是因为我们漏听了，也可能是因为干系人从未说起过。文章源自IT老刘-https://itlao6.com/4935.html

一个来自杂货店的例子文章源自IT老刘-https://itlao6.com/4935.html

假设您正在一家杂货店中，购买本周的物品。您购物清单上的项目代表着您的已知需求。您知道它们是必需的，所以将其添加到列表中。文章源自IT老刘-https://itlao6.com/4935.html

在走过过道时，您看到了橙汁，并且意识到自己忘记把它列入清单了。橙汁就是一个疏漏需求。文章源自IT老刘-https://itlao6.com/4935.html

第三类需求文章源自IT老刘-https://itlao6.com/4935.html

购物清单上的所有项目都被划掉了，加上忘记列入清单的橙汁，您走向结账的队伍。文章源自IT老刘-https://itlao6.com/4935.html

但在路上，又有一样东西吸引了您的眼球，于是您把它放进了购物车。文章源自IT老刘-https://itlao6.com/4935.html

您是否曾经在杂货店购买过自己都不知道自己需要的东西？它不在您的购物清单上（即已知需求），也并非是您疏漏的东西，而是直到看到它时您才知道自己需要的东西。文章源自IT老刘-https://itlao6.com/4935.html

两年前这事在我身上发生了。当时我留意到了某种东西，看起来像是巨大的、皱巴巴的橙子，被称为“相扑柑”。文章源自IT老刘-https://itlao6.com/4935.html

有个店员让我尝了尝。非常美味，我立刻把四个相扑柑放进了购物车。在看到并且品尝前，我并不知道自己需要，我甚至都不知晓相扑柑的存在。文章源自IT老刘-https://itlao6.com/4935.html

在那次购物之旅中，相扑柑就代表着第三类需求：浮现需求（emergent requirements）。文章源自IT老刘-https://itlao6.com/4935.html

浮现需求文章源自IT老刘-https://itlao6.com/4935.html

浮现需求是指在构建产品的过程中发现的需求。团队演示了迄今为止开发的产品特性，这时候用户说:“……能够令它变得更棒”文章源自IT老刘-https://itlao6.com/4935.html

在看到已实现的部分特性后，用户识别到了产品应具有的新功能。浮现需求不是团队通过故事编写研讨会或用户采访能发现的东西。在被访谈时，即使用户再怎么绞尽脑汁，他们也无法识别出这些需求。文章源自IT老刘-https://itlao6.com/4935.html

仅当看到已开发产品时，浮现需求才能在用户的脑海里浮现出来。文章源自IT老刘-https://itlao6.com/4935.html

需求全集

需求全集可以使用下图进行概念化。左边是我们与用户和其他干系人讨论得出的已知需求。右边是疏漏需求和浮现需求，它们共同构成了项目的未知需求（unknown requirements）。

浮现需求是总是存在的

每个项目——好吧，或许不能是类似于重写《扫雷》游戏这样的项目——都存在浮现需求。无论团队成员多么善于提出问题，或者用户对自己的需求考虑得多么透彻，都无法预先确定一切。

团队通常能在减少疏漏需求的数量和重要程度上越做越好。我们可以提出更好的问题，更积极地倾听，花足够的时间与用户相处，等等。但是真正的浮现需求是用户看到产品的早期版本前团队都无法发现的需求。

浮现需求的处理策略

由于浮现需求是无法消除，所以最好的策略是在开发过程中尽可能早地发现它们。

这就意味着产品负责人应该让他们的团队更早地开发他们认为最有可能存在浮现需求的系统部分。

您是如何处理浮现需求的?

浮现需求往往会导致项目延期。因为需求未被发现，所以团队在计划时也往往考虑不到它们。您所从事的项目是否受到过浮现需求的影响？您是如何处理的？

请在下面的评论区分享您的观点。