Функциональное ТЗ vs Техническое задание

Коротко: Функциональное ТЗ (ФТТ) описывает, что именно должен делать продукт для решения задач бизнеса (роли, сценарии, цели). Техническое задание (ТЗ) детализирует, как это реализовать на уровне программного кода, архитектуры и стандартов. Разница между ними в том, что ФТТ говорит «что» нужно, а ТЗ - «как» это будет работать технически.

Кстати, в AmSales мы делаем внедрение и настройку Битрикс24 и разработку сайтов под ключ под ключ. Если нужна помощь - напишите нам.

Функциональное ТЗ: требования со стороны бизнеса

Когда собственник или руководитель отдела продаж заказывает разработку нового модуля для CRM, он не думает о базах данных или API. Он думает о том, чтобы менеджер перестал забывать перезванивать клиентам. Именно здесь рождается функциональное ТЗ. Это документ, который переводит язык бизнес-процессов на язык логики, понятный проектировщикам. Он фиксирует функции, роли пользователей и сценарии взаимодействия с системой.

В ФТТ важно прописать не просто «нужна кнопка отчет», а конкретный сценарий. Например: «Маркетолог должен иметь возможность выгрузить список всех лидов, пришедших из рекламных каналов за последние 30 дней, с фильтрацией по региону». Здесь нет ни слова о том, на каком языке написан бэкенд или какая структура у таблицы в SQL. Есть только потребность и ожидаемый результат.

Ключевые элементы функциональных требований

Чтобы составить требования к разработке ПО на уровне бизнеса, нужно сфокусироваться на трех составляющих. Во-первых, это пользовательские роли. Кто будет работать с системой? У администратора, РОПа и обычного менеджера должны быть разные права и разные наборы функций. Во-вторых, это бизнес-цели. Зачем мы это делаем? Если цель - сократить время обработки заявки, то функционал должен быть направлен именно на ускорение ввода данных.

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

На практике ФТТ часто превращается в набор разрозненных хотелок. Чтобы этого избежать, требования нужно группировать по процессам. Например, блок «Работа с входящим трафиком», блок «Обработка заказа», блок «Постпродажное обслуживание». Такой подход позволяет увидеть пробелы в логике еще до того, как программисты напишут первую строчку кода. Это экономит недели обсуждений в будущем.

Техническое задание: стандарты и реализация ПО

Если ФТТ - это мечта о продукте, то ТЗ - это его чертеж. Техническое задание берет функциональные требования и превращает их в набор инструкций для инженеров. Здесь уже не говорят «удобный поиск», здесь пишут «индексация базы данных должна обеспечивать выдачу результата по запросу не более чем за 200 мс при объеме данных в 1 млн записей».

ТЗ определяет архитектуру, протоколы передачи данных, требования к безопасности и нагрузки. Это документ, который защищает заказчика при приемке работ. Если в ТЗ указано, что система должна выдерживать 500 одновременных сессий, а она «падает» при 100, у заказчика есть юридическое основание требовать исправления без доплаты. В этом и заключается главная разница между ФТТ и ТЗ в разработке: одно отвечает за пользу, другое - за работоспособность и соответствие спецификациям.

Из чего состоит технический документ

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

Важно разделять технические требования и функциональные. Функциональные требования к программному обеспечению отвечают на вопрос «что делает программа?», а технические - «как она это делает?». К техническим относятся производительность, масштабируемость, отказоустойчивость и требования к среде исполнения (например, поддержка конкретной версии ОС или браузера). Без четкого ТЗ проект рискует превратиться в «черный ящик», где заказчик не понимает, за что именно он платит деньги.

В современных реалиях, когда многие работают по Agile, полноценное ТЗ по всем канонам может не писаться на каждый мелкий спринт. Однако для крупных систем, интеграций или государственных контрактов без него не обойтись. Это страховка от ситуации, когда разработчик реализовал функцию, которая работает быстро, но совершенно не так, как того требовал бизнес-процесс.

Различия между ФТТ и ТЗ в разработке

Многие путают эти понятия, считая, что достаточно написать «хотелки» в письме и отдать их в разработку. Это кратчайший путь к раздутому бюджету и сорванным срокам. Чтобы не ошибиться, нужно четко понимать, чем отличается функциональное ТЗ от технического задания. Основное различие лежит в плоскости ответственности и уровня абстракции.

ФТТ - это ответственность бизнес-аналитика, продакт-менеджера или самого заказчика. Его задача - описать ценность. ТЗ - это ответственность системного аналитика или архитектора, который переводит ценность на язык алгоритмов. Если в ФТТ написано «система должна уметь распознавать клиентов по номеру телефона», то в ТЗ будет написано, через какой API сервис будет обращаться к базе данных телефонии и какой формат ответа должен приходить в систему.

Еще одно различие - это критерии приемки. В ФТТ критерием является выполнение задачи: «Менеджер смог выгрузить отчет». В ТЗ критерием является технический параметр: «Время выполнения запроса не превышает 2 секунд, потребление памяти не более 512 МБ». Если вы пытаетесь использовать ФТТ как ТЗ, вы не сможете объективно оценить качество работы кода. Если вы используете ТЗ как ФТТ, вы не сможете объяснить разработчикам, зачем вообще нужна эта функция.

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

Применение ГОСТ 19.201-78 и ГОСТ 34.602-2020

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

Если вы разрабатываете конкретный программный продукт (например, мобильное приложение или отдельный сервис), основным ориентиром является ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению». Этот стандарт задает жесткую структуру: введение, основания для разработки, назначение, требования, стадии и этапы, контроль и приемка. Он идеально подходит для описания программного изделия как самостоятельной единицы.

Однако, если ваша задача масштабнее - например, внедрение комплексной автоматизированной системы управления предприятием (АСУ П), где задействовано оборудование, сети и десятки программных модулей, - следует ориентироваться на ГОСТ 34.602-2020. Этот стандарт предназначен для создания автоматизированных систем (АС) и гораздо глубже прорабатывает вопросы взаимодействия различных компонентов системы между собой.

Нюансы работы с документацией

Важно не пытаться «впихнуть» всё в один документ. Современный подход, подтвержденный актуальными данными, разделяет документацию. Например, ГОСТ 19.101-2024 дополняет систему, указывая на необходимость разделения ТЗ на разработку самой программы и сопутствующую документацию. Это значит, что вы можете составить ТЗ на софт, но отдельно прописать требования к инструкциям для пользователей или регламентам обслуживания.

Частая ошибка - пытаться следовать ГОСТу в коммерческом стартапе, где нужно выкатить MVP за месяц. В таких случаях стандарты используются как каркас для логики, а не как жесткая форма. Вы можете не соблюдать правила оформления заголовков, но вы обязаны соблюдать логику разделов: что делаем, как проверяем, какие условия выполнения. Стандарты - это не оковы, а проверенные десятилетиями способы не забыть про критически важные детали, такие как требования к безопасности или порядок приемки работ.

Связка ФТТ и ТЗ в современных проектах

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

Связка работает по цепочке: Бизнес-цель -> Функциональные требования (ФТТ) -> Технические требования (ТЗ) -> Спецификации (API, схемы БД). Если вы пропустите этап ФТТ, разработчики начнут гадать, как именно должен работать процесс. Если пропустите ТЗ, вы получите систему, которая выполняет функции, но работает нестабильно или не может масштабироваться при росте компании.

1. Шаг 1: Сбор требований. Интервью с пользователями, описание текущих проблем и желаемых сценариев. Результат - черновик ФТТ.
2. Шаг 2: Валидация. Бизнес-заказчик подтверждает, что описанные функции решают его задачи.
3. Шаг 3: Декомпозиция. Системный аналитик берет функции из ФТТ и расписывает их технически: какие таблицы в БД нужны, какие эндпоинты создать, какие интеграции подключить.
4. Шаг 4: Утверждение ТЗ. Разработчики подтверждают, что предложенная реализация технически возможна и укладывается в бюджет/сроки.

Такая последовательность позволяет обнаружить конфликты на ранних стадиях. Например, в ФТТ может быть требование «мгновенная синхронизация данных с 1С», а при составлении ТЗ выясняется, что API старой версии 1С позволяет делать запросы только раз в 10 минут. Если бы вы не сделали связку документов, вы бы узнали об этом только в момент тестирования, когда бюджет уже потрачен, а сроки сорваны.

Типичные ошибки при постановке задач разработчикам

Ошибки в документации стоят дорого. Самая распространенная - это использование субъективных прилагательных. Слова «быстрый», «удобный», «интуитивно понятный», «масштабируемый» не несут никакой технической информации. Для разработчика «быстрый поиск» может означать выдачу за 5 секунд, а для бизнеса это неприемлемо. Всегда заменяйте прилагательные на цифры и конкретные условия.

Вторая ошибка - отсутствие негативных сценариев. Большинство заказчиков описывают «счастливый путь» (happy path): как пользователь вводит правильные данные и получает результат. Но в реальности система должна знать, что делать, если интернет пропал, если пользователь ввел буквы вместо цифр или если сервер перегружен. Если в ТЗ не прописаны обработки ошибок, разработчики сделают их «на свое усмотрение», и результат вам вряд ли понравится.

Другие критические промахи

Третья проблема - разрыв между функционалом и реальностью. Это когда в требованиях прописано огромное количество функций, но не учтены технические ограничения текущей инфраструктуры. Например, вы хотите внедрить сложную аналитику на базе AI, но ваши текущие серверы не обладают нужной мощностью, а данные в CRM хранятся в хаотичном виде. Попытка реализовать ФТТ без учета технического контекста ведет к бесконечному переписыванию кода.

Четвертая ошибка - отсутствие критериев приемки. Если в задаче не написано, как именно мы поймем, что она выполнена, вы никогда не закончите проект. Разработчик скажет: «Я сделал, как просили», а вы скажете: «Это не то, что я имел в виду». Каждый пункт требований должен иметь измеримый результат. Не «интеграция с телефонией», а «при входящем звонке в карточке сделки CRM автоматически отображается контакт клиента и история последних 5 звонков».

Как не переплатить за лишний функционал

Раздутое ТЗ - это не всегда признак хорошей работы. Иногда избыточное стремление предусмотреть всё на свете приводит к тому, что вы платите за функции, которыми никто никогда не будет пользоваться. Это называется «золочением» продукта. Чтобы этого избежать, нужно уметь отделять обязательные требования от желаемых.

Используйте метод приоритизации, например, MoSCoW. Разделите все требования из вашего ФТТ на четыре категории: Must have (обязательно должно быть), Should have (важно, но не критично), Could have (было бы неплохо, если останется время), Won't have (не в этот раз). Это позволит вам четко видеть границы бюджета. Если бюджет ограничен, вы в первую очередь вычеркиваете категорию Could have, а не начинаете экономить на качестве реализации Must have.

Еще один способ сэкономить - это поэтапная разработка. Вместо того чтобы сразу писать огромное ТЗ на систему мечты, составьте ТЗ на минимально жизнеспособный продукт (MVP). Реализуйте базовый функционал, проверьте, как он работает в реальных условиях, и только потом добавляйте новые модули. Это защитит вас от ситуации, когда вы потратили миллионы на функционал, который оказался неудобным для сотрудников или не нужен рынку.

Наконец, всегда закладывайте время на уточнение ТЗ. Если подрядчик сразу называет фиксированную и очень низкую цену на основе краткого описания - это тревожный звонок. Скорее всего, он не до конца понял объем работ и заложит все риски в стоимость «доработок» в процессе. Качественное ТЗ требует времени на обсуждение, и этот этап - самая выгодная инвестиция в итоговую стоимость проекта.

Что запомнить:

• ФТТ описывает потребности бизнеса (ЧТО), а ТЗ - техническую реализацию (КАК).
• Для программных изделий используйте ГОСТ 19.201-78, для сложных автоматизированных систем - ГОСТ 34.602-2020.
• Никогда не используйте субъективные слова (быстрый, удобный) - только цифры и конкретные сценарии.
• Всегда прописывайте негативные сценарии (обработку ошибок), а не только идеальный путь пользователя.
• Приоритизируйте требования, чтобы не платить за функции, которые не приносят прибыли.