In this article, I will try to talk about the business analyst profession for beginners and those who want to start their career.
Without experience in this field, you might ask a reasonable question: "What is the difference between a business analyst and a systems analyst?" They tried to find the answer to this question many times on Habré, no one has an unequivocal answer, but there are many good articles.
One of them: Business Analyst and Systems Analyst in IT. We understand the varieties
Introduction
I have been working as an Oracle Siebel CRM analyst for more than 3 years, for more than a year I have been preparing interns for the harsh realities of working days. As a rule, my learning style consists of small introductory lectures and immediate utilization of the trainee for real tasks with quality control.
In the conditions of self-isolation, I faced an interesting case: while working as a consultant for a company with stringent security requirements, I did not have the opportunity to consolidate the transferred theoretical knowledge with practical application. This led me to a very interesting challenge for the mentor: the need to present theory in such a way as to minimize the concepts abstract for the trainee, preparing him for real problems without practical experience. I will try to capture the experience gained in this article.
What does an analyst do?
Usually, when answering a question about my profession, I say that an analyst is a translator from the language of the humanities into the language of technicians. But is everything so simple in the world?
In fact, analytics consists of the following steps:
- Receiving a request for system revision
- Refining the desired result the user gets at the end of your process
- Clarification of the current work process
- Preliminary design of the solution
- Coordination with the customer of additional steps of the process, if they are necessary to achieve the result,
- Solution correction
- Coordination of the process with the customer
- Registration of technical specifications for the developer
- Testing the main scenarios of the functionality
- Documentation preparation, writing user instructions
- Transfer of functionality to the customer
Learn more about each step
Receiving a request for revision
As a rule, customers of modifications are people who are far from the IT sphere. Requirements are rarely systematized, described clearly and logically. This is something you will need to fix before handing over the task to the developer.
Clarification of the desired result
Here you should clarify what the customer specifically wants. It can be anything: changing the status of an application, generating a document, sending an SMS or E-mail, in general, everything that an IT system can do.
Always use the following guidelines at this stage:
- For you, there should not be a single abstract concept in the problem statement from the customer. If you are not sure if you and the customer have the same understanding of some words, make sure that you come to an understanding.
- There are no stupid questions, there are incorrectly formulated and incorrectly addressed questions. The analyst is not an expert in all areas of the business, but must be able to quickly grasp a new area. Don't be afraid to ask.
Clarification of the current process
Most often, the current work process is called the "AS-IS process"
After completing this stage, you should imagine the process as a black box .
Preliminary design of the solution
This stage implies the definition of the future process or, as they say, the "TO-BE process".
After completing this stage, your black box should turn into white, that is, you should know exactly what is happening inside the process. It looks like this:
Be guided by the following principles:
You may have noticed that "Input 3" appears in the white box. Sometimes you may find that there is not enough data in the system to achieve the result. Let's take as an example some kind of certificate on the conclusion of an agreement between the customer's company and the client, which should reflect the client's patronymic, which is not stored in your system. In this case, you must inform the customer about this and offer a solution to the problem, for example, add the "Patronymic" field to the system and ensure that it is filled in. For users, this means filling in an additional field when working with the system, which must be agreed with the customer.
Solution correction
Sometimes the coordination of new steps in the process takes place with comments on your decision from the customer. In this case, you must correct the proposed solution. But this does not always happen, which means that you are a fine fellow and have finished the design at the step "Preliminary design of the solution"
Process coordination
After completion of the design, the process must be agreed with the customer. The agreement format most often depends on the realities of a particular company and a particular customer. These can be textual descriptions of the process, description in the notation for describing business processes, or verbal agreement.
Registration of technical specifications
The format of the technical assignment also depends on the norms adopted in the companies of the customer and the executor and, often, on the competence of the developer: inexperienced developers need a more detailed description of the process. During my career, I have met companies in which there were no technical specifications at all and everything was discussed in a free format, but all statements have a common feature: you must describe arithmetic and logical functions defined at the design step, in text or visually, in the form of block schemes.
Functional testing
Anticipating the question, yes, analysts often do testing. But, as a rule, this testing is superficial to make sure that the developer understands you correctly. Usually, it is limited to going through the main scenarios of work in order to identify the presence of critical defects, that is, bugs that do not allow achieving the desired result in any way. QA specialists are engaged in the search for minor defects and testing of functionality in different conditions.
Documentation
This is perhaps the least favorite stage of most analysts, but your expert knowledge of the functionality should be recorded in writing. Write the documentation well: the process should be described in sufficient detail so that an unenlightened person can understand what is happening inside the white box, and short enough so that you can read it and stay awake.
User instructions are a short memo for the end user of your functionality, in which the user's actions are described in steps. This type of documentation should consist of a list of actions, it should not contain technical terms.
The format of these documents also depends on the norms adopted in a particular customer company.
Transfer of functionality to the customer
The most enjoyable part of the job. Here you showcase the work done to the customer, collect laurels, take pride in the work done, and charge yourself with positive emotions for the next task.
Output
An analyst's job involves a lot of communication, brainstorming and using all the possibilities of logic that nature has endowed you with.
If you enjoy organizing and optimizing, if you like everything to be clear and logical in life, working as an analyst will give you a lot of pleasure, and you will surely reach the top in your career.
I hope my article helped you form an impression about analytics and led to awareness of your path in life. Good luck!