What do business analysts in IT
Each of us probably had to hear the same question from their parents or friends not from the “programmer crowd”: “What are you doing at your job in general?”.
Usually, after trying to reply, the unchanged comment should be: “Eh, you, programmer, you can't even fix the refrigerator”. What can we say about business analysts, who cannot even properly explain to their colleagues what they are doing.
I myself often hear this question from my father, but I still can’t find the right answer. And the truth is, what do we do at work at all - analyze!
Especially for this article I had to thoroughly delve into the archives of JIRA from the last three jobs. I cannot vouch for absolute accuracy (yes, I also do not like to paint all my classes until the last minute), but the overall picture really coincides with my own feelings about the duties performed.
')
The approximate distribution of work can be described as:
But the exact number of hours in the last 3 months:
As you can see, the picture is really similar. Small differences - the lack of travel and more time working with the team - arise from the recent change of job and, accordingly, the process of integration into the new environment.
Now let's look at each item in more detail.
Let's start with the most important thing - with what, in fact, business analysis begins - with business meetings, where we will include meetings with clients, and internal meetings with the team.
First of all, it is a domain analysis and collection of requirements. It is here that we find out what the client wants from us, what problems he has, we offer the first ideas for implementation and together we draw up a preliminary project plan.
Other important elements of customer meetings are discussion of completed work, planning changes, presentations and trainings where we tell how to use the proposed product.
Perhaps, meetings are the basis of our work, they provide analysts and their teams with further tasks, so it is worth preparing for them most carefully.
I would say that if the analyst is not in a meeting, then he is sitting and working with documentation. Do not misunderstand me, this does not mean at all that you just need to knock on the keyboard just silly, on the contrary - it is here that you have to use all the capabilities of our intellect, it is this part that is the most time consuming.
Here are just a few examples of what you regularly encounter:
To work with the documentation, each analyst has his own favorite toolkit - someone likes to draw diagrams, and someone writes a canvas of text in Word. In any case, I would advise you to become familiar with the basics of UML, BPMN, User Stories and Acceptance Criteria. They will surely meet each employer.
To a greater extent, for the team it is the analyst - the voice of the client. In any incomprehensible situations, it will come to him with the questions "And what was meant here?" And it will be with him to confirm whether the customer wanted it.
I always say that IT business analysts play the role of a kind of bridge between developers and business, being able to simultaneously speak the languages of customers and programmers. In our daily work, we will jointly discuss the requirements, plan and distribute tasks, answer current questions of programmers.
It often happens that a business analyst spends a lot of time with each team member and plays a peculiar role of a deputy manager. In my practice, there have even been such cases when a manager came to me to discuss who his colleagues should give a prize, and who should not.
Obviously, understanding the requirements of the client best of all, it is we who will have to check the results of the work of programmers.
The business analyst is expected to perform so-called User Acceptance Tests - user acceptance tests. No one is required to write automated scripts or check the sizes and colors of buttons on the site. All that is required is to introduce yourself as a user and take advantage of the finished product. Check whether there is any inconvenience when using it, whether the system works in general the way the user wanted, if there are no obvious errors or inconsistencies to the requirements.
An important point! It must be remembered that analysts spend all the time with the team, participate in discussions, know about the various “hacks” and bottlenecks of the program. At the same time, when performing tests, we must understand that the client does not have this knowledge, he does not know where to press, and where not. It is necessary to evaluate the system completely unbiasedly and to point out all the mistakes the developers - the sooner they can be identified, the easier it will be to fix.
They say that in order to keep up with all the new technologies in programming, it is necessary almost every day to learn new frameworks, try new versions of your favorite languages and follow the best practices from around the world.
Fortunately, the fundamentals of business analysis do not change so often. However, as I said in my last article, in order to stand out from the crowd of business analysts, you need to be as comprehensive as possible.
You also need to follow the changes in IT, you need to develop your soft skills, learn business management, the basics of finance, understand the subject areas of clients and so on. In general, it turns out that the time for training you will often require even more than fellow programmers.
In conclusion, I will give advice on self-development - accept its necessity and discuss with your supervisor. For business development, it is crucial not to drive oneself into the framework of established processes, because tomorrow a new client and a new project from a completely different sphere will appear. The business analyst should be able to quickly get used to the changing environment and get ready to work with a new subject area. It is here that all the time you spent expanding your horizons will come to your aid.
Usually, after trying to reply, the unchanged comment should be: “Eh, you, programmer, you can't even fix the refrigerator”. What can we say about business analysts, who cannot even properly explain to their colleagues what they are doing.
I myself often hear this question from my father, but I still can’t find the right answer. And the truth is, what do we do at work at all - analyze!
What does IT analyst spend time on?
Especially for this article I had to thoroughly delve into the archives of JIRA from the last three jobs. I cannot vouch for absolute accuracy (yes, I also do not like to paint all my classes until the last minute), but the overall picture really coincides with my own feelings about the duties performed.
')
The approximate distribution of work can be described as:
- Meetings - 20%
- Documentation - 30%
- Working with a team - 25%
- Testing - 5%
- Business trips - 5%
- Self-development - 15%
But the exact number of hours in the last 3 months:
As you can see, the picture is really similar. Small differences - the lack of travel and more time working with the team - arise from the recent change of job and, accordingly, the process of integration into the new environment.
Now let's look at each item in more detail.
Meetings
Let's start with the most important thing - with what, in fact, business analysis begins - with business meetings, where we will include meetings with clients, and internal meetings with the team.
First of all, it is a domain analysis and collection of requirements. It is here that we find out what the client wants from us, what problems he has, we offer the first ideas for implementation and together we draw up a preliminary project plan.
Other important elements of customer meetings are discussion of completed work, planning changes, presentations and trainings where we tell how to use the proposed product.
Perhaps, meetings are the basis of our work, they provide analysts and their teams with further tasks, so it is worth preparing for them most carefully.
Working with documents
I would say that if the analyst is not in a meeting, then he is sitting and working with documentation. Do not misunderstand me, this does not mean at all that you just need to knock on the keyboard just silly, on the contrary - it is here that you have to use all the capabilities of our intellect, it is this part that is the most time consuming.
Here are just a few examples of what you regularly encounter:
- Requirements specification - the transformation of a free flight of a client’s thought into a structured document clearly describing what the team needs to do. Later it is this document that is approved with the client and forms the basis of the ongoing project.
- Change Requests (Change Request) - a process initiated by the client in the case when changes are required in the product after the start of development or even after its completion. The document describes what part of the system and how it should be modified, contains an assessment of the performance of work on time and cost.
- User manual and other training materials - it is obvious that after the end of the project, you need to write documentation for the client, which will describe how to use the system, give advice and answers to frequently asked questions.
To work with the documentation, each analyst has his own favorite toolkit - someone likes to draw diagrams, and someone writes a canvas of text in Word. In any case, I would advise you to become familiar with the basics of UML, BPMN, User Stories and Acceptance Criteria. They will surely meet each employer.
Work with the team
To a greater extent, for the team it is the analyst - the voice of the client. In any incomprehensible situations, it will come to him with the questions "And what was meant here?" And it will be with him to confirm whether the customer wanted it.
I always say that IT business analysts play the role of a kind of bridge between developers and business, being able to simultaneously speak the languages of customers and programmers. In our daily work, we will jointly discuss the requirements, plan and distribute tasks, answer current questions of programmers.
It often happens that a business analyst spends a lot of time with each team member and plays a peculiar role of a deputy manager. In my practice, there have even been such cases when a manager came to me to discuss who his colleagues should give a prize, and who should not.
Testing
Obviously, understanding the requirements of the client best of all, it is we who will have to check the results of the work of programmers.
The business analyst is expected to perform so-called User Acceptance Tests - user acceptance tests. No one is required to write automated scripts or check the sizes and colors of buttons on the site. All that is required is to introduce yourself as a user and take advantage of the finished product. Check whether there is any inconvenience when using it, whether the system works in general the way the user wanted, if there are no obvious errors or inconsistencies to the requirements.
An important point! It must be remembered that analysts spend all the time with the team, participate in discussions, know about the various “hacks” and bottlenecks of the program. At the same time, when performing tests, we must understand that the client does not have this knowledge, he does not know where to press, and where not. It is necessary to evaluate the system completely unbiasedly and to point out all the mistakes the developers - the sooner they can be identified, the easier it will be to fix.
Self development
They say that in order to keep up with all the new technologies in programming, it is necessary almost every day to learn new frameworks, try new versions of your favorite languages and follow the best practices from around the world.
Fortunately, the fundamentals of business analysis do not change so often. However, as I said in my last article, in order to stand out from the crowd of business analysts, you need to be as comprehensive as possible.
You also need to follow the changes in IT, you need to develop your soft skills, learn business management, the basics of finance, understand the subject areas of clients and so on. In general, it turns out that the time for training you will often require even more than fellow programmers.
In conclusion, I will give advice on self-development - accept its necessity and discuss with your supervisor. For business development, it is crucial not to drive oneself into the framework of established processes, because tomorrow a new client and a new project from a completely different sphere will appear. The business analyst should be able to quickly get used to the changing environment and get ready to work with a new subject area. It is here that all the time you spent expanding your horizons will come to your aid.
Source: https://habr.com/ru/post/443352/
All Articles