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

Ответ на этот вопрос плюс примеры техзаданий на промдизайн, а также шаблон ТЗ и инструкция по его заполнению

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

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

Почему мы так работаем? Есть причины — давайте посмотрим.

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

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

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

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

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

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

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

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

Опросник для формулировки технического задания:

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

Смотрим на аналогичные разработки:

За сутки с небольшим рисуем эскизы:

К устройству присоединяются 6 внешних антенн. То есть обязателен рисунок хотя бы с парой из них.

Выбираем самый, на наш взгляд, удачный вариант. Готово:

Итого: быстро дать старт проекту позволит использование шаблона-опросника. Этот шаблон помогает написать ТЗ:

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

Если проект, конечно, не относится к разряду самой сложной разработки на свете.

Окончание разработки дизайна без ТЗ — модель и рендеры.

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

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

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

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

Как следствие, защёлки, на которых крепилась задняя стенка, начали отваливаться, покупатели — жаловаться, а сам проект через пару лет после запуска умер. Подробности разработки здесь.

Мы пишем ТЗ потому, что так начать проект быстрее и проще; потому, что мы умеем это делать оперативнее и эффективнее, чем если бы заказчик делал это самостоятельно, и по той причине, что мы получим те вопросы, ответы на которые клиент нам не даст сам. Потому что не даст.

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

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

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

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

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

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

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

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

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

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

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

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

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

Отличить плохое ТЗ от хорошего просто.

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

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

Первый способ исправить ТЗ

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

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

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

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

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

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

Упоминая «всех», я имею в виду действительно всех — от уборщицы и бухгалтерши до Василь Степановича, который будет коробки грузить на производстве. Промышленный дизайнер должен стать коммуникатором между всеми вами (и руководство — это тоже еще одна точка постановки задач и ограничений) и клиентом вашего продукта. Я не могу судить, должен это быть штатный дизайнер или наемный работник со стороны. Был с обеих сторон баррикад и вижу и там, и там свои плюсы/минусы.

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

Техническое задание с инструкцией по заполнению и примерами: