Федя, дичь! Тотальный провал разработчиков приборов

Примерно 80% разработчиков приборов бросают свои проекты буквально за пару шагов до триумфального запуска в серию. А ведь во всё это вбухиваются время, деньги, другие ресурсы и вдобавок куча нервов. Мы попытались выяснить причины этой аномалии. Выяснили (во всём виноваты кальсонные гномы). И нашли способ лечения.

Год назад мы провели опрос среди наших клиентов, которые в 2017-2019 годах заказывали у нас контрактную разработку корпусов для их приборов и устройств. Все проекты мы выполнили полностью. Вопрос был один — начали ли заказчики серийное производство своего продукта? Ответили 10 компаний (не так много, но для понимания ситуации достаточно).

Так вот, из 10 опрошенных только двое подтвердили, что производство запущено.

Слайд из презентации нашего выступления на конференции АРПЭ по контрактной разработке электроники — проверка выполненных проектов за 2017-2019 года

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

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

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

У меня есть предположения (основанные на опыте, конечно же).

Итак, почему тотальное большинство проектов не доходит до серийного производства.

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

1. Нужен, но не сильно

Наглядно: вот буквально в декабре была доделана новая версия сайта Формлаба. Задача была — упростить поиск по портфолио, где количество проектов давно перевалило за 200, и где докопаться до нужного корпуса становится непросто.

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

Получается, что продукт в принципе нужен, но всё же не жизненно важен для компании.

Уверен, что ровно тоже самое происходит и у заказчика контрактной разработки электроники или у нашего клиента, когда ему нужен корпус для его прибора.

Дисклеймер — всё это не касается компаний, у которых обновление линейки заложено в процессы и саму суть рынка. Это и в b2b, и в b2c. Для наглядности — производители бытовой техники или тех же промышленных сварочных аппаратов. Такие компании вынуждены постоянно тратить усилия на обновления линеек и продуктов, без этого их просто вышвырнут с рынка. Но такие производители — мизер от общей массы.

2. Никто не знает, что, но давайте делать

Если помните сериал South Park, там были кальсонные гномы, у которых отсутствовала часть цепочки из процессов:

  1. Collect underpants (Сбор кальсон)
  2. ???
  3. PROFIT (Прибыль)

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

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

Большая часть электронщиков стремится разработать корпуса самостоятельно. Источник: опрос Формлаба, 2021 год

Самые частые маркеры такого незнания — это вопросы:

  1. А почему корпус стоит дороже платы?
  2. Мы разрабатывали плату 2 года, а вы какой-то корпус за 2 месяца не произведете?
  3. Мы раньше обходились покупными корпусами, они нас полностью устраивают, но…
  4. Давайте вы сделаете нам сразу 10 прототипов, а мы дальше посмотрим (кстати, вот видео про этот миф.
  5. … и с десяток подобных.

И получается, что эта часть проекта (производство своего корпуса) всегда в некоем тумане войны — примерно знаем, что да как, но когда начинаем заниматься и открывается куча всего нового, то спотыкаемся, переделываем, тратим время и деньги.

Даже если часть этого «всего» лежит на контрактном разработчике типа Формлаба, всё равно самая важная и сложная часть работы остаётся за заказчиком. Именно он сшивает все лоскутки, тащит за собой всех участников.

И это усложнение сначала сильно оттормаживает весь проект, потом сжирает больше денег и сил заказчика, а потом получаем то, что 4 компании из 5 фактически бросают проект в стол.

Этапы лечения: как добежать до производства

Единственный способ добежать до конца и начать продавать свой продукт — это чётко представлять себе ВСЮ цепочку действий, участников и процессов. А именно

— макроэтапы запуска проекта в производство.

Вот они:

Прототип → Тестовая партия → Серийное производство → Продажи

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

Прежде чем будет показана схема лечения, разберём эти этапы подробно — зачем они нужны. Это необходимо для понимания схемы (или, если вы в себе уверены, пропускайте описание этапов и скролльте сразу к «Что делать?»).

Этап «Прототип»

Вроде бы очевидная штука — этапы. В любой проектной деятельности это есть. Но если с электроникой вам всё понятно, то с другой частью любого прибора (тем же корпусом) уже всё не так ясно, и происходит логическая, даже сутейная ошибка:

Я спрашиваю заказчика: «Что мы хотим выяснить, получив прототип?» Ответ звучит по-разному, но суть у него одна: «Собрать нашу (заказчика — прим. авт.) электронику в новом корпусе».

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

Мы набросали по этому поводу вот эту статью, чтобы хоть немного «расшить» вопрос задачи этапа прототипирования.

Прототип должен быть максимально приближен к серийному продукту.

Макет, прототип и образец из тестовой партии счётчика лейкоцитов

На самом деле всё сложнее: каждый из макроэтапов (и прототипирование в том числе) — это чёткая задача, работающая на всю цепочку и достижение результата — продаж продукта. Давайте развернем прототипирование в эту сторону. Тогда внезапно выяснится, что в прототип корпуса можно не только смонтировать электронику, но и то, что прототип должен показать:

  • как устроен будущий продукт;
  • как он выполняет свою функцию (функции);
  • какими физическими свойствами он будет обладать;
  • сколько будут стоить следующие этапы, чтобы завершить цепочку и начать производить (а потом и продавать).

И если ваш прототип не отвечает на ВСЕ эти вопросы, то это не прототип — «ехать дальше» нельзя. Если вы всё же поехали, то смело считайте, что в этот момент вы сами начали подпиливать одну из ножек стула, на котором так хорошо сидите.

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

Например, выясняется, что кнопки работают теперь не так, как на макете. Что сборка устройства получила ручной допил. Или что корпус ломается на морозе. Или… (я такие «или» могу пачки накидать). Все это потому, что на этапе прототипирования был закрыт только один из вопросов — «собираемся» или расходимся «не собираемся»? Все остальное кануло «в тумане войны».

Корпус, напечатанный на 3D-принтере

Этап «Тестовая партия»

Лезем глубже — на вопрос «Зачем нужна тестовая партия?» тотальное большинство (по моему опыту, конечно, пруфов не будет) отвечает: «Надо посмотреть, что да как работает, покрутить…»

Чуете, куда клоню? Это то, что мы бы уже должны были проверить этапом ранее. А ведь тестовая партия должна быть только для одной цели:

Выявить ошибки и узнать новые сценарии использования пользователей будущего продукта.

И это не про то, что нашим прибором пользователь будет гвоздь забивать, а про то что, вы сейчас точно, однозначно, 100%, не знаете всех условий и сценариев использования, которые будут в реальной жизни прибора (если вы всё же думаете, что знаете на 100%, то на них же и ошибаетесь).

Пример 1. Устройство ломалось, когда пользователь собирал его в перчатках на морозе. Пластик становился хрупким, перчатка не давала контролировать усилие, винт разрушал корпус. Проект.

Корпус промышленного GPS-трекера VK

Пример 2. Монтажники располагали кабель-каналы вплотную к корпусу вдоль сторон. Это мешало добраться до защёлок (лицевая панель корпуса крепится именно на них). В итоге крышку кое-как выламывали, а лицевая панель стала расходным материалом.

Красивый корпус панели управления охранной сигнализацией. Красивый, но, как выяснилось, не очень надёжный

Пример 3. А этим терминалом пользователи вообще приноровились открывать пивные бутылки. В каком страшном сне разработчикам могло такое привидеться?

«Открывашка» имеется, можно бежать за пивом. Ударопрочный мобильный терминал для спецслужб АМБ

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

Можно только последовательно менять продукт под вновь открывающиеся смыслы.

Этап «Серийное производство»

Забуриваемся ещё глубже. Суть этого этапа — не произвести 1000 штук изделий. А возможность получить прибор или устройство, которые можно… продавать и обслуживать.

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

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

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

Пример 1. У металлодетектора была резиновая крышка отсека АКБ, которая обеспечивала герметичность. Когда охранникам становилось скучно на посту, они развлекались тем, что постоянно открывали и закрывали её. Резинка отрывалась, крышка терялась. Финита.

Крышка аккумуляторного отсека корпуса металлодетектора крупным планом

Пример 2. На этапе разработки в проект заложили защелки: заказчику показалось, что так будет проще собирать изделие, но сервис не получил на тест изделия и не высказался, что ему нужна разбираемость корпуса. В результате корпус просто ломался и выбрасывался в мусор.

Про каждый из этих пунктов можно писать тонны всего. Я-то хочу подчеркнуть очень простую мысль:

Ты не получишь продукт, готовый к реальным (и регулярным) продажам, если не пройдешь все три макроэтапа.

Что делать?

Метод дойти до завершения проекта всего один — сначала реалистичный план, потом искать, где сэкономить/ускорить подстелить.

Бюджет

— хватит ли денег довести продукт до регулярных продаж?

Если вы не дойдете до продаж, всё остальное теряет смысл, согласитесь. Но нам же нужно не просто разово отгрузить, а делать это регулярно, поэтому выделю слово «регулярные». Оценить бюджет непросто, но примерно прикинуть можно. Например, вот стоимость корпусов сразу нескольких проектов (поэтапно):

а) Маленький корпус (60х30 мм), общий бюджет —50K$.

Разработка и производство прототипов — 10К$
Тестовая партия 25 штук — 10К$
Пресс-формы и серийное производство 10 000 корпусов — 30К$

Или (для наглядности) в пропорциях:

б) Герметичный пластиковый корпус — 76K$

Разработка и производство прототипов — 13К$
Тестовая партия 25 штук — 13К$
Пресс-формы и серийное производство 10 000 корпусов — 50К$

в) Настольный прибор — 95K$

Прототип — 15K$
Тестовая партия из 10 штук — 15K$
Серийное производство 3000 штук — 65K$

г) Вызывная панель домофона — 315 K$

Прототип — 20K$
Тестовая партия из 10 штук — 35K$
Серийное производство 10 000 штук — 250K$

В пропорциях:

д) Напольный корпус — 310 500$

Прототип — 25K$
Тестовая партия из 25 штук — 35K$
Серийное производство 500 штук — 250K$

Сроки

— все всегда оптимистично смотрят на сроки. А зря.

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

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

Про хаос каждого такого проекта говорил вот тут и коротенько писал тут.

Вот примеры реальных сроков (за 2017-18 годы) — от старта (есть макетная плата) до отгрузки готовых изделий.

Счётчик лейкоцитов — 6 месяцев план — 14 месяцев реальность
Терминал связи "НАБАТ®" — 4 месяца план — 4 года реальность
Система автоматизированного полива IRRIOT — 5 месяцев против 18
Навигационное устройство FORT-112М — 3 месяца против 8
Пульт конференц-системы — 3 месяца в плане, а в реальности — 2,5 года

А как подстелить?

«Что делать?» — самый интересный вопрос, и ответ вам не понравится.


Отдавайте часть разработки на сторону.


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

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

Примеры, которые вижу в жизни:

а) Дизайн устройства надо выбирать вам, но не стоит лезть в радиусы, уклоны и прочее — это зона ответственности дизайнеров и конструкторов. А обсуждение этих вещей и есть их работа, но не ваша как заказчика. Иначе времени сожрётся в 2-3 раза больше, чем уйдёт на само проектирование.

б) Принимать решения относительно части компонентов, когда заказчик пытается самостоятельно погрузиться в проект, — и успешно тормозит его, потому что во время погружения отвлекается на более важные для его бизнеса дела. В итоге толкового менеджера со стороны клиента или нет, или есть, но он не уполномочен принимать решения.

Такие заказчики — сплошь и рядом. Пример: два совещания подряд заказчик не может утвердить размер дисплея, и из-за мелкого, по сути, вопроса проект встаёт на неделю…

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

Есть метод и посложнее — завязывать разработчика на этапы производства. Суть в том, что пока разработчик продает вам не физический результат (поставку прототипа, тестовой партии или серии). Он продает вам часы разработчиков, что бы он ни говорил при этом. И чем больше продаст, тем лучше. А окончание и качество услуги нельзя описать формально, оцифровать. Поэтому важно считать показателем проекта не просто утверждённый дизайн, а реальный корпус у вас на столе. Или тестовую партию на складе. И так далее.

Убираем все лишние слова и получаем:

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

Чтобы понять, что нужно для этого, перестань себя обманывать и посмотри на реальные примеры.

Чтобы не упасть по дороге, перестань решать там, где у других больше опыта.

Чтобы повысить ответственность разработчика, выбирай физический результат его разработки, а не обещание хорошо поработать.

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

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

Как часто подобное случается? В моей личной статистике таких проектов меньше одного процента.

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

Андрей Востриков,
руководитель


ФОРМЛАБ, специалисты по корпусам

подпиши НДА

Прежде чем обсудить задачу, подпишите соглашение о неразглашении

Подписать NDA