如何在考虑到变化的需求时管理客户？

Question

如何在考虑到变化的需求时管理客户？

project-managementrequirementschange-management

8

史蒂夫·耶吉的智慧尽管如此，大多数开发人员面临的要求都来自非技术客户。有时会有项目经理与客户打交道并翻译他们的需求，而有时则没有。无论如何，需求将会变化是不可避免的事实。开发适应性强的系统是构成“良好编程实践”的大部分内容，以便它们可以承受不断变化的需求。像YAGNI、DRY、松散耦合等原则都有助于这一点。迭代式开发过程，如敏捷开发，也试图解决试图击中移动目标的问题，当然，拥有一个正在测试的系统使得进行更改变得无限可行。

然而，对于我们许多人来说，需求的变更不仅会损害软件质量，还会消耗我们的动力，使我们想要刺伤某个人。

这个问题是关于如何管理客户，使他们能够以需要的方式改变其需求，同时防止任意或轻率的更改。你该怎么做？

你们有项目经理来隔离开发人员和客户吗？
你们有正式的变更管理流程吗？变更管理员？
当客户真正需要时，他们很难获得变更吗？
相反，当变更是“琐碎的”时，客户很容易获得变更吗？
在解释变更成本时，你们向客户提供多少细节？
收到变更请求后，你们能多快向客户提供这些信息？
哪些因素可能破坏该过程（例如无法对客户说不的PM？）
你们的成功方法是什么？

- Adam Bellaire

7个回答

3

我作为独立开发者，直接与客户联系。通常情况下，他们并不清楚自己实际想要什么。因此，我们会慢慢开始，并且我会提供原型让他们尝试，然后逐步进行更改。如果我认为客户想要“琐碎”的更改，那么我会告诉他这个更改不起作用或者不需要。如果只需要5分钟的工作，那么我甚至可能会去做。

后期在合同中加入一些维护条款可以帮助解决后来出现的小问题，并获得报酬。对于较大的更改，您只需按小时计费即可。

- Riho

3

管理客户是一件困难的事情，很容易出错。我认为，尽早赢得客户的信任非常重要，这可以通过以下方式实现：

- 要求客户任命一个清晰思维、能够表达需求并建立良好工作关系的产品经理。 - 真正了解他们的业务，不需要成为领域专家，但需要知道客户的出发点。 - 对他们想要的东西提出相关问题，不要假设他们最初问的就是他们真正想要的。 - 最初欢迎所有变化。这不是客户烦人和善变，而是更好地了解客户真正想要什么的机会。如果这会浪费你的时间/金钱，那么你可能需要将其视为亏损。 - 尽早交付原型，并尽可能纳入客户反馈。 - 给客户提供优秀的产品。

一旦你做到了这些，客户信任你后，你就可以开始拒绝不合理的改变，或者要求额外的支付/时间来完成之前被认为超出范围的任务。

当然，并非所有客户都能建立这种关系，有些客户是白痴（在这种情况下，看看是否可以指定不同的产品经理），但你应该尽力构建有效的工作关系。

- HermanD

1

你不能期望客户在一开始就知道他们想要什么，所以你必须具备适应性。但同时，你也需要停止为了变化而变化。

这是针对“内部”客户的。

我发现与客户讨价还价是一个有效的方法。如果他们等待或者牺牲其他（尚未实现的）功能，他们可以得到任何他们想要的功能。这迫使他们考虑所要求的更改与整个系统的价值之间的关系。

有时候这很有效，可以达成良好的妥协。但有时候客户会把他们的玩具扔出去，不断提高实现该功能的要求，从而降低质量。

如果客户付费，那就是另外一回事了。他们需要意识到变更的成本，并且随着产品接近完成，成本会增加。这意味着你必须进行大量的前期分析，确定规格并确保达成共识。然后你可以衡量发生了什么变化。这可能不是双方最有效的解决方案，但它确实保持了事情的明确和简洁。这样他们就不会不满意，你也不会免费做大量的工作。

- Jeremy French

1

在软件工程中，变化是不可避免的事实。我们会为客户做出几乎任何更改，但是每个更改都需要时间和成本估算。我们通常不会拒绝客户的要求，但有时候更改的成本非常高。在这种情况下，我们会明确告诉客户我们无法满足请求，例如潜在的安全威胁等。

我们向客户解释资金分配情况，包括开发、分析等方面的费用。我们不会明确告诉他们为什么某些东西的成本如此之高。当然，对于一些客户，我们会提供详细的账单，说明花费在哪里以及花费了多少时间。虽然这对我们来说非常罕见，但为了签订合同，我们不得不同意。

我们的销售人员有时候会无法拒绝客户的要求，这可能会导致问题。我们花费了很多时间来解决这个问题，但不幸的是它仍然会出现。我们通过解释他们没有研究就报价所造成的损失来解决这个问题。透明度是关键，每个人都必须知道他们的决策如何影响最终利润。

我们会进行琐碎的更改吗？是的。你必须记住的是，当你按小时计费时，大部分时间5分钟的更改也会被计为一整个小时，所以这是相当有利可图的。我们像处理任何更改请求一样在之前解释了所有这些内容，让客户意识到这一点，但它往往有助于防止这种行为，除非它真的很重要。事实上，我们对所有更改都采取同样的处理方式。我们不假设我们知道他们认为什么是琐碎的，无论我们认为它可能有多荒谬。我们有一个正式的更改流程，客户提出请求后，我们将其写下来并让他们签字确认，然后我们评估它并提供工作成本估算。如果他们同意，他们会正式签署文件告诉我们可以开始了，否则他们会撤回请求。我们尽力认真处理，但我们让他们知道需要几天时间才能回复他们的请求。

我的一位同事给了我关于管理客户关系的最佳建议。这是一个互惠互利的过程。为了让客户满意，你必须愿意在他们需要帮助时提供帮助，但同时，你也必须有能力说不。当与人打交道时，他们希望你帮助他们，但他们也希望你有骨气并为自己辩护。这样就变成了双赢的局面。

- Kevin

1

我更喜欢使用“不断演变的需求”这个术语，而非“变化的需求”。M.M.Lehman教授（http://www.doc.ic.ac.uk/~mml/和http://en.wikipedia.org/wiki/Meir_Manny_Lehman）在软件演化研究方面做出了重大贡献；他的作品也表明，并非所有类型的需求都会演变。如果你恰好在处理这些系统之一（例如数学库等），那么你可能会觉得自己很幸运，因为需求保持不变。

对于我们其他人来说，经验表明开发人员更喜欢尽可能提前获得有关需求的详细信息，而客户或最终用户则更注重在开发过程的后期指定或调整需求的能力。前者需要详细信息来帮助规划和设计解决方案，而后者可以通过晚期更改需求获得战略优势，因为这给了客户一些回应环境变化或在项目早期阶段/迭代中获得的信息的余地。能够拥有详细计划并进行大规模更改的能力之间的权衡，主要决定了开发过程本身（瀑布、敏捷、螺旋等）。

以下是一些管理需求演变的实用建议：

在初始计划中留出一些空间，以考虑不断变化的需求、多个检查点或迭代。
要么将易变的需求放在项目开始阶段，以便进行某种原型设计或可行性研究来澄清它们，要么计划在项目后期进行更改。
监控需求是否仍然相关。
随时准备一个最新的、优先级排序的当前需求列表。没有什么比让所有利益相关者清楚地看到当前“必须拥有”的内容及其相对优先级和成本更能控制演进。
管理客户对完成时间的期望，这也有助于保持专注。
如果需要，引入正式的更改或添加需求的流程。该流程描述需要指定涉及的角色、审查频率等。它可以作为一个很好的保障，防止一些政治上的和大多数机会主义但并非必要的需求。
即使是第一个版本，也要留出一些重构的时间。在开发过程中获得额外知识后，你很可能会抛弃整个或部分解决方案。

- Totophil

0

客户来找你做事情，是因为他们要么没有时间做，要么不知道该怎么做（并希望支付费用由你代劳）。如果有变化的需求，那就是因为前者。换句话说，他们付钱让你去解决细节问题！他们知道自己喜欢什么，不喜欢什么，但不知道它是如何工作的。

认识到这一点，任何解决方案都会落实到位。

- MSN

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Jim · Accepted Answer

如果你在寻找一个完美的世界，客户永远不会改变主意或者你得到了理想的规格 - 你可能不适合这个行业。话虽如此，我发现管理客户期望和变更请求最有效的机制是建立一个准确的度量系统。

以下是我团队的运作方式：

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

2）利用以往经验，我将这些相对估算（故事点）转化为项目主要里程碑完成的大致时间表。

3）在这些里程碑内，我们运行两周的迭代。客户参与设置批准标准以及是否批准故事。简单的燃尽图显示给客户我们距离达成发布目标有多近。

4）通常在批准会议期间，由于功能没有按照预期实现（即使它符合原始批准标准），客户会提出更改请求。这时，您可以生成一个新的故事并进行新的估算。您还可以相应地调整里程碑日期。这样就把球传回给了客户：

- 通常情况下，他们会意识到他们的更改请求并不值得（他们需要获得他们的老板批准），我们将放弃新功能。 - 有时很重要，所以我们会推迟截止日期来实现该功能。 - 最后，还有一个选项是放弃另一个不太重要的功能，需要相同的时间。

关键在于不要逃避变更请求，而是建立每个变更请求对产品的影响。没有免费的午餐这回事。