September 21, 2021

Gathering requirements is an impossible task that leads to unsatisfied clients and half-baked solutions

Gathering requirements is an impossible task that leads to unsatisfied clients and half-baked solutions

I have been dwelling on this question for a while and I would like to know your honest opinion.

Due to multitude of factors, that don’t matter much for the question at hand, my position in most of the jobs I had lately has been to be the link between the development team(s) and the « business / content ». An in between position, where I am knowledgeable about the business and the requirements of the client, but where I can also speak the language of developers and system architects. I am usually the guy that understands both worlds, allowing me to bring them together. I should stress that these businesses I am referring to are not connected to IT. They are just trying to take advantage of the most advanced technologies out there, and improve their way of functioning.

I like to think that this ability should be a great added value, but that has not been my experience lately. I think that there is something fundamentally flawed in the way requirements for software development are collected nowadays. If I can summarize it, it all comes down to being impossible to know and document in advance EVERY single requirement and the optimal behavior of the application.

From my experience, also coming from someone that can and does code from time to time, there are issues that we only come across while actually coding. Therefore, I am of the opinion that the developers should NOT be agnostic to the content of what they are creating. And that we should start reducing the layers distancing developers and clients that we have erected in the past decade.

I have had many people counter arguing that the agile approach solves this problem, or that with good planing such problems do not occur. But that is not my experience at all. The agile approaches in practice are everything but agile. They just waste a lot of time of everyone and in the end no one is fully satisfied. On the other hand, it is simply impossible to collect requirements for every scenario possible. Even with the simplest of applications. Moreover, user stories are always super simplistic, not capturing the nuances of the costumers reality.

What I have come to conclude is that the only way of overcoming this problem is to have a VERY close and direct contact with the development team, on a daily basis. One should be available as much as possible to guide the team when questions arise. In addition, I find it very important that each developer has the autonomy to raise questions and proposed alternatives. Whenever possible, I also always try to explain how the thing that they are developing will be put in practice by the clients, and the positive impact that it will have on the business as a whole.

To my knowledge there is no framework that envisages such way of working. I would like to hear your takes on this.

submitted by /u/nuno-filipe
[link] [comments]