Формлаб I 2015

Почему мы пишем ТЗ сами

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

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

Почему мы так работаем? Есть причины — давайте посмотрим.
Спойлер: здесь будут не только ответы на "Почему?" и рецепт "Как написать хорошее ТЗ на промдизайн", но и мини-руководство "Как исправить плохое техническое задание". А ещё — опросник для заказчика, инструкция по заполнению техзадания и реальные примеры.

Потому что так проект быстрее выйдет на старт

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

Возьмем пример слегка экстремального случая. Бывшее РИА "Новости", которое сейчас МИА Russia Today, в 2015 году объявило тенедер на лучший дизайн маршрутизатора (по ТЗ — "устройства передачи данных в сетях трёх операторов сотовой связи"). Это оказалась задача из разряда: "Мы не знаем, как оно должно выглядеть, но у нас есть спецификация с комплектухой".

Какие-то мысли относительно свойств будущего корпуса у клиента всегда есть. Они бродят в его голове, иногда вырываясь наружу в виде хаотичных набросков, заметок, замечаний или высказываний. Но вот сделать на основе этого "чего-то" некий структурированный документ, понятный любому непосвященному, —это огромные энергетические и трудозатраты. Сам заказчик чаще всего заявляет нечто вроде: “Нужен корпус космолёта. Пришлите ваши вопросы, мы на них ответим”.

Космолётов много. Только вот какой из них понравится заказчику? Поди угадай

Однако мы примерно представляли, что нужно будет сделать: во-первых, в активе Формлаба уже был похожий проект — модем Hornet.
Промышленный модем Hornet — опыт разработки таких устройств у нас уже был

Во-вторых (и в-главных), у нас уже есть некая шаблонная схема написания ТЗ в виде опросника. Лишних вопросов там нет — всё проверено многими годами практики. То есть мы заранее знаем, что будем спрашивать у клиента.


Хотите посмотреть на список вопросов — жмите на кнопку и качайте опросник.

Опросник для формулировки технического задания
Возвращаемся к маршрутизатору: раз есть спецификации на электронику, значит, имеются и кое-какие исходные данные. Так, в состав этого роутера должны входить три модема и модуль Wi-Fi; на корпусе нужны разъёмы Ethernet, micro-USB, SMA. Есть монохромный дисплей. Материал основной части корпуса — фрезерованный алюминий, панель — пластик, кнопки — тоже алюминиевые. Уже что-то можно придумать.

Смотрим на аналогичные разработки:
За сутки с небольшим рисуем эскизы:
К устройству присоединяется 6 внешних антенн. То есть обязателен рисунок хотя бы с парой из них.
Варианты дизайна — чистовые эскизы:
Выбираем самый, на наш взгляд, удачный вариант. Готово:
Итого: быстро дать старт проекту позволит использование шаблона-опросника. Этот шаблон помогает написать ТЗ:
  • даже в том случае, если этих данных мало или почти нет;
  • достаточно быстро;
  • в очень легкой и ненавязчивой форме — ответы на вопросы можно получить даже во время телефонного разговора.
Если проект, конечно, не относится к разряду самой сложной разработки на свете.
Отрывок из ТЗ на маршрутизатор, которое мы написали сами по шаблону
Окончание разработки дизайна без ТЗ — модель и рендеры.
Разработка конструкции корпуса пульта
"Самый правильный заказчик" (с), конечно же, ТЗ пишет сам. Но такие люди встречаются редко. Как правило, они уже много лет "варятся" в разработке и наизусть выучили все подводные камни.

Потому что сделанное самостоятельно ТЗ раскроет то, о чём сам клиент никогда не расскажет

Клиент может знать о корпусе устройства что-то очень важное. Но вам об этом никогда не расскажет. Не корысти ради и не по той причине, что ждёт, что вы сами об этом догадаетесь, — всё проще. Он просто может не подозревать, что вам эта информация нужна.

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

Потому что иногда ТЗ — это одновременно и исследование в рамках проекта

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

Идея этого пресса: кладешь в мусорное ведро-пресс пакет, кидаешь мусор, ведро трудолюбиво сжимает его, а когда оно наполняется, ты вытаскиваешь из устройства уже спрессованный, в запаянной пластиковой упаковке компактный пакетик и торжественно несёшь на помойку. Просто и красиво.
Прототип мусорного ведра-пресса
Прототип мусорного ведра-пресса
Когда заказчик рассказал о своей идее, было всё понятно. Но в тот момент, когда мы начали писать ТЗ, выяснилось, что не понятно вообще ничего, и в этом проекте разработка ТЗ стала отдельной задачей. Задание писал конструктор.

Кстати, опытный образец этого пресса был способен легко и непринуждённо сжимать даже бутылки из-под шампанского.

Потому что ТЗ — это не памятник

В 99% случаев в процессе разработки ТЗ изменяется. Дизайн, условно говоря, ты в миллиметрах не опишешь. Сначала мы делаем ТЗ "первого уровня" — черновик, к моменту начала разработки задание уточняется, и в нем описывается вообще всё, что можно уточнить. С этого момента техзадание становится основным внутренним документом, помогающим нашим разработчикам взаимодействовать со спецами клиента.

Но надо помнить, что ТЗ — это не истина в последней инстанции. Документ описывает идеальный результат разработки, такого сферического коня в вакууме.
Надгробная плита увековечивает память. ТЗ ничего такого не увековечивает, а лишь обозначает границы
Но одновременно это НИОКР, условия постоянно меняются: то выясняется, что изначально подобранная электроника не умещается в корпусе, поэтому надо либо менять габариты корпуса, либо начинку; то выясняется, например, что уже утверждённый в составе компонентов дисплей сняли с производства, и поэтому его срочно придётся заменять другим. Поэтому ТЗ — не аксиома и не волшебная шляпа: закинул в неё пожелания и вынул готовый результат. Оно лишь обозначает красные флажки вокруг разработчика.

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

Бывает и так, что ТЗ у заказчика уже есть. Это всегда замечательно, но не всегда полезно для разработки (как, например, в упоминаемом выше случае с прессом для мусора: заказчик может описывать одно, а иметь в виду немного (или совершенно) другое).

Но есть также и методы борьбы с этим явлением.

Два способа исправить плохое ТЗ

Когда задача некорректно сформулирована, есть два способа это переписать исправить.
Отличить плохое ТЗ от хорошего просто.

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

Второй критерий: отсутствие или наличие упоминаний о конкурентах. Это вообще большая проблема: люди неправильно оценивают тех, кто с ними конкурирует, или вообще не смотрят на тех, кто делает почти то же самое, что и они. А зря: как правило, конкуренты уже решили какие-то проблемы устройства, уже вложились в разработку. Игнорируя это, ты будешь набивать те же самые шишки, что когда-то — конкуренты, но уже за свои деньги. Заниматься промышленным шпионажем здесь вряд ли придётся, достаточно хорошо изучить то, что производят другие и попробовать понять, почему они так сделали.
Первый способ исправить ТЗ

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

С ответом на вопрос: "Для чего?" могут помочь в отделе продаж (и / или маркетинга тоже) заказчика. Скорее всего, там наблюдают за конкурентами уже сейчас и совершенно трезво сравнивают себя с ними, слушают возражения клиентов и могут выявить то самое свойство изделия, которое надо прописать как стержень ТЗ, сделать основной задачей проекта — добавить или усилить именно это свойство нового продукта.

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

С этой картинкой уже можно идти к электронщикам и спрашивать: "Вот такая штука нужна, когда сделаете?" Электронщики вам крылья, конечно, подрежут, но это уже рабочий процесс…

Второй способ

Когда не подходит способ №1, т.е. продавцы не могут сформулировать, что нужно, идите сразу к промышленным дизайнерам. Задача для них получится и сложнее, и проще одновременно. Они должны будут собрать "хотелки" со всех слоёв проекта, а из всего, что соберётся, сделать задачу для себя.

Упоминая "всех", я имею в виду действительно всех — от уборщицы и бухгалтерши до Василь Степановича, который будет коробки грузить на производстве. Промышленный дизайнер должен стать коммуникатором между всеми вами (и руководство — это тоже еще одна точка постановки задач и ограничений) и клиентом вашего продукта. Я не могу судить, должен это быть штатный дизайнер или наемный работник со стороны. Был с обеих сторон баррикад и вижу и там, и там свои плюсы/минусы.
Ну и Формлаб не был бы Формлабом, если бы не давал вам в руки инструментов для работы проектных команд. Вот наш внутренний шаблон технического задания с простой инструкцией по заполнению. Скачивайте, пользуйтесь.
Техническое задание с инструкцией по заполнению и примерами:
— Для промышленных дизайнеров ТЗ — это всё же больше бумажка для клиента. Мы не конструкторы, для которых важен каждый миллиметр. Но техзадание нужно — для того, чтобы мы с клиентом смотрели в одну сторону.

Андрей Востриков
Руководитель бюро инженерного дизайна Формлаб
Другие статьи
И мы рады, что оправдываем оказанное нам доверие
Показать больше