[ctb_mg]

I work with a customer who is notorious for not defining requirements. Their culture is that everyone is either too busy or not knowledgeable enough of all the working parts of a system to define requirements. It's a culture problem over there.

The tool I work on generates reports. Rather than defining requirements for reports, the only way to make progress is to understand their general needs through conversation, then provide them a draft report - your best guess. They tell you what to change or what they don't want, then you make changes and provide another draft. When enough tracer bullets are shot, you arrive at the report they actually need.

[daheza]

Aren't at this point you doing the job of two people? I have a coworker who would say this when the requirements are well defined. He would say its our job to build the requirements that are given to us. Our job is not to create / define a product. He would often follow this up by saying our company is worth X Billions of dollars, they can afford to hire a Business Analyst/ Better Product Manager.

Personally I don't agree with this. It goes against my core beliefs to make something that I don't believe is good for the end user. I have a hard time however coming up with arguments on why we should as a developer spend our time creating basically a product plan.

[jerven]

I understand how you feel. You are being hired to solve problems, and figuring out what to solve is a key part of the job. Solving problems is your aim, writing code is only helpful if it solves the problem. I love the days where I get into the office someone ask me streamline something, and all that really is required is a whiteboard, some pens and no code ever. Solving the urgent business issue at a cost of 30 minutes talking and 5 dollars of pens ;)

Hiding developers behind analysts and product managers makes everyones job less fun.

In my first job we had analysts, product managers, user councils making specifications. Specifications that where terrible and the developers in the team would have loved to do this iterative design with the end users, because the software would have been better fit for use. For me that was a soul sucking experience. Much better to be able to understand why the software needs to exist and how to make it good for users and the organisation (not always 1:1 mapping either)

Wanting perfect specs is a good way to limit your career as a developer. Because that way you will never be more than a glorified type writer with a analyst to hold your hand. Solving the whole business problem from start to end is the way to grow professionally.

Also perfect specs are impossible :( so iterating with your users is the fast way to good enough for business applications.

If you want perfect specs write sudoko solvers...

[ctb_mg]

> Aren't at this point you doing the job of two people? ... our company is worth X Billions of dollars, they can afford to hire a Business Analyst/ Better Product Manager.

Yes, definitely. The difference is that in my situation we are a software contractor, not a software development company that owns its products. If we don't work with the customer to discover and build what they want, then it doesn't get built, which means we've lost potential work.

[jon-wood]

I've worked in environments where everything is specified up front and ones where nothing is specified beyond a vague idea of the end goal. I find the latter far more honest, at least in the context of startups. My experience is that most people don't know how something should work until they see one version of how it could work, from there we can start zeroing in on the actual solution by chopping and changing things.