如何应对频繁的需求变更？

我目前在我的工作场所中正面临压力很大（我认为）的情况。

我们已经开始开发新项目，获得一些需求，实施它，然后向您展示可以称为“业务顾问”的人（知道业务需求但不会使用该程序的人）。该人员应该从客户的角度评估应用程序，进行测试等。

以下是“过程”的外观：

1. 商业顾问在晚上与我的老板在Windows Messenger上进行一两个小时的交谈
2. 第二天，我收到包含该对话副本的电子邮件。我应该从中选择任务，检查报告的错误（通常不是错误，只是测试不善，忘记了过去的机构）
3. 我实施变更，实施被接受，然后一两个星期后，事实证明他们不想要他们（他们与一些潜在客户进行了5分钟的交谈，他提出了修改建议）-我必须进行新的变更

不要误会我的意思，我知道有时候需求会改变。让我不高兴的是，这种变化在我的工作场所发生的频率如何，而“管理”的难易程度是两个因素提出了新的要求，或者有时是对现有功能的根本性更改。

同时，我们在紧迫的期限内进行工作，我给人留下的印象是，与其使用我们的软件，不如继续前进。

我寻求您的建议如何处理这种情况？这是正常情况，我对此很敏感吗？

尽可能通过电子邮件发送对话，并将其转换为需求文档。列出您可以从中收集的任务，并根据您认为优先的顺序对其进行排序，并为每个任务分配一个估算值。然后询问他们想要下一个版本的功能。

基本上，强制某种反馈循环，让管理层知道您将要构建什么。编写您自己的需求文档，直到他们收到消息为止。

故事卡

我认为您的情况非常适合介绍用户故事。它们确实为您的经理提供了一种持续的，交互式的方式来设置优先级，这很有帮助，当一周后他再次想到这个想法并意识到不可行时，他甚至可以将其丢弃。

在现实世界中，需求会定期更改。从好的方面来说，您在完成软件的构建和发布之前便已找到有关它的信息-您从软件的直接用户那里获得了紧密的反馈周期，这实际上很棒。

似乎最大的问题是变更的临时管理。您拥有敏捷/ Scrum所认为的“产品所有者”，可以提供反馈，但是该过程的文档记录不充分，而且考虑周全。

您可能希望查看Scrum中的模型，以及他们对有效产品所有者的看法，以帮助您进行下一步。

因此，与其建立临时流程，不如将其转移到一个与“业务顾问”建立更紧密，更有用的关系，每个人都在同一页面上讨论他们所讨论的变更结果的世界。

您当前的流程使这些人很容易仅凭头脑风暴而又不顾及将消耗的资源和金钱。如果他们需要所有这些功能，则需要获得一些“游戏中的皮肤”。

接收对话的电子邮件，并将其放入某种功能/错误跟踪应用程序中，即使它只是电子表格也是如此。将新添加的内容发送回给业务顾问，并请他/她在每个项目上签字或提供更正。除了批准之外，他们还应该确定优先级（您首先要选择哪个？）。

在他们批准之后，将他们的时间表发回给您，以便您完成测试的时间，并让他们有时间进行测试/批准完成。

我知道创建这种类型的文档并不是您成为程序员的原因，但是您可能会冒险丢掉这些列表，或者继续丢掉来之不易的代码。

推回。负责人需要查看这些请求的成本。

需求变更并不总是不好的。关键是要记住您的客户。在这种情况下，您的老板很可能是您的客户。您需要通知老板，您认为这些不断变化的要求限制了您生产对他最有用的产品的能力。不断响应变化，您可能会从中受益，从而使业务受益。如果是这样，那就是他们的商业模式，尽管您建议在这种情况下跑山路，但您没有做错任何事情！

那些对需求变更感到沮丧的人通常会因为他们对每个变更的管理水平而受到重视。这种“已充分处理的更改数量”度量标准可能是您真正遇到麻烦的根源。 考虑与老板讨论更好的指标。 当我面对不断变化的需求时，我会努力编写使自己适应不断变化的需求的内容。我将不再编写仿真和每天分析数据，而是编写工具，使运行仿真和分析数据的过程更便宜，并随着时间的流逝而获得回报。如果那仍然太疯狂，我什至可以编写一个工具来编写工具！

您的流程可能会受益于一些敏捷原则，例如锁定迭代。我认为一周的时间与您描述的快速变化是合理的。2周最终可能会更好。

一旦确定了足够重要的要求，在Project Owner构建这些要求时，请扮演角色的人在这些要求上签名并将其锁定一周。为自己分配足够的工作到忙碌的地方，并让您知道自己的分配情况。例如，如果每周您可以产生16点的工作，而您有16点的工作，那么您在该周就得到了充分利用。（积分概念来自敏捷工作流）

如果一周中有变化，请说出这些神奇的话：

我可以执行[此新功能]，[此新更改]，[等]，但是您不想做什么？

也就是说，您的资源有限，您只能从事大量工作。如果有新的工作项目进入，则您将被限制为现有的资源，并为新项目分配点数，并替换/更改其他项目以代替新的项目。与项目所有者一起重新安排迭代列表的优先级，您应该会更好地应对变更。

如果需求更改的频率高于此频率，则可能需要协商环境中的更多稳定性。

短语“需求变更”有时会被IT人员滥用。您所描述的确实是对需求的更改，但这可能是因为以下一项或多项（我对您的情况了解不多，所以以下内容可能适用或可能不适用）：

1. 管理层的雄心壮志是使最终用户尽快满意并显示快速进度。

2. 缺乏详细的分析。请记住，分析师需要提出有关为什么不仅是什么的问题。分析人员不仅需要接受订单，还需要与最终用户“思考”一个“解决方案”。

3. 缺乏正式的需求验证和确认流程，后又需要批准。

4. 要求不正确的人执行一个或多个角色，而他们不一定经过培训，例如业务分析师或系统分析师角色。

5. 有限的原型制作。

6. 这种假设/恐惧是必须迅速完成的，如果不是，那就应该归咎于IT。

除非正确解决了上述所有问题，否则IT与业务/最终用户之间的关系将会很紧张。请注意，这并不意味着以上几点是结论性的。还有其他一些因素会导致与您的情况类似的压力情况，但我认为此清单应该可以帮助您前进。

我认为您应该从几个方向解决这个问题：

1. 让所有利益相关者（包括整个开发团队）与业务顾问会面（离线/在线），并尝试了解领域，愿景并共同头脑风暴。

2. 形式化需求/用户故事，分级每个人的：
   一。优先（紧迫性/重要性）
   b。成熟度（定义的明确程度-多数股权持有人理解并同意*）
   c。复杂性（粗略估计）
   
   在选择下一步要处理的需求/用户存储时，请考虑所有三个因素。如果需求的成熟度很低，请在其之前添加一个研究任务，在该任务中，您与所有利益相关者联系，调查需求背后的原因并更好地定义需求（编写用例和/或创建线框并展示它们），然后再采取行动之上。

3. 在每次实现之前进行设计时，请尝试考虑一些向前的步骤-设计一种灵活的体系结构，该体系结构具有适应变化的空间。

4. 尝试适应敏捷开发过程，例如SCRUM或看板-这将为您提供用于开发具有变化需求的产品的工具包。

您还应考虑要求主持人将此问题移至PM.stackexchange.com（通过标记），因为即使此问题适合此处，也可以更好地解决。

（*）利益相关者协议：商业，市场营销，项目管理，开发和质量保证。