我读 了what-payment-structure-do-you-use-for-small-projects ，我想知道你们是如何处理错误与功能的。我曾经遇到过客户想要静态报告的情况。然后在项目的大部分工作完成后，在项目接近尾声时，他说他一直想要动态报告。这种改变并不容易，因为我们选择的框架不支持动态报告。这是一个奇怪的情况，因为客户有一个编程团队，所以他们应该知道。也许只是缺乏沟通技巧。
你们如何处理试图让您添加功能的客户，因为他们忘记了，改变了主意，或者被误解了？
我的意思是大功能，而不是小功能。
编辑：
他说预算是固定的，不能改变，而且这个特性（就像每一个一样）是至关重要的，没有它他们就不会接受这个系统。（只是最坏的情况）
以我的经验，在这个问题的两边都有，这通常更多地是关于经济学，而不是关于编程、流程或项目管理。
我们，客户，经常说“它可能是一个功能，但如果我们称之为错误，也许我们可以让他们免费做。”
最后，作为程序员，我们根据是否有助于或损害我们未来工作的机会来收取或不收取更多费用。我们，客户，将未来工作的胡萝卜作为让程序员免费做额外工作的动力。
我不相信这会因为我们有更好的流程来表达“这是一个错误”或“这是一个新功能”而改变。
在软件开发过程的早期，双方都了解他们的钱是什么，这一点很重要。敏捷方法是管理此过程的绝佳工具。如果您有团队的速度，您可以相当准确地确定在每次迭代期间可以添加多少功能。估计任务，并让客户参与确定要添加哪些功能以及哪些事情不那么重要的优先级。确保在每次迭代后都有一个客户演示，以展示你们都同意在当前迭代结束时工作的功能。如果客户想要其他功能或对您已经同意的功能进行重大更改，估计需要多少故事点（敏捷中使用的工作单元）来进行新的更改或重新设计当前的功能。这将帮助他们删除另一个他们认为不如他们刚刚建议的当前重要的功能。这让每个人都开心，并且产品“发货”时不会有任何意外
试图将它们排除在该功能之外是没有意义的。毕竟，无论是否存在沟通问题，我们的使命是在软件中交付客户需要的东西。
我会采用如下铁三角论点：
1) 显然我们想要提供您需要的产品，所以让我们一起努力。
2）我们都明白，无论我们如何走到现在，我们都只能从今天的位置继续前进。
3）我们也明白，实施变革需要时间和金钱，而这必须来自某个地方。
4）此时您的选择是这些（选择一个）
*用此更改所需的工作替换为某些其他功能计划的工作以保持预算和时间表（牺牲其他功能）
*延长截止日期（增加成本/班次期限）
* 添加资源（增加成本）
警告：尽管如果您从事制造类工作（再制造 1000 支铅笔），C 语言在逻辑上是有意义的，但在像软件工程这样的研发工作中，它通常只是 B 的另一种风格，您会放大成本和截止日期的变化。
如果不在项目计划/书面协议中，则超出范围。
我们有书面的规范，并让客户在上面签字，同意为该文档中描述的功能付费。如果他们稍后在一些简单的事情上改变主意，我们通常会在不收取额外费用的情况下进行更改，但是像您描述的任何事情都需要新的采购订单。
嗯，最简单的答案是预算或合同规定了要求。对这些要求的更改必须作为额外提交，然后通过与原始项目相同的过程。必须对它们进行预算和估计。
完成所有这些后，如果客户希望它接近原始发布日期（这是可行的），请为加班时间添加额外的时间。
至少，这就是我所做的。
我向他们收费。
我建议确保尽可能地解决这些要求，并且双方都清楚地了解所承诺的内容。它让客户高兴，因为像你描述的情况更少，它让你高兴，因为你不会一直被拉扯。
问题是关于两个主题：谈判和项目管理。
就项目管理而言，您需要提前管理客户改变主意或误解协议的风险。以下是在软件开发项目中通常会采取的预防措施列表，可在计划或重新审视项目时用作清单：
通过在开始之前批准书面规范来避免大部分风险。如果您进行较小的迭代，请获得批准的迭代规范。它不需要过于详细，但应该设定客户期望并作为参考点。详细说明您在规范中不确定的事情。
您可能有机会直接向客户报告其他一些组织来做某些有风险的事情。
在计划中加入一些应急时间和预算，向客户解释任何应急措施只有在与他们达成协议的情况下才会使用。
在规划阶段明确向客户提供替代解决方案，讨论利弊并记录决策。
即使您在项目中构建了几个里程碑，您也将在其中向客户进行小演示或阐明需求。借此机会，客户仍然可以接受建议的解决方案。
正如 Webdtc 所指出的，总是通过发送简短的摘要电子邮件来确认电话和面对面讨论的结果。
将可交付成果、验收和付款分散到超过一个月的项目中。即使客户在项目结束时付款，也要确保您获得他们批准临时可交付成果的证据。
希望当您需要与受不付款威胁的客户事后协商交付成果时，遵循这些提示不会让您陷入困境。但是，如果您发现自己不得不忍受不合理的要求，那么您在那时积累的信息会给您带来非常强大的影响力。谈判技巧：
从了解客户需求背后的确切原因开始。他们的立场究竟是什么。与客户确认您正确理解他们。
在这一点上，这可能是你的错（如果你正确地管理项目，不太可能），客户的错（有时他们确实改变了主意）或双方的公鸡（很可能）。
当一切都是你的错时，你很可能需要吞下药丸并吸取教训。但是，您需要与客户协商新的截止日期，以防止问题让您付出更多代价。始终考虑为基于您现在拥有的软件构建的问题提出替代解决方案。
当它是客户或相互的错误时，从“不”开始。推回去让他们明白你没有吸收成本，至少没有完全吸收。不要让他们让你相信他们可以轻易地走开，这绝不是真的。在这一点上，即使他们没有付给你一分钱，他们对项目的投资也将是相当可观的：评估投标所花费的时间、参加会议、他们为沟通需求所做的努力、他们和他们的客户对项目的依赖程度主要是完成按时并在预算范围内等。您可能仍然需要在两个组织之间分摊成本，但以“否”开头，以明确表示他们有责任努力及时澄清要求，就像你有责任发现什么是需要。
在我看来，客户可能正在寻找借口退出协议而不支付任何费用。如果他可以随意添加功能并坚持最终验收，无需额外费用，他就有办法让你违约。
有两种明显的方法可以避免这种情况。
一种是在整个开发过程中的付款，这样客户就无法摆脱大部分付款，并且您或多或少会从您在任何时候所做的事情中获得补偿。
另一个是良好的合同。对于任何合理的软件项目，几个小时的律师费对于此类事情来说都是便宜的保险。如果您有信心可以以约定的费用起诉客户并获胜，那么客户就不太可能制造麻烦，如果其他一切都失败了，您可以起诉。
我不知道你的工作合同安排是什么（而且我也不是律师），但在这种情况下，我会找律师，看看我处于什么样的情况。甚至如果您处于可疑的法律地位，您的律师的信可能会帮助解决问题。
并且不要再进入那个位置。
好吧，如果这是真的，那就顺其自然吧。如果你同意一件事，现在他想做额外的事情，该怎么解释？你收到推回了吗？
我要明确表示，我们最初设计了一份静态报告，这就是签署的内容。它可以扩展到动态报告，如果他想知道细节，您可以提供报价。
我经常用盖房子的比喻。客户正在更改蓝图，或者需要更多时间的整理材料，这些材料要从最初同意的内容中完成。
希望有帮助！
在这种情况下，我所做的是查看先前的文档和通信。
例如，如果文档/通信显示“创建报告”。如果没有具体提及动态报告，我不会向客户屈服。
如果有任何文件说“动态报告”，那么客户是对的，我必须免费开发报告。
如果有关于“动态报告”的交流，我将不得不看看最终结果是什么。这可能会变得更难，因为很多时候客户可能会问“是否可以创建动态报告？” 开发人员可能会说“是的，这是可能的”。（意味着它是可能的，但并不意味着我们会这样做）。这是我必须解释的地方，尽管讨论过它不在工作范围内。必须就开发一个功能达成具体协议。
如果您不保留文件和之前的沟通，那么我会说您不知所措，需要决定您是否要给客户他们想要的东西或冒失去客户的风险。
对我来说最糟糕的事情之一是坚持电话沟通的客户。这些客户通常会根据他们的要求快速轻松地播放它。我通常在这里做的是始终对客户在面对面会议或电话中讨论的所有内容进行书面跟进，并要求客户做出回应以确保我们在将要和赢得的内容上达成一致做不完。
没有正确的答案——只有几个错误的答案。规格和要求比信息有更多的空白 - 总是有解释和误解的空间......它真正归结为：
在你无能为力的事实之后，如果归结为法律诉讼，你就会失去这个客户和良好的声誉（潜在的）——小心你推动它的努力
我处于这种情况经常发生的情况。我们编写执行复杂任务的 Web 应用程序，然后在我们按照规范完成它之后，用户会转身说“我们不仅想要 X 和 Y，还想要 Z”。Z 不在项目范围内，因此在当前系统中无法实现，因此必须重写它以适应新引入的“功能”。
我们解决这个问题的方法如下。像对待白痴一样对待用户，并且比他们更了解系统。我知道这听起来很刻薄，起初当我的老板向我介绍这个时，我直截了当地告诉他我永远不会这样对待用户 - 不幸的是，我学会了艰难的道路，现在必须比用户了解更多才能完成我的任务. 缓解是最重要的，预见可能引入的重大变化是随着时间的推移而学到的技能。
我现在减轻这些计划外但可能发生的变化。