# Техническое задание на разработку — как составить пошагово Плохое ТЗ обходится дороже, чем его отсутствие. При отсутствии документа обе стороны понимают, что договариваться придётся по ходу дела. При плохом ТЗ обе стороны уверены, что уже договорились, — и выясняют обратное на приёмке, когда бюджет израсходован. Я писал технические задания на разработку электроники, на веб-инструменты, на финансовые модели и на инжиниринговые расчёты, и разница между работающим и неработающим документом всегда сводилась к одному разделу — критериям приёмки. ## Спорный вопрос: нужно ли вообще ТЗ Марти Каган ещё в середине двухтысячных писал, что классический PRD устарел, и рекомендовал вместо пятидесятистраничного документа делать прототип, проверять его на пользователях и уже прототип передавать инженерам как основу спецификации. Для цифрового продукта с собственной командой это справедливо: прототип проверяем, а текст — нет. В промышленном B2B ситуация другая по двум причинам. Первая: значительная часть разработки делается внешним подрядчиком по договору, и документ здесь выполняет ещё и юридическую функцию — он определяет, что считается выполненной работой. Вторая: у железа, оснастки и расчётных моделей нет дешёвого прототипа, который можно показать за два дня. Поэтому я работаю в смешанном режиме. Там, где прототип возможен и дёшев (интерфейс, калькулятор, форма), он делается первым и становится частью задания. Там, где нет, текст остаётся единственным носителем договорённости — и тогда к нему предъявляются повышенные требования по проверяемости. ## Шаг 1. Сначала анкета заказчику, потом ТЗ Главная ошибка — садиться писать задание сразу. Требования у заказчика в голове существуют не в том виде, в котором их можно записать: он знает свою проблему, но не знает, какие решения возможны и какие параметры критичны. Поэтому первым инструментом идёт не ТЗ, а структурированный опросник. Для приёма заказов на разработку электроники мы делали именно так: сначала анкета технических требований, которую заказчик заполняет сам или вместе с менеджером, и уже на её основе — техническое задание. Для веб-проектов работал тот же принцип: бриф с разделами о компании, продукте и задачах, заполняемый совместно с заказчиком. Что даёт анкета, чего не даёт разговор: одинаковый набор вопросов всем заказчикам, зафиксированные письменно ответы и видимые пробелы. Если поле «условия эксплуатации» пустое, это не мелочь, а незакрытый риск, который всплывёт при испытаниях. Побочный эффект оказался коммерческим. Шаблон ТЗ на разработку электроники стал базовым инструментом продаж для всех страновых направлений продукта: заполненная анкета — это уже квалификация лида, оценка сложности и повод для следующего разговора. Заказчик, потративший час на подробную анкету, вовлечён гораздо сильнее, чем тот, кто просто получил прайс. ## Шаг 2. Описать назначение и границы Первый содержательный раздел отвечает на два вопроса: что продукт делает и чего он не делает. Второй важнее. Раздел о назначении — это несколько абзацев без технических терминов: какую задачу решает изделие или инструмент, кто им пользуется, в каких условиях, как выглядит типовой сценарий работы. Он нужен, чтобы разработчик понимал смысл требований и мог предложить лучшее решение, а не буквально исполнить неудачную формулировку. Раздел о границах — это явный список того, что в объём работ не входит. Интеграции, которые не делаются. Режимы, которые не поддерживаются. Сертификация, которая остаётся на заказчике. Данные, которые заказчик предоставляет сам. Практика показывает: половина конфликтов на приёмке — это не спор о качестве, а спор о том, входило ли что-то в задание. Список исключений закрывает этот спор заранее. ## Шаг 3. Формулировать требования через сценарии, а не через список функций Список функций легко пишется и плохо проверяется. «Система должна поддерживать экспорт данных» — это не требование, потому что непонятно, каких данных, в каком формате и что считается успехом. Сценарий устроен иначе: кто, в какой ситуации, что делает, что получает на выходе. «Менеджер загружает спецификацию заказчика в формате XLSX, система сопоставляет позиции со справочником номенклатуры и формирует расчёт стоимости; позиции, которых нет в справочнике, выводятся отдельным списком для ручной обработки». Такое требование можно проверить, оценить по трудоёмкости и превратить в тест. Для расчётных задач тот же принцип работает через входы и выходы. В едином шаблоне ТЗ на финансовые модели мы фиксировали, какие исходные данные подаются, какие показатели должны получиться на выходе, с какой детализацией и в каком горизонте — иначе каждая модель приходила в своей структуре и не сравнивалась с остальными. ## Шаг 4. Написать критерии приёмки — раздел, ради которого всё затевается Это место, где хорошее ТЗ отличается от плохого. Критерий приёмки — измеримое утверждение, про которое обе стороны в момент проверки согласятся, выполнено оно или нет. Проверка простая: можно ли по этой формулировке провести испытание и получить однозначный результат. «Устройство должно работать стабильно» — нельзя. «Устройство сохраняет заявленные параметры при непрерывной работе 72 часа в диапазоне температур от минус 20 до плюс 50 градусов, отклонение выходного напряжения не более 2%» — можно. В критерии приёмки должны попасть: функциональные проверки по каждому сценарию, количественные параметры с допусками, условия и методика испытаний, состав передаваемых материалов (исходники, документация, схемы, права), порядок и сроки устранения замечаний. Последний пункт забывают чаще всего, и именно он определяет, чем закончится проект: без описанного цикла доработок приёмка превращается в бесконечную переписку. ## Шаг 5. Зафиксировать ограничения и эксплуатацию Раздел, который экономит больше всего денег и пишется небрежнее всего. Сюда входит среда работы — питание, температура, влажность, вибрация, для программных продуктов браузеры, нагрузка, объём данных. Внешние интерфейсы — с каким оборудованием и системами продукт взаимодействует и по каким протоколам. Нормативные требования — стандарты, сертификация, требования отраслевого заказчика. Ограничения по компонентам — доступность на рынке, происхождение, сроки поставки. Последнее в промышленности критично: изделие, спроектированное на компоненте с полугодовым сроком поставки, формально соответствует заданию и практически непроизводимо. Ограничение по доступности комплектующих должно быть требованием, а не открытием на этапе закупки. ## Шаг 6. Заранее описать порядок изменений Требования будут меняться — это не признак плохого планирования, а нормальное свойство разработки. Вопрос только в том, меняются ли они управляемо. Работающий механизм минимален: изменение оформляется письменно, оценивается подрядчиком по срокам и стоимости, подписывается обеими сторонами и становится приложением к заданию. Дальше — правило, которое стоит проговорить голосом: устная договорённость в переписке или на созвоне не меняет объём работ. Без этого правила ТЗ теряет силу к середине проекта, и стороны возвращаются к режиму «договоримся по ходу», ради выхода из которого документ и писался. ## Частые ошибки **Задание, написанное подрядчиком целиком.** Тогда оно описывает то, что подрядчику удобно сделать, а не то, что нужно заказчику. Подрядчик должен участвовать в проработке технической части, но назначение, границы и критерии приёмки формулирует заказчик. **Требования без приоритетов.** Если все пункты обязательны, при первом же сдвиге сроков резать будут наугад. Разделение на обязательное и желательное экономит проект. **Копирование чужого ТЗ целиком.** Шаблон нужен, но требования из другого проекта тянут за собой чужие ограничения, которые никто не перечитал. **Отсутствие единого шаблона в компании.** Когда каждое задание пишется с нуля, качество зависит от того, кто писал. Унифицированный шаблон с обязательными разделами выравнивает результат и одновременно ускоряет подготовку — по моему опыту, с нескольких дней до нескольких часов. ## Вывод Работающее техническое задание собирается в такой последовательности: анкета для сбора требований, затем назначение и явные границы, затем требования в виде проверяемых сценариев, затем критерии приёмки с методикой испытаний, ограничения по эксплуатации и компонентам и порядок внесения изменений. Проверить документ можно одним вопросом: сможет ли человек, не участвовавший в переговорах, провести приёмку по этому тексту и получить тот же результат, что и вы. Если нет — это не задание, а протокол о намерениях. ## Мои кейсы по теме - [[Шаблон ТЗ на разработку электроники]] - [[Анкета сбора требований на разработку]] - [[Шаблон брифа на веб-разработку]] - [[Единый шаблон ТЗ для финмоделей]] ## Связаться Если у вас похожая задача — обсудим ваш продукт: [[email protected]](mailto:[email protected]), Telegram [@falcolupus](https://t.me/falcolupus) или [MAX](https://max.ru/u/f9LHodD0cOJd5VFHyaG9k7YpP7BW9s55ZYkjWX6P8j51xBYS3XgDfnOxz3U). Работаю удалённо в любом часовом поясе.