Я недавно вышла в найм. И попала в реальность, где компании активно импортозамещаются, переписывают монолиты, режут их на микросервисы… Но историческая база при этом — на Oracle Database.
И если ты много лет работал с PostgreSQL, переключение ощущается не как «ну ладно, другая СУБД», а как смена диалекта с тем же словарём, но другой грамматикой.
Важно: это взгляд аналитика. Не администратора. Не архитектора. А человека, который каждый день пишет SELECT.
1️⃣ Работа с NULL
В PostgreSQL
COALESCE(value, 0)
Работает как и в большинстве СУБД.
В Oracle
NVL(value, 0)
Да, COALESCE тоже работает. Но в легаси-коде ты почти везде увидишь NVL.
Для аналитика это значит: читаешь чужой код - будь готов к другому синтаксису.
Собесы это не вызов на допрос, где тебя обязательно должны разоблачить.
«Где я, а где они? Сейчас приду, они зададут один вопрос по архитектуре, я поплыву, и все поймут, что я тупица и зря вообще сюда пришел».
Этот страх технического разъеба - главный стопор.
Из-за него сильные специалисты годами сидят на одном месте с зарплатой 120к, хотя на рынке за их опыт платят 300к+.
Нужно перестать обожествлять компании и начать воспринимать собеседование как технический диалог. Чтобы этот диалог состоялся, нужно владеть базой, на которой стоят распределенные системы.
В банках на интервью проверяют, понимаешь ли ты, как ведет себя система при сбоях. Если аналитик не знает, как спасти данные, когда упала вся система, велика вероятность, что оффер он не получит.
Проверь себя:
Идемпотентность. Как настроить взаимодействие систем так, чтобы двойной клик пользователя не списал деньги дважды. Нужно понимать, куда вставить ключ идемпотентности и как сервер должен его обрабатывать.
Паттерн Saga. Как отменить действия в цепочке микросервисов, если на последнем этапе оплаты произошла ошибка. Важно уметь выстраивать шаги, которые вернут систему в исходное состояние.
Паттерн Outbox. Как гарантированно отправить сообщение в очередь, если база данных уже обновилась, а брокер сообщений временно недоступен. Это способ обеспечить согласованность данных между сервисами.
Circuit Breaker. Как вовремя заметить, что сервис тормозит, и изолировать его, чтобы он не обрушил всё приложение. Этот паттерн работает как предохранитель и спасает систему от перегрузки.
Eventual Consistency. Как объяснить бизнесу, что данные в разных частях системы обновляются не мгновенно, и почему это нормально. Нужно уметь находить баланс между скоростью работы и согласованностью.
Когда ты владеешь архитектурным бэкграундом на хорошем уровне, ты претендуешь на другие задачи и цифры в оффере.
На вебинаре разберем применение паттернов на живых кейсах. Ты поймешь, как аргументированно защищать свои решения перед техлидами, говорить с разработкой на одном языке и обосновать свой переход на миддл+ или сеньор грейд.
Регистрируйся на вебинар и стань тем, кто получает 300к+ за глубину технических знаний и надежность своих решений.
Если хочется разобраться в профессии системного аналитика и начать в ней развиваться, логичнее всего начинать с инструментария. Или, как говорят сами аналитики, с тех стека.
Не потому что инструменты важнее мышления, а потому что именно через них видно, чем системный аналитик реально занимается каждый день. Документация, таблицы, схемы, API, задачи, логи — это не абстракция, а рабочая реальность.
Ниже — конкретный список инструментов, которые используют системные аналитики в реальных проектах и которые регулярно всплывают в вакансиях и на собеседованиях.
Документация — основа работы аналитика
Практически в любой компании системный аналитик много работает с текстом. Чаще всего это Яндекс Вики или Confluence. В них описывают требования, фиксируют договорённости, расписывают сценарии и логику работы системы.
На собеседованиях почти всегда спрашивают, как кандидат оформляет требования и как делает так, чтобы их понимали разработчики и тестировщики. Здесь важен не шаблон и не идеальная структура, а ясность. Если по твоему тексту можно работать без бесконечных уточнений — значит ты всё делаешь правильно.
Диаграммы и логика без магии
Большая часть работы системного аналитика связана с визуализацией логики системы через диаграммы. Схемы позволяют компактно и наглядно описывать взаимосвязи между компонентами, данными и процессами без перегруженных текстовых объяснений.
В работе используются разные нотации. UML применяют для описания поведения системы и взаимодействия пользователей с функциональностью. ER-диаграммы помогают моделировать структуру данных и связи между сущностями. C4-модель используют для отображения архитектуры системы на разных уровнях — от общего контекста до отдельных компонентов.
Диаграммы упрощают обсуждение решений с командой и позволяют быстрее находить нестыковки в логике, чем при описании той же информации только текстом.
Схемы, чтобы не объяснять одно и то же десять раз
Схемы нужны не для красоты и не для отчётов. Они помогают быстро договориться с командой.
Чаще всего аналитики используют простые инструменты вроде Draw.io, Miro или Figma. В них рисуют пользовательские сценарии, потоки данных, переходы между состояниями. Иногда это один экран, который экономит час обсуждений.
На собеседованиях могут спросить, рисуешь ли ты схемы и в каких случаях. Здесь важно уметь объяснить, зачем ты это делаешь и какую проблему схема решает.
Задачи и работа в трекере
Jira, YouTrack или аналогичные системы — ещё один обязательный инструмент. Именно здесь аналитик описывает задачи для разработки, отвечает на вопросы, уточняет детали и фиксирует изменения.
От системного аналитика ожидают, что он умеет писать задачи так, чтобы разработчику не приходилось догадываться, что имели в виду. Это не про длинные тексты, а про точность формулировок.
На собеседованиях часто спрашивают, как ты оформляешь задачу и что считаешь обязательным указать. Хороший ответ — через примеры, а не общие слова.
Од тут отдыхаешь, познакомимся? Мы — академия Step by Step. Обучаем системному анализу онлайн и помогаем не только освоить профессию или повысить грейд, но и трудоустроиться\получить повышение. Наши ученики находят работу с доходом от 150 до 450+ К в месяц (даже сейчас в периоды сокращений). В своих соцсетях мы бесплатно делимся практическими знаниями и инструментами, задачами и вопросами с собесов, разбором рынка и реальными карьерными сценариями.
Даже если аналитик не пишет код, он почти всегда сталкивается с интеграциями. Это означает работу с API, чтение Swagger и иногда проверку запросов через Postman.
От системного аналитика обычно ждут понимания базовых вещей: что такое запрос и ответ, какие данные передаются, что делать при ошибке. Умение открыть Swagger и понять, какие поля обязательны, уже большой плюс.
На интервью часто спрашивают, был ли опыт работы с API и как ты описывал интеграционные сценарии.
Базы данных и SQL без фанатизма
SQL нужен системному аналитику не для сложной аналитики, а для понимания данных. Минимальный уровень — уметь написать простой SELECT, добавить фильтр и соединить таблицы.
Это помогает проверять гипотезы, разбираться в данных и говорить с разработчиками на одном языке. На собеседованиях могут спросить, писал ли ты SQL и для чего использовал. Здесь важна честность и понимание, а не сложность запросов.
Логи и разбор проблем
В продуктовых командах аналитик часто участвует в разборе инцидентов. Для этого используются инструменты логирования вроде Kibana или Grafana.
Аналитик смотрит, в каком сценарии возникла проблема, помогает воспроизвести шаги пользователя и понять, где сломалась логика. Если у тебя есть такой опыт, его стоит обязательно упоминать — это всегда воспринимается как плюс.
Что важно понять в итоге
Самая частая ошибка начинающих аналитиков — пытаться выучить инструменты списком. На практике на собеседованиях почти всегда задают другой вопрос: где и зачем ты это использовал.
Системный аналитик ценится не за количество инструментов, а за понимание, когда и какой инструмент помогает команде работать лучше.
Хочешь понять, с чего лучше всего начать изучение инструментов системного аналитика?
В тг-канале нашей академии Step By Step мы подробно разбираем, как подойти к изучению тех стека системного аналитика без хаоса и перегруза. Там же есть полезные вебинары по работе с требованиями и другим ключевым темам, с которыми аналитик сталкивается в реальной работе.
Если хочется выстроить понятный путь обучения и разобраться в инструментах шаг за шагом — заглядывай в канал.
Часто аналитиков разделяют на бизнес-аналитиков и системных, но современный рынок идет к объединению их в одном лице, поэтому в данном случае рассмотрим, что это одна специальность, иногда таких специалистов называют Fullstack аналитиками
Для этого аналитик разбирается в требованиях, задаёт вопросы, продумывает сценарии, описывает логику системы и помогает разработчикам и тестировщикам реализовать всё без догадок и переделок.
Он не пишет код и не рисует интерфейсы, но именно от его работы зависит, насколько понятной и предсказуемой будет система.
Обычно в задачи системного аналитика в течение дня входят:
общение с продактом, бизнесом и командой
разбор входящих запросов и новых идей
уточнение требований и постановка правильных вопросов
анализ текущей логики системы
продумывание сценариев и исключений
фиксация договоренностей и описаний в документации
ответы на вопросы разработчиков и тестировщиков
доработка требований по ходу реализации
проектирование интеграций (взаимодействие между системами)
Например что бы отправить уведомление система должна отправить его в СМС провайдера или отправить пуш на девайс
проектирование структуры хранения данных
Например, история этих уведомлений
фиксация в Техническом Задании (ТЗ) всех сценариев, интеграций и структуры хранения этих данных
Теперь давай посмотрим на все изнутри. Как будто ты пришел в продуктовую IT-команду и просто наблюдаешь за обычным рабочим днём системного аналитика.
В команде работает системный аналитик Илья. Обычный специалист, который каждый день помогает системе работать так, как от неё ожидают люди.
Сразу уточним: в разных компаниях эта роль устроена по-разному. Где-то аналитик больше общается с бизнесом, где-то глубже уходит в техническую логику, а где-то закрывает несколько ролей одновременно. Ниже — один из самых распространённых сценариев.
Один тут отдыхаешь, познакомимся? Мы — академия Step by Step. Обучаем системному анализу онлайн и помогаем не только освоить профессию или повысить грейд, но и трудоустроиться\получить повышение. Наши ученики находят работу с доходом от 150 до 450+ К в месяц (даже сейчас в периоды сокращений). В своих соцсетях мы бесплатно делимся практическими знаниями и инструментами, задачами и вопросами с собесов, разбором рынка и реальными карьерными сценариями.
Компания делает онлайн-сервис записи к врачам. Пользователь выбирает клинику, врача, время приема и записывается через приложение.
Утро начинается с чатов
Илья приходит на работу, открывает ноутбук и заходит в рабочие чаты.
За ночь накопилось:
сообщение от продакта
вопрос от разработчика
комментарий от тестировщика
Продакт пишет: клиники жалуются, что пациенты записываются и иногда не приходят. Время простаивает. Бизнес хочет добавить подтверждение записи за сутки до приёма.
Формулировка звучит просто, но для системного аналитика это только начало.
Разобраться в задаче
Илья не начинает сразу писать требования. Он открывает схему текущего процесса записи и смотрит, как всё устроено сейчас: статусы, уведомления, отмены.
Дальше идут вопросы, которые экономят команде время и нервы:
всем ли пациентам нужно подтверждение
за сколько часов отправлять уведомление
что делать, если подтверждения нет
как это влияет на клиники
что происходит, если пациент подтвердил запись, но не пришёл
Параллельно Илья фиксирует открытые вопросы. Уже на этом этапе видно, что задача сложнее, чем кажется на первый взгляд.
Обсуждение с командой
Через некоторое время Илья созванивается с продактом и дизайнером. Они обсуждают сценарии, чтобы логика была понятной и согласованной.
Выясняется, что:
подтверждение нужно только для платных приёмов
уведомление приходит в приложение и на почту
если подтверждения нет, запись отменяется автоматически
Илья фиксирует решения в виде логики и схем, чтобы к ним можно было вернуться в любой момент.
Например, если уведомления требуется хранить, в системе нужна новая таблица, где сохраняются сами уведомления и их параметры. Для доступа к этим данным описывается API, через которое уведомления можно получить из базы и показать оператору.
Документация как рабочий инструмент
После созвона Илья открывает рабочий документ и начинает описывать требования.
Он расписывает:
когда и кому отправляется уведомление
какие статусы есть у записи
(иногда можно этот отобразить на диаграмме состояния)
как меняется статус при подтверждении
что происходит при отсутствии ответа
какие данные и когда видит клиника
интеграции
структуру хранения в базе данных
интеграции
структуру хранения в базе данных
обработку исключительных ситуаций (ошибки или нестандартные действия пользователей)
Появляется простая схема: пользователь → уведомление → подтверждение → результат.
Это и есть повседневная работа системного аналитика — превращать разговоры в понятную и проверяемую систему.
Вопросы от разработчиков
После обеда разработчик пишет в чат:
что делать, если пользователь подтвердил запись и удалил приложение
что происходит, если письмо не доставилось
как система ведет себя, если клиника вручную отменила прием
Илья возвращается к требованиям, дописывает сценарии и при необходимости уточняет детали у продакта.
Подключается тестировщик
Тестировщик смотрит требования и задаёт вопросы:
какие ошибки показывать пользователю
в какой момент запись считается отменённой
можно ли подтвердить запись дважды
Илья уточняет формулировки, чтобы тестирование прошло без сюрпризов.
Изменения по ходу дня
Ближе к вечеру появляется новая вводная: клиники хотят видеть список неподтверждённых записей заранее, чтобы обзванивать пациентов.
Илья:
уточняет детали
проверяет, как это вписывается в текущую логику
добавляет новый сценарий
обновляет документацию
Для системного аналитика такие изменения — обычная часть рабочего дня.
Что делает системный аналитик каждый день
Если посмотреть на день Ильи со стороны, он:
постоянно общается
задаёт вопросы
фиксирует договорённости
продумывает сценарии
помогает команде не додумывать за пользователя
Он не пишет код.Он не рисует интерфейсы.Он не принимает финансовые решения.
Его задача — чтобы команда одинаково понимала, как должна работать система, и могла спокойно её реализовать и поддерживать.
Очень важно, чтобы документация оставалась в актуальном состоянии, тогда многие кейсы сотрудник поддержки сможет решать без привлечения разработчика с более высокой скоростью.
Почему в другой компании день будет другим
В другой компании аналитик может работать с интеграциями в банке, каталогами в маркетплейсе или маршрутами в логистике.
Меняются домены и задачи, но суть роли остаётся прежней: разобраться, описать, объяснить и связать всё в одну систему.
Кому подойдёт такая работа
Системный анализ часто выбирают те, кто:
любит разбираться в сложных процессах
не брезгует, а в идеале - любит писать документацию
спокойно относится к неопределённости
умеет слушать и уточнять
не боится задавать вопросы
Рабочие дни здесь редко бывают одинаковыми, и для многих это становится главным плюсом профессии.
Системного аналитика сначала грузят. Потом — любят.
Итог:
Системный аналитик каждый день помогает команде делать продукт, который работает понятно и предсказуемо для пользователей. Он находится между идеей и реализацией и следит, чтобы по дороге ничего не потерялось.
Большая часть клиентской аналитики опирается на user_id - идентификатор клиента.
Пользователь → действия → история → повторные визиты → поведение во времени.
И когда user_id нет, ломается не написание SQL-запроса - ломается логика вопросов, которые вообще можно задавать данным.
В своем канале Аналитика FM начала серию постов про метрики в разных бизнесах. Являются ли эти метрики или формулы их вычисления универсальными для разных бизнес направлений.
Об этом и об аналитике в целом рассказываю у себя в канале. Канал веду с нуля подписчиков. Присоединяйся, если хочешь разобраться в SQL, python и мышлении аналитика.
Одна из самых неприятных фраз, которую аналитик может услышать в начале проекта:
user_id у нас нет
Есть метрики, которые принципиально живут без пользователя.
- Выручка за день. - Количество заказов. - Средний чек. - Сумма транзакций по категориям.
Это агрегаты "по событиям". Им не важно, кто именно сделал действие - важно, что действие произошло.
Бизнес часто живёт именно на этом уровне, и на старте ему кажется, что этого достаточно.
Проблемы с клиентскими метриками возникают в тот момент, когда появляется аналитика "на повторы".
А без user_id "человек" в данных перестаёт существовать.
И когда user_id отсутствует, бизнес начинает выкручиваться.
Вместо user_id появляются:
номер телефона
email
cookie
device_id
хэш паспорта
комбинации из "телефон + дата рождения + регион"
Это не плохие решения. Это компромиссы.
Каждый такой "заменитель пользователя" решает одну задачу и ломает другую.
Телефон: - отлично для CRM - плохо для веба и офлайна
Cookie: - хорошо для сессий - бесполезно для долгой аналитики
Email: - стабилен - но есть одноразовые email-ы
Device_id: - у клиента может быть несколько устройств - может жить до переустановки приложения - может стоять запрет на трекинг
В итоге бизнес не считает "пользователей". Он считает версии пользователей.
Из-за этого появляются странные эффекты:
пользователей стало больше, но денег больше не стало
retention упал, но продажи выросли
конверсия пляшет, а поведение вроде то же
И это не всегда ошибка данных. Это ограничение идентификации.
Важно понимать: отсутствие user_id - это не техническая проблема, а продуктовая.
Она говорит о том, как система была спроектирована изначально:
думали ли о пользователе как о сущности
или думали только о событиях и операциях
Поэтому аналитика без user_id возможна. Но она всегда:
менее точная
более приближённая
и требует аккуратной интерпретации
Хуже всего - считать "пользовательские" метрики и делать вид, что всё ок.
Лучше честно сказать:
Мы считаем это так, потому что другого способа у нас нет
Данные могут существовать без user_id. Запросы SQL может работать без user_id. Отчёты можно построить без user_id.
Но аналитика поведения - нет.
НО... Главный НО...
Наличие user_id не спасет вас от того, что клиента "на входе" не идентифицировали и завели ему новый идентификатор. Либо при объединении клиентских баз у вас не задвоится один и тот же клиент.
Это повседневные процессы бизнеса. И уникальность клиента зависит от культуры ведения данных в базе, от технических процессов и бизнес процессов.
Для дедупликации клиентских записей существуют системы класса CDI (Customer Data Integration). Такие системы помогают идентифицировать клиента и вести его мастер карточку.
Ну а в моем канале Аналитика FM не только об инструментах аналитика, но и об аналитическом мышлении, метриках, логики. Присоединяйся!
Даже не так, обучение без понимания где и как это можно применить, и возможности это применить на практике - всегда мертво.
Я одна из тех, кто любит учиться, кто загорается новыми идеями, новыми технологиями и трендами. Но я одна из тех, кто не применяет полученные знания на практике.
А пока я буду вещать про эту тему. Ибо, новый год начался, надо встряхнуть пыль со своих мозгов и пересмотреть что и почему не получилось. Подписывайся на мой канал Аналитика FM. Его я веду с нуля подписчиков, рассказываю про аналитическое мышление, инструменты аналитиков, разбираю задачки с использованием SQL и Python.
Концепцию этого канала я тоже пересматриваю, но так, чтобы он остался полезным и понятным для всех. Подписывайся!
А также, я одна из тех, кто не заканчивает курсы. Причины могут быть разные, аврал на работе, отпуск, личные обстоятельства, пропал интерес.
Но одной из причин является то, что я не успеваю за развитием этого мира. Потому что информация о новых технологиях появляется в массах и обсуждается массами не сразу. Сначала кто-то что-то расскажет, потом об этом расскажет кто-то еще, потом это применит в своей деятельности круг любознательных и отважных людей.
Только потом это пойдет в массы.
Только потом я начну думать, а может стоит этому научиться, может стоит это изучить детально. Пока я думаю, время то идет. Пока я надумала, пока я начала учиться, пока закончила учиться - ВСЕ, там уже новая технология, новый вектор развития. Там все по-новому!!!
Если посмотрим на получение новых знаний с другой стороны.
Работаю я, научилась закрывать определенный пул задач. Это мой опыт, это моя экспертность, в этом я становлюсь профессионалом.
Соответственно, для компании я закрываю определенную боль. Задачки с определенной тематикой направляются в мой адрес.
Я как личность, жаждущая развития, пытаюсь получить новые задачи с новыми инструментами. НО, т.к. у меня есть экспертность в решении определенных задач, то эти задачи начинают меня преследовать, потому что, когда бизнес сталкивается с ними, то решить их надо было еще ВЧЕРА.
Так и получаются ситуации "трясины". Задачи, в которых ты эксперт постоянно тебя затягивают обратно и не дают вырваться и начать изучать или применять новый материал.
А еще, для решения задач в которых ты эксперт, ты можешь продать себя дороже, потому что есть уверенность в этом направлении. А вот продавать себя для решения новых задач - уже сложнее. И иногда, чтобы сменить направление, придется согласиться на меньшее вознаграждение.
Рынок не покупает навыки, он покупает контекст применения.
Пока у навыков нет контекста - этот навык не существует.
Даже если рассмотрим знание SQL, знание синтаксиса, функций и т.д. Одно знание функций RANK и DENSE_RANK их синтаксис и описание не так важно, важно то, в каких случаях вы каждую из них применяете.
По сути работодателю важно знать, что вы примените нужную функцию в нужный момент. Потому что каждый из работодателей хочет "купить" снижение своих рисков.
В этих ситуациях рынку необходимо показывать, что вот такую-то проблему я решил вот таким способом. Вот такой процесс я изменил вот так-то.
Применяя такой подход, рынок оценивает ход мыслей, последовательность, принятые решения!
Почему большинству выпускников сложно найти первую работу?
Да потому что у выпускников нет опыта применения своих навыков. У выпускников есть только полученные теоретические знания или навыки, которые были применены в изолированной среде или +\- немного приближенной к действительности.
Но приблизить среду к действительности в учебном процессе сложно, т.к. это тоже различного рода бюрократические согласования программы. Поэтому мы до сих пор учимся по программе CCСР.
Новое поколение более расположено к "быстрым" изменениям. Точнее большая часть нового поколения.
Если взять людей, рожденных в 80-90х годах, то там процветал лозунг, что надо на заводе отработать 20-30 лет. И не было принято каждые 2-3 года менять работу.
Ну а я продолжу анализировать что и как глубоко мне изучить в 2026 году, чтобы и новые знания получить, и применить это на практике.
А в моем канале Аналитика FM можно познакомиться с разбором задач про накопительные суммы и скользящем окне.
Есть ситуация, знакомая почти каждому аналитику. К тебе приходит бизнес и говорит:
Нам нужен отчёт Посмотри цифры Что-то у нас не так, разберись
И на этом - всё.
Нет метрик. Нет определения "не так". Нет ответа на вопрос зачем.
Обычно, на такие вопросы у аналитика есть ответы, если он погружен в предметную область, уже сталкивался с такими кейсами, занимался данной задачей недавно (иногда аналитики на разных проектах параллельно работают и эти проекты не связаны)
А пока подписывайся на мой канала Аналитика FM. Его я веду с нуля подписчиков. В этом канале я публикую информацию об инструментах аналитика (SQL, Python) О мышлении аналитика, о метриках, об ошибках. Публикую чек-листы по стандартным видам работы аналитика. Присоединяйся!
Бизнес редко приходит с чётким запросом. Не потому что он глупый или ленивый. А потому что бизнес живёт ощущениями, а не формулами.
Продажи "просели". Конверсия "стала хуже". Клиенты "ведут себя странно".
Это язык боли, а не требований.
И тут аналитик хочет обезопасить себя со всех сторон: - написать запрос - вытащить все данные - построить отчёт "на всякий случай" - показать цифры и сказать: "Вот"
Но в реальности это почти всегда заканчивается одинаково: - "А это не совсем то" - "А можно по-другому?" - "А мы вообще не это имели в виду"
Когда бизнес не знает, что ему нужно, аналитик не исполнитель, аналитик - переводчик.
Ты начинаешь переводить бизнесовые ощущения в конкретные показатели, и смотреть как эти показатели подтверждают/опровергают эти ощущения. Ты переводишь эмоции в конкретные метрики. Подсознательное ощущение "что-то не так", ты переводишь в конкретные вопросы к данным.
И вот на этом этапе SQL становится не просто инструментом, а следствием мышления.
Очень часто проблема не в том, что запрос неправильный. А в том, что вопроса не существовало.
Например:
"Продажи упали" - относительно чего?
"Конверсия плохая" - на каком этапе?
"Клиенты уходят" - кто именно и когда?
Пока бизнес не ответил хотя бы на это - любой запрос будет случайным. Или аналитик с приличным бэкграундом, задаст их сам себе, задаст эти вопросы данным и получит развернутый ответ, чтобы у бизнеса были аргументированные показатели.
И это самый важный навык аналитика. Аналитик не должен просто писать сложные JOIN-ы, он должен уметь задавать вопросы так, чтобы: - стало понятно, что именно ищем - появилось ощущение направления - сузилось пространство неопределенности.
И да - бывает, что бизнес так и не может сформулировать запрос.
Тогда аналитик делает не отчёт, а гипотезу.
Я предполагаю, что проблема может быть здесь. Давайте проверим это.
Это нормальная практика. Гораздо честнее, чем молча строить отчёт "на всякий случай".
Самое важное: если бизнес не знает, что ему нужно - это не ошибка бизнеса.
Это точка, где аналитика становится ценностью!
Ну а в моем канале Аналитика FM не только об инструментах аналитика, но и об аналитическом мышлении, метриках, логики.
