Аналитика — итоги
ERD — Entity Relationship; SQL — SQL для аналитики, SQL; миграции — Пакетная работа. Полная таблица — о разделе.
Кратко — что стоит унести из раздела "Аналитика". Если пункт кажется туманным — откройте указанную главу или оглавление.
FAQ — Часто задаваемые вопросы
Типичные ситуации на старте в аналитике — конфликты ожиданий, размытые формулировки, давление "уже кодить". Здесь — что делать и куда смотреть в разделе; определения и формулировки для зачёта — в чек-листе.
Вопрос. Заказчик прислал письмо "сделайте как у конкурента" без цифр и сроков — с чего начать разговор?
Ответ. Зафиксируйте проблему и измеримый успех (время операции, конверсия, штрафы), а не копирование экрана. Сверьте as-is процесс и ограничения, затем предложите 2–3 варианта с trade-off. Подробнее здесь — Основы анализа требований, моделирование процессов.
Вопрос. Разработчик отвечает "в ТЗ этого нет" посреди спринта — кто прав?
Ответ. Сначала проверьте согласованный артефакт (story, AC, контракт API). Если запрос новый — оформите change request, оцените влияние на срок и тесты, не "договаривайтесь в чате". Подробнее здесь — управление требованиями, документация аналитика.
Вопрос. Два руководителя требуют противоположное в одной фиче — как не сорвать релиз?
Ответ. Вынесите конфликт на явную сессию с критериями приоритета (бизнес-ценность, риск, закон). Зафиксируйте решение в протоколе и обновите backlog; молчаливое "сделаем обоим" в коде недопустимо. Подробнее здесь — взаимодействие с командой, роль BA.
Вопрос. Менеджмент требует начать разработку, пока требования "на 30 %".
Ответ. Согласуйте минимальный срез с измеримым Definition of Ready: границы scope, критические сценарии, NFR-черновик, риски интеграций. Остальное — в очередь change с датой пересмотра. Подробнее здесь — профессиональная аналитика, формализация требований.
Вопрос. User story написана красиво, но тестировщик не понимает, что считать "готово".
Ответ. Добавьте acceptance criteria в проверяемых шагах (данные, границы, ошибки). Одна story — один измеримый результат; размытые слова ("удобно", "быстро") замените числами или ссылкой на NFR. Подробнее здесь — основы анализа, технический дизайн.
Вопрос. BPMN-диаграмма на три экрана — никто не читает на ревью.
Ответ. Режьте по подпроцессам и пулам, выносите детали в приложения; на одном листе — один сценарий от триггера до результата. Проверьте, что исключения и таймеры подписаны. Подробнее — основы диаграмм, справочник BPMN, BPMN-движки.
Вопрос. Бизнес воспринимает кликабельный прототип как почти готовый продукт.
Ответ. Подпишите статус: прототип ≠ релиз, нет бэкенда, нет безопасности и нагрузки. Согласуйте сценарии и данные, отдельно зафиксируйте отложенные правила. Подробнее здесь — прототипирование.
Вопрос. Swagger есть, но фронт и бэкенд спорят о полях запроса.
Ответ. Сделайте OpenAPI источником правды с версией и ревью; при смене контракта — changelog и совместимость. Автогенерация без дисциплины устаревает за неделю. Подробнее здесь — роль SA, исследование системы.
Вопрос. ERD нарисовали на старте, в базе уже другие таблицы — что делать аналитику?
Ответ. Сверьте фактическую схему (миграции, read-only доступ) с моделью, обновите диаграмму и трассировку к историям. Иначе отчёты и интеграции будут расходиться с продуктом. Подробнее здесь — язык данных, SQL для аналитики.
Вопрос. В середине спринта прилетело "срочное" пожелание от директора.
Ответ. Оформите как change: что вытесняем из спринта, кто принимает риск, нужны ли регресс и документы. Устные "срочно" без замены scope — главный источник срывов. Подробнее здесь — управление требованиями, профессиональная аналитика.
Вопрос. Хочу в IT — выбрать BA или SA?
Ответ. BA сильнее в процессах и ценности для бизнеса, SA — в сценариях системы, API и данных. На практике граница размыта; старт с основ анализа, затем углубитесь в BA или SA по типу задач в стажировке.
Вопрос. Меня путают с продакт-менеджером: кто за приоритеты backlog?
Ответ. PM/PO обычно владеет дорожной картой и приоритетом; аналитик обеспечивает ясность требований, моделей и приёмки. Договоритесь письменно о границах на проекте, иначе вы станете "писателем задач без влияния". Подробнее здесь — роль BA, продуктовая аналитика.
Вопрос. Единственный "источник правды" — Excel от бизнеса с макросами.
Ответ. Зафиксируйте владельца файла, версию и правила изменений; выделите справочники и расчёты, которые должны жить в системе. Excel остаётся входом, но не заменой требований и тестов. Подробнее здесь — артефакты аналитика, документация в процессах.
Вопрос. После встречи все расходятся с разным пониманием договорённостей.
Ответ. В тот же день — краткий протокол: решения, открытые вопросы, ответственные и срок. Без этого спор через месяц превратится в "вы обещали". Подробнее здесь — взаимодействие с командой, Confluence.
Вопрос. На демо заказчик добавляет "ещё пару мелочей" каждый раз.
Ответ. Это рост scope: фиксируйте список после демо, оценивайте отдельно, не смешивайте с текущим спринтом. Покажите связь с сроком и тестами. Подробнее здесь — управление требованиями, роль BA.
Вопрос. UAT: "всё неудобно", без шагов и данных для воспроизведения.
Ответ. Дайте сценарии приёмки заранее, учебные учётки, ожидаемые результаты. Просите дефекты в формате "шаг — факт — ожидание — среда". Подробнее здесь — основы анализа, соседний раздел тестирование.
Вопрос. Стартап требует полный комплект ГОСТ-документов "на всякий случай".
Ответ. Для коммерческого продукта чаще достаточен lean-набора (vision, backlog, AC, API, runbook); ГОСТ уместен для госконтракта и регламентированной отрасли. Подробнее здесь — типы документации, дополнительная проектная документация.
Вопрос. Аналитику сказали "SQL не нужен" — отчёт в BI не сходится с экраном приложения.
Ответ. Без проверки данных вы не отличите баг отчёта от бага продукта. Освойте базовые SELECT/JOIN на копии стенда. Подробнее здесь — SQL для аналитики, перевод задач на язык данных.
Вопрос. Продуктовые метрики (клики) не совпадают с KPI бизнеса (выручка).
Ответ. Свяжите цепочку цель → метрика → гипотеза → событие в продукте; иначе оптимизируете "удобную цифру". Подробнее здесь — продуктовая аналитика, язык данных.
Вопрос. На интервью с пользователем я уже предлагаю экраны — это нормально?
Ответ. Рано предлагать решение — вы слышите подтверждение своей идеи, а не боль. Сначала as-is, цели, исключения; прототип — после согласования проблемы. Подробнее здесь — исследование системы, gap analysis и journey.
Вопрос. Про производительность вспомнили за неделю до релиза.
Ответ. NFR (время ответа, пик RPS, объём данных) нужны до архитектуры и тест-плана. Иначе правки дорогие. Подробнее здесь — технический дизайн, проектирование и архитектура.
Вопрос. Трассировка "от цели до теста" звучит красиво — с чего начать на маленьком проекте?
Ответ. Минимум: ID у story, ссылка на AC, тест-кейс и дефект в одной системе (Jira, YouTrack). Хотя бы для критичных сценариев оплаты, персональных данных, отчётности. Подробнее здесь — формализация требований, артефакты.
Вопрос. Внедрение ERP: бизнес описывает "как в 1С", а целевой процесс другой.
Ответ. Разведите as-is и to-be, зафиксируйте gap и обучение; иначе команда закодирует хаос легаси. Подробнее здесь — моделирование процессов, внедрение ERP.
Вопрос. В Confluence пять версий одного ТЗ — разработка читает не ту.
Ответ. Одна страница — текущая версия, шаблон с датой и статусом (draft/approved); старое — в истории или архиве с пометкой. Подробнее здесь — Confluence, документация аналитика.
Вопрос. Интеграция с легаси: в документации API нет, только "спросите Василия".
Ответ. Заложите время на reverse engineering, тестовые вызовы и фиксацию контракта; риски — в реестр. Параллельно ищите владельца системы и окно на изменения. Подробнее здесь — исследование системы, интеграции.
Вопрос. Аналитик ушёл из проекта — знания только в переписке.
Ответ. Срочно: инвентарь артефактов, walkthrough критичных сценариев с командой, передача доступов. На будущем проекте — единый репозиторий решений и регулярное ревью документов. Подробнее здесь — артефакты, инструменты аналитика.
Вопрос. Sequence-диаграмма устарела после рефакторинга — стоит ли обновлять?
Ответ. Если по ней принимают решения по интеграциям и SLA — да, иначе она вредит (ложная уверенность). Для разового обсуждения можно пометить "снимок на дату". Подробнее здесь — технический дизайн, роль SA.
Вопрос. Заказчик требует "всё в одном PDF на 200 страниц" вместо живой базы знаний.
Ответ. PDF — снимок для подписи; рабочая правда в wiki/issue tracker с поиском. Согласуйте период обновления снимка и кто владеет изменениями после подписи. Подробнее здесь — типы документации, руководства и инструкции.
Вопрос. Чем отличается бизнес-аналитик от системного аналитика?
Ответ. BA отвечает на "зачем" и процессы бизнеса (BPMN, ценность, стейкхолдеры); SA — на "как" в системе (сценарии, API, данные, техдизайн). В маленьких командах роли смешиваются. Подробнее здесь — роль BA, роль SA, о разделе.
Вопрос. Как стать бизнес-аналитиком в IT с нуля?
Ответ. База: требования, коммуникация, модели процессов, документы; плюс SQL на уровне проверки данных. Маршрут — основы анализа → профессиональная аналитика → BA. Карьера в целом — раздел про IT-профессии.
Вопрос. Что такое техническое задание (ТЗ) на разработку ПО и что в него писать?
Ответ. ТЗ фиксирует цели, функции, ограничения, приёмку и среды; в госконтрактах — структура по ГОСТ, в Agile чаще заменяют backlog + AC + контракты API. Подробнее здесь — типы документации, дополнительная проектная документация.
Вопрос. User story и use case — в чём разница?
Ответ. User story — короткая ценность для backlog в Agile; use case — развёрнутый сценарий с актёрами, основным и альтернативными потоками. Оба описывают поведение, выбор зависит от процесса команды. Подробнее здесь — основы анализа, технический дизайн.
Вопрос. Что такое acceptance criteria (критерии приёмки) и как их писать?
Ответ. Это проверяемые условия "готово": входные данные, шаги, ожидаемый результат, ошибки. Формат Given-When-Then удобен для тестов. Подробнее здесь — основы анализа, формализация требований.
Вопрос. BPMN 2.0 — как нарисовать бизнес-процесс для заказчика?
Ответ. Начните с события-старта → задачи → шлюзы решений → конец; пулы для ролей/систем, дорожки внутри пула. Исключения выносите отдельными ветками. Подробнее — основы диаграмм, справочник BPMN, моделирование процессов.
Вопрос. BRD, ТЗ, спецификация — как не перепутать документы?
Ответ. BRD — бизнес-цели и проблема; ТЗ/спецификация — что должна делать система и как принимают; технические детали — в техдизайне и OpenAPI. Подробнее здесь — артефакты аналитика, типы документации.
Вопрос. Нужен ли аналитику SQL и зачем?
Ответ. Да, на уровне SELECT, JOIN, фильтров — сверка отчётов, проверка гипотез, понимание ERD и интеграций. Подробнее здесь — SQL для аналитики, первые шаги с SQL.
Вопрос. ERD-диаграмма — что это и когда нужна аналитику?
Ответ. Entity-Relationship показывает сущности, связи и кардинальность — мост между бизнес-терминами и схемой БД. Нужна при проектировании данных и согласовании с разработкой. Подробнее здесь — роль SA, язык данных.
Вопрос. Swagger и OpenAPI — одно и то же?
Ответ. OpenAPI — спецификация описания REST API; Swagger — экосистема инструментов (UI, генерация) вокруг неё. Для команды важен единый файл контракта в репозитории. Подробнее здесь — исследование системы, роль SA.
Вопрос. Что такое BABOK и нужно ли его учить?
Ответ. BABOK — свод знаний и практик бизнес-анализа (области знаний, техники). Полезен как карта компетенций, не обязателен дословно на каждом проекте. Подробнее здесь — профессиональная аналитика, инструменты BABOK; PMBOK и другие своды — BOK и "бабоки".
Вопрос. Какая роль аналитика в Scrum и Agile?
Ответ. Уточнение backlog, AC, участие в refinement и приёмке, связь со стейкхолдерами; документы живые, а не "ТЗ на год". Подробнее здесь — формализация требований, документация в процессах.
Вопрос. Нефункциональные требования (NFR) — примеры для веб-сервиса?
Ответ. Время ответа API, доступность, RPS, безопасность, хранение логов, RTO/RPO, совместимость браузеров. Формулируйте в цифрах, не "быстро". Подробнее здесь — технический дизайн, NFR в архитектуре.
Вопрос. Gap analysis (GAP) — что это простыми словами?
Ответ. Сравнение как есть (as-is) и как должно быть (to-be): разрывы по процессам, данным, системам — основа roadmap изменений. Подробнее здесь — моделирование и gap.
Вопрос. Прототип в Figma — обязанность аналитика или дизайнера?
Ответ. Часто wireframe делает аналитик для согласования сценария, визуал и UI-kit — дизайнер. Главное — статус прототипа и связь с требованиями. Подробнее здесь — прототипирование, веб-дизайн и прототипы.
Вопрос. Трассировка требований — зачем нужна ID и ссылки?
Ответ. Чтобы проследить цепочку цель → требование → реализация → тест при изменениях и аудите. Минимум — единые ID в Jira/YouTrack. Подробнее здесь — формализация, артефакты.
Вопрос. Change request — когда оформлять изменение требований?
Ответ. Когда меняется scope, срок, стоимость или риск после согласованной базы: фиксируйте что добавляем, что вытесняем, кто утверждает. Подробнее здесь — управление требованиями.
Вопрос. Стейкхолдеры проекта — кто это и как с ними работать?
Ответ. Все, кого затрагивает результат (бизнес, юристы, поддержка, ИБ); нужна карта влияния/интереса и план коммуникаций. Подробнее здесь — взаимодействие с командой, роль BA.
Вопрос. Системный аналитик — какие обязанности в вакансии обычно ждут?
Ответ. Сбор и формализация требований, use case/API/ERD, участие в оценке, согласование с разработкой и QA, техдокументация. Подробнее здесь — роль SA, документация аналитика.
Вопрос. Продуктовый аналитик и бизнес-аналитик — это одно?
Ответ. Продуктовый смотрит на поведение в живом продукте (метрики, воронки, A/B); BA шире про процессы и изменения в организации. Пересечение есть. Подробнее здесь — продуктовая аналитика, роль BA.
Вопрос. Как описать REST API для разработчиков — с чего начать?
Ответ. Ресурсы, методы, коды ошибок, схемы тел, пагинация, авторизация — в OpenAPI + примеры запросов. Подробнее здесь — роль SA, основы интеграции.
Вопрос. Документация по ГОСТ 34 — обязательна ли для коммерческого стартапа?
Ответ. Для стартапа обычно достаточно lean-набора; полный ГОСТ — для госконтрактов и отраслевых регламентов. Подробнее здесь — типы документации, дополнительная документация.
Вопрос. Customer journey map — когда делать аналитику?
Ответ. Когда важен опыт пользователя по этапам (реклама → покупка → поддержка) и боли между системами. Дополняет BPMN, не заменяет. Подробнее здесь — моделирование процессов.
Вопрос. Camunda и BPMN — зачем движок процессов, если есть код?
Ответ. Движок исполняет долгие согласованные процессы с таймерами, эскалациями и аудитом; код остаётся для транзакционной логики. Подробнее здесь — BPMN-движки, справочник BPMN.
Что запомнить
Вы прошли раздел "Аналитика". Ниже — сжатая карта того, что должно сложиться в голове.
Главная идея
Аналитик в IT снижает неопределённость до уровня, на котором команду можно проектировать, реализовывать и проверять решение без догадок. Ошибка на этапе анализа обходится дороже, чем ошибка в коде.
Что вы должны уметь объяснить
- Роли: BA (зачем), SA (как устроено), продуктовый и data (метрики и поведение).
- Требования: уровни BABOK, жизненный цикл, трассировка, change request.
- Модели: BPMN, use case/story + AC, ERD, sequence, OpenAPI.
- Документация: lean-набор vs ГОСТ/ТЗ по типу проекта.
- Коммуникация: согласование, scope, приёмка по критериям.
- Данные: цель → метрика → гипотеза → требования к данным.
Три правила
- Сначала проблема и измеримый успех, потом решение.
- Одна правда — в согласованных артефактах.
- Трассируйте важное: от цели до теста и релиза.
Куда дальше
- Чек-лист самопроверки
- О разделе — маршруты по ролям
- 7.06 Проектирование
- 7.05 Тестирование
Куда идти дальше
| Тема | Раздел |
|---|---|
| "Основы анализа требований" | "Основы анализа требований" |
| "Программные платформы" | "Программные платформы" |
| "Основы бизнеса для IT-специалиста" | "Основы бизнеса для IT-специалиста" |
| "Корпоративное ПО" | "Корпоративное ПО" |
Проверьте себя: Чек-лист самопроверки.