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

Middle-аналитик — это не “чуть прокачанный джун”, а качественный переход в роли. В какой-то момент ты перестаешь быть просто человеком, который аккуратно записывает требования, и начинаешь отвечать за их полноту, непротиворечивость и применимость. Уже недостаточно зафиксировать то, что сказали — нужно самому увидеть пробелы, задать правильные вопросы и довести постановку до состояния, в котором команда действительно может работать без постоянных уточнений.

Именно на уровне middle начинается настоящая ответственность: за то, что будет реализовано, за поведение системы в разных сценариях, за ошибки и границы. Здесь заканчивается модель “мне дали — я сделал” и появляется новая — “я отвечаю за то, что мы делаем и как это будет работать”. Это переход от фиксации требований к управлению ими: через осознанные решения, проработанные acceptance criteria и понимание последствий для всей системы.

Область	🟢 Junior	🟡 Middle	🟠 Middle+	🔴 Senior	🟣 Lead / Principal
📋 Работа с задачей
Понимание требований	Понимает после объяснения	Сам выявляет пробелы	Видит скрытые зависимости	Видит систему целиком	Формирует видение продукта, задаёт направление для команды
Постановка задачи	Нужна чёткая постановка	Работает с умеренной неопределённостью	Декомпозирует размытую задачу самостоятельно, формулирует цели	Переформулирует задачу, если поставлена неправильно. Работает от бизнес-цели	Сам формирует задачи для команды исходя из стратегии продукта
Работа с неопределённостью	Теряется, ждёт уточнений	Задаёт вопросы	Минимизирует неопределённость заранее, строит гипотезы, документирует допущения	Управляет неопределённостью на уровне системы	Создаёт инструменты и шаблоны для работы с неопределённостью в команде
Формирование требований	Фиксирует как есть	Дополняет и уточняет	Структурирует и улучшает	Формирует подходы и стандарты	Определяет методологию сбора требований для всей организации
Декомпозиция задач	Простая	Средняя	Сложная (фичи / эпики)	Системная декомпозиция	Декомпозиция на уровне продуктовой стратегии
✅ Acceptance Criteria
Кто определяет AC	Получает AC от старшего. Может помочь сформулировать, но не инициирует	Формулирует AC при поддержке — нужна проверка	Определяет AC самостоятельно. Для размытой задачи сам выявляет, что считать успехом	Определяет AC с учётом системных рисков, NFR и долгосрочных последствий	Формирует стандарты и шаблоны AC для всей команды / продукта
Качество AC	Пишет по шаблону, только очевидные сценарии	Сам формирует, покрывает основные сценарии	Конкретные, верифицируемые, почти как тест-кейсы. Happy path + error cases + граничные сценарии	AC связаны с бизнес-метриками, учитывают нагрузку, безопасность, совместимость	AC как часть системного контракта между командами и продуктом
Покрытие сценариев	Только happy path	+ негативные и edge cases	+ сложные и интеграционные сценарии	+ системные и кросс-доменные сценарии	Определяет стандарты покрытия для команды
🔌 API и техническая спецификация
API — описание	Базовый endpoint, заполняет шаблон по образцу	Полный контракт, описывает основные схемы ошибок	Проектирует API. Прорабатывает статус-коды, версионирование, обратную совместимость	Проектирует API с учётом эволюции: deprecation, миграции, безопасность	Определяет стандарты API-дизайна для всего продукта / компании
API — обработка ошибок	Почти не учитывает	Описывает основные ошибки	Продумывает стратегию ошибок, описывает схемы и коды	Формирует единый подход к ошибкам в системе	Стандартизирует обработку ошибок на уровне платформы
Работа с данными	Описывает поля	Проверяет валидность и обязательность	Учитывает структуру, расширяемость и rationale решений	Проектирует модели данных	Определяет принципы работы с данными для команды
Интеграции	Описывает как сказали	Понимает взаимодействие сервисов	Учитывает надёжность, поведение при сбоях, обратную совместимость	Оптимизирует интеграционную архитектуру	Проектирует интеграционную стратегию на уровне платформы
Техническое понимание	Базовое	Понимает ограничения	Учитывает транзакции, консистентность, производительность	Участвует в архитектурных решениях	Влияет на технологические решения на уровне компании
🤝 Взаимодействие с командой
Работа с разработчиками	Передаёт требования	Отвечает на вопросы, понимает базовые ограничения	Говорит на одном языке. Находит компромисс между бизнесом и разработкой	Влияет на инженерные решения	Строит процессы взаимодействия между командами
Работа с бизнесом	Передаёт вопросы	Уточняет требования	Формализует и упрощает	Влияет на продуктовые решения	Формирует продуктовую стратегию совместно с бизнесом
Эскалация	Эскалирует часто, иногда по вопросам которые мог решить сам	Эскалирует обоснованно, иногда без вариантов решения	Эскалирует только истинные блокеры. Приходит с вариантами, не с вопросом	Предотвращает эскалации за счёт раннего выявления конфликтов	Разрешает конфликты на уровне команд и стейкхолдеров
⚙️ Решения и риски
Принятие решений	Не принимает	Предлагает варианты	Выбирает и обосновывает. Приходит с вариантами, не с вопросом	Определяет направление	Принимает решения в условиях конфликта интересов стейкхолдеров
Работа с рисками	Не видит	Реагирует	Предугадывает, документирует допущения	Управляет рисками системно	Выстраивает культуру управления рисками в команде
🚀 Личные качества и рост
Самостоятельность	Низкая	Средняя	Высокая	Очень высокая	Максимальная — задаёт планку для команды
Проактивность и инициатива	Почти нет	Умеренная. Иногда поднимает смежные проблемы	Высокая. Предлагает улучшения за рамками задачи без просьбы	Инициирует изменения процессов на уровне команды	Формирует roadmap аналитической работы. Видит на 2–3 шага вперёд
Ответственность / Ownership	За описание своей части	За корректность требований по задаче	За качество постановки целиком, включая то, что не было явно поставлено	За результат на уровне фичи / эпика	За аналитическую зрелость всей команды и продукта
Менторство	Учится, задаёт вопросы	Начинает помогать джунам в отдельных вопросах	Регулярно помогает джунам, проводит ревью артефактов	Менторит middle-аналитиков, формирует стандарты качества	Нанимает, выращивает, оценивает аналитиков. Строит команду