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

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

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

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

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

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

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

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

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

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

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

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

Варианты дизайна — чистовые эскизы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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