如何管理和估计从客户那里收到的非结构化需求

在项目投标阶段的很多时候，我从各种来源（电子邮件，Word文档，excel）以非常非结构化的格式从潜在客户那里收到软件系统的要求。通常是一群来自客户方面的“产品开发”人员针对他们所遇到的业务问题提出这些“建议的解决方案”。尽管他们是业务领域的专家，但很多时候他们没有正确的解决方案。

这导致

• 相同需求的多个版本
• 将两个需求混为一谈
• 稍后有几个版本的需求，再将合并在一起的需求分离出来，每个需求都包含一些新增加的内容

您如何处理这些需求，并在开始开发之前将它们分类为正确的用例？从第一次构思到将其具体化为合适的用例，我们可以使用哪些工具来跟踪特定需求的历史？根据这样收到的需求来估算工作是一场噩梦，最终导致在正确理解需求并正确估算针对需求的工作时犯了错​​误。

一旦我们赢得了该项目，客户就可以对他们的要求进行更多的考虑，并能够正确地阐明它。在这种情况下，发生的事情是某些功能被丢弃，某些功能得到增强，某些功能又有了新的转变。从根本上讲，这可以使赢得项目之前所做的某些工作项估计无效。我很想知道是否有任何系统可以构建具有特定需求的树，以及每个分支如何导致不同的估算。

有任何技巧，工具和技巧可以使此活动更易于管理吗？我只是想从比我在需求管理和工作量估算方面更有经验的人那里获得一些见解。

需求将不断增长和变化。我认为没有人可以争论。

如何收集和处理传入的请求。

以我的经验，如果只有一个或很小的一组客户充当筛选器，以将新的或更新的需求交付给一小部分开发计划人员，那么它在收集需求时会有所帮助。他们身边的任何人都可以提出建议或写下来，但只能通过很少的一部分来交付。一方参与另一方交流的人数越少越好。

过滤较小的一组人员的目的不是要丢弃或减少其他人投入的精力和信息，即使表面上重复或看似不重要，也要限制失败点：信息丢失或处理不当。它遵循的原理类似于封装和接口的目的：保护私有数据，并建立用于处理类似请求的通用协议。我重申一下：提交副本是可以的。作为一个计划者，这告诉我他们正在谈论或提议的事情很重要。保存或记录所有内容。

如何跟踪和组织需求

在短期内，走低技术

显然，有一些低技术含量的解决方案可以在很大程度上有效地组织和跟踪传入的需求：白板，便利贴，海报板，您所拥有的。这些对于短期计划可能非常有用。它们高度可见，接受自由格式表示法，并且易于“重新配置”。

从长远来看，请使用可搜索，可排序，可链接的软件工具

对于更长距离的努力，某种软件将很有价值。有专门的需求管理工具：Doors，Clearcase / Clearquest和许多其他工具。那些高度专业化的工具擅长于其工作，但往往过于矫kill过正。有时，即使是简单的旧电子表格也绰绰有余。我个人认为一般问题跟踪系统对于完成此任务非常有用，现在我最喜欢的是redmine，但我敢肯定其他的也很好。

使用问题跟踪系统，您选择允许的任何人都可以创建“新问题”或要求，并添加他们认为合适的任何细节。他们可以观察问题，并反馈您采取的任何措施。您可以对其进行重新分类，调整优先级，重写正文，附加补充信息，将其与其他“问题”相关联，升级为更高级别的功能或“用例”或故事，或者使用适合您系统的任何术语，广告素材。换句话说，您可以做很多事情来通过问题创建可追溯，可排序，优先级，历史感知的相关需求列表。再加上开箱即用的可配置性和开源性，如果该工具在任何时候都不是我所需要或想要的，那么我可以很容易地对其进行更改，以更好地满足我的流程需求。

关于工具的最后说明，我与之交谈过的一些人在变更管理和版本控制系统中使用普通的旧文本文件取得了很大的成功。他们显然从历史版本中受益。他们还利用基本操作系统和辅助工具来查找，链接和分类需求。他们无法添加太多结构化的相关元信息，但他们觉得自己不需要它，并且他们的努力没有增加足够的价值。对于您而言，可能是这样，也可能不是。这样做的好处是可以减少开发堆栈中要管理和维护的软件数量。

合同授予后/项目开发后启动要求

问题的最后一个方面是开始努力后如何管理需求。我认为对此有两种领先思想，而您如何处理它们则取决于您与客户关系的性质：首先，如果按照固定价值签订合同，则可以纳入合同授予后提出的要求。这意味着它们可能会改变工作范围，因此，当交付并接受这些额外的项目时，费率或账单会更高。除非从接受的提案中删除了同等的精力。如果要更改范围，则必须确保客户理解并接受后果，否则，必须将这些逾期提交的表格提交。

其次，对于授予合同后出现的新要求，并且合同更加注重时间和精力（完成工作主体需要花费什么），您可以并且应该更加灵活一些，如果客户坚持在特定的搜索过程中将其包括在内。只要您说的一切都会完成，无论您是否包括在内，您都将获得报酬。

如果您不熟悉它们，则可能需要看一下看板方法和敏捷方法。这些技术可以帮助将重点放在紧迫的问题上，而不必忽略长期发展目标。

将选项呈现为“假设”场景，并为客户提供选择和决定

无论哪种情况，与客户和您的团队进行谈判时，采用“假设”估计都是一个很好的策略。按计划对任务，它们的成本和时间表进行并排比较，其中一列显示替代方法的相同信息。Microsoft Project可能是一个不错的选择，因为您可以基于一组非常相似的任务来构造不同的估算值。

但是，即使是基本的电子表格，通常也可以有效地证明特定的更改或包含内容将如何影响成本和进度。在这种情况下，清单在显示差异方面可能与树一样有效。您选择用于构建这些方案的工具和方法在很大程度上取决于项目和人员的规模（但是，即使像MS Project这样的Triple A软件也有其自身的实用性和能力限制）。

将这些方案视为内部工作项目，并将其保存在项目期间。它们是决策和谈判过程中的重要示范。您可能还需要重新审视它们，或者在连续的假设情况下重复它们。

在准备假设情景时，从技术或实施角度（以简化术语）补充说明赞成和反对的情况可能有助于确定一个替代方案为何会产生如此重大影响的理由。

我将其视为一个迭代过程。步骤1是收集需求。步骤2是对它们进行排序。步骤3是确定它们的优先级。步骤4是将每个细分成足够小的位数来估算工作量。第五步是将这些部分整合到一个全球工作量桶中（比如说84个人日）。步骤6是将工作量映射到资源上（84人日/ 2开发者= 42天）。

因此，现在您处于第1步和第2步之间。您有需求，但是没有所需形式的需求。

假设您有相同要求的多个版本。这些基本相同吗？如果是这样，请选择似乎最清晰的内容并使用它。如果它们在细节上有所不同，请选择似乎最合逻辑的内容并使用该内容。然后向客户发送一条消息，要求他们验证要求。您可能需要反复来回才能获得正确的要求。不要放弃或灰心。由于需求不佳，许多项目失败了。

使用Microsoft项目可以使工作和计划​​与不断变化的需求保持同步。如果客户要求更改，请说明其他工作，将其插入模型中，并告知他们新的日期。不要沉迷于相信您可以随机地招募新开发人员来填补空缺。每当添加新资源时，您的日程表都必须考虑加速时间。如果您注意每个项目并从中学习，则只能正确地对此建模。假设您在项目X进行了4个月的搅动后就将Bob带上了项目X。他在第一个月的工作效率如何？第三？

您应该每周重新访问项目模型，并在需要时进行任何更新。保留更改的历史记录。这将帮助您将来提供更好的估计。

道格