Enough of the debates about requirements and what we call them. Why don’t we just hire great developers and empower them to work directly with the customers?
Lost Garden
Danc, at Lost Garden has an article that asks just this question, and addresses the challenges of directly empowering developers.
A couple quotes to set the tone of their article:
What would happen if the developers possessed a deep understanding of their customers needs and desires? Suddenly, those thousand little decisions aren’t introducing random noise into the product. Instead, they are pushing the product forward.
And…
One philosophy is that we need better specs and those damned monkeys need to implement the specs exactly as designed. Better command and control system and more rigorous process is obviously the trick to success. This tends to generate poor results.
Getting Closer To The Customer
Danc offers these tips to help the developers get closer to their customers:
- Use your own product
- Onsite customers
- Observe customers using your product
- Hire psychologists and ethnologists to study your customers
- Listen to lead users
- Reduce feedback cycle time
- Improve objectivity of results
- Improve clarity of results
The only inconsistent point in his article seems to be the suggestion about using ethnologists. Don’t they present a barrier to developers in the same way that a product manager would by synthesizing and prioritizing “the voice of the customer?”
Freeing developers from a job where they are coding “to spec” will definitely empower the developers. I believe that having someone trained in prioritization and interpretation of needs (a product manager, for example) can help keep the team aligned on the important stuff by providing insight into what is important. This is the same argument for having “experts” interpret customer behaviors.
Check it out.
ohhh — that’s an interesting one. Something I’m going to have to blog about…
In my experience, ‘good’ developers do not want to have requirements thrown over the fence but would rather take an active role in not only understanding but contributing in defining the solution. In what is often a challenge is the myopic view on process-driven development.
Too often optimization, titles and processes (which are all necessary) can reduce a developer to a ‘cog’ in the wheel. While the ‘plan’ sure looks good on paper, it doesn’t account for job satisfaction, growth or passion. While developers can be technology focused, enabling the technology team as a contributor further up in the process provides rewards in passionate developers downstream.
Rob,
I think you’re exactly right. When I’ve interviewed people both for development and requirements/analyst positions one thing I always look for is reaching “beyond their role.”
I’ve become convinced over the last decade of working in the software space (combined with almost a decade as a mechanical engineer) that people who are great at whatever they do develop a significant understanding of what the people around them do. People who aren’t great at their own work rarely understand the work of their peers.
I believe that developers getting involved in requirements/specification, and understanding customer needs, qualifies in this regard.
Great insight, and thanks for reading and commenting!
Yes, BUT… :-)
There also IS the Two Cultures problem. See Wikipedia, for example.
I.e., a significant fraction of developers are not able or do not want to do the work the analysts do.
Just theorizing but, an ethnologist or psychologist may be better at discovering implicit requirements.
Hey Stoft, thanks for commenting. I agree with you – an ethnologist would do better research. My point wasn’t that the ethnologist would be less effective – just that his suggestion was to remove one set of people, but not the others. If his arguments were strictly true, they would apply to ethnologists as well.