Всем привет, меня зовут Сергей Прощаев, и в этой статье я расскажу, как на самом деле выглядит работа системного аналитика и как к ней готовиться.
Руковожу направлением Java-разработки в FinTech и несколько лет назад активно участвовал в найме системных аналитиков. За это время я просмотрел сотни резюме и провёл десятки собеседований. И знаете, что самое интересное? 90% кандидатов отлично говорят про BPMN, UML и User Stories, но когда им дают тестовое задание в духе «сделайте сервис пользователей», они теряются. Они начинают рисовать красивые, но бесполезные диаграммы, вместо того чтобы задать пять простых вопросов, которые поставят под сомнение само ТЗ.
Сегодня мы разберём решение этой задачи по шагам. Я покажу вам не идеальную картинку из учебника, а реальный рабочий процесс: как выжать требования из расплывчатой формулировки, как спроектировать интеграции, чтобы не вызвать коллапс и как составить документы, которые у разработчиков не вызовут вопросы. А в конце поделюсь, где можно научиться делать это системно, а не методом проб и дорогостоящих ошибок.
Тестовое задание — ловушка для перфекциониста
Вот типичное задание, которое вы можете получить на собеседовании или в качестве домашнего задания:
«Разработать USER-сервис. Функции: регистрация по email, верификация, восстановление пароля, админка для управления пользователями. Будет использоваться в нашем основном продукте.»
С одной стороны кажется, всё просто и понятно. И именно здесь начинается первая и главная ошибка. Кандидат, стремясь показать свою техническую подкованность, сразу хватается за Lucidchart или draw.io и начинает рисовать Use Case-диаграмму: «Актор Пользователь, прецедент “Зарегистрироваться”…».
Стоп! Вы только что провалили первый неявный этап задания — анализ контекста и уточнение потребности.
Системный аналитик — не стенографист, который красиво оформляет чужие мысли. Он — сыщик и переводчик. Его первая задача — усомниться во всём.
Вот как должен выглядеть мой внутренний диалог при виде такого ТЗ (и именно это я жду от сильного кандидата):
«Будет использоваться в нашем основном продукте» — а что это за продукт? B2C-маркетплейс, где регистрация должна быть в 1 клик через соцсети? Или B2B-банковское приложение с жёсткими требованиями KYC (Know Your Customer)? От этого зависит всё: сложность формы, необходимость двухфакторной аутентификации, хранение персональных данных.
«Верификация» — какая? Подтверждение email? Или ещё и номера телефона? А если это fintech — верификация личности через госорганы? Что происходит с неподтверждённым аккаунтом? Через сколько времени он удаляется?
«Админка» — а кто этот админ? Техподдержка? Суперадмин? Какие именно операции нужны: блокировка, смена роли, просмотр логов действий? Нужна ли аудитория действий админа (кто, когда и кого забанил)?
В одном проекте мы потратили месяц на разработку «админки» с 20 полями на основе типового шаблона. Оказалось, что 90% времени поддержка использует лишь одну функцию — разблокировку аккаунта по звонку. Остальное — бесполезный шум. Выяснять истинные потребности заказчика — дороже, чем угадывать!
Первый шаг — превращение хаоса в структуру. Работа с сырыми требованиями
Предположим, мы задали эти вопросы и получили уточнения от гипотетического продакт-менеджера:
Продукт — внутренний корпоративный портал для сотрудников (B2E).
Верификация — только подтверждение корпоративного email. Аккаунт без верификации удаляется через 72 часа.
Админка — для IT-отдела: просмотр списка, блокировка, сброс пароля.
Теперь начинается магия структуризации. Мы уходим от абстрактных слов к конкретным сущностям, акторам и бизнес-правилам.
Начинаю я всегда с простого текстового списка или ментальной карты. Вот скелет нашего будущего сервиса:
Сущности: Пользователь, Аккаунт, Сессия, Токен верификации, Токен сброса пароля.
Акторы: Гость (неавторизованный пользователь), Пользователь, Администратор, Внешний сервис (например, Email Sender).
Ключевые бизнес-правила (Business Rules):
Email должен быть уникальным в системе.
Пароль должен соответствовать политике безопасности (мин. 8 символов, буквы верхнего/нижнего регистра, цифры).
Неверифицированный аккаунт удаляется через 72 часа после создания.
Токен для сброса пароля действителен 1 час.
Администратор не может заблокировать сам себя.
Это не формальный документ, а черновик моей мысли. Именно так я ищу противоречия. Например, правило 5 появилось не сразу. Я задал себе вопрос: «А что, если админ в гневе забанит всех?» Это и есть проактивный анализ рисков. И здесь не бойтесь задавать себе вопросы, которые могут порой на первый взгляд показаться даже абсурдными!
Теперь переходим к фиксации сформулированных мыслей и инструменты тут могут быть любыми: от Miro и XMind до простого текстового редактора. Суть не в инструменте, а в мышлении категориями и связями.
Документирование — создание источника истины, а не отчёта для галочки!
1. Диаграмма прецедентов использования (Use Case Diagram) для общего контекста.
Она нужна, чтобы все заинтересованные лица (продакт, разработчик, тестировщик) буквально за 30 секунд увидели «кто и что может делать». Для ее создания воспользуюсь онлайн-редактором Mermaid Live Editor https://mermaid.live в него можно прямо вставить код и сразу увидеть результат:
2. Детализация ключевых сценариев в виде User Story с критериями приёмки (Acceptance Criteria).
Это основной рабочий документ для разработки и тестирования. Он должен быть максимально конкретным и проверяемым.
User Story: Регистрация нового пользователя
Как новый сотрудник,
Я хочу зарегистрироваться в портале, указав своё имя и корпоративный email,
Чтобы получить доступ к внутренним ресурсам.
Критерии приёмки (AC):
AC1. Успешная регистрация с валидными данными.
Дано: Я нахожусь на странице регистрации.
Когда: Я ввожу корректное имя и email в домене компании (@company.com) и пароль, соответствующий политике.
И нажимаю «Зарегистрироваться».
Тогда: Мне показывается сообщение «Письмо для подтверждения отправлено на ваш email».
И: В системе создаётся запись пользователя со статусом PENDING_VERIFICATION.
И: На указанный email отправляется письмо со ссылкой для подтверждения (токен должен быть уникальным и одноразовым).
AC2. Попытка регистрации с уже существующим email.
Дано: Пользователь с email user@company.com уже зарегистрирован.
Когда: Я пытаюсь зарегистрироваться с тем же email.
Тогда: Мне показывается ошибка «Пользователь с таким email уже существует».
И: Письмо с подтверждением не отправляется.
Обратите внимание: критерии написаны в формате Given/When/Then (Gherkin). Это не просто формальность. Такой формат:
Однозначно понимается всеми: бизнесом, разработчиками, тестировщиками.
Прямым ходом ложится в основу автоматизированных тестов.
Исключает двусмысленности типа «система должна быстро работать» (а что значит быстро?).
С какого-то времени я перестал писать многостраничные ТЗ после одного болезненного проекта. Мы сделали «идеальную» спецификацию, которую после трёх спринтов разработки больше никто не открывал. Реальность ушла вперёд, а документ устарел. Теперь я делаю живые, атомарные артефакты (как диаграмма и история выше), которые привязаны к задачам в Jira/Confluence и легко актуализируются. Документ ради документа — мёртвый документ.
Проектирование интеграций — где случаются катастрофы вроде TSB
Самая коварная часть задания, которую многие пропускают. USER-сервис почти никогда не живёт в вакууме. Он — часть экосистемы. И если на этапе проектирования не проработать интеграции, вас ждут ночные звонки и срочные хатки.
Давайте определим, с чем наш сервис будет общаться:
Email-сервис (SMTP/сервис рассылок): Для отправки писем с подтверждением и сбросом пароля.
Auth-сервис/API Gateway: Для выдачи JWT-токенов после успешного входа.
Админский фронтенд или другая система: Для использования админских функций.
Вот здесь рождаются нетехнические вопросы, которые решает системный аналитик:
Вопрос надёжности: Что делать, если Email-сервис не отвечает? Регистрация должна падать? Или мы ставим задачу в очередь, а пользователю всё равно говорим «письмо отправлено»?
Вопрос консистенции данных: Если пользователь удалил аккаунт в USER-сервисе, как мы уведомим Auth-сервис, чтобы отозвать его токены? Нужна ли синхронная транзакция или достаточно асинхронного события (UserDeletedEvent)?
Здесь нам на помощь приходит диаграмма последовательности (Sequence Diagram) изображенная на рисунке 2. Она визуализирует диалог между системами во времени и выявляет узкие места:
Обратите внимание на ключевую деталь: взаимодействие с Email-сервисом я сделал асинхронным (пунктирная стрелка). Почему? Потому что скорость отклика регистрации для пользователя критична. Мы не должны заставлять его ждать, пока письмо физически уйдёт по SMTP и пройдёт через все очереди. Мы принимаем его данные, сохраняем и сразу говорим «всё ок». А отправку письма делегируем фоновому процессу. Это архитектурное решение, основанное на нефункциональном требовании к производительности.
Чтобы понять цену ошибок на этапе анализа и проектирования, достаточно вспомнить реальный кейс 2018 года — неудачную миграцию британского банка TSB Bank на новую банковскую платформу Proteo4UK (Sabadell).
В ходе переноса более миллиона клиентских счетов оказалось, что критичные сценарии — обработка сбоев, восстановление данных, масштабирование, поведение системы при нестандартных ситуациях — были проработаны недостаточно глубоко.
В результате каскадные отказы привели к массовым сбоям: около 1,9 млн клиентовпотеряли доступ к своим счетам, а банк понёс сотни миллионов фунтов убытков, столкнулся с давлением регуляторов и серьёзным репутационным кризисом.
Во многом это следствие не только технических проблем, но и недостаточно качественного системного анализа — непродуманных edge-case сценариев, рисков интеграций и нефункциональных требований. Это не теория — это реальная цена поверхностных требований, слабого анализа и недооценки рисков при проектировании критичных систем.
Детали, которые отделяют джуна от мидла: NFR и тестирование
Сильный кандидат не остановится на функциональных требованиях. Он спросит про нефункциональные требования (Non-Functional Requirements, NFR). Для нашего USER-сервиса это:
Производительность: Сервис должен выдерживать 100 RPS (запросов в секунду) на регистрацию в час пик.
Доступность: 99.9% uptime.
Безопасность: Пароли должны храниться в хэшированном виде (bcrypt/scrypt). Все endpoints, кроме регистрации и входа, защищены авторизацией.
Аудитинг (Audit Logging): Все действия администратора (блокировка, сброс пароля) должны логироваться с указанием кто, когда и что сделал.
Все эти пункты напрямую влияют на архитектуру (нужен ли кеш? как масштабироваться?) и стоимость разработки.
Наконец, мыслить как тестировщик — суперсила аналитика. Вы должны заранее видеть дыры. Например, в сценарии сброса пароля:
Что, если пользователь запросит сброс, а потом сразу запросит ещё один? Инвалидируется ли старый токен?
Что, если пользователь перейдёт по ссылке сброса пароля после истечения срока жизни токена (1 час)?
А если админ сбросит пароль пользователю, а тот уже залогинен на 3 устройствах? Сессии должны быть сброшены?
Прописывая эти сценарии в виде дополнительных критериев приёмки, вы не просто показываете свою внимательность. Вы сокращаете цикл обратной связи и предотвращаете баги на самых ранних стадиях!
Заключение: Системный аналитик — это стратег, а не писатель
Разбор тестового задания «USER-сервис» — это не упражнение в красивом оформлении. Это симуляция реальной работы, где ваша ценность измеряется не количеством диаграмм, а способностью выявлять скрытые риски, задавать неудобные вопросы и создавать чёткие, исполнимые инструкции.
Хороший системный аналитик экономит команде месяцы работы, а компании — миллионы рублей, предотвращая катастрофы вроде провала TSB. Плохой — создаёт иллюзию работы, производя километры никем не читаемых документов.
Если этот разбор показался вам полезным и вы хотите превратить этот навык из интуитивного в системный, приглашаю вас на открытый урок «Техническое собеседование системного аналитика». На нем узнаете, какие вопросы чаще всего задают на собеседованиях, и сможете эффективнее подготовиться к собеседованиям на позицию младшего системного аналитика.
Урок пройдет в рамках курса «Системный аналитик» в OTUS 10 февраля. Участие бесплатное, нужно зарегистрироваться.
Еще больше бесплатных уроков от преподавателей курсов можно посмотреть в календаре мероприятий.
