Составление технического задания (ТЗ) на разработку электроники — это первый и самый критичный этап проекта. Ошибки на этой стадии подобны неправильному фундаменту: они приводят к лавинообразному росту затрат, срыву сроков и, в худшем случае, к полному провалу. Мы в конструкторском бюро «Проект Будущего» на основе сотен проектов выделили ключевые ошибки заказчиков и рассказываем, как их избежать.
1. «Хотелки» вместо измеримых требований
Ошибка: Формулировки типа «должно быть современным», «надёжным», «энергоэффективным» или «удобным».
- Почему это плохо: Эти понятия субъективны. «Надёжно» для одного — это 1000 часов наработки на отказ, для другого — 10 000. Исполнитель не может проверить или доказать соответствие таким требованиям.
- Как правильно: Использовать SMART-критерии. Каждое требование должно быть:
Конкретным: Не «энергоэффективное», а «потребление в дежурном режиме ≤ 0.5 Вт».
Измеримым: Не «быстрое», а «время отклика на событие ≤ 10 мс».
Достижимым: С учётом бюджета, сроков и физических законов.
Релевантным: Не «сделать Bluetooth», если устройство будет работать в Faraday cage.
Ограниченным по времени: Определить, когда требование проверяется.
2. Игнорирование среды эксплуатации
Ошибка: Полное описание функционала, но молчание о том, где и как устройство будет работать.
- Почему это плохо: Электроника для отапливаемого офиса и для неотапливаемого цеха в Сибири — это два разных устройства. Неучтённые условия приведут к мгновенному выходу из строя.
- Как правильно: В ТЗ должен быть обязательный раздел «Условия эксплуатации»:
Температурный диапазон (рабочий и для хранения).
Влажность.
Защита от пыли и влаги (степень IP).
Уровень вибраций, ударов.
Качество питающей сети (диапазон напряжений, наличие помех).
Наличие химически агрессивных сред.
3. Фокус на «что», а не «как» (микроменеджмент на этапе ТЗ)
Ошибка: Заказчик, пытаясь обезопасить себя, предписывает в ТЗ конкретные элементные базы, архитектуру микроконтроллера или топологию печатной платы.
- Почему это плохо: Вы нанимаете инженеров за их экспертизу. Диктуя конкретные решения, вы берете на себя технические риски и лишаете команду возможности найти более оптимальный, дешёвый или надёжный путь для достижения вашей цели.
- Как правильно: В ТЗ описывать требуемые функции, характеристики и интерфейсы. Дать свободу выбора средств реализации исполнителю. Оговорить, что итоговые решения (с обоснованием) согласуются в отчётной документации (Эскизном проекте).
4. Отсутствие приоритизации требований
Ошибка: Все требования в ТЗ представлены как равнозначные и обязательные.
- Почему это плохо: В реальности при жестких ограничениях по бюджету или срокам приходится чем-то жертвовать. Без ясной иерархии спор о том, чем жертвовать, приведет к конфликту.
- Как правильно: Ввести классификацию требований:
Must have (Критичные): Без этого устройство не работает или не принимается.
Should have (Важные): Существенно повышают ценность, но система может работать без них временно.
Could have (Желательные): Улучшения, которые можно отложить на следующую версию.
Won't have (Не входит в scope): Чёткое обозначение границ проекта.
5. Молчание о вопросах сертификации и стандартов
Ошибка: Предположение, что разработчик «и так знает».
- Почему это плохо: Требования FCC, CE, РЭС (Роскомнадзор), ГОСТ, ТР ТС/ЕАЭС, медицинских или взрывозащитных стандартов (ATEX, IECEx) кардинально влияют на архитектуру, схемотехнику и стоимость.
- Как правильно: Чётко прописать в ТЗ:
Целевые страны рынка сбыта.
Необходимые стандарты и классы соответствия.
Планы по дальнейшей сертификации (силами кого и когда).
6. Нереалистичные бюджеты и сроки «с потолка»
Ошибка: «Нам нужно через два месяца за 500 тысяч».
- Почему это плохо: Заниженные бюджет и сроки заставляют исполнителя либо отказываться от проекта, либо изначально закладывать компромиссы в ущерб качеству и надёжности.
- Как правильно: Составлять ТЗ параллельно с предварительным обсуждением реалистичных ориентиров с исполнителем. Профессиональное КБ после анализа требований может дать оценку в формате «от и до».
7. Игнорирование жизненного цикла изделия
Ошибка: ТЗ фокусируется только на этапе разработки и сдачи опытного образца.
- Почему это плохо: После получения рабочего прототипа встают вопросы серийного производства, ремонтопригодности, обновления ПО, логистики компонентов.
- Как правильно: Заложить требования на перспективу:
Ремонтопригодность: Наличие тестовых точек, модульность конструкции.
Доступность компонентов: Требование об использовании элементов с долгосрочной доступностью (not EOL).
Документация для производства: Какой пакет документов нужен для передачи на завод (Gerber, BOM, прошивка).
Чек-лист: Идеальное ТЗ должно давать ответы на эти вопросы
Прежде чем передавать ТЗ исполнителю, проверьте, есть ли в нём ясные ответы на этот список:
- Что делает устройство? (Функции, сценарии использования).
- В каких условиях? (Температура, влажность, вибрация, питание).
- С кем/чем общается? (Интерфейсы, протоколы, скорости).
- Какую мощность потребляет? (В разных режимах).
- Какие размеры и вес?
- Как и кем обслуживается? (Возможность апгрейда, перепрошивки).
- Как проверяется, что всё работает? (Методы и средства испытаний).
- Куда идёт продукт? (Требования по сертификации).
- Что важнее всего? (Приоритеты: стоимость, сроки, функциональность, надёжность).
- Что точно НЕ нужно делать? (Ограничения проекта).
Заключение
Хорошее ТЗ — это не перечень пожеланий, а контракт, написанный на языке технических требований. Его цель — обеспечить полное и однозначное взаимопонимание между заказчиком и исполнителем. Потратив дополнительное время на проработку ТЗ, вы сэкономите месяцы и миллионы на этапах разработки, прототипирования и внедрения.
Помните: Исполнитель, получивший чёткое и полное ТЗ, становится вашим техническим партнёром. Исполнитель, получивший сырое ТЗ, вынужден стать вашим оппонентом в спорах о том, «что же вы на самом деле хотели». Выбор за вами.