Introduction, or why would you need a Business Analyst at all
The majority of people think that the only person required for any program creation is a developer, because he is the one who writes code and makes a customer’s dream come true. However, who really knows what hides behind that “dream”? In reality, there is a huge gulf between what a customer says and what a developer creates in the end. The reason for this is not a lack of desire to communicate or misunderstanding, but the fact that the customer mainly thinks about what this program should do and what purposes it should serve, whilst the developer concentrates on how this program has to work, how to gain the data, what would the name of a new column in a data table be and so on, in other words, to think about the details of implementation.
Since both developers and customers are busy people, clarification of details looks like several questions-and-answers rounds, and it is never clear when this or that decision was made and how the ideas changed in the process of discussion. But the main disadvantage of this type of communication is that the developer asks HOW, but the customer doesn’t know how, he knows WHY and is barely interested in the rest. Moreover, usually when answering the question HOW the customer backs himself into a corner, because he cannot and does not know how many options there are available to fulfill his needs and which way is optimal. But the developer is just doing what he’s been told. And as a result, we have a situation when a puzzled customer asks why the program doesn’t fit his perception of the world and the puzzled developer says that he only did what he’d been asked to do.
Even judging by the name of the profession itself, Business Analytics deals not only with requirements gathering, but with their analysis a well, and that means the search for the optimal way of reaching the customer’s goal. This way, the analyst should know both WHY the client need this or that functionality as well as HOW competitors deals with it and WHAT is the best way to implement every single detail of it.
Analyst in Agile
Today, flexible software development methods are gaining popularity.
Generally, when considering the possibility of switching to it - and even in the process of switching or initial use - a number of questions inevitably arise. One of them is the need for the participation of a business analyst in the development process.
Everyone is familiar with the main features of the analyst which is essentially gathering requirements and writing a detailed specification of how the system should work. Even before the start of the project the requirements must be collected, the specification should be written, designs worked through, and only then the programmers should begin writing code. This is the beautiful story of how program creation rarely meets reality, even in projects using the waterfall methodology, not to mention SCRUM.
Project documentation tends to become outdated rapidly, especially when it comes to Agile, where changes are considered to be the norm rather than due to force majeure.
In this regard, it is strongly advised to minimize documentation when using Agile methodologies:
Avoid write-only documentation, i.e. the ones that it is certain no one will read
Write concisely, highlighting important points and omitting unwanted items, as details vary
Use more visual images, charts, graphical notation
But this does not mean that everything must be minimized and those minimizations should be crucial, as the absence of documentation will likely lead to the following problems:
It would be difficult to introduce new people to the project
There are chances of losing the overall concept and vision of the whole project or its individual parts
It is difficult to control the quality, because it is not clear what to refer to (especially talking about fully functional regression testing, which is very complicated to automate completely)
It is difficult to maintain and develop the initial functionality, since everyone has already forgotten what it was exactly and why it was done
And so on and so forth
In the second part of this article, we will consider functions analyst plays in Agile project and communication patterns between analysts, developers and customers (product owners).