Lecture
A business analyst — a specialist who uses business analysis methods to research the operational needs of organizations in order to identify business problems and propose solutions to them.
The International Institute of Business Analysis (IIBA) defines a business analyst «as an intermediary among stakeholders for gathering, analyzing, communicating, and validating requirements for changes to business processes, policies, and information systems. The business analyst understands business problems and opportunities in the context of requirements and recommends solutions that enable the organization to achieve its goals».
In the consulting business, "business analyst" is the top position for a consultant.
Business Analyst Day is celebrated on June 24.
The IIBA marks World Business Analysis Day on November 1
A business analyst – a specialist who uses business analysis methods to analyze the operational needs of organizations in order to identify business problems and propose solutions to them.
A project manager – a specialist who uses project management methods to ensure that project activities conform to project requirements. Here it would be appropriate to give the definition of a project: a project is a unique set of coordinated activities with a start point and an end point, aimed at achieving a specific final result within constraints of time, cost, quality, and scope of work.
Product Management and Business Analyst are fairly related professions. Product management definitely includes creating requirements for the product (functional and non-functional), which is a direct responsibility of a business analyst.
That is, internet research, analysis of standards and specifications, competitive analysis, interviews, benchmarking, focus groups and other research methods, requirements management and their prioritization, relationships with stakeholders — are common to both.
Specifically for this article, I had to dig thoroughly through the JIRA archives from my last three jobs. I can't vouch for absolute accuracy (yes, I also dislike accounting for all my activities down to the last minute), but the overall picture really does match my own sense of the duties I perform.
The approximate distribution of work can be described as follows:
And here is the exact number of hours over the last 3 months:
As you can see, the picture is indeed similar. The small differences – the absence of business trips and more time spent working with the team – arise from a recent change of job and, accordingly, the process of integrating into a new environment.
Now let's look at each item in more detail.
Let's start with the most important thing — the very thing that business analysis begins with — business meetings, among which we'll include both meetings with clients and internal gatherings with the team.
First and foremost, this is — analysis of the subject area and gathering requirements. It is precisely here that we find out what the client actually wants from us, what problems they have, offer the first ideas for implementation, and together draw up a preliminary project plan.
Other important elements of meetings with clients — discussing completed work, planning changes, presentations and trainings where we explain how to use the proposed product.
Perhaps it is meetings that are the foundation of our work; they are precisely what provides analysts and their teams with further assignments, which is why it's worth preparing for them most thoroughly.
I would say that if an analyst is not at a meeting – then they are sitting and working with documentation. Don't get me wrong, this doesn't at all mean simply pounding mindlessly on the keyboard; on the contrary — it is precisely here that you have to engage all the capabilities of our intellect, and it is this part that is the most labor-intensive.
Here are just a few examples of what one regularly has to deal with:
For working with documentation, every analyst has their own favorite toolkit — some like to draw diagrams, while others write walls of text in Word. In any case, I would advise you to familiarize yourself with the fundamentals of UML, BPMN, and the concepts of User Stories and Acceptance Criteria. You will surely encounter them with every employer.
To a large extent, for the team it is precisely the analyst who is — the voice of the client. In any unclear situation, it is to them that people will come with the questions «And what was meant here?» and it is with them that they will confirm whether this is exactly what the customer wanted.
I always say that business analysts in IT play the role of a kind of bridge between developers and the business, being able to speak the languages of both clients and programmers at the same time. In day-to-day work, we have to jointly discuss requirements, plan and distribute tasks, and answer programmers' current questions.
Very often it turns out that the business analyst spends a lot of time with each team member and plays a kind of deputy-manager role. In my practice, there were even cases where a manager came to me to discuss which of the colleagues should be given a bonus, and which — not.
Obviously, understanding the client's requirements better than anyone else, it is precisely we who have to check the results of the programmers' work.
A business analyst is expected to perform so-called User Acceptance Tests. No one requires writing automated scripts or checking the sizes and colors of buttons on the website. All that is required — is to imagine yourself as a user and use the finished product. To check whether any inconveniences arise when using it, whether the system generally works the way the user wanted, and whether there are any obvious errors or discrepancies with the requirements.
An important point! You need to remember that analysts spend all their time with the team, participate in discussions, and know about 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; they don't know where to click and where not. It is necessary to evaluate the system completely impartially and point out all the errors to the developers — the sooner they can be identified, the easier they will be to fix.
They say that to keep up with all the new technologies in programming, you have to study new frameworks almost every day, try new versions of your favorite languages, and follow the best practices from around the world.
Fortunately, the fundamental basics of business analysis do not change so often. However, as I already said in my previous article, in order to stand out from the crowd of business analysts, you need to be as well-rounded a specialist as possible.
You too need to keep track of changes in IT, you need to develop your soft skills, learn business management, the basics of finance, understand your clients' subject areas, and so on. In general, it turns out that you will often need even more time for learning than your programmer colleagues.
A business analyst must be competent in a whole range of not very closely related areas:
A business analyst – is a general name for a group of professions that work with business requirements to achieve some goal.
In the IT field, analysts are often divided depending on which area the specialist's main knowledge is concentrated in: in the area of information technology or in the customer's domain area.
Foreign business analysis practice, which is more developed in its theoretical part than the domestic one, also discusses the differences between a business analyst and a systems analyst and comes to the conclusion that everything depends on the policy adopted in the company, on the competence of each particular person, and on whom the analyst interacts with more within the framework of the project.
The business analyst finds out the client's needs and justifies the necessity of implementing the project. After this, on the basis of the identified business requirements and the client's user requirements, the analyst defines the boundaries of the project.
The next stage is gathering functional and non-functional requirements. At this stage, a systems analyst may join the business analyst's work. The difference is that the business analyst does not take into account implementation platforms and technologies, but strives to account for all the customer's wishes and goals as fully as possible, ensuring the completeness, correctness, and consistency of the requirements. The systems analyst's task – is to take into account all the peculiarities of working with a particular technology and platform and to choose the optimal way to implement all the stated functional-technical requirements.
It happens that the platform and technologies were chosen in advance. Then it is necessary to competently distribute the functional requirements across the chosen platform, adapting their descriptions to the terms of the chosen platform and interaction interfaces for the development team.
Having worked through all the requirements, the analysts begin to consult the development and testing teams. The business analyst presents the requirements from the point of view of the end user, the systems analyst – from the point of view of their implementation on the chosen platform.
You can order a business analysis consultation for your software product here.
As a result of the division of areas of responsibility, systems analysts and business analysts produce different sets of documents. As a result of the business analyst's work, a Vision and Scope document will be created, defining the boundaries of the project, business requirements (BRD) will be documented, and requirements specifications (SRC) will be drawn up.
The systems analyst will present the concept of the IT solution (Software Design Document), indicating the project's implementation platform, technologies, including programming languages, and interaction interfaces.
In practice, it is often very difficult to clearly delineate the roles of the two. Depending on the specifics of the project, they may overlap and complement each other. The job titles themselves are not important. The main thing is that the company's employees understand what lies behind the job title and whom to turn to for the resolution of an arising issue.
But in order to propose a solution to meet the need for business automation, one must have a full understanding of the aspects of developing/using information technology systems and products. Or, in order to automate a business, one must delve into its essence and problems and understand its environment. Obviously, both specialists interact closely in the process: the second is a consumer of the first's results, and the areas of responsibility are delineated. When discussing these nuances, a second point of view emerges.
A business analyst – is a person who will figure out what is wrong with you and what you want. And they can even explain what you want themselves, if you haven't yet arrived at it on your own. This same person will then explain to the specific people who will make things good for you how to make that very good thing.
A project manager – is a person who works magic to ensure that project work gets done, and on top of that within the agreed time, cost, and quality, and aimed at what really needs to be done for things to be good for you.
some people think that
Let's examine and compare their areas of responsibility and professional requirements
A business analyst, as a rule, is not involved in planning the release of «features» in a product. A business analyst does not compile the roadmap. But for a product manager, this is their foremost responsibility. As a rule, product managers participate in the regular review of the roadmap (replanning) together with other stakeholders (marketing, development team managers).
A typical roadmap — is a set of features laid out on a time axis. Dependencies between features are necessarily indicated, and they are assessed by one of the methods (value, conditional cost of implementation, or a characteristic of the Kano model). It would be good to attribute a feature by functional and structural component.
After gathering, organizing, and agreeing on the requirements, the business analyst passes the requirements to the development team. The development team may have its own product owner or someone who plays that role. All of the team's communication regarding requirements now takes place with the product owner. Next, the team engages in coding, testing, and preparing for release.
With a product manager, it's not like that. Product managers take detailed part in development:
And in general, they can halt development if something went wrong. For example, the product suddenly lost relevance (for example, your product deals with tracking excise stamps, and they were suddenly abolished).
Product launch
When a product is created, it needs to be properly put into “operation”. This is the go-to-market plan, various documentation, user migration, onboarding of existing users, deployment, etc. There is a lot of technical work here, but also a lot of organizational work, and the product manager resolves many of the issues.
A product launch may be accompanied by a marketing campaign developed by marketing managers in close cooperation with the product manager. It is precisely the product manager who must ensure the product's deployment, having laid down the appropriate functional and non-functional requirements in advance at the planning stage.
Also included here is the withdrawal of a product or its parts from the market (end-of-life). For still-popular products, this procedure can stretch out over many months.
So, besides business analysis competencies, a product manager must possess knowledge and experience in the field of project management and marketing.
It is not enough merely to deliver a product — it needs to be kept in a “living state”, and that is:
Every software product has its own KPIs (internal and external), whose values the product manager tracks and initiates corresponding changes. You'll agree, this is somewhat far from the work of a business analyst.
A product manager is strongly oriented toward getting the maximum result with the least cost. Let's call this an MVP. There are a large number of pluses in this:
Usually, it is difficult to predict a product's success and “hitting the requirements”. A reliable industrial approach — is to expand the product in small iterations while analyzing the success of each such iteration.
Let's consider the key soft skills needed for these roles. I deliberately do not focus on professional knowledge and skills (for example, for a BA these might be technical writing, visual modeling, prototyping user interfaces, knowledge of techniques and processes for working with requirements, etc.), because, as follows from the knowledge areas above – they are radically different.
Common requirements:
Specific requirements (undoubtedly, everything below is desirable for both roles to have, but with equal success it is also desirable for developers, testers, and all other project participants to have):
In conclusion, I'll give a piece of advice about self-development — accept its necessity and discuss it with your manager. For business development, it is critically important not to box yourself into established processes, because tomorrow a new client and a new project from a completely different field will appear. A business analyst must be able to quickly get comfortable in a changing environment and prepare to work with a new subject area. It is precisely here that all the time you spent broadening your outlook will come to your aid.
Dear readers, both those who agree and those ready to argue: I will be glad to receive comments and opinions on what is written above. Despite my firm conviction about the radical difference between these areas, I believe that at certain individual points of intersection / difference, the topic can be disputed and supplemented.
Comments