What do IT business analysts do
Each of us must have heard the same question from our parents or friends not from the “programmer party”: “What are you doing there at all?”
Usually, after an attempt to answer, an unchanged comment follows: "Oh, you programmer, you can’t even fix the refrigerator." What can we say about business analysts who cannot really explain to their colleagues what they are doing.
I myself often hear this question from my father, but still I just can’t find the right answer. And the truth is what we do at work - we analyze!
Especially for this article, I had to thoroughly dig into the JIRA archives from the last three places of work. I can not 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 from the duties performed.
The approximate distribution of work can be described as follows:
And here is the exact number of hours in the last 3 months:
As you can see, the picture is really similar. Small differences - the absence of business trips and longer working hours with the team - arise due to the recent change in the place of work 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, the business analysis begins with business meetings, which include meetings with clients and internal meetings with the team.
First of all, this is the analysis of the subject area and the collection of requirements. It is here that we find out what the client wants us to do, what problems he has, we offer the first ideas for implementation and together we draw up a preliminary project plan.
Other important elements of meetings with clients are discussion of completed work, change planning, presentations and trainings where we tell how to use the proposed product.
Perhaps it is meetings that 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 at the meeting, then he is sitting and working with the documentation. Do not get me wrong, this does not mean that you just need to stupidly knock on the keyboard, on the contrary - it is here that you have to use all the capabilities of our intellect, this part is the most labor-intensive.
Here are just a few examples of what you have to deal with regularly:
Each analyst has his own favorite toolkit for working with documentation - someone likes to draw diagrams, and someone writes a canvas of text in Word. In any case, I would advise you to familiarize yourself with the basics of UML, BPMN, the concepts of User Stories and Acceptance Criteria. They are likely to be found at every employer.
To a greater extent, for the team it is the analyst - the voice of the client. In any incomprehensible situations, they will come to him with the questions “What did you mean here?” And it will be with him that they will confirm whether the customer really wanted to.
I always say that business analysts in IT play the role of a kind of bridge between developers and business, being able to simultaneously speak the languages of clients and programmers. In everyday work, we have to jointly discuss requirements, plan and distribute tasks, and answer current questions of programmers.
It often happens that a business analyst spends a lot of time with each member of the team and plays a peculiar role as deputy head. In my practice, there have even been such cases when a manager came to me to discuss which of the colleagues should give a prize and who should not.
It is obvious that, best of all, understanding the requirements of the client, we will have to check the results of the work of programmers.
A business analyst is expected to run the so-called User Acceptance Tests - user acceptance tests. No one needs 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 if there are any inconveniences when using it, if the system works in general as the user wanted, if there are any obvious errors or inconsistencies with the requirements.
An important point! It must be remembered that analysts spend all the time with the team, participate in discussions, are aware of 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 click, and where not. It is absolutely necessary to evaluate the system with an open mind and point out all the errors to 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, you need to learn new frameworks almost every day, 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 the most comprehensively developed specialist.
You also need to monitor changes in IT, you need to develop your soft skills, learn business management, the basics of finance, understand the subject areas of customers and so on. In general, it turns out that you often will need even more time for training than fellow programmers.
In conclusion, I will give advice on self-development - accept its necessity and discuss with your leader. For business development, it is critically important not to push yourself into the framework of established processes, because tomorrow a new client and a new project from a completely different sphere will appear. A business analyst must be able to quickly get used to a changing environment and get ready to work with a new subject area. It is here that all the time that you spent expanding your horizons will come to your aid.
Usually, after an attempt to answer, an unchanged comment follows: "Oh, you programmer, you can’t even fix the refrigerator." What can we say about business analysts who cannot really explain to their colleagues what they are doing.
I myself often hear this question from my father, but still I just can’t find the right answer. And the truth is what we do at work - we analyze!
What does an IT analyst spend time on?
Especially for this article, I had to thoroughly dig into the JIRA archives from the last three places of work. I can not 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 from the duties performed.
The approximate distribution of work can be described as follows:
- Meetings - 20%
- Documentation - 30%
- Teamwork - 25%
- Testing - 5%
- Business trips - 5%
- Self-development - 15%
And here is the exact number of hours in the last 3 months:
As you can see, the picture is really similar. Small differences - the absence of business trips and longer working hours with the team - arise due to the recent change in the place of work 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, the business analysis begins with business meetings, which include meetings with clients and internal meetings with the team.
First of all, this is the analysis of the subject area and the collection of requirements. It is here that we find out what the client wants us to do, what problems he has, we offer the first ideas for implementation and together we draw up a preliminary project plan.
Other important elements of meetings with clients are discussion of completed work, change planning, presentations and trainings where we tell how to use the proposed product.
Perhaps it is meetings that are the basis of our work, they provide analysts and their teams with further tasks, so it is worth preparing for them most carefully.
Work with the documentation
I would say that if the analyst is not at the meeting, then he is sitting and working with the documentation. Do not get me wrong, this does not mean that you just need to stupidly knock on the keyboard, on the contrary - it is here that you have to use all the capabilities of our intellect, this part is the most labor-intensive.
Here are just a few examples of what you have to deal with regularly:
- The requirements specification is the transformation of a free flight of the client’s thoughts into a structured document that clearly describes what the team needs to do. Later, this document is approved with the client and forms the basis of the ongoing project.
- Change Request (Change Request) - the process initiated by the client in the event that changes are required in the product after the start of development or even after its completion. The document describes which part of the system and how it should be modified, contains an assessment of the performance of work in 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 tips and answers to common questions.
Each analyst has his own favorite toolkit for working with documentation - someone likes to draw diagrams, and someone writes a canvas of text in Word. In any case, I would advise you to familiarize yourself with the basics of UML, BPMN, the concepts of User Stories and Acceptance Criteria. They are likely to be found at every employer.
Team work
To a greater extent, for the team it is the analyst - the voice of the client. In any incomprehensible situations, they will come to him with the questions “What did you mean here?” And it will be with him that they will confirm whether the customer really wanted to.
I always say that business analysts in IT play the role of a kind of bridge between developers and business, being able to simultaneously speak the languages of clients and programmers. In everyday work, we have to jointly discuss requirements, plan and distribute tasks, and answer current questions of programmers.
It often happens that a business analyst spends a lot of time with each member of the team and plays a peculiar role as deputy head. In my practice, there have even been such cases when a manager came to me to discuss which of the colleagues should give a prize and who should not.
Testing
It is obvious that, best of all, understanding the requirements of the client, we will have to check the results of the work of programmers.
A business analyst is expected to run the so-called User Acceptance Tests - user acceptance tests. No one needs 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 if there are any inconveniences when using it, if the system works in general as the user wanted, if there are any obvious errors or inconsistencies with the requirements.
An important point! It must be remembered that analysts spend all the time with the team, participate in discussions, are aware of 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 click, and where not. It is absolutely necessary to evaluate the system with an open mind and point out all the errors to 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, you need to learn new frameworks almost every day, 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 the most comprehensively developed specialist.
You also need to monitor changes in IT, you need to develop your soft skills, learn business management, the basics of finance, understand the subject areas of customers and so on. In general, it turns out that you often will need even more time for training than fellow programmers.
In conclusion, I will give advice on self-development - accept its necessity and discuss with your leader. For business development, it is critically important not to push yourself into the framework of established processes, because tomorrow a new client and a new project from a completely different sphere will appear. A business analyst must be able to quickly get used to a changing environment and get ready to work with a new subject area. It is here that all the time that you spent expanding your horizons will come to your aid.