Что же произошло? расскажем языком Mermaid же
Как рост Mermaid повлияет на работу системного аналитика
С декабря 2025 Mermaid вышел в лидеры интереса среди текстовых языков диаграмм, что для системных аналитиков не косметический сдвиг, а в каком-то смысле смена рабочего режима.
Важен не столько факт популярности, сколько то, где именно Mermaid начал побеждать: в документации, в GitHub, в IDE и в AI-сценариях. draw.io прямо объявил о выводе PlantUML из онлайн-версии к концу 2025 года и объяснил это вопросами его безопасности, широтой типов диаграмм у Mermaid и client-side архитектурой последнего.
Параллельно Microsoft встроил рендеринг Mermaid в Visual Studio Markdown-редактор, а GitHub добавил предпросмотр Mermaid в Copilot Chat. Это означает, что диаграмма перестаёт быть отдельным артефактом «для презентации» и становится обычным рабочим текстом рядом с требованиями, API и кодом.
Почему именно аналитиков это касается сильнее, чем раньше
Исторически системный аналитик часто жил между двумя мирами: «формальная модель» в Visio, draw.io, Enterprise Architect или PlantUML — и «рабочий текст» в Confluence, wiki, backlog, спецификациях и письмах. Mermaid сокращает это расстояние. По сути, он встраивает диаграмму в ту же среду, где уже живут требования и обсуждения. Mermaid сам себя позиционирует как инструмент, который помогает документации не отставать от разработки, а Visual Studio и GitHub уже поддерживают сценарий «AI сгенерировал Mermaid → команда сразу посмотрела preview». Для аналитика это означает, что схема теперь может появляться в том же цикле, что и user story, ADR, контракт API или описание бизнес-правила, а не через отдельный этап «потом нарисуем красиво».
Из этого следует важная перемена: аналитик всё меньше выступает как «автор статичных картинок» и всё больше — как автор изменяемых моделей, которые можно быстро править, сравнивать по версиям и ревьюить так же, как обычный текст. Там, где раньше диаграмма устаревала после второго изменения процесса, Mermaid делает её дешёвой в обновлении. Это особенно заметно в проектах, где требования меняются еженедельно и ценится не идеальная красота схемы, а её актуальность. Этот вывод — логическое следствие того, что Mermaid ориентирован на текст, Markdown и динамическое обновление документации.
Что изменится в ежедневной работе аналитика
Первое изменение — диаграмма станет частью спецификации, а не приложением к ней. Практически это значит, что sequence diagram можно хранить прямо рядом с описанием интеграционного сценария, state diagram — рядом с бизнес-правилами жизненного цикла сущности, а ER- или class-like диаграмму — рядом с описанием доменной модели. Visual Studio уже предлагает типовые сценарии именно такого использования: API call flow, relationships between entities, lifecycle of a task, onboarding в проект. Это очень близко к реальным задачам системного аналитика.
Второе изменение — ускорится ранняя проработка решений. Раньше, чтобы показать идею, аналитик часто выбирал между двумя неудобными вариантами: либо тратить время на ручную визуализацию, либо писать сухой текст и надеяться, что все одинаково его поймут. Mermaid плюс AI сокращают этот разрыв: сначала можно быстро набросать схему текстом или попросить Copilot сгенерировать черновик, а затем уже уточнять логику. Это особенно полезно на этапах discovery, обследования и согласования интеграций, когда скорость итераций важнее идеальной нотационной чистоты.
Третье изменение — порог входа для чтения и редактирования диаграмм внутри команды снизится. Когда GitHub показывает Mermaid прямо в preview, а Visual Studio умеет его рендерить без отдельного расширения, диаграмма становится понятнее не только аналитикам, но и разработчикам, тимлидам, QA и архитекторам. Это усиливает совместное владение документацией: исправить стрелку, уточнить состояние или добавить сервисный вызов становится проще, потому что правка живёт в том же процессе, что и остальное обсуждение изменений.
Какие умения станут важнее
На первый план выйдет text-first моделирование. Аналитику нужно будет думать не «какую кнопку нажать в редакторе», а «какую структуру описать текстом так, чтобы схема собралась из неё почти автоматически». Это меняет умение: чуть меньше графического ремесла, чуть больше структурного мышления и дисциплины формулировок. Mermaid специально построен на Markdown-подобном синтаксисе, и именно это делает его удобным мостом между требованиями и визуализацией.
Второе новое умение — работа с AI как с черновым моделистом. Copilot уже умеет генерировать Mermaid-диаграммы по контексту проекта. Для аналитика это не повод «перестать думать», а повод научиться хорошо ставить задачу: какой уровень детализации нужен, какая граница системы, какие акторы и сущности важны, что должно быть на схеме, а что нельзя перегружать. Иначе AI начнёт производить визуально правдоподобные, но аналитически слабые схемы. Технология даёт скорость, но ответственность за смысл остаётся у аналитика.
Третье умение — шаблонизация. Чем доступнее становится Mermaid, тем выше риск хаоса: у каждого автора свои имена узлов, свои стрелки, свой уровень детализации. Поэтому ценность аналитика смещается в сторону стандарта: какие типы диаграмм мы используем, когда рисуем sequence, когда state, как именуем участников, как отмечаем внешние системы, как обозначаем синхронность, ошибки, таймауты, асинхронные события. Рост Mermaid сам по себе не гарантирует качества — он лишь делает качество массово управляемым.
Что станет проще
Сильнее всего выиграют те артефакты, которые часто меняются и плохо переживают ручную отрисовку: интеграционные последовательности, жизненные циклы сущностей, контекстные схемы, простые архитектурные обзоры, связи между сущностями и технические пояснения для onboarding. Microsoft прямо показывает сценарии API flow, relationships between entities и lifecycle, а GitHub — просмотр Mermaid как части обычной разработки. Для аналитика это означает, что многие «служебные» схемы можно выпускать быстрее и обновлять чаще, не превращая каждое изменение в отдельную дизайнерскую задачу.
Упростится и миграция части старых текстовых диаграмм, особенно там, где организации уже использовали PlantUML в draw.io. draw.io не просто объявил об отказе от PlantUML в онлайн-версии, но и прямо написал о вариантах переписывания в Mermaid и конвертации. Для аналитиков это означает, что в ряде команд вопрос «использовать ли Mermaid» будет не стратегической дискуссией, а практической необходимостью.
Что не станет проще и где будут проблемы
При всём росте Mermaid не превращает аналитика в «оператора автосхем». Во-первых, Mermaid хорошо решает задачу живой прикладной документации, но не отменяет потребность в более формальных и специализированных нотациях там, где нужны строгие методологические рамки, сертификация, BPMN-процессы корпоративного уровня или сложное enterprise-моделирование. Это уже не факт из источника, а практический вывод: чем массовее инструмент, тем чаще он забирает повседневный слой коммуникации, но не все специализированные случаи.
Во-вторых, появится риск ложной достаточности. Раз Mermaid легко генерируется AI и быстро рендерится в preview, команда может начать принимать любую схему за хорошую. Но хорошая аналитическая диаграмма — это не та, что «отрисовалась», а та, что правильно выделяет границы системы, роли, события, состояния и исключения. Поэтому у аналитика станет меньше механической графической работы, но больше ответственности за семантическую точность.
В-третьих, возникнет проблема избыточной детализации. Mermaid особенно удобен для коротких и средних схем. Но когда аналитик пытается запихнуть в одну диаграмму всю интеграционную вселенную компании, текстовая модель тоже превращается в шум. Поэтому практическая зрелость команды будет измеряться не тем, что она «пишет в Mermaid всё подряд», а тем, что она умеет дробить модели на читаемые слои.
Как изменится роль системного аналитика в команде
Роль аналитика станет ближе к роли куратора живой архитектурно-процессной документации. Не просто описать требования и передать дальше, а поддерживать набор коротких, понятных, версионируемых схем, которые команда использует каждый день. Mermaid этому способствует, потому что живёт в тех же каналах, где живут разработка и ревью: Markdown, IDE, GitHub, docs-as-code.
Это же меняет и ожидания от аналитика. Цениться будет не умение «нарисовать красивее всех», а способность быстро выдать точную диаграмму, встроить её в спецификацию, обновить после изменения решения и сделать так, чтобы ею реально пользовались разработчики и тестировщики. Иными словами, аналитик будет оцениваться не по количеству диаграмм, а по тому, насколько диаграммы сокращают недопонимание в проекте.
Что стоит сделать аналитикам уже сейчас
Первое: выбрать 4–6 типовых сценариев, где Mermaid даёт максимальный эффект. Обычно это context diagram, sequence diagram, state diagram, ER/model overview и короткая component/integration overview.
Второе: зафиксировать правила. Нужны договорённости по именованию, уровню детализации, цветам/классам, обозначению внешних систем, ошибочных веток и асинхронности.
Третье: внедрить принцип «диаграмма живёт рядом с текстом». Не в отдельной папке с картинками, а рядом с user story, API spec, ADR, описанием сервиса или бизнес-процесса.
Четвёртое: использовать AI только как ускоритель черновика. Пусть Copilot предлагает скелет схемы, но финальная модель должна проходить через аналитическую проверку.
Пятое: не мигрировать всё подряд. Имеет смысл переносить в Mermaid прежде всего те диаграммы, которые часто меняются, участвуют в ревью и нужны в повседневной коммуникации команды.
Итог
Для системного аналитика рост Mermaid означает не «новый модный синтаксис», а переход к новой операционной модели работы с диаграммами. Они становятся ближе к требованиям, ближе к разработке, ближе к AI и дешевле в поддержке.
Именно поэтому влияние Mermaid на профессию будет заметно не в области «красивой визуализации», а в области скорости согласования, актуальности документации и совместной работы над моделью системы. draw.io подтолкнул рынок миграцией от PlantUML, Microsoft и GitHub встроили Mermaid в повседневный developer workflow, а сама команда Mermaid через mermaid.ai усиливает единый контур документации и развития проекта.
Для аналитика это означает одно: текстовые диаграммы из нишевого навыка превращаются в базовую рабочую грамотность.
