Who is a business analyst?

I was once asked: how is a business analyst different from a secretary? It would seem that software development in Russia has been going on for more than 2 decades, but the role of a business analyst still raises questions.

In principle, instead of a secretary, you can add any other profession and ask: how does a BA differ from an accountant, a lawyer or a technical writer?

The development of any product or IT project begins with the formation of a team. How it happens: let's say, Customer We have it right away. Who else do we need on the team?

Usually it is called immediately Developer. And so the customer says that he will tell the developers what needs to be done and now they will quickly make a product. Well, let's say we believe it.
Needed Designer. To have beautiful and convenient interfaces
Needed TesterSomeone has to find the bugs, we know that there is no code without bugs.
We already have a lot of people on our team, obviously we need them Project Manager

And often someone says: we need Business Analyst! But what will he do? Many do not know. Who is this man? What does he do?

Let's say we need an analyst for the team, but what kind? Business analyst, systems analyst or full stack? And what's the difference between BA and CA?

Let's figure it out

The term Business Analyst most often refers to at least 2 different professions:

1st – this is an employee of a business unit of some company who is actually engaged in the analysis of the company's business. Graphs, reports, forecasts for the development of a particular service, revenue, payback, etc.

2nd – this is an employee of the IT department or IT company. This is the BA who is part of the team developing some software. It is this BA that will be discussed further.

A business analyst is a person whose main task is to translate the language of the business customer into the language of the developers. A very exaggerated and simple definition. Nevertheless, this is one of the most important tasks of BA.

Can’t the Customer immediately set the task for the development so that they understand?
No, it can't.

The business customer or Product Owner often (not always, but often) describes a certain image of the result that he wants to receive. For example: Implement the ability to work with comments in the task. Create, delete, edit. And he can add: well, like everywhere else. What other requirements do you need?

At best, the developer will torment the customer with questions, of which there will be a lot.

в каком формате показывать дату и время комментария?
а ФИО пользователя
а аватарку показывать?
а сортировать в порядке убывания или возрастания?
а кто должен иметь права на редактирование?
а если, а если, а если?

In the worst case, the developer will do as he understood/thought of/saw somewhere.

So, the BA is the person who will describe (and this is very important. He will not tell, sing, dance or record a voice. He will write!) in great detail what we want to get as a result. These will be our requirements – which the development will take as input.

Requirements

Requirements can be divided into business requirements and system requirements.

Business requirements are requirements that are important from the point of view of the business, i.e. the customer. These can be interface requirements: data display formats, a set of functions. This is essentially what determines how the product should look and what it should do.

System requirements are a description of how the development should implement business requirements. Descriptions of methods, tables in the database, fields, API, etc.

An analyst who writes business requirements is a business analyst. And an analyst who writes system requirements is a systems analyst.

To put it very simply, BA is a person who writes in human, Russian language. He describes WHAT needs to be done. And CA describes HOW the development should do it. That is, he writes system requirements at the level of DB tables, tasks for the back, front, etc.

It seems simple. But, ha-ha, the devil is in the details. Business requirements can also be integration requirements. For example, integration of Billing and CRM. If the essence of the improvement and the main business value is not the display in the interface of the ability to pay a bill or connect a service. But, for example, enrichment of some data stored in the database, then the requirements for this data can also be business requirements.

Difficulties always start when we try to formally separate BA and CA. And here a full stack analyst often appears – who is both BA and CA. In fact, it is rare to meet a real full stack analyst, after all, these are slightly different specifics and different skills, experience. CA is already a bit of a developer. And BA is a bit of a RO. And a full stack is a bit of both. But more often than not, this is easier than trying to separate requirements by criteria.

Capturing and Managing Requirements

If you hear that there is no need to describe the requirements for your system, because “we talked and everything is clear anyway” - then you are not talking to a BA (or to a bad BA). — If you hear that there is no need to describe the requirements for your system, because “we talked and everything is clear anyway” – then you are not talking to a BA (or to a bad BA).

The business analyst must record all requirements. These can be documents of completely different levels: TZ, CTZ, BFT, Specification, Use case, user story, statement. These can be documents in Word according to GOST or pages in the Knowledge Base. But the requirements must be recorded.

Requirements must be written down, numbered (preferably), verified, and traced (i.e. linked).

BA decomposes requirements: breaks them down into smaller pieces to make them easier for developers to code.

And an important step when working with any requirements is to agree on them! This is a separate skill for BA, to be able to agree on a document with different customers, especially if they have different goals and tasks for the system.

I always ask this question at interviews: if you have 3 customers and they tell you opposite requirements for the system, what will you do? The answers always indicate whether the candidate has real experience working as a BA.

What else does BA do that is important?

Of course, it designs business processes! There are many notations, each BA has their favorites. I believe that a good business process is one that is understandable to both the business customer and the developer without special training.

To depict a complex process simply and clearly is the highest level of skill!

A business process can be described as the behavior of one user in one system (for example, working with comments in a task) or a long end-to-end business process through many systems (for example, you pay for the Internet in your personal account and in 5 minutes it will be unblocked for you. There will be about 10 participant systems here and it is important to refine each system so that in the end this business process works).

Well, let's say our BA wrote the requirements, formalized them into the technical specifications or the statement. And that's it? Sat down to rest? A bad BA – perhaps, but it's not worth talking about such people. I really like the famous phrase: no complaints about the buttons, but the suit doesn't fit.

A business analyst is the person who is responsible for making sure the suit fits.

BA participates in grooming and discussions with development. When writing requirements, it is very important to understand what and how can be implemented, and what will take a long time or be expensive to implement. The business analyst must make sure that the development has understood the requirements correctly. Practice shows that any even very unambiguous phrase can be interpreted in different ways. It is important to read everything together, discuss it and record it so that it is clearly understood by everyone.
BA is involved in acceptance of functionality and checks it. The analyst checks it as a whole, did it work as planned? Maybe something was designed inconveniently? Something was forgotten? The BA knows exactly how the user will work with it, will he be able to?
Since the BA knows what is important to the user, it also will check the documentation for the user. Is the functionality really described in full? Are the necessary accents made?
BA can help RO conduct product demonstrationsanswer users' questions.
In my product, BAs are also an entry point from the side 3 lines of technical support. All requests that cannot be answered by the 1st and 2nd lines go to the product business analysts. If there is a suspicion of a defect, we pass it on to QA. If the user suggests some new functionality, we suggest whether it is in the product development backlog and if not, we go to the RO with the question.

There is often a feeling that all BA does is talk to everyone.
In principle, that's true. And he writes the requirements in his free time, in the quiet early in the morning or on weekends.

Who is BA talking to?

With the customer – this is the first step, to figure out what needs to be done. And agree with everyone.
With a designer – interface design can never be done in isolation from requirements.
With development – make sure development understands what needs to be done.
With testing – to help determine whether it is a bug or not.
From then on, writers – help write the documentation.
With support – help answer user questions.
With users – tell them about the product, conduct a demo.

The key skill of a Business Analyst is the ability to find a common language with different people. So that in the end your product's suit fits well.