您如何管理客户对变更的需求？

Question

尽管如此，大多数开发人员仍然面临来自非技术客户的需求。有时会有项目经理与客户打交道，并转换他们的需求，而其他时候则不然。无论如何，需求会改变这一事实是不可避免的。

大多数包含“良好编程实践”的内容都与开发适应性强的系统有关，以便它们能够承受不断变化的需求。YAGNI、DRY、松散耦合等原则都有助于这一点。迭代开发过程(如敏捷)也试图解决试图实现移动目标的问题，当然，让系统处于测试中可以使更改变得更加可行。

尽管如此，对于我们中的许多人来说，改变需求不仅可以是损害了我们软件的质量，还可以是耗尽我们的动力，并使我们想要刺伤某人。

这个问题是关于如何管理客户，使他们能够以他们所需要的方式更改他们的需求，同时阻止任意或琐碎的更改。你是怎么做到的？

• 您是否有项目经理将开发人员与客户隔离开来？
• 您有正式的变更管理流程吗？更换经理？
• 当顾客真正需要的时候，得到改变有多难呢？
• 相反，当一个客户“轻浮”时，得到一个改变又有多容易呢？
• 在解释更改的成本时，您给客户提供了多少细节？
• 在收到更改请求后，您能以多快的速度向客户提供此信息？
• 哪些因素可以破坏这一过程(如谁不能对顾客说不呢？)
• 什么对你有用？

Answer 1

如果你正在寻找一个理想的世界，客户永远不会改变他的想法，或者你得到了理想的规范-，你是在错误的商业。尽管如此，我发现管理客户期望和变更请求的最有效机制是建立一个精确的测量系统。

我就是这样管理我的团队的：

1)我们从用户故事开始。客户参与编写它们，开发团队估计每个用户故事将以相对方式花费多长时间。

2)利用以前的经验，我采用了这些相关的估计(故事点)，并为项目的主要里程碑何时完成创建了一个粗略的时间表。

3)在这些里程碑中，我们进行了两周的迭代。客户参与设置审批标准，以及是否已批准该故事。一张简单的刻录图向客户展示了我们离完成发射目标有多近。

4)在审批过程中，客户通常会请求更改，因为功能并没有达到他预期的结果(尽管它符合他最初的批准标准)。此时，您用新的估计生成了一个新的故事。您还可以适当地调整里程碑日期。这就把球放回了顾客球场：

• 通常情况下，他们会意识到他们的变更请求是不值得的(他们必须得到老板的批准)，而我们会扼杀这个新特性
• 有时这很重要，所以我们会推迟到期日，以便在
• 最后，总是有一种选择，可以删除另一个不太重要的特性，这将花费相当的时间。

关键不是逃避更改请求，而是确定每个更改请求都会对产品产生影响。没有免费午餐这样的东西。

Answer 2

我是合作开发人员，所以直接与客户联系。大多数时候，他们根本不知道自己到底想要什么，这是正常的。因此，我们开始缓慢，我给他们的原型，在早期发挥，然后变化将逐步作出。如果我认为客户想要“轻率”的改变，那么我就告诉他，这种改变不起作用，也不需要改变。如果这是5分钟的工作，那么我甚至可能做它无论如何。

它有助于在以后的合同中添加一些维护条款，以便为那些稍后会出现的小更改提供资金。对于更大的变化，你只需按小时收费。

Answer 3

管理客户很难，而且很容易出错。

我发现尽早您需要获得客户的信任。对我来说，我认为你可以这样做：

• 请客户指定一位产品经理--他的思路足够清晰，能够传达他/她想要的需求，并寻求与他/她建立牢固的工作关系。
• 真的试着理解他们的业务--你不需要成为一个领域专家，但是你需要知道客户来自哪里。
• 问一些关于他们想要什么的相关问题--不认为他们要求什么(一开始)就是他们真正想要的。
• 首先，欢迎所有的更改，。这不是客户的烦人和变化无常，它是一个机会，以更好地理解客户真正想要的。如果这花费了你的时间/金钱，那么你可能需要接受它作为一个损失领导者。
• 提供了一个早期的原型，并在切实可行的情况下整合了尽可能多的客户反馈。
• 给客户一个令人兴奋的产品。

一旦您这样做了，并且客户信任您，那么您就可以开始反击不合理的更改，或者要求为以前被认为超出范围的事情支付额外的费用/时间。

当然，你不能与每一个客户建立这样的关系，有些人是白痴(在这种情况下，看看你是否可以任命一个不同的产品经理)，但是你应该尽你所能建立一种有效的工作关系。