Исследование работы системных аналитиков

Интервью, профессиональные рутины и ценность актуальной документации. Материалы исследования Tracebook.

Краткое саммери исследования

Проведены интервью с системными аналитиками всех грейдов из разнообразных айти-команд, из финтеха (Альфа-Банк, Сбер, Тбанк), продуктовых компаний (Ламода, 2ГИС, BPMsoft, СберЛизинг, СМЛаб), строительства, фармакологии. Команды от 5 до 50+ человек, продуктовая и проектная разработка.

Существующие проблемы в пользовательском опыте

Документация расходится с реальностью: либо разработчик правил логику без обновления, либо страница с множеством перекрёстных ссылок становится нечитаемой. Команда натыкается на расхождение и теряет доверие к документации: «когда люди натыкаются на ситуацию, когда документация не соответствует реальной жизни, они перестают ей верить — а самое страшное, что может случиться с документацией, это отсутствие доверия» (Виталий, СберЛизинг).

Без актуальной документации каждая фича занимает в 10 раз больше времени, потому что аналитик не видит связи в системе и не понимает, что сломается при изменении. На каждый релиз — 10–20 хотфиксов; у команды с поддерживаемой документацией — два хотфикса в год на 25 релизов (Виталий, СберЛизинг).

Восстановление as-is на legacy-системах — отдельная статья: в кейсе ВТБ команда из двух аналитиков, архитектора и разработчиков занималась только этим три месяца, «не отвлекаясь ни на что» (Максим, ex-ВТБ, Альфа-Банк). Аналитик, отправивший в разработку требования с пробелами, выпадает «на весь день» на ответы тестировщикам и разработчикам (Анна, Сбер).

Половина или более рабочего времени аналитика уходит на разговоры. Анастасия (СМЛаб): «С 8:00 утра и до того, как созвонилась с вами [14:00], я разговаривала практически всё это время. Где бы я ни работала аналитиком, говорить приходилось много — всегда». Документация ведётся в оставшееся после разговоров время, в notepad++ и таблицах как буферах перед переносом в Confluence.

Обобщение оценки потерь в деньгах

— Требования, отправленные в разработку с пробелами или без предварительной синхронизации с командой. Один инцидент — до 500 тыс. рублей
— Расхождение документации с кодом и реальностью. 20 хотфиксов на релиз вместо 2, удорожание каждой фичи в 10 раз — до 2 млн рублей в год только на хотфиксах. Плюс необратимая потеря доверия к документации как активу.
— Невозможность impact analysis при изменениях. Каскадные баги, дублирование решений несколькими командами параллельно — до 0.5 млн рублей в год на один эпизод дублирования.

Текущее решение и его особенности

Confluence (часто с Jira) — рыночный стандарт. Корпорации продолжают использовать Confluence «в серую» или «в черную» даже после ухода Atlassian из России.

Особенности и проблемы решения:
— Тяжеловесность на масштабе: «1001 перекрёстная ссылка и страница грузится очень долго, либо неактуально через месяц» (Максим).
— Дифы нечитаемы: «практически невозможно понять, что изменилось» (Виталий, СберЛизинг).
— Поиск работает на собственном языке запросов: «я вообще не понимаю, как им пользоваться» (Всеволод, разработчик).
— Внутренние замены теряют ключевую функциональность: Сбер-Confluence «вообще забыл, что существует такое, как PlantUML» (Анна, Сбер).
— Яндекс.Вики и Я.Трекер имеют отдельный набор проблем: проблемы с корректной вёрсткой внутри, выгрузка через Word в трекер ломает форматирование, два типа таблиц с разной функциональностью не комбинируются (Наталья, BPMsoft).

Альтернативы пробовали и откатывались:
— Notion и Teamly: качество документации тех же аналитиков «прямо заметно» падает из-за Markdown-ограничений.
— Чистый Doc-as-Code (Markdown в Git): таблицы превращаются в «стену текста» (Дмитрий, Ламода); требует Git-культуры, «порог входа выше», большинство SA не тянет (Илья, Тбанк).
— AI поверх Confluence: «фантазирует больше, чем помогает» (Максим), «иногда какую-то чушь отдаёт» (Алексей, финтех).
— Самодельные пайплайны на LLM: озвучено пятью респондентами, используется для микро-задач, без интеграции, контроля галлюцинаций и переиспользования между аналитиками.

Продуктовая стратегия: сосуществование и замещение

Confluence воспринимается зонтично, обобщённо — как текстовый редактор для всех корпоративных задач, не только для разработки. Лицензии оплачены или взломаны, процессы давно укоренены и привычны, рынок SA заточен под Confluence: «искать аналитика, знакомого с чем-то ещё, где он будет не менее эффективен, чем в Confluence, — очень сложно» (Максим, Альфа-Банк). Продажа замены упирается в перенос документации, согласование бюджета на платный инструмент вместо привычного бесплатного, переобучение команды — каждый из этих факторов отдельно достаточен, чтобы сделку остановить.

Реалистичная точка входа — сосуществование. Либо параллельное, не пересекающееся и неизбежно дублирующее, либо соприкосновение с Confluence как источником, возвращение оформленных результатов обратно. Привычка не ломается, миграция не нужна, ценность видна сразу. Постепенно мигрировать проекты в продукт, оставляя Confluence как файлообменник для бизнеса. Замещение происходит само, без необходимости защищать перед клиентом бюджет на замену работающего инструмента.

Маркетинговая стратегия: ограничения и возможности

Ограничения:
— Клиент часто не видит проблему в работе с документацией целиком или в каких-либо аспектах. Тимлиды и CTO видят симптомы: растущий TTM, хотфиксы, легаси-долг, но не связывают их с работой с документацией. Продажа требует проблематизации, а не только демонстрации решения.
— SA носители боли и «компенсаторы трения», не покупатели. Аналитики принимают существующее положение вещей легко и безропотно — собственную роль «для экономии», процессы, инструменты.
— Confluence фактически бесплатен. Сравнение «платный новый инструмент vs привычный бесплатный» работает против нас по умолчанию.
— Lock-in через рынок труда: компании держатся за Confluence, чтобы не сужать воронку найма.

Возможности:
— Экономика потерь в разработке в части работы с документацией принципиально считабельна, цифры значимы для менеджмента. Это инструмент проблематизации.
— Целевой первый сегмент — компании с большим объёмом разработки и осознанным отношением к качеству документации. На пересечении этих двух осей коммуникация проще, средний чек выше.
— Многие лиды команд, которые могут быть ЛПР изначально выросли из разработки, поэтому доступны к аргументации и как менеджеры (через показатели и потери, через дельту, которой они могут отчитаться перед руководством) так и через аргументацию к разработке (Docs-as-Code, specfirst, логика IDE для аналитиков etc)
— Компании не могут игнорировать бум AI и продукты, которые конструктивно и без фантазийных обещаний помогают компаниям готовиться к AI-переходу — в фокусе у C-level

Мир системного аналитика

Кто эти люди

Системный аналитик — роль с размытыми границами. Каждая компания вкладывает в неё то, что нужно, и сами аналитики это осознают. Дмитрий (Ламода) формулирует прямо: «Само понятие системного аналитика и те задачи, которые он решает, они ничем не определены по факту. В каждой компании может очень сильно отличаться». При этом есть общий знаменатель: SA — это человек, который переводит потребность бизнеса в форму, пригодную для разработки, и несёт ответственность за точность этого перевода. Во многом роль системного аналитика становится пересекающейся или замещающей роль бизнес аналитика.

Наталья (BPMsoft) описывает суть роли через метафору: «Эта профессия подразумевает перевод с одного языка на другой. Перевод с бизнеса на систему и наоборот. Параллельно между этим ещё должно происходить проектирование». Максим (Альфа-Банк): «Работа аналитика не в написании документа, работа аналитика в согласовании позиций всех задействованных сторон. А документ — это то, что рождается по факту работы».

Восемь респондентов упоминают, что SA часто совмещает роли бизнес-аналитика, частичного тестировщика, частичного PM а иногда и DevOps. Наталья (BPMsoft) называет это «затычка в каждой бочке»: «Аналитик присутствует везде. Ты всегда с кем-то, где-то что-то делаешь, у тебя не бывает такого, что у тебя нет работы».

Системные аналитики — профессиональная область с очень неравномерным уровнем компетентности и профессиональной погруженности. Отчасти это связано с тем, что ещё десять лет назад системный аналитик в разработке был относительной редкостью, респонденты говорят о соотношении 1/10 к разработчикам, тогда как на 2025-26 г. это отношение стремится к 1/2 и более. В такой ситуации профессия системного аналитика рассматривается как «легкий вход» в сферу IT, как QA в 2022, фронтенд в 2018 и т. д. В таком положении, когда представление о профессии «три месяца обучения до трудоустройства» встречает высокий спрос на рынке труда — снижение среднего профессионального уровня происходит с неизбежностью.

Важно отметить, что при этом внутри IT системные аналитики рассматриваются как «прокладка» между бизнесом и разработкой, то есть как средство снижения трения в разработке — способ «сэкономить», что неизбежно формирует определённое пренебрежительное отношение как к самим системным аналитикам, так и к их труду.

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

Важно отметить, что сами Системные Аналитики принимают существующее положение вещей (в первую очередь собственную роль «для экономии») легко и безропотно. Это легко прослеживается как в самоопределении содержания их профессиональной идентичности, так и в том, насколько как данность воспринимаются ими процессы и инструменты внутри их профессиональной деятельности.

Рутины, которые воспроизводятся нашими респондентами

1. Археология и реверс-инжиниринг / составление, описание as-is [сужение до работы с кодом, вынести работу с коммуникациями в вторую рутину] [тут мы описываем то, что по факту реализовано = есть в коде]

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

Как выглядит рутина:
Аналитик восстанавливает контекст: идет в базы данных, читает старый код (или просит нейросеть его прочитать / разработчика объяснить) и поднимает старые чаты.

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

2. Синхронизация ожиданий и требований

Аналитик соединяет бизнес (которому нужно быстро), разработку (которой нужно понятно) и безопасность, внешние команды.

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

3. Визуализация и проектирование [проектирование системы vs визуализация для бизнеса]

Люди плохо читают текст, поэтому постоянная рутина СА — отрисовка схем.

Как выглядит рутина:
Написание YAML/JSON файлов, создание сиквенс-диаграмм в PlantUML, рисование BPMN в Draw.io, Archimate

4. Поиск "слепых зон" (эдж кейсы)

Заказчик представляет, что всё будет "как запланировано". В реальности опыт пользователя всегда включает в себя эдж-кейсы

Как выглядит рутина:
Продумывание альтернативных сценариев, обработки ошибок, действий при падении серверов или блокировках БД.

5. Обработка изменений в процессе разработки

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

Как выглядит рутина:
Изменение переменных, переписывание кусков ТЗ и попытки как-то выделить эти изменения для команды (цветом, комментариями или коммитами), а иногда и полный откат на 1 этап аналитики.

6. Механическая редактура документации

Аналитики вынуждены выполнять роль форматировщиков и верстальщиков документации.

Как выглядит рутина:
Перенос SQL-кода в маппинг-таблицы, массовое добавление одного и того же параметра в 10 разных документов, борьба с версткой таблиц в Confluence/Яндекс.Вики.

Интервью показывают, что Рутины 1, 2, 4 — это творческая и коммуникационная работа, которую инструментально можно только поддержать, но Рутины 3, 5 и 6 доступны для автоматизации.

Рабочий день SA это непрерывное переключение контекстов. Анастасия (СМЛаб): «Моя работа, она по большей части разговорная, чем прикладная. С 8:00 утра и до того, как созвонилась с вами, я разговаривала практически всё это время».

Документация создаётся в зазорах между согласованиями, созвонами, уточнениями. Черновики ведутся в блокнотах и Excel — как буфер между разговором и Confluence. Анастасия (СМЛаб): «Экселечка и какой-нибудь блокнотик — это две незаменимые вещи».

Анна (Сбер) описывает оптимизацию рутины: «Я беру, открываю, сколько у меня документов, столько документов в различных вкладочках открываю и начинаю их массово редактировать. Пока я редактировала предыдущий, у меня как раз второй документ открылся».

Ключевые задачи

Ниже описаны десять ключевых работ (jobs), которые SA выполняют в контексте документации. Каждая работа описана через триггер, желаемый исход, более крупную задачу, существующие решения и их косты, с привязкой к конкретным цитатам из интервью.

Ключевая задача 1. Написать требования так, чтобы разработчик написал код без возвратов

Цена решения: задача на 4 часа делалась полтора месяца, бюджет x2 (Владимир М.);
«весь день уйдёт на ответы тестировщикам и разработчикам» (Анна)

Ключевая задача 2. Восстановить реальную картину системы as-is

Цена:
«10 команд занимаются рефакторингом Legacy» (Максим);
«3 месяца постоянной работы, не отвлекаясь ни на что» на одну систему в ВТБ;
«аналитик приходит новый — через неделю уже пишет задачи» при наличии доки (Виталий) vs месяцы без неё

Ключевая задача 3. Собрать единый источник правды из разрозненной информации

Цена: рабочий день состоит из разговоров, фиксация вручную (Анастасия); «приходишь и понимаешь, что вообще ничего не понятно — то, что обсуждали, нерелевантно» (Юлия)

Ключевая задача 4. Синхронизация всех участников до единого понимания, контекста

Цена: «фича не достигает цели бизнеса, а лажает; количество сопровода растёт — сначала один, потом его руководитель, потом руководитель руководителя» (Анна)

Ключевая задача 5. Описать и поддерживать API-контракты без ручной вёрстки

Цена: нет точного отображения в корпусе интервью

Ключевая задача 6. Доставить документацию в рабочий контекст потребителя

Цена: каждое переключение контекста — потеря фокуса; костыли (копипаст в Git) устаревают мгновенно, создавая риск работы по неактуальной версии

Ключевая задача 7. Актуализировать документацию

Цена: через год разработка вязнет — «каждая фича в 10 раз дольше», «на каждый релиз по десятку-двадцатке хотфиксов» (Виталий); «главное не писать код несколько раз» (Максим); «То, что я наговорила, занимает примерно две недели. Нам надо было уталкать в 3 дня» (Анастасия);

Ключевая задача 8. Верифицировать, что реализация соответствует задуманному

Цена: «сопровод тратит на тебя и на твою систему кучу времени» — каждый баг на проде генерирует поток вопросов к аналитику (Анна)

Ключевая задача 9. Не дублировать решения, которые уже существуют в системе

Цена: дублирование логики → при изменении в одном месте ломается в другом; техдолг нарастает; «разработчики напишут нормально функцию, а вы у себя задублировали — и думаете, что изменили одну страничку, а на самом деле изменили и вторую» (Виталий)

Ключевая задача 10. Понять, что сломается при изменении

Цена: «на каждый релиз по десятку-двадцатке хотфиксов, потому что перестают понимать, как связано то, что делают, с тем, как система начинает себя вести» (Виталий); у команды с актуальной докой — «два хотфикса в год на 25 релизов» (Виталий)

Существующие решения

Софтверные решения

Confluence + Jira: монополист по умолчанию

Используется всеми девятью респондентами в том или ином виде. Даже после ухода Atlassian из России корпорации продолжают эксплуатировать старые инсталляции или форки. Максим (Альфа-Банк): «У всех он прям решение, без разницы, абсолютно. Более того, почти в каждой крупной корпорации есть команды, занимающиеся самостоятельной доработкой Jira и Confluence».

Переход на альтернативы блокируется рынком труда: «Искать аналитика, знакомого с чем-то ещё, где он будет не менее эффективен, чем в Confluence, — очень сложно» (Максим, Альфа-Банк).

Ключевые проблемы Confluence, названные респондентами:

• Невозможность связать UI-элемент с API-вызовом (Максим, Альфа-Банк)
• Отсутствие двусторонней связи с кодом (Максим, Альфа-Банк): «Confluence не имеет возможности подтягивать что-то из реализации»
• Тяжеловесность на масштабе (Максим, Альфа-Банк): «Либо 1001 перекрёстная ссылка и страница грузится очень долго, либо неактуально через месяц»
• Проблемы с таблицами и экспортом (Наталья, BPMsoft): невозможность менять колонки местами, сломанный экспорт PlantUML в PDF, невозможность совместного редактирования без пересоздания страницы

Яндекс.Вики / Яндекс.Трекер

Навязывается как корпоративный стандарт в компаниях, связанных с Яндексом. Наталья (BPMsoft) описывает букет UX-проблем: два типа таблиц с разным функционалом, которые нельзя комбинировать; отсутствие истории изменений для динамических таблиц; невозможность менять колонки местами.

Внутренние корпоративные замены (Сбер-Confluence и аналоги)

Попытки импортозамещения наталкиваются на базовые упущения. Анна (Сбер): «Они вообще забыли, что существует такое, как PlantUML. Вы представляете — ребята разрабатывают продукт, а они не знают, что такое PlantUML. Там просто не представляете, сколько воплей аналитиков в чате — тысячи сообщений».

Notion / Teamly

Анастасия (2ГИС) описывает опыт перехода: Notion закрылся, перешли на Teamly, «не зашло». Качество документации тех же аналитиков в Notion было заметно ниже, чем в Confluence — из-за ограничений Markdown-подобного формата. Анастасия (2ГИС): «Если сравнить качество документации от тех же аналитиков в Notion и в Confluence — разница прямо заметна. В Notion приходилось ужиматься в подформат Markdown». Отдельно: невозможность мёржить ячейки в таблицах оказалась критичной.

Doc-as-Code (Git + Markdown/Docusaurus)

Радикальный подход, решающий проблему версионирования и расхождения с кодом. Илья (Тбанк): TypeSpec → OpenAPI → Docusaurus, хранение в Git, автоматическая верификация через CI. Два источника правды: Open API для бэкенда, Figma для фронта.

Проблемы подхода: порог входа, потеря UX для микроправок, невозможность нормально делать таблицы в чистом Markdown. Дмитрий (Ламода) пробовал и вернулся: «Мы писали прямо честно в Markdown. Таблицу делать — трудоёмкость гораздо сильнее. Будет просто стена текста».

Инструменты визуализации

PlantUML — стандарт де-факто для sequence-диаграмм (минимум 5 из 9 респондентов). Draw.io — для всего остального (BPMN, ERD, архитектура, C4). Figma — для фронтенда. Miro — для верхнеуровневых схем, но раздражает лицензированием.

AI-инструменты

Пятеро озвучили использование AI, но исключительно для микро-задач:

• Валидация JSON/XML, структурирование данных (Алексей, финтех — локальный GPT)
• Проверка BRD на противоречия (Максим, Альфа-Банк — внутренний агент с доступом к Confluence)
• Реверс-инжиниринг кода (Юлия, строительство — Cursor)
• Полный конвейер с автогенератором промптов и верификатором (респондент-методолог)

Общий паттерн: AI используется для проверки и форматирования, а не для генерации документации. Галлюцинации остаются барьером. Алексей (финтех): «Иногда какую-то чушь отдаёт, одну страну может взять и пропустить».

Методологические решения

Помимо софта, аналитики выстраивают процессные решения:

• Шаблоны и стандарты — присутствуют у всех, но различаются по жёсткости. От свободных «вопросов на самопроверку» (Максим) до строгих «объект, атрибут везде одинаково» (Наталья, BPMsoft)
• Tri Amigo (Илья, Тбанк) — синхронизация трёх ролей до написания ТЗ. Снижает вероятность отвержения решения разработкой
• Глоссарий (респондент-методолог) — фиксация терминов в начале проекта
• Цветовое кодирование изменений (Юлия, строяк) — ручная альтернатива tracked changes
• Запись грумингов (Анна, Сбер) — видеозапись как страховка от потери контекста
• Конвейер документации (респондент-методолог) — девять шаблонов + автогенератор промптов + верификатор + CI/CD. Сократил цикл с 40–80 часов до 16

Ключевой неудовлетворённый запрос

Дмитрий (Ламода) сформулировал его точнее всех: «Если вы к этому сделаете удобные таблицы, диаграммы и всю красоту из макросов Confluence — это будет очень круто». Запрос на инструмент с Git под капотом и WYSIWYG-редактором сверху — повторяется прямо в разных формулировках у трёх-четырёх респондентов.

Текущая ситуация в деньгах и аналитика ценности

Системный аналитик

По данным https://career.hh.ru средняя заработная плата системного аналитика уровня миддл по России составляет 160 - 180 тыс. р., уровня синьор - 293 – 300 тыс.р.

По данным Dreamjob, средняя зарплата на должности системный аналитик в России за 2026 год ‒ 160 000 рублей, ведущий системный аналитик - 300 тыс. р.

По данным Flow у большинства опрошенных (41,0 %) миддл аналитиков заработная плата составляет 100 – 199 тыс. р., в то же время, у большинства синьор аналитиков (42,58%) – 300 –399 тыс. р.

Миддл
career.hh.ru: среднее диапазона = (160+180)/2 = 170 тыс.
Dreamjob: 160 тыс.
Flow: середина диапазона 100–199 = (100+199)/2 ≈ 150 тыс.
Среднее по трём источникам: (170 + 160 + 150) / 3 ≈ 160 тыс. руб (1 рабочий час - 1000р.)
Gross (13% НДФЛ) - 160 000 / 0,87 ≈ 183 908 тыс. р. (1  рабочий час ≈ 1149.4)

Синьор
career.hh.ru: среднее диапазона = (293+300)/2 ≈ 297 тыс.
Dreamjob: 300 тыс.
Flow: середина диапазона 300–399 = (300+399)/2 ≈ 350 тыс.
Среднее по трём источникам: (297 + 300 + 350) / 3 ≈ 316 тыс. руб.(1 рабочий час - 1975 р.)
Gross (13% НДФЛ) - 316 000 / 0,87 ≈ 363 218 тыс. р. (1  рабочий час ≈ 2270.1)

Разработчик

По данным career.hh.ru средняя заработная плата разработчика уровня миддл: backend 125 000 – 150 000 ₽, frontend 80 000 – 100 000 ₽. Уровня синьор: backend 220 000 – 250 000 ₽, frontend 230 115 – 250 000 ₽.

По данным GetGrade, средняя зарплата миддл-разработчика: backend (Java/Python/.Net) — 242 000 / 294 000 / 315 000 ₽, frontend (React/Web/Vue) — 258 000 / 190 000 / 200 000 ₽. Синьор backend — 395 000 / 416 000 / 311 000 ₽, frontend — 330 000 / 289 000 / 303 000 ₽.

По данным Хабр Карьеры, средняя зарплата backend-разработчика уровня миддл — 223 958 ₽, уровня синьор — 351 666 ₽. Frontend миддл — 196 666 ₽, синьор — 337 500 ₽.

Миддл backend
career.hh.ru: среднее диапазона = (125 + 150) / 2 = 137,5 тыс.
GetGrade: среднее по специализациям = (242 + 294 + 315) / 3 ≈ 284 тыс.
Хабр Карьера: 224 тыс.

Среднее по трём источникам: (137,5 + 284 + 224) / 3 ≈ 215 тыс. руб. (1 рабочий час ≈ 1344 р.)
Gross (13% НДФЛ) — 215 000 / 0,87 ≈ 247 126 ₽ (1 рабочий час ≈ 1544.5 р.)

Миддл frontend
career.hh.ru: среднее диапазона = (80 + 100) / 2 = 90 тыс.
GetGrade: среднее по специализациям = (258 + 190 + 200) / 3 ≈ 216 тыс.
Хабр Карьера: 197 тыс.

Среднее по трём источникам: (90 + 216 + 197) / 3 ≈ 168 тыс. руб. (1 рабочий час ≈ 1 050 р.)
Gross (13% НДФЛ) — 168 000 / 0,87 ≈ 193 103 ₽ (1 рабочий час ≈ 1207 р.)

Синьор backend
career.hh.ru: среднее диапазона = (220 + 250) / 2 = 235 тыс.
GetGrade: среднее по специализациям = (395 + 416 + 311) / 3 ≈ 374 тыс.
Хабр Карьера: 352 тыс.

Среднее по трём источникам: (235 + 374 + 352) / 3 ≈ 320 тыс. руб. (1 рабочий час ≈ 2 000 р.)
Gross (13% НДФЛ) — 320 000 / 0,87 ≈ 367 816 ₽ (1 рабочий час ≈ 2 299 р.)

Синьор frontend
career.hh.ru: среднее диапазона = (230 + 250) / 2 = 240 тыс.
GetGrade: среднее по специализациям = (330 + 289 + 303) / 3 ≈ 307 тыс.
Хабр Карьера: 338 тыс.

Среднее по трём источникам: (240 + 307 + 338) / 3 ≈ 295 тыс. руб. (1 рабочий час ≈ 1 844 р.)
Gross (13% НДФЛ) — 295 000 / 0,87 ≈ 339 080 ₽ (1 рабочий час ≈ 2119 р.)

PM

Миддл
hh.career 85 000 – 100 000 ₽
https://career.habr.com/ 150 000 ₽
GetGrade 100 000 - 150 000 ₽

Сеньор
hh.career 177 000 – 200 000 ₽
https://career.habr.com/ - 250 000 ₽
GetGrade - 255 000 - 300 000 ₽

Миддл
Среднее по трём источникам: 122 500 ₽ (1 рабочий час — 766 ₽)
Gross (13% НДФЛ) — 122 500 / 0,87 ≈ 140 805 ₽ (1 рабочий час ≈ 880 ₽)

Синьор
Среднее по трём источникам: 238 667 ₽ (1 рабочий час — 1 492 ₽)
Gross (13% НДФЛ) — 238 667 / 0,87 ≈ 274 330 ₽ (1 рабочий час ≈ 1 715 ₽)

Архитектор (программного обеспечения)

Миддл
hh.career - 174 000 – 224 025 ₽
https://career.habr.com/ - 374 000 ₽
Сеньор
hh.career - 330 000 – 475 000 ₽
https://career.habr.com/ - 432 500 ₽

Миддл
Среднее по трём источникам: 286 506 ₽ (1 рабочий час — 1 791 ₽)
Gross (13% НДФЛ) — 286 506 / 0,87 ≈ 329 317 ₽ (1 рабочий час ≈ 2 058 ₽)

Синьор
Среднее по трём источникам: 417 500 ₽ (1 рабочий час — 2 609 ₽)
Gross (13% НДФЛ) — 417 500 / 0,87 ≈ 479 885 ₽ (1 рабочий час ≈ 2 999 ₽)

Дизайнер (UI/UX)

Миддл
GetGrade 100 000 - 175 000 ₽
https://career.habr.com/ 109 000 ₽
hh.career 52 200 – 70 000 ₽

Сеньор
GetGrade 250 000 - 340 000 ₽
https://career.habr.com/ - 200 000 ₽
hh.career 175 000 – 200 000 ₽

Миддл
Среднее по трём источникам: 102 533 ₽ (1 рабочий час — 641 ₽)
Gross (13% НДФЛ) — 102 533 / 0,87 ≈ 117 854 ₽ (1 рабочий час ≈ 737 ₽)

Синьор
Среднее по трём источникам: 227 500 ₽ (1 рабочий час — 1 422 ₽)
Gross (13% НДФЛ) — 227 500 / 0,87 ≈ 261 494 ₽ (1 рабочий час ≈ 1 634 ₽)

QA

Миддл
GetGrade 110 000 - 222 000 ₽
hh.career 80 000 – 100 000 ₽
https://career.habr.com/ 150 000 ₽

Сеньор
GetGrade 210 000 - 250 000 ₽
hh.career 180 000 – 200 000 ₽
https://career.habr.com/ 242 000 ₽

Миддл
Среднее по трём источникам: 135 333 ₽ (1 рабочий час — 846 ₽)
Gross (13% НДФЛ) — 135 333 / 0,87 ≈ 155 555 ₽ (1 рабочий час ≈ 972 ₽)

Синьор
Среднее по трём источникам: 220 667 ₽ (1 рабочий час — 1 379 ₽)
Gross (13% НДФЛ) — 220 667 / 0,87 ≈ 253 640 ₽ (1 рабочий час ≈ 1 585 ₽)

Команда
Исходя из пропорции 1 SA на 2 разработчиков базовая команда выглядит следующим образом:

• 2 SA
• 4 разработчика (2 бэк + 2 фронт)
• 1 архитектор (SA lead)
• 1 QA
• 1 PM
• 1 дизайнер

По данным трёх источников (career.hh.ru, Хабр Карьера, GetGrade) стоимость команды из 10 человек в месяц составляет:
Команда миддлов
SA (2 чел.): 320 000 ₽ net | 367 816 ₽ gross
Архитектор/тимлид (1 чел.): 286 506 ₽ net | 329 318 ₽ gross
Разработчик бэкенд (2 чел.): 430 084 ₽ net | 494 350 ₽ gross
Разработчик фронтенд (2 чел.): 335 110 ₽ net | 385 184 ₽ gross
QA (1 чел.): 135 333 ₽ net | 155 556 ₽ gross
PM (1 чел.): 122 500 ₽ net | 140 805 ₽ gross
Дизайнер (1 чел.): 102 533 ₽ net | 117 854 ₽ gross
Итого: 1 732 066 ₽ net | 1 990 880 ₽ gross в месяц; 20 784 792 ₽ net | 23 890 560 ₽ gross в год
Команда синьоров
SA (2 чел.): 632 000 ₽ net | 726 437 ₽ gross
Архитектор/тимлид (1 чел.): 417 500 ₽ net | 479 885 ₽ gross
Разработчик бэкенд (2 чел.): 640 444 ₽ net | 736 142 ₽ gross
Разработчик фронтенд (2 чел.): 589 928 ₽ net | 678 078 ₽ gross
QA (1 чел.): 220 667 ₽ net | 253 640 ₽ gross
PM (1 чел.): 238 667 ₽ net | 274 330 ₽ gross
Дизайнер (1 чел.): 227 500 ₽ net | 261 494 ₽ gross
Итого: 2 966 706 ₽ net | 3 410 007 ₽ gross в месяц; 35 600 472 ₽ net | 40 920 084 ₽ gross в год
Смешанная команда (реалистичный сценарий)
Итого: 2 349 386 ₽ net | 2 700 444 ₽ gross в месяц; 28 192 632 ₽ net | 32 405 328 ₽ gross в год
Ранее было выделено несколько типов потерь:
Типичные- те, что происходят постоянно, возьмем за среднее значение 1р/неделя, то есть 4 р/месяц
Непостоянные - 1 раз в квартал = 0.33 раза в месяц
Пограничная - 1 раз в полгода = 0.17 раза в месяц

5.1. Базовая экономика: стоимость SA и инструментов для документации

Стоимость инструментов

Confluence Data Center на 500 пользователей на 2025 год ≈ 27625$ за год. Из расчета, что в 21 году лицензия на 500 пользователей стоила 22100$, а в 23 - 27000$, а с продвижением Cloud подорожание Data Center сильно снизилось на
~1–2% в год против прежних ~10% в год в период 2021–2023

Confluence Cloud является более кастомным решением, фактическое ценообразование Enterprise всегда обсуждается и значительно варьируется в зависимости от продолжительности контракта, состава пакета(например + Jira + JSM или дополнительные плагины), поставщика услуг, прошлый опыт пользования продуктами Atlassian(для постоянных покупателей предусмотрены скидки) и самих переговоров. По словам сертифицированного Atlassian специалиста, для расчета текущей цены можно смело умножать ценник Data Center на 2-3 раза, то есть ≈ 55250$ - 82875$ в год

5.2. Карта потерь по ключевым задачам

Все расчёты в разделе приведены в gross (с учётом НДФЛ 13%).

Раздел описывает десять ключевых задач SA, связанных с документацией, и их экономические последствия. На уровне команды эти задачи группируются в четыре профиля потерь. Все цифры приведены как среднее между миддл- и синьор-грейдом — ориентир для смешанной команды.

Профиль 1 — команды с legacy и унаследованными системами — охватывает задачи восстановления as-is (Задача 2) и актуализации документации (Задача 7). Разовое восстановление as-is — три месяца работы команды из пяти человек — стоит в среднем 4 700 400 ₽. Фоновые потери на legacy-баги составляют 41 028 ₽ ежемесячно на каждого аналитика, 492 336 ₽ в год.

Профиль 2 — команды без выстроенных процессов синхронизации — охватывает задачи передачи требований в разработку (Задача 1), выравнивания участников до старта (Задача 4) и верификации реализации (Задача 8). Один день SA на саппорт неполных требований стоит в среднем 13 743 ₽ за инцидент; выброшенное ТЗ — 41 028 ₽; пограничный случай некомпетентной постановки — 491 292 ₽ за инцидент.

Профиль 3 — команды с неактуальной документацией в активной фазе роста — охватывает задачи понимания зависимостей при изменениях (Задача 10), недублирования решений (Задача 9) и описания API-контрактов (Задача 5). Дублирование аналитической работы обходится в среднем в 136 760 ₽ за эпизод; разница между 20 и 2 хотфиксами на релиз — 190 566 ₽ ежемесячно, 2 286 792 ₽ в год.

Профиль 4 — фоновые потери, характерные для любой команды с SA — охватывает задачи сбора единого источника правды (Задача 3) и доставки документации в контекст потребителя (Задача 6). 4 часа в день каждого SA уходят на коммуникацию вместо документирования — 150 436 ₽ в месяц, 1 805 232 ₽ в год. Потери по Задаче 6 количественно не подтверждены.

Детальные расчёты по каждой задаче приведены ниже.

Задача 1. Написать требования так, чтобы разработчик написал код без возвратов

Потеря 1. Аналитик выпадает на весь день из работы и погружается в разъяснения

Когда требования неоднозначны, SA перестаёт заниматься своей задачей и весь день отвечает на вопросы разработчиков и тестировщиков. Анна (Сбер): «Весь день уйдёт на ответы тестировщикам и разработчикам».

Оценка потери: 6–8 ч времени SA на каждую итерацию.
Миддл: 6 894–9 192 ₽ | Синьор: 13 620–18 160 ₽

Типичная, не исключительная ситуация.

Потеря 2. Бюджет ×2 при некачественной постановке

«Решение, которое можно было сделать за 4 часа, делали полтора месяца. В два раза вырос бюджет — сначала заплатили за плохое решение, а потом за хорошее».

Некомпетентный аналитик потратил 40 часов (1 рабочая неделя) на написание плохой постановки. Разработчик работал по этому ТЗ 236 часов впустую (240 ч фактических − 4 ч плановых).

Оценка потери:

Пара миддл + миддл
SA миддл: 40 ч × 1 149 ₽/ч = 45 960 ₽
Разработчик миддл: 236 ч × 1 374 ₽/ч = 324 264 ₽
Итого потеря: 370 224 ₽

Пара синьор + синьор
SA синьор: 40 ч × 2 270 ₽/ч = 90 800 ₽
Разработчик синьор: 236 ч × 2 210 ₽/ч = 521 560 ₽
Итого потеря: 612 360 ₽

Пограничная ситуация.

Задача 2. Восстановить реальную картину системы as-is

Потеря 1. Восстановление as-is стоит месяцев работы целой команды, не одного аналитика

«На то, чтобы с этим разобраться, двум аналитикам, архитектору, разработчикам привлечённым — просто на то, чтобы разобраться, каков проект — три месяца постоянной работы, не отвлекаясь ни на что».

Состав команды из кейса: 2 SA + 1 архитектор + 2 разработчика бэкенд. Три месяца = 480 рабочих часов каждый.

Оценка потери:

Команда миддлов
2 × SA миддл: 480 ч × 2 × 1 149 ₽/ч = 1 103 040 ₽
1 × Архитектор миддл: 480 ч × 1 × 2 058 ₽/ч = 987 840 ₽
2 × Разработчик бэкенд миддл: 480 ч × 2 × 1 545 ₽/ч = 1 483 200 ₽
Итого потеря: 3 574 080 ₽

Команда синьоров
2 × SA синьор: 480 ч × 2 × 2 270 ₽/ч = 2 179 200 ₽
1 × Архитектор синьор: 480 ч × 1 × 2 999 ₽/ч = 1 439 520 ₽
2 × Разработчик бэкенд синьор: 480 ч × 2 × 2 300 ₽/ч = 2 208 000 ₽
Итого потеря: 5 826 720 ₽

Непостоянная ситуация.

Потеря 2. Legacy-долг становится запланированной статьёй потерь

«Поддержка текущих процессов разделена на правку багов, которые произошли сейчас, и на legacy-баги. Это 15% у нас считается выделенного времени».

Оценка потери:

Миддл: 15% × 160 ч × 1 149 ₽/ч = 27 576 ₽
Синьор: 15% × 160 ч × 2 270 ₽/ч = 54 480 ₽

Типичная, не исключительная ситуация, ежемесячные траты.

Задача 3. Собрать единый источник правды из разрозненной информации

Потеря 1. Рабочий день SA уходит на разговоры, фиксация происходит вручную в зазорах

«Моя работа по большей части разговорная, чем прикладная. С 8:00 утра и до того, как созвонилась с вами, я разговаривала практически всё это время». «Где бы я ни работала аналитиком, говорить приходилось много — всегда».

Это не разовая ситуация — это базовый режим работы SA. Созвон состоялся в 14:00 — 6 часов из 8 прошли в разговорах. Оцениваем консервативно: 4 часа в день как среднее.

Оценка потери:

Миддл: 4 ч × 1 149 ₽/ч = 4 596 ₽ (в день) | 101 112 ₽ (в месяц, 22 рабочих дня)
Синьор: 4 ч × 2 270 ₽/ч = 9 080 ₽ (в день) | 199 760 ₽ (в месяц, 22 рабочих дня)

Типичная, не исключительная ситуация, ежемесячные траты.

Задача 4. Синхронизировать всех участников до единого понимания контекста

Потеря 1. Детальное ТЗ написано впустую без предварительной синхронизации

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

Оцениваем как 24 часа потерянного времени SA (3 рабочих дня). Разработчик не участвует — ТЗ отвергается до начала разработки.

Оценка потери:

Миддл: 24 ч × 1 149 ₽/ч = 27 576 ₽
Синьор: 24 ч × 2 270 ₽/ч = 54 480 ₽

Типичная, не исключительная ситуация.

Задача 5. Описать и поддерживать API-контракты без ручной вёрстки

Потеря 1. Ручное описание контрактов таблицами — системная потеря времени SA

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

Типичная, не исключительная ситуация.

Потеря 2. Расхождение контракта с реальным кодом

Когда разработчик меняет логику в коде без обновления контракта, документация перестаёт соответствовать реальности. Команда работает по устаревшему контракту незаметно — ошибка обнаруживается только на интеграционном тестировании или на проде.

Илья (Тбанк) решил эту проблему технически: «У нас каждый раз при сборке, сборка будет падать, если Open API будет не соответствовать контракту» — существование этой потери признаётся как достаточно значимое, чтобы выстраивать CI-защиту от неё.

Оценка цены боли требует дополнительных данных.

Непостоянная ситуация.

Задача 6. Доставить документацию в рабочий контекст потребителя

Потеря 1. Документация живёт не там, где работает разработчик

Анна (Сбер): «Для нас 3 секунды — это долго, всё что тупит — остаётся». Переключение из IDE в браузер и обратно — достаточное трение, чтобы разработчик предпочёл не открывать документацию вовсе.

Максим (Альфа-Банк) описывает попытку решить это копипастом страниц из Confluence в Git — «это не супер решение»: копия мгновенно расходится с оригиналом и создаёт риск работы по неактуальной версии.

Прямая денежная оценка невозможна: потеря материализуется не как потраченные часы SA, а как снижение качества разработки. Это усиливает потери из Задачи 1 и Задачи 7.

Типичная ситуация, цена боли количественно не подтверждена.

Задача 7. Актуализировать документацию после изменений

Потеря 1. Давление сроков делает актуализацию структурно невозможной

Ахтиам описывает крайний исход: «Ребята начали просто вообще без документации все доработки делать» — результат более 100 багов в одном релизе.

Документация жертвуется первой при давлении дедлайна. Потеря реализуется позже — как переделка или накопленный техдолг.

Количественная оценка на основе интервью невозможна. Ниже модельное допущение для ориентира: переделка из-за неактуальной документации — 1 неделя SA на диагностику и переписывание доки + 2–3 дня разработчика на исправление реализации.

Миддл + миддл: 40 ч × 1 149 + 20 ч × 1 374 = 45 960 + 27 480 = 73 440 ₽
Синьор + синьор: 40 ч × 2 270 + 20 ч × 2 210 = 90 800 + 44 200 = 135 000 ₽

Непостоянная ситуация.

Потеря 2. Потеря доверия к документации обнуляет все инвестиции в её создание

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

Ахтиам: команда, переставшая доверять документации, перешла на полностью устный режим — результат «больше 100 багов, может быть даже под 200» в одной реализации.

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

Непостоянная ситуация.

Задача 8. Верифицировать, что реализация соответствует задуманному

Потеря 1. Без выстроенного QA аналитик берёт на себя ручное тестирование

Анна (Сбер) описывает системную перегрузку SA при отсутствии выделенного QA: аналитик вынужден проверять реализацию вручную, тратя время на задачи вне своей специализации. Edge-кейсы, которые он не проверил, возвращаются с прода.

Количественная оценка на основе интервью невозможна. Ниже модельное допущение для ориентира: ручная верификация одной фичи без QA — половина рабочего дня SA (4 часа).

Миддл: 4 ч × 1 149 ₽/ч = 4 596 ₽ на фичу
Синьор: 4 ч × 2 270 ₽/ч = 9 080 ₽ на фичу

Непостоянная ситуация — зависит от наличия QA в команде.

Потеря 2. Каждый баг на проде генерирует поток обращений к SA

Анна (Сбер): «Сопровод тратит на тебя и на твою систему кучу времени» — каждый дефект, пропущенный на этапе верификации, материализуется как поток вопросов от поддержки к аналитику.

Количественная оценка на основе интервью невозможна. Ниже модельное допущение для ориентира: один дефект с прода = половина дня SA на диагностику и ответы саппорту (4 часа).

Миддл: 4 ч × 1 149 ₽/ч = 4 596 ₽ на инцидент
Синьор: 4 ч × 2 270 ₽/ч = 9 080 ₽ на инцидент

Типичная ситуация при отсутствии выстроенного QA.

Задача 9. Не дублировать решения, которые уже существуют в системе

Потеря 1. Три аналитика независимо придумывают одно и то же

«Приходят три аналитика, приносят совершенно одинаковый объект. Каждый из аналитиков потратил там пять дней на то, чтобы придумать свою классную, супер продвинутую логику».

Три аналитика потратили по 5 дней (40 ч) каждый на задачу, которую должен был решить один. Переплата = стоимость двух лишних аналитиков.

Оценка потери:

Миддл: 2 лишних × 40 ч × 1 149 ₽/ч = 91 920 ₽
Синьор: 2 лишних × 40 ч × 2 270 ₽/ч = 181 600 ₽

Непостоянная ситуация.

Задача 10. Понять, что сломается при изменении

Потеря 1. Каждая фича в 10 раз дольше без актуальной документации

«Каждая следующая фича занимает в 10 раз больше времени, чем она бы заняла, просто если бы человек пошёл и в конкретном месте документации что-то поправил, посмотрел бы на связи».

Базовая фича: 40 ч разработчика + 8 ч SA. Без актуальной документации те же работы занимают в 10 раз больше.

Оценка потери:

Миддл + миддл: базовая стоимость 64 152 ₽ | реальная стоимость 641 520 ₽ | потеря на фичу 577 368 ₽
Синьор + синьор: базовая стоимость 106 560 ₽ | реальная стоимость 1 065 600 ₽ | потеря на фичу 959 040 ₽

Системное состояние команды без актуальной документации — не частотный инцидент.

Потеря 2. 20 хотфиксов вместо 2 на каждые 25 релизов

«На каждый релиз по десятку, по двадцатке хотфиксов». И в сравнении: «У нас два хотфикса в год — это было плохо. На 25 релизов — два хотфикса».

Один хотфикс = 4 ч разработчика + 2 ч SA (диагностика, фикс, деплой).

Оценка потери:

Миддл + миддл: 1 хотфикс — 7 794 ₽ | 20 хотфиксов (без доки) — 155 880 ₽ | 2 хотфикса (с докой) — 15 588 ₽ | разница на 25 релизов — 140 292 ₽
Синьор + синьор: 1 хотфикс — 13 380 ₽ | 20 хотфиксов (без доки) — 267 600 ₽ | 2 хотфикса (с докой) — 26 760 ₽ | разница на 25 релизов — 240 840 ₽

Типичная ситуация.

Исключением является ключевая задача 10 потеря 1 - это не частотный инцидент, а описание системного состояния команды без актуальной документации