Пять типичных ошибок системного аналитика на ИТ-проекте

Разберём пять ошибок, которые системные аналитики допускают на крупных enterprise-проектах. Я опираюсь прежде всего на банкинг и финтех: здесь особенно заметны последствия неясных требований, сложных интеграций, регуляторных ограничений и несогласованных ожиданий.

1. Требования без проверяемого смысла

Частая проблема — высокоуровневые формулировки без критериев проверки. Например: «Нужен удобный перевод средств для корпоративных клиентов». Без сценариев, типов операций, лимитов и критериев приёмки команда будет по-разному понимать результат.

Что делать

Для каждого требования зафиксируй критерии приёмки, а для измеримых продуктовых целей — метрики. Опиши основной, альтернативные и граничные сценарии. До разработки проверь формулировки с бизнесом, разработчиками и QA; если в команде есть бизнес-аналитик, разберите предметную часть вместе.

2. Игнорирование архитектурной среды и интеграций

Новая функция должна вписаться в работающий ландшафт. Если не учесть legacy-системы, шлюзы платёжных провайдеров, владельцев данных и ограничения интеграций, оценка трудоёмкости окажется неверной, а часть решения придётся пересматривать уже во время разработки.

Что делать

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

3. Недостаточное понимание домена и его регуляторики

Технически корректное решение может оказаться неприемлемым для бизнеса или комплаенса. При этом требования зависят от конкретного контура: PCI DSS охватывает обработку карточных данных и системы, способные повлиять на безопасность этой среды. Требования KYC/AML определяются применимыми нормами для конкретной организации, клиента и операции. Механически переносить весь набор норм в каждую спецификацию тоже неправильно.

Что делать

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

4. Недостаточная проработка негативных сценариев

Для финтех-систем обработка ошибок, граничных условий и частичных отказов — часть основного поведения. Потеря связи, некорректный формат реквизитов, превышение лимита, повтор запроса или недоступность API должны иметь понятный исход для системы и пользователя.

Что делать

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

5. Отсутствие ранней валидации концепций

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

Что делать

Работай короткими итерациями и проверяй наиболее рискованные допущения раньше остальных. Для одних задач подойдёт прототип интерфейса, для других — spike, контракт API или разбор сценария с бизнесом. Формат валидации должен соответствовать риску.

---

Системный анализ на крупных проектах связывает бизнес-цель, архитектуру, данные, безопасность, регуляторные требования и эксплуатацию. Хороший результат виден не по объёму документации, а по тому, насколько одинаково участники понимают решение и насколько рано команда замечает риски.

Разберём один запрос до проверяемого решения

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

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

Неясность	Что согласовать	Как проверить
«Доступный счёт»	Правило доступа и источник полномочий	Пользователь видит только разрешённые счета
«Перевод выполнен»	Финальное состояние и источник подтверждения	Интерфейс не объявляет успех до подтверждённого результата
«Попробуйте снова»	Правила повтора и идентификатор операции	Повтор после тайм-аута не создаёт второй перевод
«Данные актуальны»	Допустимую давность и реакцию на задержку	Просроченное состояние явно обозначено

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

Что руководителю проверить перед стартом разработки

Я бы попросил показать цепочку: цель → сценарий → правило → контракт → критерий приёмки. Не обязательно помещать всё в один документ. Важно, чтобы по критичному требованию можно было пройти этот путь и найти человека, который подтвердил решение.

Если ответ пока неизвестен, он должен стать видимой задачей исследования с владельцем. Например, сначала проверить поведение внешнего API после тайм-аута, затем выбирать механизм повтора. Неизвестность сама по себе нормальна; опасно считать её закрытым решением.

На ревью полезен короткий разбор со сменой ролей. Аналитик объясняет сценарий, инженер показывает границы реализации, QA пробует нарушить предположения, владелец продукта проверяет смысл результата. Несовпадение понимания здесь — полезная находка. После выпуска оно стало бы дефектом или дорогой переделкой.

Могу помочь разобрать требования и архитектуру вашего продукта →

---

Из моего Telegram-канала @it_underside.

Ваш ДПУПП