Etikettarkiv: role

The distinction between requirements and technical work

Let me tell you a little story from my current assignment.  I have a gig as a developer in a project.  A few days ago I was about to start on a new piece of functionality that nobody had thought much about beforehand.  There were no requirements and only vague ideas of what the functionality was good for.  Given that I have much experience in working with requirements I thought that I was certainly capable of finding out the requirements myself and this would be a much faster way to do things than to wait for an analyst to show up.  So, I started asking questions, trying to get further down in the details of what this new functionality should do, why it should do it and how it should be done.

I have been in that situation many times before.  This time, just as practically all other times, the response from the people around me was not positive.  Instead it was along the lines of “what, you are a technical person; you should not do that work; that is for analysts to do…”

Why is that?  Why have most organizations put in a very high wall between requirements people (analysts, business people) and technical people (architects, developers)?  Why are people so afraid to “break” this boundary?  My latest employer even had distinct lines of organization for analysts and architects and it was very odd to be somebody like me (who is somewhat of a mix between analyst and architect/developer).  Also, since many organizations have this wall in place, there tends to be a focus on some kind of formal handoff from requirements to development.

To me it is obvious that there are great benefits of working on both sides of this distinction simultaneously.  Requirements without the understanding of what really can be done and what is easy and hard in the current environment tend to focus on the wrong things and not reaping the benefits that the technical environment gives you.  Architecture/development without the understanding of what is really needed and why tends to build great technical solutions that few people want.