IT language of the Business Analyst

— I remember my reaction at my first meetings with a development team. It seemed like I didn't understand anything. As you work, you find that your communication language starts to look and sound like very bad English. You basically stop talking in Russian and start communicating with Anglicisms instead.

Who is a business analyst

— When people ask what a business analyst does, the logical answer is that they analyze business. In fact, it's not that simple. At one meetup I heard this question: “How soon will a business analyst become an obsolete profession?” No one really understands what they do: they don't write code, they don't make product decisions. The answer, however, was that the business analyst is unique because they have “two brains.” One understands business and the other understands developers, at the same time.

— The business analyst straddles two worlds. They are the link between the business and the people who write the code. For example, a business says it needs an online store. The question arises: What does an online store represent? The first thing that comes to mind is a website. A business analyst should ask a lot of clarifying questions: what kind of site is this; what will the tabs be; what products will be presented; will the site allow payment and, if so, through what systems? Or maybe the store is intended to be just a showcase without a means of purchase, somewhere a person can familiarize themselves with the assortment of available offerings? If so, will it be possible to leave comments on the order? Even when a business decision seems like a simple one, a lot of inter-related questions arise, but a business representative often doesn't think about them. And developers or designers need to know what to draw and develop; to do that, they need sufficiently detailed information. So, you can't just come in and say you need to create an online store. The business analyst is the team member who goes through and synthesizes all the steps that start as just an idea about the product, and the business side, to bring the concept to the point where it will work.

Popular business analytics terms

• User story is an explanation that includes a description of the product's features, preferably in plain and simple language. It has a specific format and must match a generally accepted set of criteria. One such criterion is the avoidance of ambiguity. The story should be perceived and understood by different people in the same way. A user story consists of two parts: the main part and the acceptance criteria. The main part is a structural description of the user's desires. The acceptance criteria are the conditions that a product must meet to be accepted by the user. Business analysts think not only about what the user can do, but also why they need to do it. The BA makes sure that the development (the feature being developed) is necessary for both the business and the user. One of the tasks of the business analyst is to control what functions go into development. Each must fit the business goals and the user needs, stay within the scope (the amount of work that needs to be done to achieve the project goals), and solve the problem. If a customer comes to you and says “I want my site to have a plane flying from the left to the right corner,” you need to find out why — what business goal it covers, what user need it covers. Generally speaking, a business analyst is an eternally rigorous person who asks a lot of questions all the time.
• BA approach. It is important for a business analyst to choose the right tools according to the objectives of the project. This is what the BA approach is for — to determine how best to document and communicate on the project, what templates to use for user stories and documentation, and how to systematize and store this information. The BA approach is an instruction manual for how to work. It is especially important for juniors who just came to the project and do not know (and should not be expected to) how to act in various situations. The key is to be able to correctly use what your senior colleagues have prepared.
• Stakeholder management. Stakeholders are people whose decisions and actions affect the product. It is very important for the business analyst to know where requirements come from. The BA is in constant communication with the business, so it is necessary to understand which person is responsible for what, and who has what kind of authority. Frequently, the project sponsor doesn't have time to dive into the details. But there are also some stakeholders who don't have a lot of influence on the project, but their interest in it is very high. This group includes the end users of the product. It is important for the BA to understand who is responsible for what, what questions to go to whom, and with whom and how often to communicate. A common case is when stakeholder 1 comes in and says that the button should be red, and stakeholder 2 says it should be blue. What do you do as a business analyst? Review the project documentation and see what stakeholder 1 is responsible for, and what stakeholder 2 is responsible for, and which one has the authority to make the decision.
• Risk management. This term is familiar not only to analysts, but also to managers across all business types. Everyone has their own list of risks that can occur. Risks can be both negative and positive. Typically, everyone focuses on negative risks. For a business analyst, one of the most common and frequently discussed risks is that of dealing with the silent stakeholder, when you find yourself writing letters to nowhere. You need to clarify something, your deadline is nearing, your development team is idle, you can't pass the user story to development without a final authorization or the clarification of certain details, and there is no response. Thinking about this in advance, and developing a plan of action for this common and difficult situation, is definitely not superfluous. This risk is closely related to stakeholder management.
• Elicitation and gathering of requirements. It is important for the business analyst not to invent their own requirements for the system. Instead, they must be able to competently and efficiently find out, from the business, what it needs. And you should be aware that simple and clear answers do not always follow from simple and clear questions. To find the truth, you will use various techniques: interviews, brainstorms, surveys, and other methods. It is very important to ask the right questions. How you ask a question influences how you will be answered. The best answer for a business analyst is clear, complete, and unambiguous. You need to identify all requirements as fully as possible to work with them and then pass them on to development.
• Traceability management. This tool is designed to ensure that the BA does not go overboard or inadvertently allow any gaps in the project. Establishing quality goals in the beginning is the key to the success of the project. Next, it is important to create a sequence of events from the initial business requirement to the final user story. Since it is a long journey, requirements often arise that did not exist originally, or, conversely, something is lost along the way. At some point, you may realize that you no longer understand why you're doing it. BAs correlate business needs with the needs of the user. Then, they come up with a solution, break the solution down into features, and features into stories. This can all be presented in the form of a traceability matrix, a table which shows how you get from the source of the problem to the particular story. It's a great tool to use, so that during the process, you don't forget what you're doing, why you're doing it, and for whom. At the end, when you realize that you have roughly 30 user stories and many of them do not cover any of the business goals, they must be abandoned to eliminate extra work and the possible disappointment of the customer.
• Backlog. The business analyst is one of the people in charge of the product backlog. This is where all of the tasks that need to be done are put together. Then, the BA, along with the team and the product owner, estimates (evaluates) and prioritizes the tasks (you can find a lot about prioritization techniques here). Assigning the right priority to a task is very important, because you should not forget about the Pareto Principle, which says that 80% of the result is determined by 20% of the effort. That 80% of the result allows the product to work and deliver some value. It often happens that tasks assigned a low priority are addressed out of order because they are not needed, or are of insufficient value.
  
• Business processes. Business analysts can identify and describe how data travels, but they are more concerned with business processes — the sequence of activities that results in the creation of a product. This is where the Business Process Model and Notation (BPMN) diagram helps (there are many different notations, but this is one of the main ones). The key task is to understand the process AS IS (how things work now). Creating the visualization often makes it clear where in the process there are “pain points” (problems). The second step is to create a TO BE diagram (what the process should be so that it doesn't contain pain points). Next, based on the notation, work is done to develop and implement a new feature or improve an already implemented one.

More information about BPMN can be found here.

Qualities a business analyst should have

— Soft skills are a must for a business analyst. The foundation is communication — being able to find common ground with business personnel and developers. Creating artifacts is just as important. But that flows from the communication part of the job. That is why it is important to pay attention to skills such as problem solving, conflict management, and teamwork. You may have excellent hard skills, but if you do not communicate effectively, nothing will work.

Technical knowledge is also important, at least at the level of understanding how it works. Remember about the necessity of communication with your fellow developers.

You can't go anywhere without a good working knowledge of English, either. I recommend that you read all of the literature in English. If it's difficult to read in English initially, you can read the material first in your native language, and then read it in English.

— It is important to remember that the business analyst must constantly communicate with the team and the stakeholders in the same language (even though each has a different working language), while at the same time not making things more complicated than necessary.

We invite you to discuss this article in our Discord channel.