refactoring - 如何让自由客户了解开发和维护成熟产品的成本？

Question

我有一个自由 Web 应用程序项目，客户每两周左右请求新功能。我无法预测即将推出的功能的要求。因此，当客户端请求新功能时，可能会发生以下几种情况之一:

我轻松实现该功能
因为它兼容
现有平台

我用
困难，因为我必须重写
很大一部分
平台基础

客户撤回请求，因为它
实现成本太高
现有平台

在项目开始时，大约六个月，所有功能请求都属于 1) 类，因为系统小而敏捷。但在过去的六个月里，大多数功能实现都属于第 2 类)。系统很成熟，每次我想添加新模块时，我都不得不重构和测试。此外，我发现自己破坏了过去可以工作的东西，并修复它(我没有为此获得报酬)。

客户开始对我实现新功能的时间和成本表示失望。对他们来说，许多功能请求的规模与他们六个月前请求的功能相同。例如，客户会问:“如果去年你花了 1 周时间构建票务系统，为什么今天需要 1 个月来构建事件注册系统？事件注册系统比票务系统简单得多。应该只需要你 1 周的时间!”由于这种情况，我担心功能请求很快就会进入第 3 类)。事实上，我自己已经承担了很多成本，因为我自愿花费了很多时间来支持这个项目。

当我诚实地告诉客户做某事所需的时间时，客户常常会感到震惊。客户总是将我的估计与项目的前几个月进行比较。我认为他们没有为开发、维护和支持成熟的 Web 应用程序的真正成本做好准备。

在为一家全职公司工作时，经理们更容易接受我的估计，甚至鼓励我填写我的数字，以备不时之需。有没有办法让我的客户以同样的方式思考？

任何人都可以就我如何在不消耗太多成本的情况下继续从事这个网络项目提供建议吗？

附加信息 - 我只做了一年的全职自由职业者。我还没有高端客户，但我正在慢慢到达那里。随着时间的推移，我得到了质量更好的客户。

Answer 1

在我看来，您的架构中有一些技术债务；它在变化方面很脆弱。此外，尚不清楚您是否在正确的时间进行测试。编写测试的最佳时间是在编写代码之前，让测试作为代码的可执行规范运行。

一个健壮的架构应该通过鼓励类之间的解耦来促进变化。随着新功能的添加，这应该会限制更改的传播。听起来好像你的耦合比健康的要多，但如果不查看代码，这几乎是不可能的。我只是根据你对症状的描述。

如果是这种情况，可能值得花一些时间来改进底层架构。提前告知您的客户，底层系统不再符合他们的要求，您现在需要一些时间，以便可以更快、更便宜地完成 future 的更改。其中一些可能是你的错——如果是这样，也请诚实点。我不认为期望客户选择选项卡以更改支持其新功能所需的体系结构是不合理的。但是，如果部分原因是缺乏经验，您可能想自己承担一些成本，并将其归结为学习经验。如果您可能会失去客户，您可能还是想这样做。