Техническое задание для контрактной разработки: кто его пишет

Почему заказчик не может переложить техническое задание на подрядчика?

Техническое задание для контрактной разработки требует рыночной экспертизы, которой у контрактного разработчика физически нет, потому что он работает с разными проектами и отраслями, а заказчик десятилетиями специализируется на одном рынке. Ошибка возникает, когда заказчик рассчитывает, что подрядчик самостоятельно продумает бизнес-требования, сертификационные нормы и формат вывода продукта на рынок. По наблюдению Kedr Solutions, такая логика чаще встречается у компаний, впервые выходящих на рынок разработки электроники — например, у дистрибьюторов, привыкших работать с готовой продукцией, а не с формированием требований к ней. Формируйте бизнес- и сертификационные требования самостоятельно ещё до обращения к подрядчику.

Категории требований не закреплены жёстко — граница между зонами смещается в зависимости от продукта, рынка и степени регулирования. Реестровая медицинская продукция требует от заказчика глубокого понимания сертификационных процедур, тогда как для нерегулируемого потребительского устройства этот блок требований проще. Согласно техническому определению из стандарта ISO/IEC/IEEE 29148 (2018), инженерия требований включает элицитацию, анализ, специфицирование и валидацию — и элицитация бизнес-требований логически принадлежит той стороне, которая знает рынок. Уточняйте у подрядчика на старте проекта, какие категории требований смещаются в совместную зону для вашего конкретного продукта.

Какие требования формирует заказчик

Бизнес-требования — первая категория, которую заказчик прописывает самостоятельно, потому что именно он выстраивает коммерческую модель продукта. Речь идёт о понимании рынка, объёма спроса, конкурентов и клиентов — данных, которыми контрактный разработчик не владеет по определению. Продукт всегда остаётся собственностью заказчика: он выпускает его, продаёт и зарабатывает на нём в течение всего жизненного цикла. Формулируйте бизнес-требования как отдельный раздел технического задания до начала переговоров с подрядчиком.

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

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

Какие требования формирует подрядчик

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

Надёжность и ремонтопригодность продукта также определяет подрядчик, потому что эти параметры напрямую связаны с выбором компонентов, схемотехническими решениями и подходом к тестированию. Контрактный разработчик прогнозирует наработку на отказ, продумывает доступ к узлам для обслуживания и закладывает запас по электрическим параметрам компонентов. Доверяйте выбор конкретных инженерных решений для надёжности подрядчику, но фиксируйте в задании требуемый срок службы продукта.

Производственные аспекты — третья категория зоны подрядчика, включающая технологичность конструкции, доступность компонентов и совместимость с производственными линиями. По практике Kedr Solutions, на производственном этапе типично возникают вопросы замены компонентов из-за долгих сроков поставки — это рабочая ситуация, а не аварийный сбой проекта. Уточняйте у подрядчика ожидаемое число итераций прототипирования и производственные риски ещё на этапе оценки проекта.

Как строится совместная работа над техническим заданием?

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

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

Подробнее о других системных ошибках заказчиков в контрактной разработке — в статье 7 ошибок заказчиков при контрактной разработке электроники.

Пример: дистрибьютор, который переложил требования на подрядчика

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

Итог делегирования требований подрядчику — несостыковки, которые обнаруживаются уже в ходе проекта, а не на этапе планирования. Подрядчик реализует техническое решение исходя из своего понимания задачи, но без полноценных бизнес-требований это понимание неизбежно расходится с ожиданиями заказчика. По практике Kedr Solutions, такие расхождения приводят к дополнительным итерациям и пересмотру уже согласованных решений, что увеличивает бюджет и сроки проекта. Формулируйте продуктовое видение и требования клиентов на своей стороне независимо от опыта работы с разработкой.

Что делать, если готового технического задания нет?

Отсутствие готового технического задания — не исключение, а типичная ситуация: по статистике Kedr Solutions, у 70% заказчиков нет полноценного документа на момент обращения к подрядчику. Это не считается критической проблемой, если заказчик готов участвовать в формировании требований вместе с подрядчиком. В компании Kedr Solutions для таких случаев работают аналитики и технические специалисты, которые собирают требования через структурированный опросник и серию интервью с заказчиком. Обращайтесь к подрядчику даже без готового документа — отсутствие технического задания не блокирует старт проекта.

Опросник для сбора требований состоит из наводящих вопросов, которые помогают заказчику сформулировать то, что он интуитивно понимает, но не успел зафиксировать в документе. Специалисты Kedr Solutions заполняют опросник совместно с заказчиком онлайн или отправляют его для самостоятельного заполнения, после чего уточняют детали в диалоге. Итогом становится полноценное техническое задание, на основе которого можно декомпозировать работу и сделать детальную оценку проекта. Если у вас нет готового документа, планируйте на старте проекта отдельный этап согласования требований вместе с подрядчиком, а не пытайтесь составить его в одиночку.

О том, как валидировать продукт до старта полноценной разработки, — в статье MVP в разработке электроники, а о работе с технической неопределённостью проекта — в материале R&D и НИОКР в контрактной разработке электроники. Общие принципы формирования и согласования требований описаны в справочнике INCOSE Systems Engineering Handbook.