8

尽管Steve Yegge 很有智慧，但大多数开发人员都面临着从非技术客户那里收集到的需求。有时有项目经理与客户打交道并翻译他们的要求，有时则没有。无论如何，需求将发生变化的事实是不可避免的。

构成“良好编程实践”的大部分内容都与开发适应性强的系统有关，以便它们能够承受不断变化的需求。YAGNI、DRY、松散耦合等原则促成了这一点。诸如敏捷之类的迭代开发过程也试图解决试图击中移动目标的问题，当然，拥有一个正在测试的系统使得进行更改变得更加可行。

尽管如此，对于我们中的许多人来说，不断变化的需求似乎不仅会损害我们的软件质量，而且还会消耗我们的动力，让我们想要刺伤某人。

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

  • 您是否有项目经理将开发人员与客户隔离开来？
  • 您有正式的变更管理流程吗？更换经理？
  • 客户在真正需要时获得更改有多难？
  • 相反，当“轻率”时，客户获得更改有多容易？
  • 在解释变更成本时，您向客户提供了多少细节？
  • 在收到更改请求后，您能多快向客户提供此信息？
  • 哪些因素会破坏流程（例如无法对客户说不的 PM？）
  • 什么对你有用？
4

7 回答 7

9

如果您正在寻找客户永远不会改变主意的理想世界，或者您获得了理想的规格，那么您就错了。话虽如此，我发现管理客户期望和变更请求的最有效机制是建立一个准确的测量系统。

这就是我管理团队的方式：

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

2）利用以前的经验，我采用这些相对估计（故事点），并为项目的主要里程碑何时完成制定一个粗略的时间表。

3) 在这些里程碑中，我们运行 2 周的迭代。客户参与设置批准标准以及故事是否已被批准。一个简单的燃尽图向客户展示了我们离实现发布目标有多近。

4) 在审批过程中，客户通常会要求更改，因为该功能没有达到他的预期（即使它符合他最初的审批标准）。此时，您会生成一个带有新估计的新故事。您还可以适当调整里程碑日期。然后将球放回客户场地：

  • 他们经常意识到他们的变更请求不值得（他们必须得到老板的批准），我们会取消新功能
  • 有时它很重要，所以我们会推迟截止日期以获取该功能
  • 最后，总是可以选择杀死另一个不那么重要的功能，这将花费相同的时间。

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

于 2009-01-26T13:36:12.767 回答
3

我作为独立开发人员工作，因此直接与客户联系。大多数时候他们不知道自己真正想要什么，这很正常。所以我们慢慢开始，我很早就给他们原型让他们玩，然后逐渐做出改变。如果我认为客户想要“轻率”的更改，那么我会告诉他这种更改不起作用或不需要。如果是 5 分钟的工作，那么我什至可能会这样做。

它有助于稍后在合同中添加一些维护条款，以便为稍后出现的那些小改动获得资金。对于较大的更改，您只需按小时收费。

于 2009-01-26T13:18:46.827 回答
3

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

我发现你需要尽早获得客户的信任。对我来说，我认为您可以通过以下方式做到这一点：

  • 要求客户任命一名产品经理——他/她的思维清晰，可以传达他/她想要的要求，并希望与他/她建立牢固的工作关系。
  • 真正尝试了解他们的业务——您不需要成为领域专家，但您需要知道客户来自哪里。
  • 问他们想要什么的相关问题——不要假设他们（起初）要求的是他们真正想要的。
  • 首先欢迎所有的变化。这不是客户烦人和善变，而是一个更好地了解客户真正想要什么的机会。如果这会花费您时间/金钱，那么您可能需要接受它作为损失领导者。
  • 尽早交付原型，并尽可能多地纳入客户反馈。
  • 给客户一个踢屁股的产品。

一旦你做到了这一点，并且客户信任你，那么你就可以开始拒绝不合理的更改，或者为以前被认为超出范围的事情要求额外的付款/时间。

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

于 2009-01-26T14:47:09.597 回答
1

你不能指望客户一开始就知道他们想要什么，所以你必须适应。但你也需要为了改变而停止改变。

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

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

有时这很有效，并且达成了很好的妥协。其他时候，顾客把他们的玩具从婴儿车里扔了出去，不管他们为了实现这个功能而必须走多高，质量都会降低。

如果客户付款，那就是另一场比赛了。需要让他们意识到变更成本，并且成本会随着产品接近完成而增加。这意味着您必须对您将交付的内容进行大量前期分析，并确保就规范达成一致。因此，您可以衡量发生了什么变化。对于任何一方来说，这可能都不是最有效的解决方案，但它确实可以让事情变得干脆利落。所以他们不会不满意，你也不会最终免费做大量的工作。

于 2009-01-26T14:22:39.350 回答
1

在软件工程中，变化只是一个事实。它会发生。对我们来说，一切都是有代价的。我们几乎会做出客户想要的任何改变，但总会有时间估算和与之相关的成本。我们是否曾经告诉客户不 - 通常不是，但有时更改请求的成本非常高。我们确实在潜在的安全威胁等方面划清界限，在这种情况下，我们会冷静地向他们解释我们无法满足该请求。

我们向客户解释了多少，我们解释了资金将分配到哪里，用于开发，用于分析等等。我们没有明确地告诉他们为什么某些东西会以这种方式收费。现在我承认，这确实与我们的一些客户有所不同。他们中的一些人得到了非常详细的账单，以确定在哪里花费了多少小时。为了得到合同，我们必须同意，尽管这对我们来说非常罕见。

我们的销售人员有时不能拒绝，这可能会导致问题。我们花了很多时间来解决这个问题，但不幸的是它仍然出现了。我们通过引用一些东西来解释他们花了我们多少钱而不研究它需要什么来对抗它。透明度是所有级别的关键。每个人都必须知道他们的决定如何影响底线。

我们会做无意义的改变吗？是的。您必须记住的是，当您大部分时间按小时计费时，5 分钟的更改按整小时计费，因此这是非常有利可图的。我们之前解释了所有这些，就像我们对任何更改请求所做的那样，以便他们意识到这一点，但它往往有助于阻止这种行为，除非它真的很重要。事实上，我们对待所有的变化都是一样的。我们不认为我们知道什么对他们来说是轻浮的，无论我们认为它可能多么荒谬。我们有一个正式的变更流程，客户要求我们将其写下来并让他们签字，这就是我们对其进行评估并提供工作成本估算的内容。他们要么同意在这种情况下正式签署一份文件，让我们知道可以开始，要么他们撤销请求。我们努力勤奋，

我的一位同事给了我听过的关于管理客户关系船舶的最佳建议。这是一个给予和接受。为了让客户满意，你必须愿意在他们需要的时候帮助他们，但同时，你必须能够说不。与人打交道时，他们希望您帮助他们，但他们也希望您有脊椎并为自己挺身而出。这样就变成了双赢的局面。

于 2009-01-26T14:36:25.750 回答
1

我更喜欢“不断变化的需求”这个术语。MMLehman 教授（http://www.doc.ic.ac.uk/~mml/和http://en.wikipedia.org/wiki/Meir_Manny_Lehman）对软件进化的研究做出了相当大的贡献；他的作品还表明，并非所有类型的需求都会演变。如果他们碰巧在其中一个要求保持不变的系统（即数学库等）上工作，他们可能会认为自己很幸运。

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

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

  • 在初始计划中建立一些空间，以考虑不断变化的需求、多个检查点或迭代。

  • 要么将易变的需求放在项目的开始，以便某种原型或可行性研究可能会澄清它们，要么计划在项目后期进行更改。

  • 监控需求是否仍然相关。

  • 手边有一份最新的、按优先顺序排列的当前需求列表。没有其他方法可以帮助控制进化，让所有利益相关者都能看到当前“必备品”的所有利益相关者，包括他们的相对优先级和成本。

  • 继续管理客户对事情需要多长时间的期望；这也有助于保持专注。

  • 如果需要，请引入正式流程以更改或添加需求。过程描述需要详细说明所涉及的角色、审查频率等。它可以很好地防止一些政治和最投机但不是必要的要求。

  • 即使是第一个版本，也要花一些时间进行重构。由于在开发过程中获得了额外的知识，您很可能会抛出全部或部分解决方案。

于 2009-01-27T16:14:46.893 回答
0

客户来找你做某事是因为他们要么没有时间去做，要么不知道该做什么（并且想付钱让你为他们做这件事）。如果您有不断变化的需求，那是因为后者。换句话说，他们付钱让你弄清楚细节！他们知道自己喜欢和不喜欢什么，但他们不知道它是如何工作的。

认识到这一点，无论解决方案需要什么到位。

于 2009-01-27T19:40:58.207 回答