scope - 项目范围的灵活性？

Question

如果客户请求不在项目范围内的需求，程序员应该有多灵活？

Answer 1

一般观点：

你需要谋生；客户需要一个计算解决方案：客户有权确保您提供的解决方案符合他的需求。达成协议后的更改和添加，反映了您将用户需求分析到系统设计中的能力，因为未能足够深入和详细地调查这些需求：您需要仔细执行此操作并获得书面签字与客户就您的系统设计达成一致。

法律观点：

您应该确定项目的范围，并让客户签署该范围的协议。一旦您达成了该协议，任何未包含在该协议中的内容都将构成一个新项目。

商业视角：

您想继续（与当前和未来的客户）开展业务吗？您需要评估添加所需的新功能对当前项目的影响：如果影响很小，那就去做，但要以书面形式告诉客户您是在帮他一个忙；如果影响更大，那么您必须与客户协商，概述问题，并调整您当前的协议，或制定新协议。你不想做的是与你的客户对抗。

最后：“客户永远是对的。” - （直到你不得不放弃并离开的地步。）

Answer 2

这个问题不能一概而论。这取决于项目。

例子：

客户有钱要烧，时间线长，没有其他项目在忙，我很灵活。

客户很紧张，时间很短，还有其他项目在进行中，我一点都不灵活。

其他因素也会发挥作用，例如为项目选择的过程。例如，您将在敏捷过程中更加灵活，而在瀑布方法中则不太灵活。

Answer 3

我认为你的问题的答案归结为你的客户在时间和成本方面的灵活性，因为你不能在不影响这两件事的情况下改变项目的范围。

如果范围蔓延允许项目发展并对项目结果产生整体积极影响，那么范围蔓延可能是一件好事。您确实需要一个正式的变更流程来管理范围变更。

Answer 4

如果这是一个固定投标项目，那么我愿意进行谈判，并同意扩大一个领域的范围，以换取在其他地方缩小范围，或增加预算，或换取其他一些考虑。

如果是我按小时计费的客户，那么他们可以扩大他们想要的范围，因为无论是否在项目的原始定义范围内，我都会按我花费的时间向他们收费。

Answer 5

预先定义系统将执行的功能列表。

如果客户端添加了新功能，则相应地增加成本和时间。

如果客户决定将某个功能排除在范围之外，那么如果您还没有实现它，则减少成本和时间。