The post has been translated automatically. Original language: Russian
"We need a mobile app."
"Add another report."
"Make the button blue."
This is how many projects start. But there is rarely a real business need behind such requests. As a result, the team implements functions that work technically, but do not solve the real problems of users.
The task of a business analyst is not just to collect requirements, but to understand the problem that needs to be solved. That is why analytics has become one of the key disciplines in digital product development today.
Who is a business analyst?
There is a common misconception that an analyst is a person who writes technical assignments.
In fact, his role is much broader.
A business analyst acts as a link between the customer, users and the development team. He helps turn abstract ideas into understandable requirements and makes sure that the product brings real value.
A good analyst is constantly asking questions:
- What problem are we solving?;
- who faced this problem?;
- why did it arise;
- how are users dealing with it today;
- how will we understand that the solution was successful?
The answers to these questions become the foundation of the future product.
Why are requirements not a solution yet?
Let's imagine the situation.
The company is making a request:
"We need a chat with customers."
At first glance, the task is clear.
But after analyzing it, it turns out that customers are asking the same question: "Where is my order?"
In this case, a full-fledged chat may be redundant. It may be enough to add convenient order tracking and automatic notifications.
A correctly formulated problem allows you to find a simpler, cheaper and more effective solution.
Analytics starts with processes
Any digital product automates an existing process.
If the process itself is not studied, automation will only consolidate existing shortcomings.
Therefore, the analyst first examines how the business works today.:
- who is involved in the process;
- what actions are being performed;
- where the delays occur;
- which operations are repeated?;
- which errors occur most often.
Only then does it become clear what really needs to be changed.
A good analyst can speak the language of business.
Developers are interested in architecture, integration, and technology.
Business profits, speed of service, cost reduction and customer satisfaction.
The analyst must understand both languages.
For example, instead of the wording:
"We need to implement integration with the new system."
It's much more useful to explain:
"The integration will reduce the order processing time from five minutes to one and reduce the number of manual errors."
This way, the team understands not only what needs to be done, but also why.
Paperwork is just part of the job
Many associate the analyst solely with the preparation of documentation.
Of course, quality requirements are important.
But no less important:
- conduct interviews;
- model business processes;
- identify risks;
- coordinate solutions;
- participate in testing;
- analyze feedback after launch.
The analyst's work continues throughout the entire product lifecycle.
What tools help the analyst?
Depending on the project, different approaches and notations are used.
The most common tools:
- User Story — description of functionality through the user's eyes;
- Use Case — scenarios of interaction with the system;
- BPMN — Business process modeling;
- UML diagrams - a description of the structure and behavior of the system;
- Customer Journey Map — user experience analysis;
- interface prototypes;
- requirements and traceability matrices.
The tool alone does not make the project successful. It is much more important to understand what task it helps to solve.
Mistakes that are costly to the project
Even experienced teams sometimes face typical problems.
Development starts too early
The desire to start programming faster often leads to numerous improvements after the release.
No clarifying questions are asked
If you take every customer's wish literally, you can implement a function that will not be beneficial.
End users are ignored
Sometimes the requirements are formed only by managers, although completely different employees use the system on a daily basis.
There are no acceptance criteria
If you do not determine in advance what the result should be, endless arguments arise about whether the task has been completed or not.
How to understand that the analysis was carried out qualitatively
Good analytics is not noticeable by the number of pages of documentation.
Its signs are much more practical:
- the team understands the goals of each task;
- the requirements do not cause ambiguous interpretations;
- the number of changes during development is minimal;
- users get a solution that really helps in their work.;
- the business sees a measurable effect after implementation.
It is these indicators that indicate that the analyst has done his job efficiently.
Results
Successful digital products don't appear because the team writes code quickly. They appear when development begins with an understanding of the business, users, and their real needs.
Business intelligence helps you avoid costly mistakes, reduce the number of completions, and focus on creating value. The more complex the product and the more project participants there are, the higher the role of the analyst becomes as a person who unites the interests of business, users and the development team.
Therefore, we can say that a good product does not start with the first line of code, but with correctly asked questions.
«Нам нужно мобильное приложение.»
«Добавьте еще один отчет.»
«Сделайте кнопку синей.»
Именно так начинаются многие проекты. Но за подобными запросами редко стоит настоящая потребность бизнеса. В результате команда реализует функции, которые работают технически, но не решают реальных задач пользователей.
Задача бизнес-аналитика — не просто собрать требования, а понять проблему, которую необходимо решить. Именно поэтому аналитика сегодня стала одной из ключевых дисциплин в разработке цифровых продуктов.
Кто такой бизнес-аналитик
Существует распространенное заблуждение, что аналитик — это человек, который пишет технические задания.
На самом деле его роль гораздо шире.
Бизнес-аналитик выступает связующим звеном между заказчиком, пользователями и командой разработки. Он помогает превратить абстрактные идеи в понятные требования и следит за тем, чтобы продукт приносил реальную ценность.
Хороший аналитик постоянно задает вопросы:
- какую проблему мы решаем;
- кто столкнулся с этой проблемой;
- почему она возникла;
- как сегодня пользователи справляются с ней;
- как мы поймем, что решение оказалось успешным.
Ответы на эти вопросы становятся фундаментом будущего продукта.
Почему требования — это еще не решение
Представим ситуацию.
Компания обращается с запросом:
«Нам нужен чат с клиентами.»
На первый взгляд задача понятна.
Но после анализа выясняется, что клиенты задают один и тот же вопрос: «Где находится мой заказ?»
В таком случае полноценный чат может оказаться избыточным. Возможно, достаточно добавить удобное отслеживание заказа и автоматические уведомления.
Правильно сформулированная проблема позволяет найти более простое, дешевое и эффективное решение.
Аналитика начинается с процессов
Любой цифровой продукт автоматизирует существующий процесс.
Если сам процесс не изучен, автоматизация только закрепит существующие недостатки.
Поэтому аналитик сначала исследует, как работает бизнес сегодня:
- кто участвует в процессе;
- какие действия выполняются;
- где возникают задержки;
- какие операции повторяются;
- какие ошибки происходят чаще всего.
Только после этого становится понятно, что действительно необходимо изменить.
Хороший аналитик умеет говорить на языке бизнеса
Разработчиков интересуют архитектура, интеграции и технологии.
Бизнес — прибыль, скорость обслуживания, снижение затрат и удовлетворенность клиентов.
Аналитик должен понимать оба языка.
Например, вместо формулировки:
«Нужно реализовать интеграцию с новой системой.»
Гораздо полезнее объяснить:
«Интеграция позволит сократить время обработки заказа с пяти минут до одной и уменьшит количество ручных ошибок.»
Так команда понимает не только что нужно сделать, но и зачем.
Документы — лишь часть работы
Многие связывают аналитика исключительно с подготовкой документации.
Безусловно, качественные требования важны.
Но не менее важно:
- проводить интервью;
- моделировать бизнес-процессы;
- выявлять риски;
- согласовывать решения;
- участвовать в тестировании;
- анализировать обратную связь после запуска.
Работа аналитика продолжается на протяжении всего жизненного цикла продукта.
Какие инструменты помогают аналитику
В зависимости от проекта используются разные подходы и нотации.
Наиболее распространенные инструменты:
- User Story — описание функциональности глазами пользователя;
- Use Case — сценарии взаимодействия с системой;
- BPMN — моделирование бизнес-процессов;
- UML-диаграммы — описание структуры и поведения системы;
- Customer Journey Map — анализ пользовательского опыта;
- прототипы интерфейсов;
- матрицы требований и трассируемости.
Инструмент сам по себе не делает проект успешным. Гораздо важнее понимать, какую задачу он помогает решить.
Ошибки, которые дорого обходятся проекту
Даже опытные команды иногда сталкиваются с типичными проблемами.
Разработка начинается слишком рано
Желание быстрее приступить к программированию часто приводит к многочисленным доработкам уже после релиза.
Не задаются уточняющие вопросы
Если принимать каждое пожелание заказчика буквально, можно реализовать функцию, которая не принесет пользы.
Игнорируются конечные пользователи
Иногда требования формируют только руководители, хотя ежедневно системой пользуются совершенно другие сотрудники.
Отсутствуют критерии приемки
Если заранее не определить, каким должен быть результат, возникают бесконечные споры о том, выполнена задача или нет.
Как понять, что аналитика проведена качественно
Хорошая аналитика заметна не по количеству страниц документации.
Ее признаки гораздо практичнее:
- команда понимает цели каждой задачи;
- требования не вызывают двусмысленных трактовок;
- количество изменений в ходе разработки минимально;
- пользователи получают решение, которое действительно помогает в работе;
- бизнес видит измеримый эффект после внедрения.
Именно эти показатели говорят о том, что аналитик выполнил свою работу качественно.
Итоги
Успешные цифровые продукты появляются не потому, что команда быстро пишет код. Они появляются тогда, когда разработка начинается с понимания бизнеса, пользователей и их реальных потребностей.
Бизнес-аналитика помогает избежать дорогостоящих ошибок, сократить количество доработок и сосредоточиться на создании ценности. Чем сложнее продукт и чем больше участников проекта, тем выше становится роль аналитика как человека, который объединяет интересы бизнеса, пользователей и команды разработки.
Поэтому можно сказать, что хороший продукт начинается не с первой строки кода, а с правильно заданных вопросов.
