对客户收取非常小的费用

你付出的可能比你想象的要多。

有趣的是,我在浏览了我的即时通讯、电子邮件和电话日志之后,就阅读了你的问题,以便将我所做的与我的账单进行比较。这个月,我又一次以3-5分钟的增量给出了近20个计费小时。

罪魁祸首:

• 在电话上快速聊天
• 通过即时消息发送“快速问题”
• 包含元讨论的持久电子邮件线程
• “快速三分钟”更改

你将会是 吃惊的 与你实际的账单相比,这些赤字会以多快的速度增加到实实在在的赤字。

我所做的只是开始以15分钟为增量计费。虽然快速的改变在实践中只需要几分钟,但它确实涉及到一个破坏性的过程。15分钟足够我完成任务或回答问题。或者回复电子邮件,然后 回来 我所做的一切。

我不是说你 应该 每件小事都要收费,但我要经常收费。从长远来看,这有助于您的客户机,因为他们(应该)开始在将更改组合成消耗一个小时或更长时间的列表方面做得更好。

有趣的是,我最大的罪魁祸首竟然是即时消息。说到这个,Skype是个邪恶的小盒子。

这让我想起了一个古老的故事,一个铁路专家因为一辆全新的内燃机车不能启动而被请来,不管工程师做了什么。经过一小段时间的研究,专家用锤子轻敲机车。它马上就开始了。当铁路公司收到专家1000美元的账单时,他们要求他逐项列明。回答是:

用锤子敲击机车:10美元

知道去哪里打它:990美元

我的工作是尽可能准确地记录所有花费在做任何事情上的时间,而我的经理则是负责账单的。

你经常和这个客户一起工作吗?如果是这样,你可以把它折成下一张账单。

如果不是的话,我认为你应该向他们收取最低的费用(比如一个工作小时),或者根本不向他们收取费用。

我现在是一个项目经理;但是我开始是一个Fortran和Clipper开发人员,并且经营自己的业务。小变化是我们生存的祸根。

让我从一个问题开始。你一天能做多少15分钟的小改动?有趣的是,如果你注意你的一天,它不会是32每8小时一天。它会更像8!你,和我一样,会坐在那里,想知道其他6个小时去了哪里。像我一样,一个典型的软件开发人员只考虑编码时间。

进入软件开发生命周期。实际上,开发前有领导任务,开发后有完成任务,项目开始时有永久性任务,项目结束时有完成。总之,这些其他任务的执行时间大约是实际软件开发时间的三倍。这些其他任务包括需求、分析、设计、测试(U、I、S、A)、管理和一些QA。

即使是一个人的装备,除了实际的代码更改之外,您还将执行所有这些操作。很可能很难区分零部件。看来这只是完成工作的一部分。相信我,如果你不做这些事情,你就不会继续得到很多工作。需求和验收测试是重要的客户接口,但可能只是一个电话呼叫。分析和设计可以很快地与编码一起流动,因为您熟悉系统和用户体验,但是,您仍然在这样做。我敢打赌,如果不至少在本地查看代码,然后在客户环境中再次安装代码,您永远不会将更改推后。全生命周期。

在所有这些之后,在回答你的问题时,虽然变化似乎很小,但你应该注意在一天内可以管理多少。一旦你意识到它真正需要的时间,你可能会觉得更舒适的计费时间最短为一个小时和更经常的计费,这样客户不会忘记工作。感知是唯一的现实,密切管理它。

维护合同(或任何合同)的条款是什么?

通常情况下,你应该按照你认为合理的最低收费时间单位收费。

回到法国(是的,我是法国人),一家正常的IT服务公司会为此收取1小时的工作费……客户必须小心,不要一遍又一遍地要求小的更改,如果这是他们第一次这样做,你可能会放手。

如果您与客户处于“升级”模式,并且需要积累一些善意,那么作为善意的表示,最好是免费进行。(因为你只花了3分钟时间)。 另一方面,如果客户一直给你提供大量的业务,你会时不时地想给你一个免费赠品:—)

更严重的是,您可能最终需要根据项目涉及的时间/工作/成本预先对项目本身进行分类。我曾在一些项目上工作过,这些项目被归类为“小变化”,基于先前商定的一套标准,涉及工时/成本。然后很容易让客户将微小的变化打包成一个包,并将其作为一个“小变化”项目提供给您。