Greetings! My name is Sergey, and I am a business / systems analyst. I have been working in the IT industry for about 8 years, starting with maintenance that flows into testing and continuing with analytics: both business and system. I have not yet worked separately as a business and as a system analyst.In the course of my professional activities in general, including practice and personal interviews, and in particular interviews with potential candidates, I gradually came to understand what skills the market expects from the Analyst. Habr did not see fresh articles on this subject for a long time, so I decided to prepare the material myself.For whom, in my opinion, the article will be useful:- Beginning business / system analysts;
- Analysts who want to continue to pump their prof. Skills
- Perhaps recruitment managers.
I must say right away that the points below are my subjective vision of the analystâs specialization , which was formed during the practice. If your company runs a full-fledged scrum with a product owner sitting a meter away from you, with a designer and an architect allocated for the team, some of the above may not be in demand.Nevertheless, at least all these skills will not be superfluous and will make the analyst even more competent in his questions. Of course, you need to understand that I did not list all the skills and abilities of the analyst (the same notations, business skills, sql and so on).Business analytics
- Eliminate ambiguous requirements at the earliest stages
When talking with a business customer, you need to be aware that its language can differ significantly from yours. A business requirement can be voiced in such a way that several participants in the requirements approval process have a different understanding of what this requirement means. The ambiguity is generated, which is very expensive for the team in the later stages of development.The problem is most acute when there are several business customers, each of which puts forward its own requirements. For example, when integrating two systems, each of which has its own representative from the business.Case study: a month of development was spent on the functional of transferring the list of activities from object No. 1 to object No. 2. At the stage of acceptance testing, it was discovered that the customer expected a completely different functionality - copying, not transferring activities. In the process of redoing the functionality and detailing the ambiguity, the IT team, firstly, agreed with the customer about MVP, and, secondly, the need to work with the root of the business problem. It was hypothesized that the copying functionality itself is required only because of insufficiently implemented functionality for loading activity templates.
- Do not be afraid to check with the customer about the requirements of the requirement
I met with cases when I worked out when the development statement was described without fixing a business goal: what exactly would this completion help the business? What pain will this refinement relieve from business?Often, such improvements without purpose led to unpleasant consequences already at the testing stage, when both the developer and the tester did not understand why we designed this functionality. Worse, the developer and tester did not receive answers from the analyst, and if they did, they often came up with the analyst himself: goals that the analyst formed on his own.
Write down goals together with the customer, so that absolutely all participants in the process at any time understand why they are doing their job.- Demand your customer attendance at business meetings
In practice, I came across different customers, some of which were not immediately ready to invite the analyst to their offline meetings. The analyst will also have to work with this: to agree and show the result of well-coordinated collaboration., â UX- â « », , . : , , windows-, . , .
Many analysts, including myself, in the process of formulating requirements, faced with a hard deadline, used the following technique: they wrote a letter to the participants of the process with a deadline by which the letter should be answered and the requirements agreed / comments should be made. Otherwise, the requirements will be automatically recognized as agreed.As practice has shown, there is nothing good in this approach. It is clear that, working on the side of the vendor and having an agreement on hand, you have to resort to such methods, but still try to avoid tacit consent, try to understand why the participants do not want to give you an answer right now, and solve the problem as soon as possible.It is better to document in writing the fact that the answer was not received from such and such persons and you see the following risks for the project in this. However, the work process cannot stand still, therefore you are forced to continue your analytical work, while the previously defined risks should be clear to all participants in the process.In the process of developing the integration of the two systems, we were faced with the formation of requirements by the director covering the actions of users in the two systems, but the lack of explicit coordination of these same requirements from the immediate head of the unit, whose employees were users of the system.
As it turned out later, the head of the division did not understand at all why all these improvements and how they would help optimize the processes in his area of ââresponsibility.
Often, participants in the approval process are simply afraid to put their signature, because they do not fully understand certain sections of the updated business process. Your task as a business analyst is to eliminate this misunderstanding.
- Introduce the subject area to developers
Spend a few hours, but tell your developers about the customer, current business processes, pain and development plans. As a rule, well-motivated developers not only do their job perfectly well, understanding who they are writing the code for, but also make a valuable contribution: they offer optimization, workarounds, are more willing to ask clarifying questions.If necessary (and lack of scrum), attract the customer to such a meeting. As a rule, Business representatives willingly agree to such initiatives.- Teach the customer to answer the question âWhat?â Rather than formulate requirements in the format âHowâ
The customer should not formulate a business / user requirement from the âHow toâ position: we need a button on this screen to generate a report; we need a link to an external system in this section; etc.At the stage of the initial analysis of the process, prior to the design itself, the customer should not offer a solution.Instead, teach the customer to formulate the problem, their âpainâ: we need to generate a report on a weekly basis, which is manually supplemented by an employee and sent to management; in the process of working with the client, we need to analyze additional information, and since it is not available in the CRM system, we have to open a new tab in the browser and log in to the adjacent system.Having learned the pain of the customer, you, as a specialist, can offer options for optimizing the process and its automation. For example, automatically send the generated report to the employeeâs mail, save the employee from manual work with the report, in principle, automatically download data from an adjacent system to CRM, and so on.In many cases, this approach will face reality: deadlines and priorities. But you, in any case, honestly tried.
- Be sure to divide users into classes
Accepting requirements from the user of the system, without fail take into account his role in the business process. In practice, there are often cases when the head of the department forms the requirements for the functional with which an ordinary employee will work.Divide the users of the system into roles, and the functionality that is sharpened for one role, do not "smear" under another role.Once, within the framework of the System, we implemented the display of a list of transactions with customers.
It was assumed that both managers and ordinary employees would work with the list. Unfortunately, we were not able to get an understanding from the customer of the need to divide the UI part of the revision into two lists / screens: one list for the manager for the purpose of analysis and control, the second list for the employee for the purpose of carrying out operational activities.
The result was a certain monster, which subsequently had to be finalized and finalized.
Apply best practices from UX: work out characters - user models. Convince the customer to separate the requirements for each character.- Actively use analytical brainstorming
It is possible in tandem with the second analyst, it is possible in tandem with the UX designer. In the assault process, try on two roles: one person first generates a lot of ideas, feasible and not very, the second - criticizes these ideas, decomposes them, writes them down, thinks them over; then switch roles and do the same job.As practice shows, this approach will significantly accelerate the process of compiling functional requirements and improve their quality. But there is a difficulty in that both specialists should be in the context of the task.- If you are stuck in Waterfall, do not despair and move towards Scrum
In one of the companies, literally in a year, our team managed to transfer the process of introducing improvements from the well-established at the level of managing managers to Waterfall to some kind of Scrum. Yes, the âclearâ deadlines for the highly smeared backlog, which the customer constantly demanded from the IT team, were pulling back, while the rhetoric was gradually mitigated through two-week releases, MVP solutions and a quick response to changes.- Never demonize the customer.
Yes, there are all kinds of customers. There are those who are literally furious. Nevertheless, a business analyst must resolve this issue either on his own or with the involvement of a manager, and in no case should he take a âquarrel out of the hutâ - on the team.The team should be well motivated to work, and the role of a business analyst in the process of motivation formation is one of the key.Seriously. When in the process of communicating with the customer, I hear ridiculous verbal interruptions from my analytic colleague, when my analytic colleague interrupts the customer without listening to him to the end, I want to send him to courses on negotiating or elementary ethics.Try and listen to the interlocutor, and hear him.- Get rid of parasite words
Try to avoid parasitic words and less âmooâ in conversations. At first itâs hard, but, believe me, itâs doubly difficult for the customer to listen to such an analyst who cannot express his thoughts clearly and clearly. A parasite can be affected by a developer, designer, tester, but not a business analyst connecting the IT team with the Business. :
- " ".
- ", : ".
System analytics
- When setting the task to front and back, try to describe the sequence diagram
Or, in Russian, sequence diagrams. The diagrams will prove to be useful even not from the point of view of development, but from the point of view of verification of their own requirements. Very often, when describing a message flow, I identified âholesâ in my own process. For example, an irrelevant API.To quickly âdrawâ a sequence of diagrams, use the PlantUML plugin for Confluence. It seemed to me that itâs faster to type code than to adjust the location of blocks and arrows with pens. But everyone in this part has their own experience and their own preferences.
In terms of analysis, the Swagger Editor allows you to close your own holes in requirements. Somewhere they missed the attribute, somewhere they forgot to create a task in JIRA to finalize the database. Do not try to memorize Swagger syntax, but create templates for different types of APIs (directories, filters, etc.) to simplify your life in the future.
- Actively use the developer tool in the target browser to analyze client requests and responses from the server
Firstly, during the initial acceptance process, you can check the API that you yourself described. Sometimes itâs faster to check some of the improvements by outgoing requests than by the UI, in order to understand the root of the problem at an early stage.You, as an analyst, will need much less time to check the implementation from the developer: outgoing data, incoming data, the result in the UI.
Secondly, you can verify the correct call sequence. After all, you yourself described it in the framework of the sequence diagram.This approach allowed our team to bring out quite tricky improvements to the proms as part of the sprints without delay. :
- " JavaScript". JSON, , HTML, http / https, .
- . , . " . , , ". , , , .
In addition
- Immerse yourself in the UX
You might even like it and want to evolve towards UX analytics. In any case, studying the relevant literature and design tools will benefit at least from the point of view of finding a common language with the UX designer from your team.Often those requirements that you, as an analyst, detail and write down, will subsequently be adjusted by the designer. After all, you are not alone, in fact, are designing the user experience.To be on the same wavelength, practice your UX analysis. For example, in your free time in Sketch or Figma, from time to time showing the result to your designer. Such an analytics experience will never be superfluous. :
- " ".
- " ".
- ". ".
- ". ".
***Thanks for reading the article! I would be grateful, firstly, for the feedback. Secondly, for recommendations on literature, sources, for best practices, personal experience and recommendations.