Первый полноценный проект может быстро объяснить, почему работа бизнес-аналитиком не сводится к сбору требований и красивым схемам. Младший бизнес-аналитик направления BI компании «ДАР» из ГК «КОРУС Консалтинг» Дарья Шадривова описала выводы после года в профессии: техническое образование помогает войти в тему, но не заменяет умения договариваться, разбираться в данных и принимать решения в условиях неполной информации.
О своём опыте Шадривова рассказывает Habr / Карьера. Автор пришла в профессию после двух технических специальностей: бизнес-анализ показался ей точкой пересечения интереса к технологиям, коммуникации и решению практических задач. Однако реальная работа бизнес-аналитиком началась не с аккуратной теории, а с длинного проекта, где параллельно шли разработка, интеграции, обсуждения с заказчиком и неизбежные изменения требований.
Технический бэкграунд не отменяет погружения в проект
Главный ранний урок — знания из университета не дают автоматически понимания конкретного проекта. На старте аналитик может видеть множество терминов, систем и участников, но не понимать, какие детали критичны именно сейчас и где проходят границы его ответственности. Для BI-проектов это особенно заметно: дашборд выглядит финальной точкой, а до него нужно разобраться в источниках, правилах преобразования и качестве данных.
В опыте Шадривовой такими источниками были 1С, «Битрикс» и Excel. Отдельной задачей стала историчность данных, собранных из нескольких систем. Это знакомая ситуация для компаний, где процессы развивались быстрее, чем единая архитектура: один и тот же показатель может иметь разные определения, а нужный период — жить в нескольких контурах. Аналитику в такой конфигурации недостаточно записать пожелание заказчика. Нужно выяснить, откуда берётся показатель, кто отвечает за исходные данные, как работают интеграции и что произойдёт при изменении логики расчёта.
Автор делает практичный вывод: новичку не стоит изображать автономность там, где её ещё нет. Вопросы к системным аналитикам, разработчикам и тимлиду сокращают путь к пониманию проекта. Это не просьба «объяснить всё», а способ собрать рабочую карту: последовательность задач, зависимости, ограничения и риски. Для команды такой подход полезнее молчаливого согласия, за которым позже обнаруживается другое понимание требования.
Аналитик работает между людьми, системами и изменениями
Шадривова описывает профессию через формулу «всё, везде и сразу». «Всё» — потому что участие от кик-оффа до завершения проекта постепенно даёт насмотренность: какие вопросы задавать на анализе, где искать риски, какие решения уже принимались в похожих ситуациях. Одного проекта для этого недостаточно. Опыт приходится добирать через обсуждения со старшими коллегами, профильную литературу и постоянное присутствие в профессиональной среде.
«Везде» — потому что бизнес-аналитик постоянно переключается между языками бизнеса и разработки. В одном стриме он может заниматься дашбордом, в другом — перейти к заказной разработке. В случае Шадривовой такой переход привёл к интеграции внешнего решения через iFrame. К технической части добавились задачи по макетированию и применению знаний UX/UI. Это не аргумент в пользу того, чтобы сделать аналитика универсальным солдатом без границ роли. Скорее напоминание: роль требует быстро восстанавливать контекст и выстраивать отношения с новыми участниками проекта.
Особенно важным навыком автор называет управление ожиданиями и изменениями со стороны заказчика. Формально клиент может быть назван коллегой, но рабочая модель здесь другая: у него есть собственные процессы, ограничения, сроки и представление о результате. Изменение интерфейса или логики отчёта может затронуть привычный сценарий десятков сотрудников. Поэтому технически корректная реализация ещё не гарантирует, что решение будет принято и начнёт использоваться.
Третья часть формулы — «сразу» — связана с решениями, которые нельзя бесконечно откладывать до консультации с руководителем. Для начинающего специалиста почти каждое действие кажется необратимым: хочется перебрать все варианты и найти один безошибочный. Но тревожный перебор сценариев не равен анализу. В качестве личного приёма Шадривова использует идею «просто сделать следующий шаг»: не действовать наугад, а выбрать обратимое действие, получить новую информацию и уточнить решение. Для проектной работы это полезная дисциплина — особенно когда данных пока меньше, чем дедлайнов.
Отдельно автор отмечает роль наставничества. Поддержка старших коллег помогает не только освоить инструменты, но и набрать уверенность в собственных решениях. При этом обмен знаниями не должен работать строго сверху вниз. Шадривова привела простой пример: она подсказала более опытной коллеге функцию Microsoft Office для подписей к рисункам и таблицам с последующим обновлением нумерации во всём документе. Специалист может отлично владеть сложными возможностями инструмента и не знать конкретного приёма, который экономит время другому человеку. Грейд не отменяет полезности точечного опыта.
Финальный вывод из первого года работы — ошибки в проекте нужно разбирать через контекст, а не через поиск виноватого. Требование могли понять по-разному, риск мог проявиться позже, а заказчику бывает сложно перестроить процесс, который существовал годами. Для аналитика полезнее вернуться к исходной бизнес-логике и выяснить, почему решение было принято, чем спорить о том, чья формулировка оказалась неудачной. Чем сложнее данные, интеграции и число участников, тем ценнее эта привычка: в ближайшие годы работа бизнес-аналитиком будет всё меньше про передачу требований и всё больше про удержание общего смысла между бизнесом и технической командой.