/tl;dr

Бизнесу нужны рубли и проценты, а не слова про «выявление требований». Аналитик не кодит и не продаёт — как доказать, что он вообще что-то даёт? Цифрами.

Минимум метрик: трудозатраты на требования, доработки после релиза, конверсия, средний чек, время отклика бизнеса, ROI аналитики. Начните с двух–трёх — трудозатраты, баги, конверсия. Остальное добавите позже.

Сравнивать только «было» и «стало»: один и тот же функционал до и после переделки с аналитиком (например, при смене API). Иначе «задачи разные», «сезон другой» — и ваши цифры списывают на совпадение.

Зафиксируйте базовый период, нормализуйте цифры (на релизы, команду, сложность), постройте тренд и переведите эффект в рубли. Один график «до/после» сильнее десяти слайдов про «мы поработали хорошо».

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

Метрики — не способ оправдаться, а способ показать вклад аналитика и улучшать процессы. Сначала измеряй, потом убеждай.

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

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

В этой статье я делюсь тем, как за последние полгода я превратила ИИ в своего партнёра по работе. Показала, как нейронные сети, большие языковые модели (LLM) и удобная инфраструктура MCP + IDE Cursor (или её аналоги) могут стать настоящими союзниками системного аналитика, облегчая рутину и открывая новые возможности для творчества.

В этой статье на реальном кейсе я хочу рассмотреть весь путь превращения требований от бизнес-заказчика в техническое задание для разработчиков. Кроме того, в отдельных врезках я буду приводить объяснение той или иной технологии, того или иного понятия на доступном языке — для чайников (сама таким была и очень хотела, чтобы мне кто-то на пальцах объяснил все).

Итак, начнем.

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

Давайте начнем с теории. Согласно Карлу Вигерсу существует множество заинтересованных лиц:

«Заинтересованное лицо (stakeholder) — это человек, группа или организация, которая активно задействована в проекте, подвержена влиянию процесса или результата или может влиять на процесс или результат.»

их подмножество — клиенты:

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

и их подмножество — пользователи:

«Требования пользователей определяют те, кто прямо или косвенно взаимодействуют с продуктом. Эти пользователи (часто их называют конечными пользователями) являются подмножеством клиентов. Прямые пользователи непосредственно работают с продуктом. Непрямые пользователи могут получать результаты работы системы, не входя в непосредственный контакт с ней.»

Все эти подмножества я представила кругами Эйлера на рисунке ниже.