Системный аналитик и ТЗ: кто пишет документ и что получает бизнес
Этап аналитики и составления проектной документации обычно воспринимают как неудобство на пути к настоящей работе, разработке. Пока аналитика идет, ценность сложно увидеть: потрогать руками нечего, поэтому этап часто пропускают. Иногда это верное решение, но узнать об этом получается только на финальных этапах, и тогда экономия может обойтись в копеечку. В статье разберем, для чего нужна системная аналитика, какие документы пишут до разработки, кто готовит техническое задание и кто его утверждает, как проверить готовый документ, сколько времени придется отдать своим людям и когда аналитика выгоднее взять в команду на этап.
Коротко
- Кто пишет ТЗ: системный аналитик. Бизнес приносит цели и отвечает на вопросы, утверждает документ заказчик.
- До разработки бывает до семи документов: от BRD о целях бизнеса до проекта архитектуры и кода. На небольшом проекте они сливаются в один-два.
- Годное ТЗ можно проверить без технического образования: у каждого требования есть критерий приемки и понятная цель.
- Цену и срок подготовки ТЗ точно заранее не назвать: их задает глубина документа, интеграции и число ролей.
- Аналитика берут в свою команду на этап, когда своя разработка есть, а держать роль в штате после этапа незачем.
Зачем бизнесу системная аналитика перед разработкой
Между решением «нам нужна система» и первой строкой кода лежит работа, которую легко пропустить. Команде нужно:
- понять, какие информационные системы уже работают в компании;
- определить, как люди и соседние системы будут взаимодействовать с новой;
- выявить и сформулировать функциональные и нефункциональные требования;
- составить спецификацию, по которой программисты будут работать без догадок.
Системная аналитика и объединяет эти четыре задачи.
Разночтение, найденное на согласовании, стоит правки в документе. То же разночтение после старта разработки стоит переписанного кода и сдвинутого срока. В ходе анализа требования постоянно уточняются: появляются новые, неактуальные уходят. Системный аналитик сверяет каждое новое требование с уже согласованными и ищет противоречия раньше, чем их найдет тестировщик или пользователь. Для бизнеса вывод простой: спорить о смысле требований выгоднее до написания кода, пока спор стоит часа встречи.
Что делает системный аналитик в проекте заказчика
Системный аналитик описывает, как будет работать система, настолько подробно, чтобы разработчики делали ее без догадок. На практике это сущности и их статусы, правила переходов между статусами, интеграции с другими системами и критерии, по которым работу примут. Пример вопроса аналитика: «что происходит с заказом, если оплата прошла, а товар на складе закончился?».
Основную часть времени аналитик выявляет, анализирует и согласует требования. Работа идет вместе с заказчиком, и обратная связь показывает, что потребности бизнеса учтены и поняты правильно.
Источник знаний зависит от того, есть ли уже система. Для нового продукта аналитик изучает аналоги, документы, с которыми происходит работа, и системы, с которыми продукту предстоит обмениваться данными. Для действующей системы он восстанавливает ее текущее состояние, AS IS, и описывает целевое с новыми пожеланиями, TO BE. Знания предметной области аналитик получает на встречах с людьми заказчика.
Описание нужно даже там, где задача выглядит простой. Компания хочет повторить продукт конкурента, и возникает вопрос, зачем тогда ТЗ: «сделайте, как там». Как чужой продукт устроен целиком, в компании никто не знает. Есть понимание нескольких сценариев, которые сотрудники прошли сами или видели на демонстрации, а правила за экраном, исключения и роли остаются скрытыми. Аналитику все равно приходится описать, как продукт работает у конкурента, и вместе с заказчиком выбрать из этого то, что нужно. Без такого описания команда копирует видимую часть, а остальное придумывает сама.
Чтобы расставить приоритеты, аналитик выясняет, сколько людей и из каких групп будут работать с системой. Кладовщику, менеджеру и бухгалтеру нужны разные экраны и права, и самые ценные для бизнеса функции видны только в таком разрезе.
Требования меняются и после старта разработки. Аналитик оценивает, как изменение затронет то, что уже сделано: какие экраны, интеграции и проверки придется переделать. Без такой оценки небольшая правка в одном месте ломает соседний модуль, и выясняется это уже на тестировании. Когда подрядчик включает аналитика в команду, полезно сразу спросить, кто со стороны заказчика будет отвечать на его вопросы: от этого зависит скорость всей работы.
Чем бизнес-аналитик отличается от системного аналитика
Обе роли называют словом «аналитик», и в вакансиях их часто смешивают. Граница проходит по вопросу, на который отвечает каждый: что изменить в работе компании или как устроить систему.
Бизнес-аналитик исследует бизнес, ищет узкие места и предлагает способ решения, не углубляясь в технические детали. Возьмем пример. Руководители и сотрудники подразделений тратят дни на согласование бумаг. Печатный документ ходит из кабинета в кабинет, сканы множатся во вложениях корпоративной почты, и при постоянном потоке оба способа одинаково медленные. Бизнес-аналитик предлагает внедрить систему электронного документооборота: документы просматривают и визируют в ней, статус каждого виден сразу. Так появляются требования к системе со стороны бизнеса.
Системный аналитик берет формализованные бизнес-требования и определяет, какой будет система и как она встроится в информационную среду предприятия. Здесь речь идет о требованиях нижнего уровня. Аналитик описывает интерфейсы для пользователей и то, что происходит «под капотом»: какие статусы проходит документ, что делать, если подписант в отпуске, куда уходят данные после подписи.
Совмещать роли получается редко, потому что для этого нужны одновременно глубокое знание информационных технологий и предметной области. Чтобы сделать продукт для банка, надо разбираться в действующих нормах банковского законодательства и учитывать их в каждом требовании. Специалиста, который одинаково силен в нормах банка и в модели данных, найти трудно, и роли разумнее разделить. Специалист по нормам обычно уже есть у самого заказчика: это эксперт его предметной области.
Чем системный архитектор отличается от системного аналитика
Аналитик и архитектор работают с одними требованиями, и на старте проекта их роли легко смешать. Разница в вопросе: аналитик отвечает, что делает система, архитектор решает, из чего она собрана и на чем работает.
Системный аналитик описывает поведение системы: какие в ней сущности, через какие статусы они проходят, что видит каждая группа пользователей и что происходит при ошибке. Его результат — ТЗ и спецификация, по которым разработчики пишут код, а тестировщики готовят проверки.
Системный архитектор решает, из каких крупных блоков будет состоять система, как они связаны и на каких технологиях построены. Он выбирает стек, решает, оставить ли один монолит или разделить систему на микросервисы, и думает на годы вперед: выдержит ли система рост нагрузки, во что обойдется следующая крупная доработка. Результат его работы описывают в HLD, высокоуровневой архитектуре. В примере с электронным документооборотом аналитик описывает маршрут документа и замену подписанта в отпуске. Архитектор решает, где хранить сканы, как подключить электронную подпись и как система будет обмениваться данными с учетной системой компании.
Роли пересекаются на интеграциях и требованиях к скорости, нагрузке и безопасности. Аналитик фиксирует, сколько пользователей работают одновременно и за какое время заявка должна дойти до склада, а архитектор решает, как этого добиться. Отдельный архитектор нужен не каждому проекту. Если система встает на готовую платформу и стек уже выбран, без него обходятся. Если стек не выбран, интеграций много или нагрузка заметная, архитектора подключают до разработки: ошибка на этом уровне дорогая, и исправляют ее месяцами.
Эксперт предметной области (SME): кто отвечает на вопросы аналитика
Системный аналитик знает, как описать систему. Как устроены банковские гарантии, датчики на строительном объекте или путь заявки между складом и бухгалтерией, знает другой человек. Его называют экспертом предметной области, по-английски Subject Matter Expert, сокращенно SME. Обычно это сотрудник заказчика: юрист, главный инженер, руководитель отдела, который годами работает с процессом.
Аналитик погружается в предмет настолько, чтобы описать модель и задать точные вопросы. Источником знания он не становится: правило из регламента или исключение, которое помнит только опытный сотрудник, приходит от эксперта. Бизнес-аналитик эксперта тоже не заменяет, если сам не работал в этой области. В банковском проекте нормы законодательства объясняет юрист или методолог банка.
Полностью передать аналитику работу над требованиями не получится, и это лучше заложить до старта. В нашей практике эксперт заказчика тратит на аналитика около четырех часов в неделю суммарно: встречи и уточнения в переписке по итогам. Это ориентир из наших проектов, замера никто не делал, и на проекте со сложным комплаенсом вопросов может быть больше.
Мы пишем ТЗ вместе с заказчиком и не ждем его готовым. Если эксперт занят на месяц вперед, аналитик заполняет пробелы предположениями, и они всплывают на приемке. Назначить эксперта и поставить ему часы в календаре стоит до подписания договора.
Кто пишет документы до разработки и когда подключается каждая роль. На небольшом проекте документы сливаются в один-два
Не только лишь ТЗ: какие документы пишут до разработки (BRD, PRD, FRD, SRS, SDD, TDD и HLD)
До первой строки кода у проекта может появиться несколько документов. Каждый отвечает на свой вопрос и пишется своим автором, поэтому путаница в названиях быстро превращается в путаницу в ответственности.
Всем известно понятие «техническое задание», ТЗ. В силу своей расхожести под ним могут понимать документ любой полноты и проработанности, который фиксирует договоренность заказчика и исполнителя о конечном результате сотрудничества: что должно быть сделано и как работу примут. Часто основная функция документа юридическая. В закупках по 44-ФЗ и 223-ФЗ, то есть у государственных заказчиков и компаний с государственным участием, описание объекта закупки, по сути то же ТЗ, входит в документы закупки. По нему участники считают цену, а заказчик потом принимает работу.
Для ТЗ есть и государственные стандарты: ГОСТ 34.602-2020 для автоматизированных систем и ГОСТ 19.201-78 для программ. ГОСТы применяются добровольно, как и другие национальные стандарты. Обязательными они становятся, если этого требуют договор, условия закупки или нормативный акт. В реальной же работе для разработки требуются разные наборы документов, каждый из которых формально можно назвать техническим заданием. Рассмотрим, что это за документы.
Документы выстраиваются в цепочку от вопроса «зачем» к вопросам «что» и «как». Зачем компании система, описывает BRD. Что система должна делать, описывают PRD, FRD и SRS. Как ее построить, решают HLD, SDD и TDD. В таком порядке документы обычно и появляются:
- BRD, Business Requirements Document, документ бизнес-требований. Зачем компании проект: какую проблему он решает и какой результат должен дать. Пример цели: «сократить время обработки заявки с двух дней до двух часов».
- PRD, Product Requirements Document, документ требований к продукту. Для кого продукт, какие функции входят в версию и по какой метрике понять, что продукт сработал.
- FRD, Functional Requirements Document, документ функциональных требований. Что делает система с точки зрения пользователя: сценарии работы, действия на экранах, бизнес-правила.
- SRS, Software Requirements Specification, спецификация требований к программному обеспечению. В русской практике ее чаще называют просто спецификацией или «спекой». SRS собирает функциональные требования и добавляет к ним требования к скорости, нагрузке и безопасности, а также контракты API. Часто отдельного FRD нет: функциональные требования сразу живут в спецификации.
- HLD, High-Level Design, высокоуровневая архитектура. Общая схема системы: крупные блоки, связи между ними, внешние системы и технологии.
- SDD, Software Design Document, документ проектирования программного обеспечения. Детальный проект системы: модули, схема базы данных, интерфейсы между компонентами.
- TDD, Technical Design Document, документ технического проектирования. Как будет реализована конкретная часть системы на уровне кода: классы, запросы к базе данных, обработка ошибок. По нему разработчики пишут код и тесты.
Две аббревиатуры из списка совпадают с названиями подходов к разработке, и их легко спутать. SDD в списке документов означает Software Design Document. В разделе про ИИ-агентов ниже SDD означает Spec-Driven Development, разработку от спецификации. TDD в списке означает Technical Design Document, а у разработчиков TDD чаще значит Test-Driven Development, разработку через тестирование: сначала пишут тест, потом код. Если аббревиатура встретилась в переписке с подрядчиком, стоит уточнить, о документе речь или о подходе.
BRD составляют вместе со стейкхолдерами, то есть со всеми, на кого влияет проект: с руководителем, который платит, отделом продаж, бухгалтерией. В документе нет экранов и кода, только цели, ограничения и критерии успеха. PRD ведет владелец продукта и обновляет его по ходу работы. HLD пишет архитектор, чтобы заказчик и команда одинаково понимали устройство системы до детального проектирования.
На небольшом проекте документы сливаются, и это нормально. Бизнес-требования и требования к системе могут жить в одном документе, и это нормально. HLD тоже нужен не всегда: архитектора подключают, когда проекту нужны выбор стека и общая схема. Для заказчика важнее полнота ответов. В любом наборе документов должны найтись ответы на все вопросы из таблицы, даже если вопрос закрыт одним абзацем.
Кто пишет техническое задание, кто его утверждает и зачем оно бизнесу
Спор о том, кто пишет ТЗ, идет годами. Заказчик считает, что исполнитель лучше знает, что ему нужно для работы. Исполнитель отвечает, что без знаний заказчика документа не будет и что писать его нужно за отдельные деньги. Любой исполнитель согласится, что это достаточно объемная работа, которая должна отдельно оплачиваться.
В разработке системы роли распределяются так. ТЗ пишет системный аналитик. Бизнес приносит цели, в виде BRD или письма с задачей, и через эксперта предметной области отвечает на вопросы. Утверждает документ заказчик: он платит за разработку и потом принимает работу по этому документу.
Выявленные требования аналитик оформляет в техническое задание или спецификацию. Оба документа подробно описывают функции и ограничения будущей системы, и по ним можно спрогнозировать бюджет и сроки.
Что бизнес получает от готового ТЗ:
- оценки подрядчиков, которые можно сравнить, чтобы установить, например, начальную максимальную цену в тендере: все считают один и тот же объем;
- возможность сменить подрядчика или продолжить разработку своими силами, потому что ТЗ и спецификацию может читать любая команда;
- приемку по критериям вместо спора о том, что имелось в виду.
Без документа разработчики додумывают требования сами. Код получается аккуратным, но решает задачу, которую никто не ставил. Устаревший документ опасен по-своему: команда сверяется с ним и уверенно делает то, от чего бизнес уже отказался.
ТЗ не обязано быть полным до старта. Удобнее двигаться итерациями: каждая заканчивается работающей версией продукта, и документацию на следующий этап аналитик готовит, пока команда завершает предыдущий. Документ растет вместе с системой при одном условии: после каждого изменения он остается актуальным.
ТЗ можно дописывать по этапам: аналитику следующего этапа готовят, пока команда заканчивает текущий, и после каждого цикла есть работающая версия
Как проверить ТЗ до подписания
Для первой проверки технического образования не нужно. Достаточно пройти по документу с карандашом и задать каждому разделу несколько вопросов. Признаки годного ТЗ:
- у каждого требования есть критерий приемки: понятно, что покажут на сдаче и что будет считаться выполненным;
- каждое требование связано с целью бизнеса, и можно ответить, зачем оно нужно;
- в документе нет формулировок «на усмотрение разработчика» и «по согласованию» без указания, с кем и когда;
- понятно, что изменится в сроке и объеме, если поменять одно требование;
- видно, кто и когда менял документ и какая версия действующая.
Требование «удобный функционал заказа» проверку не проходит: сдать его можно только через спор. Требование «покупатель видит статус заказа и может отменить заказ, пока его не передали в доставку» проверяется за минуту на демонстрации. Если по документу набирается несколько таких расплывчатых мест, его стоит вернуть аналитику с вопросами до подписания: правка текста сейчас дешевле переделки кода после старта.
Сколько стоит и сколько длится подготовка ТЗ
Объективного способа точно оценить цену и срок ТЗ заранее нет. Глубина документа становится ясна, когда по нему начинают работать. Возьмем одну интеграцию с внешней системой. В одном ТЗ она занимает строку «есть интеграция с платежной системой», дальше разработчики решают сами. В другом к строке приложена спецификация с готовым контрактом API конкретной выбранной платежной системы: какие данные уходят, в каком формате, что делать при ошибке. Оба документа называются ТЗ, а трудоемкость у них разная.
Публичных цен на подготовку ТЗ немного. По нашему опыту, системная аналитика требует примерно в пять раз меньше часов, чем разработка, около 20%. Поэтому исполнители часто сначала прикидывают грубое значение стоимости всей системы, как они ее понимают, и за ТЗ называют в среднем 20% от этой суммы.
По календарю доля аналитики выше: около четверти срока проекта, изредка ближе к трети. Аналитик на проекте обычно один, и его работу не раздать нескольким людям. Разработку делят между разработчиками и ведут параллельно.
По часам аналитика примерно в пять раз меньше разработки, по календарю занимает около четверти срока: аналитик обычно один, а разработку делят между людьми
С ИИ-агентами треть календарного срока на аналитику маловероятна: агенты ускоряют саму аналитику. При разработке от спецификации черновики требований, сценариев и прототипов собираются быстрее, а по разрозненным документам проще искать и сводить информацию воедино. Даже без агентов по каждой видеовстрече теперь сразу есть краткое изложение, а раньше записи разбирали вручную. Аналитик меньше упирается в собственную пропускную способность.
Что двигает объем работы:
- интеграции и их тип: подключить облачный сервис с открытой документацией проще, чем корпоративную систему или старую базу без описания;
- число групп пользователей и различия в их правах;
- тип системы: корпоративный бэк-офис для сотрудников описывать дольше, чем клиентский сервис;
- комплаенс: требования регуляторов и нормы отрасли добавляют вопросы к эксперту и проверки в каждом требовании.
Перед запросом цены полезно собрать для подрядчика список систем, с которыми новая будет обмениваться данными, группы пользователей и отраслевые нормы. По ним оценка получится точнее.
Кто может выполнять работу аналитика
Функции аналитика в компании может взять на себя не только аналитик. Встречаются три варианта:
- требования собирают разработчики: так работают небольшие команды, где системный архитектор сам говорит с заказчиком и записывает договоренности;
- требования пишет бизнес-аналитик, если система простая, а основная сложность в процессах компании;
- в проекте есть отдельный системный аналитик, когда у системы много сущностей, ролей и интеграций и разработчикам нельзя додумывать поведение.
В стартапах и малых командах функции бизнес-аналитика выполняет менеджер продукта, а функции системного аналитика выполняют старшие разработчики, и это нормальная практика.
Отдельный аналитик не нужен и тогда, когда главный риск проекта лежит в технике. Бизнес-логика бывает простой, а неясно другое: выдержит ли интеграция нагрузку, заработает ли выбранная библиотека. Такой вопрос решает быстрый эксперимент, проверка концепции. Подробное ТЗ на систему, которая может технически не заработать, пишут после проверки.
Если отдельная роль нужна, ее организуют одним из способов: нанимают аналитика в штат, отдают этап аналитики подрядчику или берут специалиста в свою команду на время проекта. Подготовка документации требует времени и опыта, и штатный аналитический отдел окупается, когда компания регулярно запускает новые системы и аналитику есть чем заниматься между проектами. При разовом проекте подрядчик сдает этап документом, и дальше компания сама решает, кому отдать разработку.
Штатный системный аналитик оправдан в крупных компаниях с большим ИТ-контуром и в сервисных компаниях, которые выполняют проекты на заказ. В остальных случаях системную аналитику выгоднее заказывать на этап.
Когда аналитика берут в свою команду на этап
Третий вариант подходит компании, у которой есть своя команда разработки и человек, который ею управляет, а системного аналитика в штате нет или он занят на другом проекте. Специалиста подключают на время проекта, после завершения работ он уходит. Такой формат называют аутстаффингом.
Роль дорогая. По данным Хабр Карьеры, опубликованным в июле 2026 года, медианная зарплата системного аналитика 222 тысячи рублей в месяц, бизнес-аналитика 176 тысяч. Медиана по всему ИТ за первое полугодие 2026 года, по исследованию той же площадки, 191 тысяча. Нанять системного аналитика в штат ради одного проекта значит взять постоянную строку расходов под временную задачу. Довод за подключение на этап связан со временем. Аналитик нужен, пока собирают и меняют требования, а после этапа работы для него в штате мало.
Подключать специалиста имеет смысл, когда у компании есть ядро команды, которое примет его результат и продолжит работу. Если своей разработки нет, аналитику некому передать документ, и логичнее отдать подрядчику этап целиком.
Что меняется с ИИ-агентами
ИИ-агенты пишут код по описанию задачи, и качество кода теперь прямо зависит от качества описания. Агент не переспрашивает, как переспросил бы разработчик на встрече: недосказанное он додумывает. Поэтому требования сейчас значат больше, чем до агентов.
Под эту задачу появился подход SDD, Spec-Driven Development, или разработка от спецификации. Требования ведут как машиночитаемую спецификацию в репозитории проекта, рядом с кодом. Каждое изменение требования видно в истории версий, и агенты пишут и проверяют код по этой спецификации. Документ перестает устаревать незаметно: расхождение между требованием и кодом видно в репозитории.
Мы применяем SDD с этапа аналитики. Агенты проверяют спецификацию на неоднозначности, пропуски и противоречия, а отвечает за требования аналитик. Агент находит место, где два требования спорят друг с другом, но решить, какое из них верно для бизнеса, может только человек, который говорил с экспертом заказчика. ИИ усиливает аналитика, и роль остается.
Роль аналитика чаще всего видна на прототипах. Сотрудник собирает прототип с ИИ-агентом за выходные, идея подтверждается, но нагрузку, данные и безопасность прототип не выдерживает. Чтобы довести его до промышленной эксплуатации, систему сначала описывают спецификацией, и работа аналитика начинается с того, что уже собрано.
Что заложить перед стартом проекта
Системная аналитика нужна бизнесу, чтобы договориться о системе до того, как за нее заплатят разработчикам. Теперь понятно, какой документ на какой вопрос отвечает, кто его пишет и что проверить перед подписью. Чаще всего на старте недооценивают время своих людей. Эксперта предметной области назначают до договора и ставят ему часы в календаре, иначе аналитик заполняет пробелы догадками.
Практическая тонкость перед выбором подрядчика: попросить показать фрагмент ТЗ с прошлого проекта без имени клиента. По одной странице видно, есть ли у требований критерии приемки и как аналитик описывает исключения: отмену заказа, ошибку интеграции, пустой склад.
