Продолжаем цикл статей о разработке hardware-продуктов. В предыдущих материалах мы рассматривали этапы создания хардверного устройства, выбор производства и производственный цикл. Однако ни один продукт не может быть успешно осуществлен без тщательной подготовки технического задания.
Информации по этой теме предостаточно, но многие все еще не уделяют должного внимания этому этапу и его влиянию на конечный результат проекта. В данной статье мы рассмотрим подробный план создания технического задания.
Техническое задание (далее ТЗ) является фундаментом дальнейших успешных работ: сокращает их сроки, снижает риски и позволяет эффективно общаться заказчику и исполнителю еще до того, как та или иная сторона приняла на себя какие-либо обязательства по проекту.
Этот документ идеально подходит для того, чтобы заказчик понял всю важность и сложность задачи, и за что он платит деньги.
Что такое ТЗ
Формально, ГОСТ дает определение документу «Техническое задание», но оно, как правило, кажется абстрактным и понятным лишь специалистам, работающим с ЕСКД (Единой Системой Конструкторской Документации) . Нам же важно понять суть ТЗ.
Суть состоит в том, чтобы установить общее понимание между заказчиком и исполнителем. Это как коммуникационный мостик между бытовым описанием идеи и глубоко техническими деталями, которыми зачастую не владеет заказчик.
Техническое задание — это документ, который описывает вид будущего продукта и должен быть понятен как заказчику, так и исполнителю, независимо от их технического уровня.
Формальность или необходимость
Чтобы заказчик и исполнитель успешно сотрудничали, нужно общаться и четко ставить задачи для достижения желаемого результата. Внутри одной команды ТЗ не всегда обязательно, но при работе с внешним исполнителем оно становится необходимым для разрешения возможных разногласий. Формальность ТЗ зависит от удобства взаимодействия, но если его отсутствие может причинить больший вред, чем его наличие, то лучше его создать.
Можно ли написать ТЗ за час
Быстро и легко это не получится. Можно добиться результатов, если уделить немного больше времени и сконцентрироваться.
Если мы понимаем, что ТЗ необходимо для правильного общения и взаимопонимания в работе, то за один час можно сделать что-то поверхностное или использовать готовый шаблон. Ради будущего успеха стоит уделить больше внимания подготовке.
Для написания нужно собрать:
- рыночную информацию,
- проанализировать решения,
- оценить вложения,
- правильно сформулировать требования,
- выявить конфликтные или противоречащие требования,
- проконсультироваться с экспертами и провести другие действия.
Это позволит сократить общую стоимость проекта в будущем, где каждый день простоя обходится заказчику дорого.
Разница в составлении ТЗ для производства в РФ и Китае
Вашим партнером может быть не только российский инженер, но и предприятия из Китая, Евросоюза, США и других стран, которые также оценивают ваше ТЗ через исполнителя.
Здесь важно знать не только правила по ГОСТ, но и нормы общения по ISO, который является одним из наиболее распространенных стандартов управления качеством.
Если ваше ТЗ соответствует блокам и описаниям в соответствии с нормами ISO, это значительно ускорит согласование работ с компаниями из других стран.
Всем известны примеры «заказал в Китае машину, привезли вертолет и напильник». И это в основном не из-за желания китайских компаний обмануть вас. Хотя и такие примеры есть, но не чаще, чем в любой другой стране. Связано это именно с ментальностью и прочтением документа.
Например, вы никогда не получите точного «нет» на любое пожелание в ТЗ от китайских производств. Но зато вы рискуете получить их интерпретацию того, как, по их мнению, можно достичь результат по ТЗ. В 90% случаях ваше представление о желаемом результате будет отличаться от того, что предложит китайский исполнитель.
Аналогично для США и для ЕС. Правила работы с лицензиями в этих странах проработаны детальнее, чем в России и Китае, и будут подразумевать дополнительную оплату, если в ТЗ содержатся конкретные технологические требования.
От ясности всем участникам и соответствия ТЗ базовым правилам оформления по ISO будет зависеть простота общения и оценочная стоимость будущих работ. Это не означает наличие аккредитации по ISO для усложнения себе работы, а просто иметь ввиду, что ISO – это сборник вековых отработанных правил, которые работают. И почему бы не упростить себе работу в этом вопросе.
В рамках ISO/ГОСТ/ЕСКД документы для любой страны одинаковые, потому что это стандарт. Но важно учитывать, что различия в менталитете могут привести к разным трактовкам одних и тех же документов. Это уже зависит от опыта и понимания специфики.
Часто в описаниях стадий разработки и требований можно встретить аббревиатуры EVT (Engineering Validation Test)/ DVT (Design Validation Test)/ PVT (Production Validation Test). Необходимо учитывать, что эти описания относятся только к испытаниям изделия (EVT/DVT/PVT) и являются частью PAPP (Процесс утверждения производственных деталей). PAPP в свою очередь описывается стандартом IATF-16949 (бывший ISO-16949) и представляет собой упрощенную схему процесса утверждения производственных деталей в рамках всего процесса разработки.
Что касается нашего подхода, то при наличии требований от заказчика по оформлению ТЗ в соответствии с ЕСКД, сначала составляется русскоязычный документ. Поскольку в большинстве проектов, в которых мы участвуем, приходится иметь дело с иностранными производственными партнерами, ТЗ по ЕСКД переводится / переформатируется в Technical Requirement Document / Product Requirement Document (PRD) .
Большое количество слов не всегда помогает
Когда речь идет о техническом задании, важно определить, насколько понятно оно для всех. И тут возникает вопрос: какой язык лучше использовать?
Существуют основные принципы, которыми нужно руководствоваться при выборе слов и стиля:
- Простота. Использовать простые предложения и слова без двойных смыслов.
- Ясность. Стремление проявить грамотность с помощью «умных» слов и терминологии приводит к недопониманию. Используйте термины и слова, понятные для вас и читателю документа.
- Краткость. Если вам не хватает 5 слов, чтобы описать функцию или цель изделия, то, вероятно, это будет сложно понять вашему собеседнику.
Основные шаги при составлении ТЗ для hardware-продукта
Шаг 1. Определить Цели продукта
С самого начала рекомендуется четко сформулировать Цель продукта, которую необходимо достичь в ходе всех будущих работ.
Цель должна отвечать следующим критериям:
- Конкретность. Простой способ сделать цель конкретной — заменить все прилагательные в тексте существительными, цифрами, глаголами.
- Достижимость. Рекомендуется проверить и проконсультироваться относительно реалистичности вашего продукта.
Чем лучше вы понимаете степень достижимости, тем проще будет вести работу. Например, если ваша цель — достичь Луны, вы должны осознавать сложность запуска ракеты в космос. Или же собрать информацию о сложности, чтобы ТЗ было воспринято адекватно исполнителем.
Любые фантазии увеличивают цену работ по ТЗ.
- Ограниченность по времени. Понимание времени важно как для вас, так и для исполнителя, поскольку сроки могут значительно повлиять на стоимость работ.
Пример цели продукта: Разработать ноутбук. Срок выполнения: 16 месяцев.
Шаг 2. Описать продукт
Основной вопрос, стоящий перед заказчиком: как предоставить информацию о продукте в ТЗ, не раскрывая конфиденциальные данные. Вот несколько общих правил:
-
Не раскрывайте чувствительную конфиденциальную информацию до подписания соглашения о неразглашении.
- Помните, что соглашение о неразглашении не гарантирует полной конфиденциальности. Поэтому лучше избегать раскрытия каналов сбыта, партнеров, поставщиков и другой коммерчески важной информации.
Подходите к описанию продукта со всех сторон его использования. Если это ноутбук, то опишите его взаимодействие с пользователем (потребительские свойства), окружающей средой (экология и выбор материалов), с производством (технология производства) и даже с предметами окружающей среды, таким как упаковкой.
Различия ТЗ и техническое предложение
Около 95% полученных нами документов имеют системную ошибку — смешивание ТЗ и технического предложения. Зачастую заказчики включают в ТЗ требования использования конкретных компонентов. Для исполнителя это означает, что заказчик предварительно провел аудит рынка и оценил перспективы использования этих компонентов.
В таких случаях лучше прикрепить к ТЗ отдельное Техническое решение с полным описанием и критериями выбора. Если анализ не проводился, то лучше указывать границы допустимого и критерии выбора, а не конкретные компоненты, чтобы избежать долгого согласования.
С другой стороны, исполнитель не является частью бизнеса заказчика, и иногда есть необходимость применять конкретный компонент, конкретное решение для удовлетворения спроса на рынке. Скажем, Intel Inside или именно BLE 5.2, а не 4.2, USB Type-C и другие решения. В этом случае стоит указать эти требования в ТЗ или техническом предложении.
2.2. Описать функции продукта
Опишите все функции продукта, которые соответствуют его цели. Эти функции можно разделить на три основных блока:
- Потребительские функции. То, чем обладает продукт с точки зрения пользователя.
Например, ноутбук должен иметь клавиатуру для ввода информации или иметь аккумулятор емкостью 50 Вт·ч.
- Функции взаимодействия с окружающим миром.
Например, функция подключения стороннего мобильного устройства по технологии Wi-Fi.
- Функции администратора, которыми должно обладать изделие для работы с техническими специалистами.
Например, наличие панели администратора с функцией глубоких настроек.
2.3. Описать структуру продукта
Опишите структуру продукта, в которой функции должны выполняться правильно. Используйте блок схемы с комментариями, чтобы упростить понимание. Форма и вид диаграммы может быть любой, главное, чтобы это было наглядно и понятно для всех.
Глубина детализации зависит от вас: если вы обращаетесь за помощью, чтобы получить ответы на конкретные вопросы, дайте краткое описание каждого блока своими словами. Важно избегать сложной терминологии, чтобы не запутать и не усложнить понимание.
2.4. Сформулировать требования к надежности
Когда речь идет о надежности продукта, важно определить требования как для всего изделия, так и для его отдельных частей, если это необходимо. Существует несколько стандартов, которые помогут вам сформулировать требования:
- IK-код — классификация степеней защиты, обозначающая степень защиты корпуса прибора от механических повреждений, ударов и падений.
- IP-код классификация степеней защиты оболочки.
Первая цифра обозначает степень защиты от проникновения сторонних предметов. Вторая — степень защиты от проникновения воды.
Для примера. Знакомый многим IP68 означает, что продукт пыленепроницаемый (цифра 6) и способен работать под водой на глубине более 1 метра.
Существуют и другие стандарты надежности как для программного, так и для физического обеспечения продукта, и они выбираются в каждом конкретном случае.
Если вы не знакомы со стандартами, можно описать конкретные требования. Скажем, вместо IP68 написать «пыленепроницаемый и способен работать под водой без проникновения влаги».
2.5. Указать условия эксплуатации, транспортировки, хранения и обслуживания
В этом разделе необходимо указать будущему исполнителю, в каких условиях будет использоваться продукт, как его будут транспортировать, хранить, кто и каким образом будет обслуживать, если это предполагается.
Эти требования помогут понять сложность продукта. К примеру, длительное хранение при экстремальных температурах потребует специальных материалов, что может повысить стоимость разработки и производства.
Обычно указывают следующее, если это важно для продукта:
- Внешние факторы (температура, влажность, уровень шума, наличие солнечного света или его отсутствие, звуковые колебания, влияние животных и т.д.).
- Квалификация пользователя, то есть для кого предназначен продукт и какими знаниями он должен обладать для корректного использования.
- Требования к транспортировке (вид транспорта, температура, влажность, требования к упаковке, ориентации изделия в пространстве и т.д.).
- Условия хранения (температура, влажность, срок хранения).
- Условия обслуживания и ремонта продукта (гарантийные обязательства, квалификация специалиста для обслуживания).
Например, если LiCoO2-аккумуляторы (обычно используемые в телефонах) подвергнуты нарушению температурного режима в процессе транспортировки и хранения, они могут выйти из строя, возгореться или существенно потерять емкость.
2.6. Определить требование к патентной чистоте
Это важное требование для будущего успеха продукта. Патентная чистота и соответствующие требования позволят исполнителю понять, насколько сложные будут работы по ТЗ. Что влияет на сроки и стоимость проекта.
Для справки: получение патента на «Изобретение» может в несколько раз увеличить стоимость разработки по сравнению с патентом на «Полезную модель» или »Промышленный образец».
Например, Ложка с BLE — Полезная модель. Метод получение InGaN полупроводника для производства синих светодиодов — Изобретение.
Патент на «Изобретение» требует высокого уровня изобретательности, где изделие не должно быть очевидным результатом из уже существующих компонентов с известными функциями.
«Полезная модель» может быть комбинацией компонентов, которая позволяет улучшить результат или функцию.
«Промышленный образец» — это конкретный чертеж и исполнение серийного изделия, не защищающие принцип работы, а только конструкционные и дизайнерские решения.
Примеры типов патентов слева направо: Изобретение, Полезная модель, Промышленный образец
Хотя патентное оформление не является обязательным, вы можете не указывать требование к патентной чистоте, если в этом нет необходимости.
Надежный исполнитель проведет патентный поиск, чтобы предоставить вам техническое решение, не нарушающее патентных прав третьих лиц.
Шаг 3. Описать экономические требования к продукту
Если продукт разрабатывается с целью получения выгоды и выхода на рынок, заказчика и исполнителя будет интересовать прогнозируемая себестоимость его производства. Это не просто из любопытства, а потому, что необходимо оценить реализуемость всех требований в рамках установленных границ себестоимости, предложить оптимальные методы производства и компоненты, соответствующие требованиям.
В ТЗ указывается лишь верхняя граница или «начальная себестоимость» продукта, основанная на представлениях заказчика. Обычно рассчитывают стоимость продукта на полке, вычитая из неё расходы на поставщиков, посредников, доставку, обслуживание, а также учитывая срок окупаемости вложенных средств и желаемую прибыль. В результате получается максимальная себестоимость продукта, при которой его производство оправдано.
Помимо верхней границы указывайте планируемую себестоимость, чтобы избежать разногласий и обеспечить возможность реализации продукта в будущем.
Себестоимость необходимо указывать в USD с указанием учета в себестоимости цены логистики до вашего склада, таможенных пошлин и других налоговых обязательств.
Шаг 4. Установить сроки и этапы работ по продукту
Как заказчик, так и исполнитель стремятся к прозрачности будущих работ, пониманию сроков и этапов, что играет ключевую роль при оценке ТЗ.
Этапы могут быть описаны индивидуально или могут использоваться шаблоны, которые применяются при создании большинства продуктов.
-
Оценка ТЗ, где исполнитель анализирует документ, задает уточняющие вопросы и согласовывает детали с заказчиком.
-
Создание технического предложения, где исполнитель проводит аудит и разрабатывает конкретные технические решения для будущего устройства.
- Создание Эскизного проекта, где будущий продукт уже имеет набор общих чертежей, компоновку, экономическое обоснование и оценку патентной чистоты.
- Создание Технического проекта, где выбираются окончательные технические и технологические решения для изделия.
- Разработка конструкторской документации. Максимальная конкретизация достигается в конструкторской документации, которая готова для постановки на серийное производство продукта.
Каждый этап может включать требования по созданию макетов, прототипов и опытных образцов. Рекомендуем указывать требования к приемке и сдаче работ для обеспечения прозрачности на финальном этапе проекта.
Шаг 5. Указать требования к результату работ по продукту
В этом разделе следует указать, какие конкретные результаты вы ожидаете от проекта и в каком виде. Это является ключевым аспектом для ясного общения и создания общего понимания работ по проекту.
Вам нужно четко определить, что именно вы хотите получить в конце проекта. Это может быть:
- официальный документ,
- часть программного кода,
- функциональный макет продукта.
Все зависит от вашей ситуации, характера продукта и пожеланий.
В этом шаге могут появиться термины, такие как MVP, DVT, PVT, EVT и так далее. Например, если мы говорим о MVP (минимально жизнеспособный продукт), сначала нужно определить, что именно будет считаться минимально жизнеспособным продуктом для вас как заказчика. MVP может представлять собой макет, прототип или опытный образец.
Но вот проблема: люди часто используют термины, не понимая их смысла. Этот случай возвращает нас к написанию конкретных требований к результату работ вместо использования общих и недостаточно ясных терминов. Если требуется создание макета, прототипа или опытного образца, следует четко описать требования к его оценке.
Не забывайте про оформление
Техническое задание — это документ коммуникации. Поэтому важно учесть следующие рекомендации по его оформлению, чтобы облегчить его прочтение и понимание:
-
Структурируйте текст, используя блоки, а параметры и функции продукта указывайте в таблицах.
-
Для иллюстрации используйте простые блок-схемы.
- Оставьте свободные поля в таблицах, чтобы исполнитель мог внести свои вопросы и предложения по каждому пункту. Это поможет определить, насколько глубоко исполнитель проводил оценку вашего ТЗ.
Время, необходимое для составления ТЗ, зависит от его объема. Иногда это может занять месяц, а иногда год, если речь идет об экосистемных проектах, в которых разрабатывается множество устройств/модулей с созависимостями.
Если вы столкнулись с ситуацией, когда ТЗ недостаточно продумано, появляются новые функции или технические предложения, лучший вариант — приостановить работы и вернуться на этап «Составления ТЗ».
Рекомендации
Вы создали документ и готовы отправить его исполнителям, ожидая обратную связь. На этом этапе рекомендуем показать ТЗ эксперту или человеку, который не знаком с темой, чтобы получить их отзыв.
Экспертное мнение поможет вам увидеть техническое задание под другим углом и выявить возможные пропуски, а мнение неспециалиста покажет, насколько вы понятно изложили свои мысли. Если и эксперт, и неспециалист пришли к единому представлению о будущем продукте – это успех.
Что после?
После того как техническое задание написано и оформлено, его следует отправить исполнителю на анализ. Рекомендуем детально смотреть на то, какую образную связь дает исполнитель и какие вопросы задает. Это первый индикатор, по которому можно судить о квалификации исполнителя и успехе будущих работ.
Как быть, если исполнитель задает сложные вопросы, а вы, как заказчик, неудачно формулируете свои потребности или не до конца понимаете, что именно хотите?
В такой ситуации вы приходите к исполнителю за помощью, будто к психотерапевту. Задача исполнителя — разобраться в ситуации, поставить «диагноз» и обеспечить клиента ощущением легкости, а не оставить его с ощущением путаницы. Иногда инженеры могут пытаться утверждать свою компетентность за счет невежества клиентов, но с такими специалистами лучше не иметь дела.
Надеемся, что данная статья помогла вам понять важность этапа составления ТЗ и предоставила четкий план для его детальной разработки. Подписывайтесь на канал, создавайте устройства вместе с notAnotherOne.
.
