Привет, Хабр! На связи Варвара – системный аналитик Управления анализа и архитектуры фронтовых и интеграционных решений компании «Совкомбанк Технологии».
Представьте мир, где каждое ваше платежное поручение теряется между банковскими системами. Где клиент не может оформить кредит, потому что «что-то сломалось». Где регуляторы штрафуют за несоответствие данных, а ИТ-команда разводит руками: «Но бизнес же не объяснил, что ему нужно!»
В финансовых технологиях цена ошибки особенно высока – это не просто неудобный интерфейс, это потерянные клиенты, штрафы и репутационные риски. Именно здесь на первый план выходит системный аналитик – специалист, который превращает хаотичные пожелания бизнеса в работающие ИТ-решения.
В статье мы разберём, как системный аналитик собирает информацию, формирует техническое задание (далее ТЗ) и какие подводные камни могут встретиться на этом пути. Рассмотрим как теоретические аспекты, так и кейсы из реальной практики нашей компании. Вы узнаете, чем именно занимается этот специалист в банке и почему его работа так важна.

В общем о профессии
Да кто такой этот ваш системный аналитик?!
Системный аналитик – это специалист, который выступает связующим звеном между бизнес-заказчиком и командой разработки. В банке его основная задача –трансформировать регуляторные и бизнес-потребности в технические требования к программному обеспечению. По сути, аналитик «переводит» с языка бизнеса на язык ИТ и обратно. В структуре ИТ-проекта системный аналитик занимает стратегически важное положение.
Ну и чем же он занимается?
Если в очень общих чертах, работу системного аналитика в банке можно разделить на три основных этапа:
работа с требованиями – анализ регуляторных и бизнес-требований, выявление потребностей стейкхолдеров;
подготовка ТЗ – описание интеграций, детализация логики, учёт отраслевых нюансов;
сопровождение/консультация команды развития в процессе разработки и тестирования.
Всё равно ничего не ясно. Можно пример?
Разберём на классическом примере – добавление кнопки в интерфейс.
-
Исследование и анализ требований. Аналитик выясняет у бизнеса и изучает систему:
Зачем нужна кнопка?
Где её разместить?
Какое поведение ожидается после нажатия?
Не конфликтует ли нововведение с существующей логикой?
-
Какие технические ограничения учесть?
Итог: размытое «сделайте какую-то кнопку» превращается в конкретные требования.
-
Составление ТЗ. Аналитик подготавливает:
Цель доработки – какую проблему решает кнопка.
Алгоритмы – как должна работать кнопка.
Диаграммы – например, UML-диаграмму последовательности для сценария её работы.
Прототипы – схематичное расположение кнопки.
-
Чек-лист приёмки – «Кнопка активна только при заполненных полях X и Y».
Итог: лаконичный, структурированный документ, исключающий разночтения у разработчиков и тестировщиков.
-
Сопровождение задачи. После передачи ТЗ в разработку аналитик:
Отвечает на вопросы команды разработки.
Помогает тестировщикам разбирать неочевидные кейсы.
Вносит правки в ТЗ, если на этапе разработки/тестирования были найдены неописанные кейсы.
-
Участвует в приёмке – сверяет результат с изначальными требованиями.
Итог: задача успешно выполнена, кнопка работает, все довольные едят пиццу.
Ниже мы детальнее разберём ключевые этапы – работу с требованиями и создание ТЗ. Именно на них аналитик тратит 80% рабочего времени и от их качества зависит успех всего проекта.

Работа с требованиями. Этапы работы с требованиями
Сбор: как вытащить из заказчика полезную информацию
Приходим за задачей, собираем все данные о ней. Выявляем потребности заинтересованных лиц для достижения целей проекта.
Первый шаг – понять, что именно хочет бизнес. Но «сделайте красиво и удобно» – не инструкция, а старт для диалога. На начальном этапе задача аналитика – использовать разные источники и методы сбора требований. Чем больше каналов информации, тем полнее картина. Важно не просто записать пожелания, а выяснить контекст, бизнес-цели и ограничения.
Источниками требований могут быть: люди, документы, системы.
Методы сбора требований:
-
Глубинное интервью – индивидуальная беседа с заказчиком/пользователем, во время которой он делится с исследователем своим опытом, пожеланиями и взглядом на проблему.
Пример: обычная беседа с представителем бизнеса по итогам последнего релиза. Не важно, будь то в переговорке или за чашкой чая на кухне.
-
Наблюдение – фиксация естественных действий пользователя в конкретной жизненной ситуации.
Пример: наблюдение за процессом согласования корпоративных платежей для выявления узких мест и задержек.
-
«Мокасины» – инструмент, который позволяет исследователю максимально приблизиться к опыту пользователя, буквально «встать на его место».
Пример: выполнение типичных операций андеррайтера для выявления неудобств в работе системы.
-
Изучение документов – изучение регламентов, описаний процессов, стандартов, шаблонов документов. Сюда можно добавить даже изучение кода и реверс-инжиниринг – если документации совсем нет.
Пример: изучение документации другого сервиса для реализации интеграции по получению скоринговой оценки заёмщика.
-
Прототипирование – предоставление модели ожидаемого продукта, по максимуму демонстрирующей пользователям будущий продукт.
Пример: демонстрация прототипа личного кабинета для загрузки документов и сбор обратной связи.
-
Анкетирование/опрос – составление листа-опросника для подтверждения или детализации ранее известных требований, выбора параметров для решений.
Пример: опрос лояльности пользователей корпоративного портала.
-
Брейн-шторм – метод коллективного обсуждения для быстрого генерации идей по решению проблемы или сбору требований.
Пример: обсуждение, какие новые функции добавить в мобильное приложение банка.
Анализ: находим подводные камни
Вербально читаем текст, понимаем данные, делаем выводы, проверяем их. Получаем более широкое и точное понимание всех требований и представление набора требований в нужном виде.
После сбора требований наступает этап глубокого анализа: аналитик выявляет противоречия, уточняет детали и проверяет техническую реализуемость. Главная задача – убедиться, что все требования четкие, полные и не противоречат друг другу. На этом этапе важно структурировать требования, а также определить приоритеты и возможные ограничения. Часто за кажущейся простотой скрывается целый комплекс взаимосвязанных процессов.
В таблице ниже – ключевые свойства хорошего требования с примерами:
Свойство |
Описание |
Пример хорошего требования |
Пример плохого требования |
---|---|---|---|
Атомарность |
Требование не должно иметь возможность быть разделенным на несколько требований. |
«Система должна формировать PDF-отчет по выполненным заказам» |
«Система должна формировать PDF-отчет на почту» |
Проверяемость |
Требование должно быть проверяемым, чтобы можно было оценить в ходе тестирования, выполняется ли оно в конечной системе или нет. |
«Система должна загружать страницу авторизации за <=2 секунды» |
«Система должна быть быстрой» |
Применимость |
Требование должно быть взаимосвязанным с другими требованиями. |
«Система должна учитывать статус клиента при расчёте пенсионной скидки» |
«Система должна учитывать скидки» |
Осуществимость |
Требование должно быть реалистичным и выполнимым с учетом ограничений, таких как актуальность, бюджет, ресурсы и технические возможности. |
«Система должна поддерживать обработку файлов формата pdf/doc/docx/txt размером до 10мб» |
«Система должна уметь обрабатывать любые файлы» |
Однозначность |
Требование должно быть ясным и не подверженным различным интерпретациям. |
«Система должна отправлять смс на основной мобильный номер клиента при сбое оплаты» |
«Система должна уведомлять об ошибке» |
Полнота |
Требование должно содержать все необходимые детали, чтобы его можно было реализовать без дополнительных уточнений. |
«Система должна сохранять информацию о заказе, в частности, его ID, сумму и статус» |
«Сохраняем заказ» |
Документирование: превращаем «хотелки» в инструкцию для разработки
Получаем и документируем совокупные знания о требованиях постоянным и хорошо организованным способом. Подтверждаем правильность имеющегося набора требований.
Главная задача аналитика – декомпозировать бизнес-требования и перевести их на технический язык, создавая не просто перечень пожеланий, а детальную инструкцию для разработчиков. Качественное техническое задание представляет собой четко организованный документ с диаграммами, пользовательскими сценариями и точными формулировками. Оно включает:
Бизнес-цель (краткое и конкретное описание, зачем нужна система/доработка).
Чёткие технические требования к системе (описание алгоритмов работы системы на каждом этапе бизнес-процесса).
Структурированные пользовательские сценарии с понятными критериями успеха.
Проработанные сценарии поведения системы в альтернативных (неуспешных) кейсах.
Визуальные модели процессов (например, BPMN-, UML-диаграммы).
Прототипы интерфейсов.
Мы используем готовый шаблон ТЗ в Confluence, который включает все необходимые разделы – от пользовательских сценариев до описания настроек. Это позволяет формировать связанные артефакты и сокращает время подготовки документации, гарантируя её соответствие стандартам.
Главное правило – документ должен быть настолько понятным, чтобы разработчик сразу мог приступить к работе. Процесс включает четкую фиксацию требований, их регулярное уточнение и проверку на полноту, так как в ходе разработки изменения неизбежны. Ключевая цель – не создать идеальный документ, а обеспечить достаточное понимание для реализации текущего этапа проекта.
Типичные ловушки и как их избежать
С теорией разобрались. А на практике, на практике-то что?!
Работа системного аналитика – это не только структурирование информации, но и умение ориентироваться в неопределённости. На каждом этапе – от сбора требований до подготовки документации/MVP – можно столкнуться с подводными камнями. Ниже представлены наиболее частые ловушки и рекомендации, как их избежать.
-
Скрытые требования. Иногда заказчик считает очевидным то, о чём не говорит. В итоге система «неудобна», потому что не реализовала то, что «и так всем понятно».
Что делать: всегда прорабатывать альтернативные сценарии, а также использовать техники активного слушания, задавать уточняющие вопросы, анализировать текущие процессы. Уточните: что будет, если это требование не реализовать? Кто пострадает?
-
Конфликтующие требования. Один стейкхолдер хочет одно, другой – прямо противоположное. Пример: руководителю нужна проверка, пользователю – быстрое оформление без проверок.
Что делать: не бояться предложить альтернативу; фиксировать источник каждого требования, выносить спорные моменты на согласование, документировать решения и компромиссы. Использовать принципы приоритизации.
-
Размытые формулировки. «Удобно», «надёжно», «по стандарту» – такие слова дают простор для интерпретаций. Разные специалисты могут понять их по-разному.
Что делать: переводить общие слова в конкретные характеристики: метрики времени отклика, сценарии, допустимые форматы и условия. Применять SMART-формулировки и свойства качественного требования.
-
«Золотой молоток». Когда заказчик приходит с готовым решением вместо описания проблемы: «Добавьте поле X», хотя настоящая проблема – в неудобной логике системы.
Что делать: копать глубже. Спрашивать: «Зачем нужно это поле? Что пользователь хочет достичь?» – и только потом предлагать решение.
-
Непонимание ограничений. Системы работают в рамках технических, юридических и организационных ограничений. Требование, не учитывающее эти рамки, может оказаться нереализуемым.
Что делать: с самого начала фиксировать и проверять ограничения (архитектура, производительность, безопасность, нормативы). Обсуждать осуществимость с командой разработки в рамках консультаций.

Кейсы из реальной практики
Без примеров всё это может звучать как красивая теория. Нужна пара реальных историй, слегка обезличенных, но от этого не менее поучительных.
Можно сто раз прочитать про идеальный процесс работы с требованиями, но только реальные кейсы показывают, где теория даёт трещину. В этом разделе – настоящие истории (чуть приукрашенные анонимностью), которые показывают, как даже небольшие упущения могут привести к серьёзным последствиям. За каждой из них – часы переговоров, исправлений и ценных уроков. Читайте, смейтесь (или плачьте), и главное – учитесь на чужих ошибках.
«Устные договорённости – это миф»
Ситуация: в процессе работы с бизнес-заказчиком мы согласовали важное решение в устном формате – на созвоне или в переписке. Все участники вроде бы были согласны, но когда пришло время сдачи задачи, выяснилось, что заказчик либо забыл о договорённости, либо передумал. А письменного подтверждения не было. В итоге – конфликт, переделки и испорченные нервы.
Почему так вышло? Люди (даже ответственные) склонны забывать детали, менять мнение или интерпретировать договорённости по-своему. Это нормально. Но если решение не зафиксировано – доказать свою правоту почти невозможно.
Мораль: Любые договорённости, даже кажущиеся очевидными, нужно фиксировать письменно. Письма, комментарии в задачах, протоколы встреч – что угодно, лишь бы был след.
«Переименовали блок – сломали процесс»
Ситуация: в рамках доработки мы изменили название одного из блоков данных. Казалось бы, мелочь – ну подумаешь, вместо Block_A теперь Block_B. Но, когда обновлённые данные отправили в Систему1, она не смогла их обработать, потому что ожидала старое название. Из-за этого не сформировался важный комментарий для другой системы – Системы2, которая как раз должна была получить информацию от Системы1.
Почему так вышло? Тестирование проводилось без учёта сценария изменения названий, а никто даже и не подумал, что переименование может настолько повлиять на процесс.
Мораль: Даже незначительные изменения (вроде переименования поля) требуют повышенной внимательности аналитика: обязательного ревью у опытных коллег, перепроверки интеграционных точек и расширенного тестирования. Задача системного аналитика – не просто зафиксировать изменение, а спрогнозировать его последствия на всех уровнях системы.
«Легаси-код: маленькая фича vs килограммы проблем»
Ситуация: Бизнес запросил, казалось бы, простую доработку: сделать поле «Комментарий» настраиваемым по длине. «Пустяк!» – подумали мы. Но оказалось, что это поле завязано на старый код, и его изменение потянуло за собой кучу багов в неочевидных местах. В итоге доработка заняла в разы больше времени, чем ожидалось.
Почему так вышло? Не было глубокого анализа влияния изменений на legacy-части системы.
Мораль: Прежде чем лезть в старый код, нужно оценить риски. Если доработка требует значительных усилий, а ценность для бизнеса небольшая – лучше честно сказать: «Это возможно, но дорого. Может, есть другой способ?»
«myParameter vs MyParameter: проблема регистра»
Ситуация: Смежная система (Система2) начала передавать параметр myParameter (с маленькой буквы) в нашу систему (Система1), хотя в XSD-схеме он объявлен как MyParameter. Мы заметили несоответствие, но совместно решили, что «и так сойдёт» – ведь процесс работал. Позже подключили третью систему (Система3), которой тоже понадобилось это значение. И тут выяснилось, что из-за разницы в регистре наша система (Система1) не сохраняет параметр корректно в БД – и передать его дальше невозможно.
Почему так вышло? Проблему проигнорировали на раннем этапе, решив, что «работает – и ладно».
Мораль: Если где-то работает «и так» – это не значит, что так и надо. Рано или поздно найдётся кейс, который вас накажет.
«Нельзя просто так взять и перепроектировать БД»
Ситуация: Поступило требование расширить возможности конфигурации «клиент-документ». Первая мысль: «Нужно переделывать структуру БД – иначе не получится из-за имеющихся ограничений». Но после более детального анализа выяснилось, что достаточно убрать одну валидацию при вставке данных. Никто не помнил, зачем эта валидация была нужна, но её удаление решило проблему без перепроектирования.
Почему так вышло? Изначальный анализ был поверхностным. Не был предусмотрен вариант того, что можно обойтись «малой кровью».
Мораль: Прежде чем предлагать сложные решения, нужно копнуть глубже. Возможно, проблема решается минимальными изменениями.
Коротко о главном
Системный аналитик – не только «переводчик» между заказчиком и разработчиком. Это человек, который умеет делать из туманных хотелок понятные шаги, видеть риски до того, как они всплывут на проде, и создавать документацию, которая работает, а не просто лежит в Confluence/Jira.
Почему это важно сейчас? Потому что ИТ-проекты становятся сложнее, рынку нужны не просто исполнители, а связующие звенья. Люди, которые умеют мыслить структурно, задавать правильные вопросы, и – главное – слышать ответы, даже если их не произнесли вслух.
Хорошее ТЗ – это не когда всё расписано до запятой, а когда у команды не остаётся вопросов. А ещё – это про здравый смысл. Он помогает выбрать, что действительно важно, отличить хотелку от бизнес-цели, а красивую презентацию – от работающего сервиса. Именно здравый смысл позволяет строить надёжные перспективы, радоваться человеческому общению, делиться знаниями и вкладываться с энергией в то, что создаёшь.
Спасибо, что дочитали до конца! Надеюсь, что материал был полезным и понятным – как хорошее ТЗ. Если у вас есть вопросы или хотите поделиться своим опытом – оставляйте комментарии!
А найти работу системным аналитиком (и не только) в Совкомбанк Технологиях можно по ссылке.
Комментарии (4)
Cordekk
16.07.2025 09:33многих ошибок можно избежать, если ведется хорошая и подробная документация. Но очень подробная документация, как правило, сложна и не читабельна, да и писать её лень, поэтому на одни и те же грабли наступают вновь и вновь
IKSparrow
Скажите пожалуйста, чем системный аналитик отличается от бизнес-аналитика?
SovcomTech Автор
Добрый день!
Ответим в разрезе финтеха:
Бизнес-аналитик исследует рыночные тренды, формирует требования к продукту и согласует их.
Системный аналитик проектирует техническую реализацию: разрабатывает схемы API для платежных шлюзов, настраивает интеграцию с процессинговыми системами или проектирует базы данных для обработки транзакций. BA отвечает за то, «что нужно бизнесу», а SA — за то, «как это реализовать технически».