|
|
|
|
|
by commandlinefan
1801 days ago
|
|
If I was surrounded by people who could put together accurate software estimates that made upper management happy, and I was the only one who was always got it wrong, I'd hang up my hat and see if I could get a job selling life insurance. Hell, if 10% of my peers could put together accurate software estimates that made upper management happy, I'd lobby to have them elevated to senior positions and spend all my time begging them to explain their secrets. But they don't. Nobody does. They don't just get the timelines wrong, they get the tasks and milestones wrong - which makes sense, because the people asking for the estimates don't actually know what the goals are, usually even after the software is delivered. The only thing an intelligent software developer can do is play along, learn to read subtle cues as to what they want you to say, say that, and get on with the actually messy business of delivering working software. |
|
And this is the real problem. People who know how to build & design products should be able to explain the goals of what they're asking for. If they don't then either you need to move or you need to get them moved.
One of the first things I tell new engineering managers is that an easy hack to is to always be asking yourself "what am I trying to accomplish?" Whether it's an emotional conversation or writing a document, if you can't answer that question then you probably shouldn't be moving forward with whatever you're about to do. And if you're writing a document, make the very first section "The goal of this document is..." because as you write you can constantly ask yourself "is what I'm writing accomplishing my stated goal?"
Communicating your goal also helps your team - if they know the goal then they don't act as automatons following directions, they can make actual decisions on their own.
If you know the business goal of what you're building then you have a better shot at getting the requirements and tasks correct, which gives you a better shot at giving a good estimate. I've worked with a number of product managers who had no real goal behind what they were asking for. I refuse to have the team start building things until someone can explain why we're doing it and what we're trying to achieve.