Joh*_*ohn 21 refactoring time-estimation
我有一个自由Web应用程序项目,客户端每两周左右请求一次新功能.我无法预测即将推出的功能的要求.因此,当客户端请求新功能时,可能会发生以下几种情况之一:
我轻松实现该功能,因为它与现有平台兼容
我很难实现这个功能,因为我必须重写该平台的重要部分
客户撤回请求,因为在现有平台上实施成本太高
在项目开始时,大约六个月,所有功能请求都归入类别1),因为系统很小且敏捷.但在过去的六个月中,大多数功能实现属于第2类).系统已经成熟,每次我想添加新模块时都迫使我进行重构和测试.另外,我发现自己破坏了用来工作和修复它的东西(我没有得到报酬).
客户开始对我实施新功能的时间和成本感到沮丧.对他们来说,许多功能请求的规模与六个月前他们要求的功能相同.例如,客户会问,"如果去年建立一个票务系统需要1周时间,为什么今天要建立一个事件登记系统需要1个月？事件登记系统比票务系统简单得多.它应该只需要你一个星期!" 由于这种情况,我担心功能请求很快就会出现在类别3)中.事实上,我自己已经花了很多钱,因为我自愿花了很多时间来支持这个项目.
当我诚实地告诉他做某事所花费的时间时,客户经常感到震惊.客户总是将我的估算值与项目的前几个月进行比较.我认为他们没有为开发,维护和支持成熟的Web应用程序所花费的成本做好准备.
在为一家全职公司工作时,管理人员更愿意接受我的估计,甚至鼓励我填写我的数据以应对意外情况.有没有办法让我的客户以同样的方式思考？
任何人都可以提供关于我如何继续在这个网络项目上工作而不需要花费太多费用的建议吗？
附加信息 - 我只有1年的全职自由职业生涯.我还没有高端客户,但我慢慢到那里.随着时间的推移,我的客户越来越好.
听起来像你在你的架构中有一些技术债务; 它在改变方面很脆弱.此外,您还不清楚您是否在合适的时间进行测试.编写测试的最佳时间是在编写代码之前,让测试作为代码的可执行规范.
强大的架构应该通过鼓励类之间的分离来促进变更.这应该在添加新功能时限制更改的传播.听起来好像你有更多的耦合而不是健康,但是如果不看代码那几乎是不可能的.我只是按照你对症状的描述.
如果是这种情况,可能需要花一些时间来改进底层架构.与您的客户保持联系,使基础系统不再符合他们的要求,并且您需要花一些时间,以便更快,更便宜地完成未来的更改.有些可能是你的错 - 如果是这样的话,也要诚实.我不认为期望客户端选择支持其新功能所需的架构更改的选项卡是不合理的.但是,如果这部分是由于缺乏经验,你可能想要自己吃一些费用并将其归结为学习经验.如果您可能失去客户,您可能还想要这样做.
最近我自己做了自由职业的事情(不同的领域),我在合同中加入了两件事; a)如果对框架进行任何重大(在我看来)增加/更改,每个都被视为一个单独的项目,具有单独的交付要求和成本计算,b)我将提供适当级别的文档,以便如果他们对我的'估计'不满意,他们可以尝试其他人.
我有一个客户端尝试选项b一次; 他们很快就回来了.