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