3 ms·

I had a manager once who would just divide the number of hours I stayed in office by two and then tell me that that was the time I was actually doing something

I had a manager once who would just divide the number of hours I stayed in office by two and then tell me that that was the time I was actually doing something useful. He did that for everyone in his team and kept it in mind when planning for long term projects. This heuristic seems to work pretty well for him. His planning was never far from perfect and he did deliver quite a few large projects within the timelines.

ubercow13 8y ago
How is it useful to know the number of hours someone is actually working on a project when planning? That seems to granular to be useful. It seems easier to have a sense of what can be done in a day than an hour. Each hour is going to vary a lot anyway.
- ubermonkey 8y ago
  How else would one forecast? If you need to accomplish TaskX, you work with the team that will do TaskX to come up with a valid estimate of effort required to complete it -- say, 300 hours of work. You could just naively assume that this task would then be done in 300 hours / 8 hours per day / # of workers, but that assumes 100% productivity -- which isn't true basically anywhere. Ergo...
  - ubercow13 8y ago
    Even if you are estimating your own tasks and there aren't many unknowns, as a developer I don't normally check in with myself every hour and ponder how much I've achieved, so my idea of how much I can do in an hour is not going to be too accurate. Then multiply the error by 300. At least if a team has daily standups they'd be used to assessing their progress per day.
    - selljamhere 8y ago
      I doubt the manager focused on the hours. It was a simple way to say the manager doubled the expected timeframes when estimating tasks. By assuming the team is productive 1/2 the time, the task should take 2x the initial estimate.
    - ubermonkey 8y ago
      (Nice name) The thing is, though, for many business models being able to accurately estimate time and cost is critical, and so is executing vs. that estimate. It's nice to be able to say "I have no idea how long this will take," but it's also a luxury not available to many (most?) developers.

ubercow13 8y ago

How is it useful to know the number of hours someone is actually working on a project when planning? That seems to granular to be useful. It seems easier to have a sense of what can be done in a day than an hour. Each hour is going to vary a lot anyway.

ubermonkey 8y ago
How else would one forecast? If you need to accomplish TaskX, you work with the team that will do TaskX to come up with a valid estimate of effort required to complete it -- say, 300 hours of work. You could just naively assume that this task would then be done in 300 hours / 8 hours per day / # of workers, but that assumes 100% productivity -- which isn't true basically anywhere. Ergo...
- ubercow13 8y ago
  Even if you are estimating your own tasks and there aren't many unknowns, as a developer I don't normally check in with myself every hour and ponder how much I've achieved, so my idea of how much I can do in an hour is not going to be too accurate. Then multiply the error by 300. At least if a team has daily standups they'd be used to assessing their progress per day.
  - selljamhere 8y ago
    I doubt the manager focused on the hours. It was a simple way to say the manager doubled the expected timeframes when estimating tasks. By assuming the team is productive 1/2 the time, the task should take 2x the initial estimate.
  - ubermonkey 8y ago
    (Nice name) The thing is, though, for many business models being able to accurately estimate time and cost is critical, and so is executing vs. that estimate. It's nice to be able to say "I have no idea how long this will take," but it's also a luxury not available to many (most?) developers.