3 ms·

Too much protest here. I feel you'd be eventually judged on those numbers as well. Are you a time & materials shop? The fact is that you either start a clock

Too much protest here. I feel you'd be eventually judged on those numbers as well. Are you a time & materials shop? The fact is that you either start a clock when you start working on something and stop it when it's done or you have standard times that things should take (like an auto shop does.) If you're working efficiently, you can tell your client that you work efficiently and this is simply how long the change took. If you're procrastinating and charging the client for the time, you should fix that.

stronglikedan 8y ago
I don't think four hours is unreasonable for any type of shop (with 4-8 being CYA estimating). One or more resources likely have to do most of the steps below. * Document the customer request * Investigate the customer request * Create and document the requirement * Assign the task * Switch current context * Deploy a dev environment * Make the change * Submit the change to QC * Test the change * Deploy the change * Clean up dev environment * Document the change * Bill the customer Ideally, you would encourage the customer to bundle multiple requests, so that most of the tasks could be shared among them. However, if they insist that they need it now, then they need to pay accordingly. This story seems like it could be solved with improved up-front communication.
- projektfu 8y ago
  Totally agree it's a reasonable time. I think that it's a waste of time to argue why it takes time to do your work. You'd only write that letter because you feel bad about charging your client for your time. A better letter if you wanted to write one would be about the benefits you provide and the completeness of your work. I wouldn't even mention the time it takes.
  - SketchySeaBeast 8y ago
    If you're charging T&M money, and the client comes back with "why does it cost that much?", what would you suggest? Assuming burning the bridge isn't an option.
    - munk-a 8y ago
      Itemize the bill, break it down relentlessly into tiny components and show how long different facets tied to the feature build took, ideally pin some of the time on them if it's appropriate ("Remember when you guys were a bit wobbly on the background color, well we had quite a few meetings and dev was tied up while we were talking, it ended up taking us about three hours between those two hour meetings and then an additional thirty minutes to redo the change three times - thankfully we held off on testing until we'd all gotten on the same page.") The more explanation you get out there the better, if you're honest (or a good faker) people will be reassured by your explanations - but accept that not all clients are profitable ventures, a customer who can't pay for the time it'll take isn't one you should take on, just try and leave things in an amiable state.
      - SketchySeaBeast 8y ago
        > Totally agree it's a reasonable time. I think that it's a waste of time to argue why it takes time to do your work. You'd only write that letter because you feel bad about charging your client for your time. > A better letter if you wanted to write one would be about the benefits you provide and the completeness of your work. I wouldn't even mention the time it takes. I understand your response, but the (grand?) parent seems to be indicating you don't do that, and just explain that you do good work.
VBprogrammer 8y ago
That change may not be worth the cost, or even just the opertunity cost, of doing it. Someone presumably thought it was a good idea to make the change and assumed it would take only a few minutes work. I think the senario is that they are given an estimate of up to a day and can't understand how a developer could spend that much time on it. For me it's a little too close to the memories of an old job. I tried in vain to argue with the owner of the company that having a 15 minute estimate category was pointless because the change itself would be drowned out by the fluff (creating branches, setting up data for a manual test, creating pull requests etc).

stronglikedan 8y ago

I don't think four hours is unreasonable for any type of shop (with 4-8 being CYA estimating). One or more resources likely have to do most of the steps below. * Document the customer request * Investigate the customer request * Create and document the requirement * Assign the task * Switch current context * Deploy a dev environment * Make the change * Submit the change to QC * Test the change * Deploy the change * Clean up dev environment * Document the change * Bill the customer Ideally, you would encourage the customer to bundle multiple requests, so that most of the tasks could be shared among them. However, if they insist that they need it now, then they need to pay accordingly. This story seems like it could be solved with improved up-front communication.

projektfu 8y ago
Totally agree it's a reasonable time. I think that it's a waste of time to argue why it takes time to do your work. You'd only write that letter because you feel bad about charging your client for your time. A better letter if you wanted to write one would be about the benefits you provide and the completeness of your work. I wouldn't even mention the time it takes.
- SketchySeaBeast 8y ago
  If you're charging T&M money, and the client comes back with "why does it cost that much?", what would you suggest? Assuming burning the bridge isn't an option.
  - munk-a 8y ago
    Itemize the bill, break it down relentlessly into tiny components and show how long different facets tied to the feature build took, ideally pin some of the time on them if it's appropriate ("Remember when you guys were a bit wobbly on the background color, well we had quite a few meetings and dev was tied up while we were talking, it ended up taking us about three hours between those two hour meetings and then an additional thirty minutes to redo the change three times - thankfully we held off on testing until we'd all gotten on the same page.") The more explanation you get out there the better, if you're honest (or a good faker) people will be reassured by your explanations - but accept that not all clients are profitable ventures, a customer who can't pay for the time it'll take isn't one you should take on, just try and leave things in an amiable state.
    - SketchySeaBeast 8y ago
      > Totally agree it's a reasonable time. I think that it's a waste of time to argue why it takes time to do your work. You'd only write that letter because you feel bad about charging your client for your time. > A better letter if you wanted to write one would be about the benefits you provide and the completeness of your work. I wouldn't even mention the time it takes. I understand your response, but the (grand?) parent seems to be indicating you don't do that, and just explain that you do good work.

VBprogrammer 8y ago

That change may not be worth the cost, or even just the opertunity cost, of doing it. Someone presumably thought it was a good idea to make the change and assumed it would take only a few minutes work. I think the senario is that they are given an estimate of up to a day and can't understand how a developer could spend that much time on it. For me it's a little too close to the memories of an old job. I tried in vain to argue with the owner of the company that having a 15 minute estimate category was pointless because the change itself would be drowned out by the fluff (creating branches, setting up data for a manual test, creating pull requests etc).