我有一个自由网页应用程序项目，客户端每两周左右请求一次新功能。我无法预测即将推出的功能的要求。因此，当客户端请求新功能时，可能会发生以下几种情况之一：
我轻松实现了这项功能 因为它兼容 现有平台
我用它实现了这个功能 困难，因为我必须重写 很大一部分 平台的基础
客户撤回请求，因为它 实施成本太高 现有平台
在项目开始时，大约六个月，所有功能请求都属于类别1），因为系统很小且敏捷。但在过去的六个月中，大多数功能实现属于第2类）。系统已经成熟，每次我想添加新模块时都迫使我进行重构和测试。另外，我发现自己正在破坏用于工作的东西，并修复它（我没有得到报酬）。
客户开始对我实施新功能的时间和成本感到沮丧。对他们来说，许多功能请求的规模与六个月前他们要求的功能相同。例如，客户会问，“如果去年建立一个票务系统需要1周时间，为什么今天要建立一个事件登记系统需要1个月？事件登记系统比票务系统简单得多。它应该只需要你一个星期！“由于这种情况，我担心功能请求很快就会出现在类别3）中。事实上，我自己已经花了很多钱，因为我自愿花了很多时间来支持这个项目。
当我诚实地告诉他做某事所花费的时间时，客户经常感到震惊。客户总是将我的估算值与项目的前几个月进行比较。我不认为他们已经为开发，维护和支持成熟的Web应用程序所花费的成本做好了准备。
在为全职公司工作时，经理们更愿意接受我的估计，甚至鼓励我填补我的数字以应对意外情况。有没有办法让我的客户以同样的方式思考？
任何人都可以提供有关如何继续处理此网络项目的建议而不会自己花费太多费用吗？
其他信息 - 我只有1年的全职自由职业生涯。我还没有高端客户，但我慢慢到那里。随着时间的推移，我的客户质量会越来越高。
答案 0 :(得分：9)
在我看来，你的架构中有一些技术债务;它在改变方面很脆弱。此外，您还不清楚您是否在合适的时间进行测试。编写测试的最佳时间是在编写代码之前，让测试作为代码的可执行规范。
强大的架构应该通过鼓励类之间的分离来促进变更。这应该在添加新功能时限制更改的传播。听起来好像你有更多的耦合而不是健康，但是如果不看代码就几乎不可能分辨出来。我只是按照你对症状的描述。
如果是这种情况，可能需要花一些时间来改进底层架构。与您的客户保持联系，使基础系统不再符合他们的要求，并且您需要花一些时间，以便更快，更便宜地完成未来的更改。有些可能是你的错 - 如果是这样的话，也要诚实。我不认为期望客户端选择支持其新功能所需的架构更改的选项卡是不合理的。但是，如果这部分是由于缺乏经验，你可能想要自己吃一些费用并将其归结为学习经验。如果否则你可能会失去客户，你可能想要这样做。
答案 1 :(得分：6)
最近自己做了自由职业的事情（不同的领域），我在合同中加入了两件事; a）如果对框架进行任何重大（在我看来）增加/更改，每个都被视为一个单独的项目，具有单独的交付要求和成本计算，b）我将提供适当级别的文档，以便如果他们对我的'估计'不满意，他们可以尝试其他人。
我有一个客户端尝试选项b一次;他们很快就回来了。
答案 2 :(得分：2)
答案 3 :(得分：1)
任何人都可以就我的方式提供建议 继续在这个网络项目上工作 不吃太多的费用 自己？
透明度和沟通是您最好的工具。如果您的客户无法理解为什么曾经花费一周的事情现在需要三周时间，您需要能够更好地解释。根据客户的专业领域，你可能会找到一个与他们产生共鸣的比喻 - 试图在模型T框架上建立一个普锐斯，或者试图用没有元音的打字机来编写战争与和平。不要为你的诚实估计感到羞耻，也不要被欺负。并尽可能多地与客户分享您的流程和遇到的障碍 - 您甚至可能会发现他们有一些有价值的建议。
关于技术债务的问题 - 我同意这是潜在的问题 - TDD将带你走远，广泛的测试覆盖允许的频繁重构也是如此。想想哪些设计可以轻松地允许所有更改 - 并且通过测试和重构逐步实现该设计。也许你必须吃掉它的成本，因为功能已经全部付清了。但是，展望未来，在您的估算中包含重构成本 - 并且不要将其视为填充。填充（可以说）是不诚实的;保持代码的设计以适应未来的变化是您工作的诚实要求。