project-management - 您如何根据不断变化的需求管理客户？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

2年前关闭。




Improve this question




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

构成“良好编程习惯”的大部分内容都与 developing systems which are adaptable 有关以便他们能够承受不断变化的需求。 YAGNI、DRY、松耦合等原则对此有所贡献。诸如敏捷之类的迭代开发过程也试图解决试图击中移动目标的问题，当然，拥有一个正在测试的系统使得进行更改变得更加可行。

尽管如此，似乎对我们中的许多人来说，不断变化的需求不仅可以 hurt the quality of our software ，但也可以drain our motivation并让我们想要刺伤某人。

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

您是否有项目经理来将开发人员与客户隔离开来？

您有正式的变更管理流程吗？换经理？

客户在真正需要时获得改变有多困难？

相反，当“轻率”时，客户获得更改有多容易？

在解释更改的成本时，您向客户提供了多少详细信息？

在收到更改请求后，您能多快向客户提供此信息？

哪些因素会破坏该过程(例如 PM's who can't say no to the customer? )

什么对你有用？

Answer 1

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

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

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

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

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

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

很多时候，他们意识到他们的变更请求不值得(他们必须得到老板的批准)，我们将取消新功能

有时这很重要，因此我们会延迟截止日期以在

中获得该功能

最后，总有一个选项可以杀死另一个不太重要的功能，这将花费相同的时间。

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