Антипаттерны бизнес-анализа — это повторяющиеся ошибки бизнес-анализа в требованиях, коммуникациях и документации (включая use case), которые ведут к переделкам, срывам сроков и конфликтам; лечатся они не “талантом аналитика”, а дисциплиной: проверкой цели, критерием готовности (DoR/DoD), трассировкой требований и нормальным циклом согласования.

Самая дорогая иллюзия новичка в BA (Business Analyst, бизнес-аналитик) — что его работа “написать ТЗ”. Нет. Его работа — уменьшить стоимость ошибки до того, как разработчики и тестировщики превратят неясную мысль бизнеса в код, а потом обратно в боль. В российских реалиях это обычно выглядит так: менеджер спешит, у бизнеса “вчера”, у команды релиз по пятницам, а у аналитика — пачка чатов в Telegram и один Confluence, который видели только археологи.

И да: рынок довольно прагматичен. В вакансиях по РФ бизнес-аналитику почти всегда хотят: умение собирать требования, описывать процессы (BPMN/UML), писать user story/use case, работать с бэклогом, понимать интеграции (API), SQL “на посмотреть”, плюс адекватное общение с разработкой и бизнесом. Зарплатные вилки гуляют по регионам и компаниям, но ориентир простой: Junior BA часто стартует заметно ниже сильного разработчика, зато растёт быстрее, если вы умеете снижать риски, а не плодить PDF.

10 антипаттернов бизнес-анализа, которые встречаются чаще, чем здравый смысл

1) “Сделаем как в прошлый раз” вместо цели и метрик

Тезис: требования без цели — это список желаний, не продуктовая работа.

Обоснование: когда не зафиксированы метрики успеха (например, “сократить время оформления заявки с 7 до 3 минут” или “уменьшить процент отказов по анкете на 15%”), вы не отличите улучшение от шума.

Вывод: начинайте с проблемы, пользователя, метрики, а потом уже “какие кнопки”.

Подводный камень: “цель” формулируют как функциональность: “сделать новый экран”. Это не цель, это симптом.

2) Сбор требований “у самого громкого”

Тезис: если слушать только инициатора, вы построите систему для его удобства, а платить будет бизнес.

Обоснование: в российских компаниях часто есть скрытые стейкхолдеры: бухгалтерия, безопасность, юристы, поддержка, операторы, интеграционные команды.

Вывод: делайте карту стейкхолдеров и матрицу влияния/интереса, фиксируйте владельца процесса.

Подводный камень: “пусть руководитель подпишет — и норм”. Руководитель подпишет, а потом линейные пользователи уничтожат внедрение пассивным саботажем.

3) Use case как литературный жанр

Тезис: use case нужен, чтобы проверить логику сценариев и исключения, а не чтобы впечатлить объёмом.

Обоснование: типичная ошибка бизнес-анализа — писать use case на 12 страниц, где нет альтернативных потоков, ошибок, ролей и предусловий, зато есть “пользователь нажимает кнопку”.

Вывод: use case держите структурным: акторы, предусловия, основной поток, альтернативы, постусловия, бизнес-правила.

Подводный камень: путать use case с user story. Story — про ценность (“как пользователь…”), use case — про поведение системы по шагам.

4) “Согласовали в чате” — и потеряли контекст

Тезис: требования живут там, где их можно найти и проверить, а не в переписке.

Обоснование: в проектах на 3–6 месяцев половина “решений” тонет в чатах, а потом всплывает на UAT (User Acceptance Testing, приёмка) как сюрприз.

Вывод: фиксируйте решения в едином источнике (Confluence/Notion/вики), с датой, автором и ссылкой на обсуждение.

Подводный камень: “потом оформлю”. Потом наступит релиз.

5) Отсутствие критериев приемки (Acceptance Criteria)

Тезис: если нельзя проверить — значит, это не требование, а пожелание.

Обоснование: без критериев приемки QA тестирует “как понял”, разработчик делает “как смог”, бизнес принимает “как привык”.

Вывод: добавляйте критерии в формате Given/When/Then или чек-листом, плюс нефункциональные требования (время ответа, роли, аудит).

Подводный камень: писать критерии как “должно быть удобно”. Удобно кому, по каким признакам?

6) Нефункциональные требования считаются “позже”

Тезис: безопасность, производительность и логирование не появляются магически после релиза.

Обоснование: особенно в РФ, где часто есть требования 152‑ФЗ (персональные данные), журналы действий, роли, согласия, сроки хранения.

Вывод: заведите шаблон NFR (Non-Functional Requirements): доступы, аудит, SLA, интеграции, отказоустойчивость, хранение данных.

Подводный камень: “это решит архитектор”. Решит, но поздно и дорого.

7) “Интеграции потом”: игнор API и источников данных

Тезис: 80% “неожиданностей” живёт на стыке систем.

Обоснование: CRM, 1С, СЭД, ДБО, Госуслуги (если это B2G), внешние скоринги — у каждой системы свои форматы, ограничения, окна выгрузок.

Вывод: рисуйте контекстную схему (C4 Level 1), описывайте контракты, частоту обмена, владельцев, ошибки и ретраи.

Подводный камень: “ну там JSONчик”. А потом выясняется, что там XML, очередь, и лимит 10 запросов в минуту.

8) Процессы без реальности: BPMN как искусство ради искусства

Тезис: схема процесса должна помогать принять решение, а не быть постером.

Обоснование: частая ошибка бизнес-анализа — рисовать BPMN, не проверив, как реально работает операционный контур (ручные обходы, Excel, звонки, “согласовано устно”).

Вывод: делайте AS-IS на уровне, достаточном для изменений, и сразу TO-BE с точками контроля, ролями и системами.

Подводный камень: перепутать “как должно быть” с “как удобно описать”.

9) Нет трассируемости: требования не связаны с задачами и тестами

Тезис: без трассировки вы не знаете, что именно вы релизите.

Обоснование: в Jira/YouTrack требования, задачи разработки и тест-кейсы должны быть связаны. Иначе изменения в одном месте ломают другое, а виноват “кто-то”.

Вывод: заводите простую матрицу: Epic/Feature → Story/Use case → Dev tasks → Test cases → Release notes.

Подводный камень: “слишком бюрократично”. Бюрократично — это переделывать функционал на проде.

10) “Сделали и забыли”: отсутствие управления изменениями

Тезис: изменения требований неизбежны; проблема не в изменениях, а в хаосе вокруг них.

Обоснование: без change management любой “небольшой правочки” достаточно, чтобы уехать по срокам и бюджету.

Вывод: фиксируйте изменения: что меняем, зачем, влияние на сроки/стоимость/риски, кто согласовал.

Подводный камень: принимать изменения из серии “ну ты же аналитик, придумай”. Придумать можно, но платить придётся проекту.

Таблица: как антипаттерны превращаются в деньги и сроки

Два кейса из практики (без украшательств)

Кейс “как сэкономили месяц”. Команда делала доработку в личном кабинете клиента для российской финтех-системы. Бизнес хотел “добавить шаг подтверждения”. На груминге выяснилось: подтверждение уже есть, но ломается на альтернативном сценарии “пользователь меняет телефон”. Один короткий use case с альтернативными потоками и критериями приемки — и вместо “нового экрана” сделали правку в проверке статуса и доработали логирование. Итог: меньше кода, меньше регрессии, релиз в срок.

Кейс “как потеряли квартал”. Внедряли процесс согласования договоров между СЭД и 1С. Требования собирали у руководителя, а пользователей (делопроизводителей) подключили в конце. На UAT выяснилось, что 30% договоров идут “по исключению” и требуют ручной маршрут. AS-IS никто не проверил, NFR по ролям не описали, интеграционные ошибки не продумали. Переделка затронула схему данных и права. Привет, перенос релиза и “а что делал аналитик?”.

Если вам нужен ещё разбор похожих ситуаций и чек-листы по требованиям, можно заглянуть на https://itokno.ru — здесь такие истории обычно без глянца и с выводами, которые применяются на следующем созвоне.

Экспертный вердикт и инструмент: анти-антипаттерн чек-лист

1. Зачем? Сформулирована проблема и метрика (время, деньги, риск, конверсия).
2. Кто? Есть список стейкхолдеров и владелец процесса.
3. Что именно? Требования разбиты на MVP/не-MVP, есть приоритет.
4. Как проверяем? Acceptance Criteria + негативные сценарии.
5. Где тонко? Интеграции, роли, 152‑ФЗ, аудит, SLA — зафиксированы.
6. Где это живёт? Единый источник правды + ссылки из задач.
7. Что изменилось? Изменения проходят оценку влияния и явное согласование.

Частые вопросы