Project management 当客户端的bug真的是一个新特性时

我读 我想知道你们是如何处理bug和特性的。我曾经遇到过一个客户需要静态报告的情况。在项目接近尾声时，在完成了大部分关于报告的工作之后，他说他一直想要动态报告。这种改变并不容易，因为我们选择的框架不支持动态报告。这是一个奇怪的情况，因为客户有一个编程团队，所以他们应该知道。也许只是缺乏沟通技巧

你们如何处理那些试图让你们添加功能的客户，因为他们忘记了，改变了主意，或者被误解了

我指的是大功能，不是小功能

编辑：

---

他表示，预算是固定的，不能更改，并且该功能（与其他功能一样）至关重要，没有它，他们不会接受该系统。（只是最坏的情况）

我们有书面的规范，并让客户签字确认，同意为该文档中描述的功能付费。如果他们以后对一些简单的事情改变主意，我们通常会在不收取额外费用的情况下进行更改，但是，像您所描述的任何东西都需要新的采购订单。

如果项目计划/书面协议中没有，则超出范围。

重要的是，双方在软件开发过程的早期就了解他们从资金中得到了什么。敏捷方法是管理这个过程的一个极好的工具。如果您有团队的速度，您可以相当准确地确定在每次迭代期间可以添加多少功能。评估任务，并让客户参与确定要添加哪些功能以及哪些内容不太重要的优先级。确保在每次迭代后都有一个客户演示，以展示在当前迭代结束时双方都同意可以使用的功能。如果客户想要另一个特性或对您已经同意的特性进行重大更改，请估计进行此新更改或返工当前功能所需的故事点数量（敏捷中使用的工作单元）。这将帮助他们移除另一个他们认为不太重要的特征。这让每个人都感到高兴，当产品“发货”时也不会有任何意外。好吧，最简单的答案是预算或合同规定了要求。对这些需求的更改必须作为额外提交，然后按照与原始项目相同的流程进行。必须对其进行预算和估算

一旦所有这些都完成了，如果客户希望它接近最初的发布日期（这是可行的），增加额外的加班时间

---

至少，这是我所做的。

我向他们收费。

根据我的经验，在这个问题上，我一直站在两个方面，这通常更多的是关于经济学，而不是关于编程、流程或项目管理

我们，客户，经常说“这可能是一个功能，但如果我们称之为bug，也许我们可以让他们免费做。”

最后，作为程序员，我们收费与否更多地取决于它是否有助于或损害我们未来工作的机会。我们，客户，将未来工作的胡萝卜作为激励，让程序员免费做额外的工作

---

我不相信仅仅因为我们有一个更好的流程来说“这是一个bug”或“这是一个新功能”，所有这些都会改变。

在我看来，客户可能在寻找借口，不支付任何费用就退出协议。如果他可以任意添加特性并坚持进行最终验收，而不需要额外的费用，他有办法让你违反合同

有两种明显的方法可以避免这种情况

一种是在整个开发过程中进行支付，这样客户就无法从大部分支付中摆脱出来，而您在任何时候所做的工作或多或少都会得到补偿

另一个是良好的合同。对于任何一个合理的软件项目来说，几小时的律师费是防止类似情况发生的廉价保险。如果你确信你可以起诉客户收取约定的费用并胜诉，那么客户就不太可能制造麻烦，如果其他一切都失败了，你可以起诉

我不知道你工作的合同安排是什么（而且我也不是律师），但在这种情况下，我会找个律师，看看我的处境如何。即使你的法律地位可疑，你的律师的一封信也可能有助于解决问题

---

不要再陷入那种境地

试图说服他们放弃该功能是没有意义的。毕竟，不管是否存在通信问题，任务是在软件中提供客户所需的内容

我将使用如下铁三角论点：
1） 显然，我们希望交付您所需的产品，因此让我们共同努力。
2） 我们都明白，无论我们如何走到现在，我们只能从今天的位置继续前进。
3） 我们也明白，实施变革需要时间和金钱，而这些都必须来自某个地方。
4） 此时，您可以选择以下选项（选择一个）
*将计划用于某些其他功能的工作替换为此更改所需的工作，以符合预算和时间表（牺牲其他功能）
*延长截止日期（增加成本/轮班截止日期）
*增加资源（增加成本）

---

警告：虽然如果你在做制造型工作（再制造1000支铅笔），C是合乎逻辑的，但在软件工程这样的研发工作中，C通常只是B的另一种风格，在B中，成本和截止日期的变化会被放大。

好吧，如果这是事实，就按它去做吧。如果你同意了一件事，而现在他又想做额外的事，那该怎么解释呢？你收到回击了吗

我