11 основных ошибок hardware-стартапов и как их избежать
Hardware-стартап — это компания по созданию, разработке и производству электронных устройств.
Hardware, или железо, противопоставляется software, или софту: если во втором случае стартап занимается программным обеспечением, то в первом продуктом являются реальные физические объекты.
Из-за общей специфики «железных» стартапов фаундеры зачастую совершают похожие ошибки. В нашей статье перечислены главные недочеты при управлении хард-стартапом и способы избежать некорректных решений.
Характеристики hard-стартапа
По отношению к железным компаниям действует правило: чтобы проект трансформировался в успешный бизнес, продукт должен быть масштабируемым. Поэтому разница между проектом и продуктом — это разница между созданием некой единицы и производством множества.
Однако «производство множества» традиционно связывается с высокой стоимостью процесса, недоступностью материалов и иными сложностями. Чтобы компания росла и развивалась, ей необходимо придумать, как поддерживать низкую стоимость производства.
К счастью, за последние несколько лет сформировалась тенденция на облегчение мануфактурных процессов. Это напрямую коснулось и компаний, создающих hardware.
Особенности производства hardware
Создание компании по производству полноценных физических продуктов может отличаться по нескольким ключевым параметрам.
Примеры hardware-стартапов в России и в мире
Отечественные железные стартапы
RoboCV — производитель интеллектуальных автопилотов для роботизированной транспортировки складских грузов. Разработанное стартапом решение X-MOTION NG — первая в мире полностью автономная мобильная робототехническая система, предназначенная для работы внутри помещений. Промышленные роботы от RoboCV могут взаимодействовать с объектами по всем трем осям. Управление осуществляется посредством облачной технологии. Основатель — Сергей Мальцев. Год основания — 2012.
DRD Biotech — стартап родом из республики Бурятия по разработке экспресс-тестов in vitro для выявления повреждений головного мозга на основе биотехнологий и IT. Продукция компании используется для определения ишемического инсульта, эпилепсии и ЧМТ. В 2020 году в разработку был запущен экспресс-тест на коронавирус. Основатель — Анжей Жимбиев. Год основания — 2014.
Мировые производители железа
Graphcore — британская компания по разработке чипов и процессоров для искусственного интеллекта и машинного обучения. Продукция Graphcore используется в таких областях, как медицина, робототехника, автономная мобильность. Стартап намерен возвести собственную технологию Intelligence Processing Unit (IPU) в мировой стандарт AI. Основатели — Найджел Тул, Саймон Ноулз. Год основания — 2012.
Главные ошибки хард-стартаперов
1. Попытка создать очередную Apple или Tesla
Простейший способ моментально исчерпать весь финансовый ресурс стартапа — подражание техногигантам. У начинающих компаний просто нет капитала, чтобы делать то же самое, что делают мастодонты индустрии.
Например, когда компания Apple начала производство алюминиевых корпусов для Macbook Air, ей пришлось закупить 10 000 станков с ЧПУ, чтобы отгружать миллион единиц в год. Очевидно, ни один стартап это не повторит. Если бы новоиспеченному проекту предстояло сделать похожий корпус, он бы изменил конструкцию деталей так, чтобы они выполняли прежние функции, но требовали других производственных процессов.
Решение: изначально выстраивать производство по принципу Lean startup. Сохранять простоту процессов. Не пытаться быть «Теслой от мира Х», где Х — избранная индустрия или ниша, а сразу развивать собственный уникальный оффер.
2. Оголтелое доверие мнениям клиентов
Здесь возникает закономерный вопрос: разве бизнес не должен прислушиваться к потребителям? Отвечаем: не всегда. Или, по крайней мере, не отключая критическое мышление.
Когда фаундеры увлечены проектом, у них может появиться соблазн предоставить клиентам все, что они просят. И хотя прислушиваться к потребителям — необходимость для любого стартапа, следует также учитывать рамки финансовых ограничений. Начинающий проект не может сделать всех счастливыми: не хватает ресурса, опыта и команды.
Решение: нужно сосредоточиться на одной конкретной потребности клиента и решить ее лучше всех на рынке. Чем больше функций выполняет продукт, тем выше сложность и стоимость производства и тем больше поворотных моментов, когда все может пойти не так.
Любой неверный шаг hardware-бизнесу обходится дороже. Крупные компании могут позволить себе ошибаться, но для молодого проекта это критично. Поэтому вначале лучше не усложнять задачу и оставлять продукту меньше функционала — а значит, и меньше пространства для ошибки.
3. Проектирование без учета технологических требований
Создание функционального прототипа — только половина успеха. Настоящий челлендж начинается с попытки масштабировать его до массового производства.
Здесь важное место занимает разработка печатной платы и внешнего вида продукта. Причем второе намного коварнее: сколько бы прототипов ни придумал стартап, как минимум половина из них не подойдет для запуска «в продакшен».
Трудности начинаются, когда фаундеры недооценивают необходимость проектировать продукт с учетом технологических требований. Непродуманная разработка, особенно когда ошибки выявляются посреди крупной партии, может вызвать огромные расходы и задержки.
Решение: как правило, первичные прототипы печатают на 3D-принтере или делают из подручных материалов: картона, дерева, бумаги. По мере развития стартап может заказать профессиональное проектирование продукта. Такое решение соединит эстетические качества, удобство использования и функциональность. При этом учитываются производственные ограничения и другие технические особенности.
4. Слепая влюбленность в идею
Одной лишь хорошей идеи недостаточно — для нее нужен рынок сбыта. Но иногда основатели так одержимы своими концепциями, что не способны принять и учесть экономическую ситуацию, объективно оценить спрос, выслушать конструктивную критику со стороны пользователей, инвесторов, семьи и друзей.
Решение: важно улучшать свои проекты, дорабатывая их по мере проведения CustDev-опросов и сбора данных от конечных пользователей. Это увеличивает шансы продукта задержаться на рынке и найти его целевую аудиторию.
5. Недооценка затрат на разработку и производство
Стоимость электронных компонентов и инструментов для создания прототипов продолжает снижаться. Тем не менее, когда производство расширяется до тысяч единиц в месяц, расходы могут увеличиться незаметно и с геометрической прогрессией.
Часто это результат недооценки общих расходов, включая сертификацию, сборку, упаковку, складирование и доставку. Играет роль и невнимательность основателей по отношению к неожиданным задержкам, изменениям в инструментарии, выявленным дефектам.
Решение: заранее исследовать вопрос затрат; расспросить производителей или фаундеров аналогичных стартапов, сколько может стоить разработка. Чем больше мнений — тем лучше. Наконец, тщательно и внимательно рассчитать бюджет, не вливая в производство весь финансовый ресурс.
6. Некорректное планирование и/или график
В западных странах запуски потребительских товаров нередко планируются на рождественский сезон, чтобы монетизировать праздничный рост продаж. При этом ни один бизнес не защищен от неожиданных сбоев в запланированном производственном графике.
Решение: необходимо принять во внимание возможные задержки, учесть их в графике и дополнительно выделить щедрый буфер, который закроет экстренные ситуации.
Также стоит включить в график важные события и праздники страны-производителя. Например, если продукт производится в Китае — зафиксировать, что из рабочего процесса выпадают выходные, приуроченные к китайскому Новому году.
7. Нехватка надлежащего тестирования
Предположим, фаундеры получили великолепный прототип смартфона. Его водонепроницаемый корпус тестировался на уровне моря, и все исследования показали, что он работает безукоризненно.
Но на более крупных высотах гидроизоляционный материал может деформироваться. Подобный случай указывает на то, что проектировщики не учли перепад давления, а также не протестировали товар в разных средах и/или сценариях использования.
Решение: придется потратить немало времени (и средств), чтобы протестировать продукт перед отгрузкой. При этом следует опираться на надлежащие методологии и стандарты тестирования продуктов.
8. Нехватка предварительных исследований
Еще одна ловушка для железных стартапов — незнание потребностей, желаний и болевых точек конечного пользователя. Так, многие фаундеры начинают разработку проекта в информационном вакууме. Получившиеся продукты не решают реальных проблем, не имеют реального рынка и бизнес-модели.
Решение: на раннем этапе все решает обратная связь. Чтобы начать собирать отзывы клиентов, необходимо определить целевую аудиторию и провести обширное исследование. Подробнее о CustDev.
Такое предварительное исследование позволяет стартапу понять, что ищет целевая аудитория, и отказаться от лишенных потенциала идей. Это помогает сосредоточиться на решении реальных проблем и избежать «расползания функций», то есть приумножения ненужных «фич».
Подсказка: чтобы проверить, есть ли реальный спрос на стартап-концепцию, можно использовать краудфандинг. Если люди готовы заплатить за продукт на стадии идеи, это подтверждает ее востребованность. К тому же успешная краудфандинговая компания станет решительным аргументом для инвесторов.
9. Неправильный выбор производителя
Не одному и не двум стартапам пришлось остановить производство из-за полной некомпетентности партнера-производителя. В части случаев это происходит, когда компания подбирает фабрику некорректного масштаба.
Например, заказ на 20 тысяч деталей просто и утонет в операционной деятельности крупного производителя, поставляющего более миллиона деталей каждый месяц. В то же время более скромная фабрика сможет удовлетворить запрос и окружить заказчика должным вниманием.
Решение: требовать соответствующую документацию и справочные материалы, чтобы убедиться, что производитель действительно может отгрузить заявленные услуги.
Коммуникация — ключ к менеджменту любых отношений. Поэтому лучше избегать взаимодействия с посредниками и проводить больше времени с командой производителя на местах. Это поможет понять корпоративную культуру, вникнуть в процессы, а также сформировать ожидания от стандартов качества.
10. Отсутствие конкурентного преимущества
Мы живем в мире, где на каждую инновационную идею найдется компания в Китае, которая может предложить то же самое по более низкой цене. Большинство hardware-продуктов особенно легко подвергаются обратной разработке или копированию.
В защите бизнес-идей может помочь патент, но его оформление — весьма дорогое удовольствие. К тому же в случае судебных издержек нарушитель почти всегда может похвастаться более глубоким карманом, чем начинающий стартап. Поэтому сегодня патенты в целом не входят в арсенал фаундера.
Решение: если у хард-проекта нет объективного и некопируемого конкурентного преимущества, следует создать крепкое, сплоченное коммьюнити вокруг бренда. Предлагая исключительную клиентскую поддержку и роскошный опыт, стартап выделится на фоне даже самых качественных подделок.
11. Недостаточный трекшн
Вспомним гипотетических фаундеров с гипотетическим смартфоном. Команда стартапа месяцами доводит мелкие детали прототипа до совершенства, но когда запускает продукт на рынок — выясняется, что потребители не слишком заинтересованы в водонепроницаемом телефоне.
Это происходит повсеместно: иногда стартапы просто не могут добиться успеха, хотя создали отличную концепцию. Провал объясняется тем, что проект не набрал достаточно первоначальной поддержки вследствие слабой маркетинговой стратегии.
Решение: начать рекламную кампанию на раннем этапе, чтобы вызвать интерес и создать сильную клиентскую базу. Когда стартап будет готов предоставить блестящие новенькие прототипы, в продукте уже заинтересуется достаточно людей, а значит, компания быстрее получит первые заказы.
Краткие итоги
Железные стартапы занимаются разработкой реальных физических гаджетов с инновационными особенностями. Из-за специфики направления фаундеры хард-стартапов совершают одинаковые ошибки. В целом, все они связаны с проблемами, которые можно распределить по трем основным группам.
Каждая из этих ошибок способна отбросить проект на несколько шагов назад, аннулировать совершенный прогресс и вылиться в тысячи, если не миллионы рублей убытков. Поэтому, как и в любом другом венчурном бизнесе, мы рекомендуем тщательно планировать свою стратегию, многократно проверять все гипотезы и держать руку на пульсе рынка.
P. S. Если у вас есть вопросы по данной теме или предложения, то всегда можно задать их в чате Admitad Projects в Telegram.
Hardware разработка: что стоит знать тем, кто затеял «железный» стартап
Аналитики компании Cbinsights выяснили, что только 48% стартапов удается привлечь второй раунд инвестиций, до третьего и четвертого доходят 15%, а единорогами становятся лишь 1%. Их успешность складывается из многих составляющих. Одна из них – успешный электронный дизайн в Hardware разработке, о котором и пойдет речь в этой статье.
Hardware разработка – сложный процесс. Она сильно отличается от software разработки и, например, не позволяет сделать бэкап или обновиться в случае обнаружения ошибки. Процесс разработки состоит из последовательных шагов. Пропуск любого из них несет большие риски, которые, увы, могут быть выявлены только на более поздних стадиях разработки.
Благодаря таким крупным IT-компаниям, как Яндекс, Сбер и Mail.ru сейчас на рынок поступает много девайсов российской разработки, и рынок «железных» продуктов быстро растёт. Однако менеджеров по управлению железной продуктовой разработкой на рынке совсем немного. Причина в том, что исторически «железной» и продуктовой разработкой занимались разные специалисты.
В своих подходах я ищу баланс между надежными подходами космического приборостроения и гибкими методами коммерческих компаний. На основании своего опыта работы я выделила основные этапы разработки девайса и их результаты. Вы можете ознакомиться с ними на этой диаграмме:
В этой статье я расскажу о разработке электронного дизайна устройства. Я не буду затрагивать тему разработки дизайна корпуса девайса, так как в сети есть отличная статья на эту тему.
Перед подробным разбором хочу выделить несколько этапов в разработке электронного дизайна. Это разработка технических требований (technical requirements), прототипирование (proto stage), разработка электронного дизайна (schematics, layout), изготовление сэмплов (samples production), тестирование (reliability tests) и утверждение электронного дизайна (confirmation). Для более простого запоминания ниже привожу схематичное изображение последовательности шагов. Далее в статье я детально остановлюсь на каждом шаге.
На самом начальном этапе, при определении концепции устройства, продукт-менеджер формирует требования и описывает пользовательские сценарии использования девайса. Затем вместе с командами разработки проджект менеджер описывает технические требования.
Продуктовые требования очерчивают пользовательские функции продукта, их вы обычно видите в магазине в описании девайсов. Технические требования описывают эти функции более детально и являются входными требованиями к разработке для профильных инженеров. В них указываются погрешности, диапазоны значений, требования к производительности, пропускная способность каналов, уровни напряжений и прочие технические параметры.
Чтобы лучше разобраться в отличиях продуктовых требований от технических, предлагаю вам взглянуть на эту таблицу, которую я составила из технических описаний, найденных в интернете.
Некоторые требования не существуют как продуктовые, а фигурируют только как технические. Например, требование к тепловыделению проектора или умной колонки пользователю не важно и не несет для него никакой практической пользы (если вы не разработчик обогревателей 😀 ). Но оно важно с технической точки зрения, так как перегрев некоторых компонентов может вывести девайс из строя, и пользователь не сможет больше прослушивать музыку или смотреть видосики.
Технические требования – это то, что обязательно проверяется перед утверждением электронного дизайна. Если, например, по какой-то причине требование по объему перегоняемого воздуха датчиком загрязнения воздуха не будет прописано как техническое, то на этапе тестирования оно не будет валидировано, и электронный дизайн будет утвержден без его проверки. В результате после начала продаж мы можем получить жалобы на то, что датчик загрязнения воздуха меняет свои показания при перемещении на каждые 10 см.
Чтобы не допускать таких оплошностей, предлагаю использовать мой чек-лист технических требований.
Предлагаю самостоятельно вводить и другие подразделы, если вам необходимо указать какие-то уникальные и специфические требования. Каждый параметр в подразделе стоит указывать с допустимыми отклонениями и погрешностями, ведь в мире нет ничего абсолютного.
На втором этапе проджект менеджер заказывает изготовление прототипов тех частей электронного дизайна, которые требуют проверки и подтверждения работоспособности.
Например, если это компактный девайс, то нужно проверить, влезают ли платы и самые крупные компоненты в требуемые размеры корпуса. Если мы сомневаемся, что более дешевый процессор потянет требуемую нагрузку, то покупаем отладочную плату и проверяем его работу под предполагаемой нагрузкой. Если же у команды небольшой опыт, или она делает девайс нового типа или применения, то можно быстро собрать схемотехническое решение на макетных платах и посмотреть, работают ли основные функции. Команда разработки в результате прототипирования должна убедиться, что проект реализуем.
На этапе прототипирования я рекомендую утвердить состав изделия, описанный в технических требованиях, основные функциональные блоки девайса и их назначение.
Состав работ на этапе прототипирования всегда стоит сначала обговорить с командами разработки. Прототипирование может занять несколько дней или недель, но, если вы уделите ему должное внимание, то на выходе получите более качественные и продуманные решения.
При определении объема работ прототипирования стоит также учесть, что к разным проектам предъявляются разные требования по срокам, стоимости и надежности в зависимости от особенностей их использования.
Например, технические характеристики чайника, пульта управления и умной колонки отличаются радикально. Чайник постоянно подключен к сети 220 В и пожароопасен, колонка с дешевым аккумулятором при сильном перегреве может взорваться и нанести увечья пользователю, а с пультом управления для ТВ на батарейках вряд ли может случиться что-то катастрофическое. Поэтому прототипом пульта для ТВ на батарейках может быть просто габаритный макет для проверки удобства положения в руке, а при прототипировании чайника и колонки уже нужно производить платы или отдельные функциональные узлы и проводить функциональные тесты.
Понимаю, что такое легкомысленное суждение может вызвать критику у инженеров, которые склонны перестраховываться по надежности технических решений.
Однако я оцениваю процесс с точки зрения менеджера. То есть для меня важны, в первую очередь, сроки выполнения работ и стоимость конечного продукта.
На этом этапе может возникнуть конфликт интересов, в ходе решения которого мы как команда выбираем наиболее оптимальное решение по надежности, срокам и стоимости конечного продукта.
Электронная часть устройства состоит из печатных плат с установленными электронными компонентами, коннекторов, шлейфов, антенн, кнопок и других электронных компонентов.
На этом этапе команда разработки готовит документацию для изготовления электроники. Я рекомендую использовать такой набор документации:
Чтобы не тратить время и ресурсы впустую, я бы посоветовала переходить к разработке топологии печатных плат сразу же после прототипирования и проверки электрической схемы. В противном случае, если на одном из последующих этапов будет выявлена ошибка, разработанную топологию печатной платы будет сложно и практически невозможно откорректировать, и ее придется переделывать заново.
Планированием и организацией процесса разработки в первую очередь занимаются технические лиды команд, поэтому я не буду останавливаться на нем подробно.
В VC уже были публикации про подготовку этих процессов. Например, много ценных рекомендаций по работе с БОМ файлом вы можете найти в этой статье.
Перед тем, как приступить к работе с фабрикой по производству девайсов, проджект менеджер заказывает их образцы, чтобы проверить разработанные технические решения в действии. Вместе с командой конструкторов проджект менеджер может подобрать быстрые и наиболее дешевые способы изготовления образцов, подходящие для единичного производства.
На этапе тестирования команда разработки совместно с тестировщиками проверяет, выполняет ли разработанный девайс все технические и продуктовые требования. А владельцы бизнеса, совместно с продукт-менеджером, окончательно утверждают внешний вид девайса.
Ни один вид тестирования не проводите только лишь на одном девайсе. Тестирование на разных устройствах минимизирует влияние случайных факторов. Например, ошибок монтажа, неисправностей, возникших при транспортировке, бракованного электронного компонента и даже пыли, вызвавшей короткое замыкание на плате.
Количество девайсов для каждого вида испытаний, уточняет проджект-менеджер совместно с командой разработки и QA на этапе согласования программы испытаний.
При выборе количества устройств исходите из бюджета проекта, уровня технических решений (чем сложнее устройство девайса, тем больше экземпляров потребуется). Если у вас большая команда разработки и мало времени, то рекомендую всем функциональным командам раздать минимум по три девайса, чтобы проводить проверки параллельно.
К примеру, на термоиспытания и стресс-тесты я рекомендую выделять большее количество девайсов (по 5-10 штук), чем на другие виды испытаний (2-5 шт) из-за погрешностей измерения температуры и возможной неравномерности в нагрузке девайса. То же самое касается и других важных тестов. Минимальное количество девайсов на испытания – 2-3 штуки, чтобы исключить ошибки сборки или брак какого-то одного компонента на единственном девайсе из-за того, что сборщик чихнул при сборке =D
Например, для тестирования я изготавливала 20 девайсов в корпусе и 30 комплектов плат без корпуса. Девайсы использовались для тестов, в которых корпус влияет на измерения. При проведении стресс-тестов измеряется тепловыделение девайса, и корпус играет важную роль в этом процессе – форма корпуса напрямую влияет на процесс рассеивания тепла внутри девайса.
Также на девайсах в корпусах обычно проверяются акустические параметры, работа при повышенной и пониженной температуре окружающей среды, работа компонентов, закрепленных непосредственно на корпусе (разъемы, микрофоны, кнопки и т.п.).
В одном из моих проектов на этапе EVT возникла ситуация, когда уровня напряжения сигнала управления шаговым мотором не хватило до уровня логической единицы. В итоге шаговый мотор совсем не работал, несмотря на то, что мы предварительно макетировали схему управления шаговым мотором, а в макете всё работало отлично. Также оказалось, что режим работы шагового мотора в нашем целевом железе гораздо более громкий, чем на макете. Поэтому в итоге пришлось сильно изменять схему управления, добавлять микроконтроллер и планировать повторение полного цикла EVT-тестов на следующей стадии разработки.
Из опыта своей работы, я выделила пять основных этапов испытаний электронного дизайна (EVT tests):
Приведу пример набора тестов:
Часто на этапе EVT девайс много раз собирается и разбирается, происходят замены плат и иногда компонентов, где-то что-то отваливается, отклеивается, раскручивается и ломается. Все замечания я рекомендую собирать в списки и на этапе DVT/PVT возвращаться к ним и перепроверять. На этом этапе стоит составить два списка потенциальных рисков для проверки на следующих стадиях разработки: конструктивные и сборочные.
Я рекомендую отметить все компоненты, которые плохо прикручены, раскручены, отклеены, шатаются, плохо затянуты, разбалтываются, криво посажены и припаяны, плохо стоят и упираются друг в друга и т.п.
Примером потенциального риска сборочного процесса может быть раскрученный винт (он мог раскрутиться при транспортировании или недостаточно закручен при сборке); компонент, упирающийся в другие детали; разъем, мешающий установке других компонентов; болтающиеся провода и шлейфы; ненадежное приклеивание проводов, шлейфов и прочих компонентов. Это может быть даже выкрутившийся звенящий винт, перекатывающийся внутри девайса (и такое встречалось в нескольких проектах =) )
По результатам испытаний команда разработки и тестирования принимает совместное решение: можно ли считать текущую стадию разработки завершенной. Если в процессе испытаний команда тестирования выявила недостатки, требующие доработки электронного дизайна, то проджект-менеджер совместно с командой тестирования и разработки согласовывает план мероприятий по их устранению. В зависимости от критичности недостатка и от способа его устранения я предлагаю работать по нескольким сценариям:
Если недостаток некритичный (например, необходима замена номинала резистора в том же типоразмере компонента), то можно перепаять элемент и провести повторные тесты, на которых недостаток выявился.
При некритичном недостатке с необходимостью переразведения платы, лучше всего переизготовить платы и повторить тест. Однако в зависимости от сроков проекта и процессионализма команды разработки можно принять и другие более рискованные решения. Например, иногда может потребоваться внести доработку на текущих платах, перерезав ненужные дорожки и спаяв дополнительные компоненты на проводах, и повторить испытание. В таком случае схемотехническое решение будет проверено, и останется риск только в возможной ошибке разведения платы.
При критичном недостатке с необходимостью замены микросхемы на другую в точно таком же корпусе, нужно принимать решение по ситуации. Например, если вопрос тепловыделения критичен или близок к критичному, лучше переизготовить плату, так как некачественный пропай сложного корпуса может непредсказуемо повлиять на тепловыделение.
Если недостаток критичный, то чаще всего требуется переразведение платы. Это чаще всего повлечет за собой увеличение сроков разработки.
После успешного прохождения всех испытаний команда разработки и тестирования принимает решение об утверждении электронного дизайна. Это означает, что команды разработки и тестирования создали документанцию, изготовили девайсы и проверили выполнение всех технических и продуктовых требований. Можно переходить на следующую стадию разработки – DVT.
Все выявленные ошибки должны быть устранены до начала этой стадии разработки. Если какая-то проблема будет выявлена на стадии DVT, это потребует перезапуска туллинга. То есть нужно будет заново начать стадию DVT с новой оплатой и потерей 45 дней.
Поэтому так важно внимательно отнестись к составу работ на каждом этапе до запуска туллинга, произвести прототипирование важных функциональных узлов и проверить все технические требования.
Это мой первый опыт публикации в VC. Буду рада узнать, откликнулась ли у вас эта статья и почитать в комментариях о вашем опыте в hardware разработке. В следующих статьях я хотела бы подробнее рассказать о видах испытания «железа» и поделиться своим опытом запуска серийного производства в одной российской компании. Хотели бы узнать больше об этих темах?:)
П.С.: Спасибо Насте Седухиной за помощь в ректировании текста.
