如何让自由职业客户了解开发和维护成熟产品的成本？
我有一个自由 Web 应用程序项目，客户每两周左右就会请求新功能。我无法预测即将推出的功能的要求。因此，当客户端请求新功能时，可能会发生以下几种情况之一：
我轻松实现了该功能 因为它兼容 现有平台
我使用以下方式实现该功能 困难，因为我必须重写 的很大一部分 平台的基础
客户撤回请求，因为 实施成本太高 现有平台
在项目开始时，大约六个月的时间里，所有功能请求都属于类别 1)，因为系统较小且敏捷。但在过去的六个月中，大多数功能实现都属于类别 2)。系统已经成熟，迫使我每次要添加新模块时都要重构和测试。此外，我发现自己破坏了曾经有用的东西，然后修复它（我没有为此获得报酬）。
客户开始对我实施新功能所需的时间和成本表示沮丧。对他们来说，许多功能请求的规模与他们六个月前请求的功能相同。例如，客户会问：“如果去年你花了 1 周的时间来构建一个票务系统，为什么今天你花了 1 个月的时间来构建一个活动注册系统？活动注册系统比票务系统简单得多。应该只需要你1周的时间！”由于这种情况，我担心功能请求很快就会落入第 3 类）。事实上，我自己已经承担了很多成本，因为我自愿投入大量时间来支持该项目。
当我诚实地告诉客户做某事所需的时间时，客户常常感到震惊。客户总是将我的估算与项目最初几个月进行比较。我认为他们没有准备好应对开发、维护和支持成熟 Web 应用程序的实际成本。
当在一家全职公司工作时，经理们更容易接受我的估算，甚至鼓励我增加数字，为意外情况做好准备。有没有办法让我的客户也以同样的方式思考？
任何人都可以提供建议，告诉我如何继续从事这个网络项目，而不需要自己承担太多成本吗？
其他信息 - 我从事全职自由职业才一年。我还没有高端客户，但我正在慢慢实现这一点。随着时间的推移，我得到了更优质的客户。
I have a freelance web application project where the client requests new features every two weeks or so. I am unable to anticipate the requirements of upcoming features. So when the client requests a new feature, one of several things may happen:
I implement the feature with ease
because it is compatible with the
existing platformI implement the feature with
difficulty because I have to rewrite
a significant portion of the
platform's foundationClient withdraws request because it
costs too much to implement against
existing platform
At the beginning of the project, for about six months, all feature requests fell under category 1) because the system was small and agile. But for the past six months, most feature implementation fell under category 2). The system is mature, forcing me to refactor and test everytime I want to add new modules. Additionally, I find myself breaking things that use to work, and fixing it (I don't get paid for this).
The client is starting to express frustration at the time and cost for me to implement new features. To them, many of the feature requests are of the same scale as the features they requested six months ago. For example, a client would ask, "If it took you 1 week to build a ticketing system last year, why does it take you 1 month to build an event registration system today? An event registration system is much simpler than a ticketing system. It should only take you 1 week!" Because of this scenario, I fear feature requests will soon land in category 3). In fact, I'm already eating a lot of the cost myself because I volunteer many hours to support the project.
The client is often shocked when I tell him honestly the time it takes to do something. The client always compares my estimates against the early months of a project. I don't think they're prepared for what it really costs to develop, maintain and support a mature web application.
When working on a salary for a full time company, managers were more receptive of my estimates and even encouraged me to pad my numbers to prepare for the unexpected. Is there a way to condition my clients to think the same way?
Can anyone offer advice on how I can continue to work on this web project without eating too much of the cost myself?
Additional info - I've only been freelancing full time for 1 year. I don't yet have the high end clients, but I'm slowly getting there. I'm getting better quality clients as time goes by.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
看看这些两篇文章。
Take a look at these two articles.
透明度和沟通是您最好的工具。如果您的客户无法理解为什么以前需要一周的事情现在需要三周，那么您需要能够更好地解释。根据客户的专业领域，你也许能够找到一个能引起他们共鸣的比喻——比如，尝试在 T 型车架上建造一辆普锐斯，或者尝试用没有元音的打字机写《战争与和平》。不要为自己的诚实估计感到羞耻，也不要被欺负。并与您的客户尽可能多地分享您的流程和您面临的障碍 - 您甚至可能会发现他们有一些有价值的建议。
关于技术债务问题（我同意这是根本问题），TDD 将带您走得更远，广泛的测试覆盖范围允许的频繁重构也将带您走得更远。考虑什么样的设计可以轻松地允许您进行所有更改 - 并通过测试和重构逐步实现该设计。也许你必须为此付出代价，因为所有功能都已经支付了。但是，展望未来，请将重构成本纳入您的估算中，并且不要将其视为填充。填充（可以说）是不诚实的；维护代码的设计以适应未来的变化是对您工作的诚实要求。
Transparency and communication are your best tools. If your clients can't understand why something that once took a week now takes three weeks, you need to be able to explain better. Depending on the client's area of expertise, you may be able to find a metaphor that resonates with them - trying to build a Prius on a Model T frame, say, or trying to write War and Peace with a typewriter with no vowels. Don't be ashamed of your honest estimates, and don't be bullied. And share with your customer as much as they can bear about your process and the obstacles you face - you may even find that they have some worthy suggestions.
With respect to the issue of technical debt - and I agree that this is the underlying problem - TDD will take you far, as will the frequent refactoring that broad test coverage permits. Think about what design would have permitted all your changes easily - and work toward that design, incrementally, with tests and refactoring. Maybe you have to eat the costs of that, because the functionality is all already paid for. But, looking forward, include costs for refactoring in your estimates - and don't think of it as padding. Padding is (arguably) dishonest; maintaining the design of your code to accommodate future changes is an honest requirement of your work.
在我看来，您的架构中存在一些技术债务；它对于改变来说是脆弱的。此外，尚不清楚您是否在正确的时间进行测试。编写测试的最佳时间是在编写代码之前，让测试充当代码的可执行规范。
健壮的架构应该通过鼓励类之间的解耦来促进变革。随着新功能的添加，这应该会限制变化的传播。听起来好像你的耦合比健康的耦合要多，但如果不看代码几乎不可能知道这一点。我只是根据你的症状描述。
如果是这种情况，可能值得投入一些时间来改进底层架构。提前告知您的客户，底层系统不再符合他们的要求，您现在需要花一些时间，以便将来的更改可以更快、更便宜地完成。有可能其中一些是你的错——如果是这样，也要诚实地面对这一点。我认为期望客户选择对支持其新功能所需的架构进行更改是不合理的。不过，如果部分原因是缺乏经验，你可能想自己承担一些成本，并将其归结为学习经历。如果您可能会失去客户，无论如何您可能都想这样做。
It sounds to me like you've got some technical debt in your architecture; it's brittle with respect to change. In addition, it's not clear that you're testing at the right time. The best time to write your tests is before you write your code, letting your tests function as an executable specification for your code.
A robust architecture should facilitate change by encouraging decoupling between classes. This should limit the propagation of change as new features are added. It sounds as if you have more coupling than is healthy, but that's nearly impossible to tell without looking at the code. I'm just going by your description of the symptoms.
If this is the case, it might be worth investing some time in improving the underlying architecture. Be up front with your client that the underlying system no longer fits their requirements and that you need to take some time now so that future changes can be done faster and cheaper. It's possible that some of this is your fault -- if so, be honest about that, too. I don't think that it's unreasonable to expect the client to pick up the tab for changes to the architecture required to support their new features. If it's partially a result of inexperience, though, you may want to eat some of the cost yourself and chalk it up to a learning experience. You may want to do this anyway if you might otherwise lose the customer.
最近我自己在做自由职业（虽然是不同的领域），我在合同中加入了两件事； a）如果要对框架进行任何重大（在我看来）添加/更改，每个都被视为一个单独的项目，具有单独的交付要求和成本计算，b）我将提供适当级别的文档，以便如果它们对我的“估计”不满意，他们可以尝试其他人。
我有一位客户尝试过选项 b 一次；他们很快就回来了。
Been doing the freelancing thing myself recently (different field tho), and I built into the contract two things; a) If any major (in my opinion) additions / changes were to be made to the framework, each was counted as a separate project with separate delivery requirements and costings, b) that I would provide a suitable level of documentation so that if they wern't happy with my 'estimate', they could try someone else.
I had one client try option b once; they came back fairly quickly.