tl;dr

• Пришла в компанию, где аналитику не доверяли, ТЗ были фикцией, монолит — чёрным ящиком, а знания жили только в головах разработчиков. Что могло пойти не так? Правильно — всё.

• Сначала описала текущие системы, разделила документацию на функциональную и архитектурную, превратила ТЗ в набор артефактов, выстроила процесс требований и набрала команду аналитиков.

• Встроила аналитику во весь цикл: от хотелки до макетов, API, БД и очередей, внедрила Docs as Code, запустила «Нытинги» и начала подтягивать ИИ. Спойлер: проблемы всё равно остались.

Монолит, костыли, UML и ИИ: как я поднимала системный анализ в компании

Я пришла в компанию, где системный анализ «формально был», но по факту системные аналитики жили отдельно от разработки и продукта. Итог был предсказуем: аналитики писали ТЗ, которые никто не читал, разработчики ходили к бизнесу напрямую, интерпретировали хотелки «как поняли», в систему прилетали костыли, странные обходные пути и тонны лишней логики, а в прод выкатывалось то, что скорее напоминало мем с качелями «что хотел заказчик — что в результате получилось».

Никто не видел систему целиком: связи между компонентами проявлялись уже в проде, когда всё ломалось. Документация существовала в мифах и легендах, разработчики её не любили и не писали, знания лежали в голове у одного‑двух людей, что давало bus factor уровня «просто страшно».

Параллельно нужно было пилить гигантский монолит на микросервисы, не имея нормальной карты существующей системы. То есть у нас был чёрный ящик, и его нужно было аккуратно препарировать, не зная, где у него нерв.

Шаг 1. Описать зоопарк и не сойти с ума

Первое, что пришлось сделать, — описать текущую экосистему: продукты, компоненты, их взаимосвязи и ключевые потоки данных (аккаунты, транзакции и т.п.). Чтобы не утонуть, документацию сразу разделила на два уровня: функциональный (что видит бизнес) и архитектурный (какие сервисы, базы и интеграции это обеспечивают).

Архитектуру собирала буквально «по крупицам»: кто‑то рисовал на бумажке, кто‑то скидывал ссылки на Bitbucket, у кого‑то чудом нашлись диаграммы в сторонних инструментах. Это быстро показало, что люди по‑разному потребляют информацию: кому‑то подавай текст, кому‑то схемы, кому‑то комментарии в коде. Одним универсальным форматом всех не осчастливить.

Шаг 2. Собрать артефакты в одном ТЗ

Решение было простым и рабочим: включать в ТЗ разные типы артефактов.

• краткое описание бизнес‑цели;

• полное описание бизнес-нужды (обязательно для тех, кто хочет понимать, «зачем это всё», но под кат для тех, кому «многабукф»);

• детальное описание логики, API, баз данных;

• диаграммы и схемы — выбрали UML, что дальше хорошо легло на практику Docs as Code;

• макеты в Figma и скриншоты;

• ссылки на код, если это важно разработчикам.

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

Как получить доступ к телу.

Отдельный квест — достучаться до бизнес заказчика высокого уровня так, чтобы всем было комфортно. Помощница руководителя на встрече с командой разработки не хотела выглядеть «глупо» перед своим шефом из-за непонимания технических вопросов, а разработчики, которые до этих пор общались с бизнесом напрямую, выдавали свой техно-спик, который бизнес между собой называл «птичьим языком». «Из какой таблицы и в каком формате вам нужны данные?» Все были напряжены и немного недовольны друг другом.

Трюк был прост: признать, что помощница не обязана знать, в какой таблице БД лежат нужные данные и что это за формат такой. Её реальность — это кнопка и отчёт. Поэтому мой вопрос прозвучал по-человечески: «Вам нужен сальдированный итог по всем точкам вот в этой клеточке?» — «Да». В глазах помощницы вспыхнула неподдельная благодарность, а когда через пару дней сальдированный итог красиво отображался в нужной клеточке, двери к руководителю для меня были теперь всегда открыты.

Первое нормальное ТЗ и «+100 к доверию»

На базе нового подхода родилось первое ТЗ: с понятными целями, схемами и пользовательскими сценариями. Разработчику не пришлось додумывать половину требований, реализация прошла быстро, а заказчик получил ровно то, что ожидал, — без сюрпризов и дополнительных кругов ада. Доверие бизнеса и разработчиков к аналитике резко выросло.

Постепенно вырисовалась общая картина хаоса и план, как из него выходить эволюционно, без революций. Примерно через два месяца после старта мне дали зелёный свет на набор собственной команды аналитиков.

Шаг 3. Формализация процесса сбора требований

Дальше процесс работы с бизнес‑требованиями закрепился как pipeline:

1. Сбор требований во всех их формах — от «сделайте отчёт» до «хочу, чтобы было как в том банке».

2. Выяснение, что именно стоит за словами (иногда под «сделайте кнопочку» скрывается мини проект).

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

4. Подготовка для заказчика нескольких осмысленных вариантов решения.

«Многабукф, не читал»: режим выживания с занятыми людьми

Открытые вопросы в стиле «расскажите подробнее, как вы видите этот отчёт» не работают с перегруженными стейкхолдерами. Если отправить им простыню текста, велика вероятность, что ответ вы увидите в следующей жизни или никогда.

Поэтому стратегий две:

• вопросы формата «да/нет»;

• заранее подготовленные 2–3 варианта решения с просьбой «просто назовите номер».

Сначала проработайте варианты сами, принесите готовые варианты, и тогда коммуникация станет в разы быстрее и честнее.

Шаг 4. От согласованной концепции к use cases и техдизайну

Когда общая концепция согласована и все перестали бояться, начинается скучная, но важная часть: детализация. В документе подробно расписываются все use cases, в том числе альтернативные и негативные сценарии (где всё идёт не по плану, а по жизни).

Затем:

• документ уходит к дизайнерам для отрисовки макетов;

• параллельно описывается техническая составляющая.

Техническая часть включает:

• проектирование или доработку API (эндпоинты, параметры запросов и ответов);

• проектирование или расширение БД (таблицы, поля, связи);

• выбор механизма обмена данными между сервисами (очереди, in‑memory, gRPC и т.п.).

Все эти технические детали, конечно же, обсуждаются с разработчиками (лидом или архитектором — тем, кто ещё не устал от бесконечных митингов). И вот тут важно не забыть об обратной совместимости, потому что в нашей экосистеме продуктов это не просто "nice to have", а вопрос выживания. Помимо веб-приложений у нас есть мобильные, обновление которых — это не взмах волшебной палочкой, а эпические танцы с бубнами вокруг сторов, модераторов и пользователей, которые игнорируют уведомления месяцами. В итоге мобильные клиенты не могут синхронно прыгнуть на новую версию API вместе с вебом — и привет, раздвоение реальности, где один сервис живёт в 2025-м, а другой упорно ковыряется в 2023-м.

Шаг 5. От техдизайна до прода

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

На этом этапе аналитик никуда не исчезает — начинается авторский надзор:

• консультирует разработчиков по ТЗ и сценариям;

• помогает тестировщикам сформулировать тест‑кейсы и не забыть про пограничные и неприятные случаи;

• при необходимости вносит изменения в ТЗ, если в процессе реализации всплыли неучтённые моменты или пришлось слегка поменять заложенную концепцию.

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

• блокеры: «так жить нельзя, в прод не идём»;

• хотелки: «чуть‑чуть не так, давайте во вторую итерацию».

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

Все, мы в проде!

Шаг 6. Документация как системный артефакт

После удачного выезда в прод ТЗ не отправляется «в стол».

• Архитектурная часть уезжает к техписателю в раздел архитектуры (БД, сервисы, интеграции).

• Функциональная часть опять-таки силами техписателя раскладывается по соответствующим разделам — сценарии, поведение системы, бизнес‑логика.

Так ТЗ превращается в связующее звено между тем, что хотели, что сделали и как это теперь живёт в проде. Благодаря такому сквозному процессу работы с ТЗ и вовлеченности аналитиков во весь цикл разработки получаем живой комплект артефактов, который обновляется по мере развития системы, а не пылится в архиве.

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

Это даёт несколько плюсов:

• документация (по крайней мере та её часть, которая близка разработчикам) живёт рядом с кодом;

• разработчики начинают воспринимать её как «свою» и чаще помогают держать схемы в актуальном состоянии;

• проще отслеживать изменения через обычные механизмы контроля версий.

  

«Нытинги»: клуб людей, которым не всё равно

Чтобы аналитики не превратились в набор одиночек, раз в две недели мы проводим очные встречи всей команды, которые сами аналитики нежно прозвали «Нытинги». По сути, это регулярный sync аналитиков.

Цели у этих встреч простые:

• обмен информацией по текущим задачам;

• подсветка пересечений и связей между сервисами/функциональностью;

• предложение и обсуждение идей по улучшению процессов системного анализа в компании.

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

Это немного терапия, немного техревью и немного клуб анонимных любителей диаграмм.

Где тут ИИ и какие проблемы он не решает

Мы активно внедряем ИИ в процессы, связанные с анализом и документацией, и я подробно описывала это в отдельной статье. ИИ помогает ускорять рутину, но не превращает хаос в систему сам по себе — всё равно нужна голова, которая понимает контекст и последствия.

При этом остаются проблемы, которые ИИ сам по себе не решает:

• Поддержание документации в актуальном состоянии. Не все изменения в сервисах и подсистемах проходят через системных аналитиков, и из‑за этого документация постепенно разъезжается с реальной реализацией. Если мы натыкаемся на такие случаи — приводим всё в соответствие, но автоматического радара «док отвязался от реальности» пока нет.

• Сопротивление внедрению ИИ. Часть людей относится к нему настороженно, поэтому изменения идут медленнее, чем хотелось бы, и приходится работать не только с процессами, но и с опасениями людей.