21

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

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

  2. 我很难实现该功能，因为我必须重写平台基础的重要部分

  3. 客户撤回请求，因为在现有平台上实施成本太高

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

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

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

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

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

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

4

4 回答 4

10

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

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

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

于 2010-03-22T02:50:20.250 回答
6

最近我自己在做自由职业者（不同的领域），我在合同中加入了两件事；a) 如果要对框架进行任何主要的（在我看来）添加/更改，每个都被视为一个单独的项目，具有单独的交付要求和成本计算，b) 我将提供适当级别的文档，以便如果他们对我的“估计”不满意，他们可以试试其他人。

我让一位客户尝试过一次选项 b；他们很快就回来了。

于 2010-03-22T02:40:39.270 回答
2

看看这 两篇文章。

于 2010-03-22T02:52:00.620 回答
1

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

透明度和沟通是您最好的工具。如果您的客户无法理解为什么以前需要一周才能完成的事情现在需要三周，那么您需要能够更好地解释。根据客户的专业领域，您可能会找到一个与他们产生共鸣的比喻——例如，尝试在 T 型车架上建造一辆普锐斯，或者尝试用没有元音的打字机写《战争与和平》。不要为你的诚实估计感到羞耻，也不要被欺负。尽可能多地与您的客户分享您的流程和您面临的障碍——您甚至可能会发现他们有一些有价值的建议。

关于技术债务问题——我同意这是根本问题——TDD 将带你走得更远，广泛的测试覆盖允许的频繁重构也将如此。想想什么样的设计可以让你轻松地进行所有更改 - 并通过测试和重构逐步朝着该设计努力。也许您必须为此付出代价，因为功能已经全部付清。但是，展望未来，在您的估算中包括重构成本 - 不要将其视为填充。填充（可以说）是不诚实的；维护您的代码设计以适应未来的变化是您工作的诚实要求。

于 2010-03-23T15:02:51.963 回答