Как составить ТЗ на hardware-продукт

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

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

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

Этот документ идеально подходит для того, чтобы заказчик понял всю важность и сложность задачи, и за что он платит деньги.

Формально, ГОСТ дает определение документу «Техническое задание», но оно, как правило, кажется абстрактным и понятным лишь специалистам, работающим с ЕСКД (Единой Системой Конструкторской Документации) . Нам же важно понять суть ТЗ.

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

Чтобы заказчик и исполнитель успешно сотрудничали, нужно общаться и четко ставить задачи для достижения желаемого результата. Внутри одной команды ТЗ не всегда обязательно, но при работе с внешним исполнителем оно становится необходимым для разрешения возможных разногласий. Формальность ТЗ зависит от удобства взаимодействия, но если его отсутствие может причинить больший вред, чем его наличие, то лучше его создать.

Быстро и легко это не получится. Можно добиться результатов, если уделить немного больше времени и сконцентрироваться.

Если мы понимаем, что ТЗ необходимо для правильного общения и взаимопонимания в работе, то за один час можно сделать что-то поверхностное или использовать готовый шаблон. Ради будущего успеха стоит уделить больше внимания подготовке.

Для написания нужно собрать:

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

Вашим партнером может быть не только российский инженер, но и предприятия из Китая, Евросоюза, США и других стран, которые также оценивают ваше ТЗ через исполнителя.

Здесь важно знать не только правила по ГОСТ, но и нормы общения по ISO, который является одним из наиболее распространенных стандартов управления качеством.

Всем известны примеры «заказал в Китае машину, привезли вертолет и напильник». И это в основном не из-за желания китайских компаний обмануть вас. Хотя и такие примеры есть, но не чаще, чем в любой другой стране. Связано это именно с ментальностью и прочтением документа.

Например, вы никогда не получите точного «нет» на любое пожелание в ТЗ от китайских производств. Но зато вы рискуете получить их интерпретацию того, как, по их мнению, можно достичь результат по ТЗ. В 90% случаях ваше представление о желаемом результате будет отличаться от того, что предложит китайский исполнитель.

Аналогично для США и для ЕС. Правила работы с лицензиями в этих странах проработаны детальнее, чем в России и Китае, и будут подразумевать дополнительную оплату, если в ТЗ содержатся конкретные технологические требования.

От ясности всем участникам и соответствия ТЗ базовым правилам оформления по 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) .

Когда речь идет о техническом задании, важно определить, насколько понятно оно для всех. И тут возникает вопрос: какой язык лучше использовать?

Существуют основные принципы, которыми нужно руководствоваться при выборе слов и стиля:

Шаг 1. Определить Цели продукта

С самого начала рекомендуется четко сформулировать Цель продукта, которую необходимо достичь в ходе всех будущих работ.

Цель должна отвечать следующим критериям:

Чем лучше вы понимаете степень достижимости, тем проще будет вести работу. Например, если ваша цель — достичь Луны, вы должны осознавать сложность запуска ракеты в космос. Или же собрать информацию о сложности, чтобы ТЗ было воспринято адекватно исполнителем.

Пример цели продукта: Разработать ноутбук. Срок выполнения: 16 месяцев.

Шаг 2. Описать продукт

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

Подходите к описанию продукта со всех сторон его использования. Если это ноутбук, то опишите его взаимодействие с пользователем (потребительские свойства), окружающей средой (экология и выбор материалов), с производством (технология производства) и даже с предметами окружающей среды, таким как упаковкой.

Около 95% полученных нами документов имеют системную ошибку — смешивание ТЗ и технического предложения. Зачастую заказчики включают в ТЗ требования использования конкретных компонентов. Для исполнителя это означает, что заказчик предварительно провел аудит рынка и оценил перспективы использования этих компонентов.

В таких случаях лучше прикрепить к ТЗ отдельное Техническое решение с полным описанием и критериями выбора. Если анализ не проводился, то лучше указывать границы допустимого и критерии выбора, а не конкретные компоненты, чтобы избежать долгого согласования.

С другой стороны, исполнитель не является частью бизнеса заказчика, и иногда есть необходимость применять конкретный компонент, конкретное решение для удовлетворения спроса на рынке. Скажем, Intel Inside или именно BLE 5.2, а не 4.2, USB Type-C и другие решения. В этом случае стоит указать эти требования в ТЗ или техническом предложении.

2.2. Описать функции продукта

Опишите все функции продукта, которые соответствуют его цели. Эти функции можно разделить на три основных блока:

Например, ноутбук должен иметь клавиатуру для ввода информации или иметь аккумулятор емкостью 50 Вт·ч.

Например, функция подключения стороннего мобильного устройства по технологии Wi-Fi.

Например, наличие панели администратора с функцией глубоких настроек.

2.3. Описать структуру продукта

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

2.4. Сформулировать требования к надежности

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

Первая цифра обозначает степень защиты от проникновения сторонних предметов. Вторая — степень защиты от проникновения воды.

Для примера. Знакомый многим IP68 означает, что продукт пыленепроницаемый (цифра 6) и способен работать под водой на глубине более 1 метра.

Существуют и другие стандарты надежности как для программного, так и для физического обеспечения продукта, и они выбираются в каждом конкретном случае.

Если вы не знакомы со стандартами, можно описать конкретные требования. Скажем, вместо IP68 написать «пыленепроницаемый и способен работать под водой без проникновения влаги».

2.5. Указать условия эксплуатации, транспортировки, хранения и обслуживания

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

Эти требования помогут понять сложность продукта. К примеру, длительное хранение при экстремальных температурах потребует специальных материалов, что может повысить стоимость разработки и производства.

Обычно указывают следующее, если это важно для продукта:

Например, если LiCoO2-аккумуляторы (обычно используемые в телефонах) подвергнуты нарушению температурного режима в процессе транспортировки и хранения, они могут выйти из строя, возгореться или существенно потерять емкость.

2.6. Определить требование к патентной чистоте

Это важное требование для будущего успеха продукта. Патентная чистота и соответствующие требования позволят исполнителю понять, насколько сложные будут работы по ТЗ. Что влияет на сроки и стоимость проекта.

Для справки: получение патента на «Изобретение» может в несколько раз увеличить стоимость разработки по сравнению с патентом на «Полезную модель» или »Промышленный образец».

Например, Ложка с BLE — Полезная модель. Метод получение InGaN полупроводника для производства синих светодиодов — Изобретение.

Примеры типов патентов слева направо: Изобретение, Полезная модель, Промышленный образец

Хотя патентное оформление не является обязательным, вы можете не указывать требование к патентной чистоте, если в этом нет необходимости.

Шаг 3. Описать экономические требования к продукту

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

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

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

Шаг 4. Установить сроки и этапы работ по продукту

Как заказчик, так и исполнитель стремятся к прозрачности будущих работ, пониманию сроков и этапов, что играет ключевую роль при оценке ТЗ.

Этапы могут быть описаны индивидуально или могут использоваться шаблоны, которые применяются при создании большинства продуктов.

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

Шаг 5. Указать требования к результату работ по продукту

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

Вам нужно четко определить, что именно вы хотите получить в конце проекта. Это может быть:

Все зависит от вашей ситуации, характера продукта и пожеланий.

В этом шаге могут появиться термины, такие как MVP, DVT, PVT, EVT и так далее. Например, если мы говорим о MVP (минимально жизнеспособный продукт), сначала нужно определить, что именно будет считаться минимально жизнеспособным продуктом для вас как заказчика. MVP может представлять собой макет, прототип или опытный образец.

Но вот проблема: люди часто используют термины, не понимая их смысла. Этот случай возвращает нас к написанию конкретных требований к результату работ вместо использования общих и недостаточно ясных терминов. Если требуется создание макета, прототипа или опытного образца, следует четко описать требования к его оценке.

Не забывайте про оформление

Техническое задание — это документ коммуникации. Поэтому важно учесть следующие рекомендации по его оформлению, чтобы облегчить его прочтение и понимание:

Время, необходимое для составления ТЗ, зависит от его объема. Иногда это может занять месяц, а иногда год, если речь идет об экосистемных проектах, в которых разрабатывается множество устройств/модулей с созависимостями.

Рекомендации

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

Экспертное мнение поможет вам увидеть техническое задание под другим углом и выявить возможные пропуски, а мнение неспециалиста покажет, насколько вы понятно изложили свои мысли. Если и эксперт, и неспециалист пришли к единому представлению о будущем продукте – это успех.

Что после?

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

Как быть, если исполнитель задает сложные вопросы, а вы, как заказчик, неудачно формулируете свои потребности или не до конца понимаете, что именно хотите?

В такой ситуации вы приходите к исполнителю за помощью, будто к психотерапевту. Задача исполнителя — разобраться в ситуации, поставить «диагноз» и обеспечить клиента ощущением легкости, а не оставить его с ощущением путаницы. Иногда инженеры могут пытаться утверждать свою компетентность за счет невежества клиентов, но с такими специалистами лучше не иметь дела.

Надеемся, что данная статья помогла вам понять важность этапа составления ТЗ и предоставила четкий план для его детальной разработки. Подписывайтесь на канал, создавайте устройства вместе с notAnotherOne.

#инструкция #тз #устройства #hardware