Под катом — конспект моего недавнего доклада. В нем два больших блока: про этапы разработки устройства и про общение с фабриками в Китае. Надеюсь, конспект будет полезен тем, кто начинает думать о производстве собственных устройств.
- Как мы разрабатываем устройства
Исследование проблемы и proof of concept
Между proof of concept и инженерным прототипом
Инженерный прототип
Как мы со всем этим взлетим?
Engineering validation test, EVT
Design validation test, DVT
Production validation test, PVT - Фабрики
- Споры между заказчиком и фабрикой
1. Несоответствие ожиданий сторон
2. Нечетко прописанные роли и ответственность
3. Отсутствие компетенций
4. Непонимание мотивации сторон - Качество и прибыль
- Немного о Китае
- Итог
— Яндекс делает множество устройств — электронику для беспилотного автомобиля, бортовые компьютеры Яндекс.Авто, устройства контроля внимания водителей Такси, собственные серверы для дата-центров. Моя команда отвечает за умные колонки — сейчас это Яндекс.Станция и Яндекс.Станция Мини, а также за устройства умного дома: умную розетку и умный пульт Яндекса.
Как мы разрабатываем устройства
Разработка и производство неразрывно связаны. Есть хороший теоретический план от Бена Эйнштейна:
Бен очень красиво отразил всю сложность процесса разработки реального hardware-продукта, в его статье много примеров. Давайте разберем план слева направо.
Исследование проблемы и proof of concept
Сначала надо понять, какой же девайс мы выпускаем, зачем он нам нужен, как он соответствует стратегии компании или продукта, по какой цене мы хотим его продавать, какие фичи у него должны быть. Мы впервые задумываемся, возможно ли такое устройство сделать физически, хватит ли у нас ресурсов на разработку и прочее.
Это классический этап анализа, «что делать». Он отнимает много времени, потому что надо продумать очень много вещей, найти стейкхолдеров внутри компании и договориться со всеми.
Между proof of concept и инженерным прототипом
Здесь мы решаем, как устройство будет выглядеть и как оно будет устроено. На плане видно, что здесь происходит два параллельных процесса. Первый процесс связан с внешним видом девайса, второй — с внутренним устройством.
Внешний вид и UI/UX: кнопки, LED, звуки, настройка, упаковка
С одной стороны, здесь мы прорабатываем вопросы внешнего вида: планируем, будет ли устройство круглым или квадратным, тканевым или пластиковым, черным или белым и т. д.
С другой, здесь же возникает очень серьезная часть задач — всё вокруг UI/UX. Предположим, устройство должно мигать лампочкой. Тогда именно здесь решается, сколько должно быть этих лампочек, белые они или цветные. Как устройство реагирует звуком, как мы будем обеспечивать настройку девайса? И прочее. Это гораздо больше, чем просто внешний вид.
Внутреннее устройство
Параллельно идет поток чисто инженерных задач. Если говорить про умные колонки, то тут мы делаем первые прикидки, сколько нам нужно динамиков, где мы расположим платы, примерно как они будут между собой соединяться, какой софт нам нужен, какие компоненты будут стоять внутри устройства и на самой плате. Это ранний инжиниринг. Здесь мы широкими мазками понимаем, из чего состоит девайс и как его компоненты связаны между собой.
Инженерный прототип
Впервые ветки внешнего вида (оранжевая) и внутреннего устройства (синяя) соединяются в инженерном прототипе. Причина очевидна: многие связанные с UX вещи надо сбалансировать с инжинирингом. Например — как подвести провода к кнопкам, где эти кнопки расположены, как форма устройства влияет на размер платы и прочее.
Получившийся инженерный прототип очень смутно похож на финальное устройство. Обычно он сделан на 3D-принтере и выглядит некрасиво. Но он уже как-то работает и (хотя бы по габаритам) похож на итоговое устройство.
Как мы со всем этим взлетим?
С одной стороны, на этапе внешнего вида возникают очень крутые внешние концепты. Инженеры думают: мы сейчас поставим какой-нибудь офигенный процессор, суперусилители, и у нас все будет невероятно круто звучать. Но не все так просто.
Между инженерным прототипом и тем, что пойдет в продажу, находится как минимум очень глубокая пропасть, целый каньон. Почему?
- Прототип никогда не бывает пригодным для удержания себестоимости. Иногда он стоит тысячи долларов, даже если мы делаем элементарный девайс.
- Обычно прототип физически невозможно произвести на конвейере, это штучная вещь.
- Качество прототипа оставляет желать лучшего. Он может зависать, перегреваться и прочее.
Как преодолеть этот каньон различий между прототипом и финальным устройством? Это очень важный этап, на нем останавливались самые крутые проекты с гигантским финансированием, суперкомандами и т. п. (Вспомните анонсированную, но так и не выпущенную беспроводную зарядку Apple AirPower.)
Весь мой дальнейший рассказ будет о том, каким образом перейти от прототипа к массовому производству. Глобально можно сказать, что этот путь разбит на три этапа: EVT, DVT и PVT. Это очень важные для нас слова, прямо религиозные.
Engineering validation test, EVT
Здесь мы проверяем, что устройство способно работать как надо. Что это значит? Мы начинаем тестировать все крупные компоненты девайса. Например, Wi-Fi-модуль должен не просто раздавать или принимать сигнал, но и работать надежно и качественно, не теряя пакеты и прочее. Динамики не просто играют музыку, но играют ее действительно хорошо, так, чтобы это соответствовало требованиям к устройству. Устройство не просто работает, но еще и выполняет требования, выданные сертификационными органами. Например, проходит тесты по электростатическому напряжению или по электромагнитному излучению.
Это очень итеративный процесс. Мы устраиваем гору тестов различных компонентов и девайса целиком, много раз что-то исправляем, подбираем те или иные компоненты, ругаемся, меняем поставщиков компонентов, оптимизируем цену, срываем сроки.
В конце этого этапа мы получаем по-прежнему некрасивое устройство, но уже нормально работающее с точки зрения пользовательского восприятия и основных функций. Внешний вид устройства будет очень далек от финального, но первые попытки сделать девайс похожим на финал мы тоже делаем на этом этапе.
Design validation test, DVT
Здесь мы решаем вопрос оптимальности устройства. Что это значит?
С одной стороны, мы проверяем, что устройство действительно имеет требуемую себестоимость. То есть занимаемся подбором компонентов — качественных, но не заоблачных по цене.
С другой стороны, мы впервые начинаем видеть девайс в красивом виде: его дизайн уже достаточно близок к финальному. Приведу пример: Яндекс.Станция покрыта тканью, и мы проверяем, что даже при долгой работе или в помещении с очень высокой температурой или влажностью цвет ткани не будет выгорать, пластик не будет менять свой цвет, а само устройство будет нормально работать и не перегреваться.
Когда человек тестирует образцы на этом этапе, его не только не должно бить током. Ему должно быть удобно, кнопочки должны нажиматься приятно, диоды — светить комфортно и прочее. Мы стараемся произвести хотя бы несколько сотен экземпляров, привезти их в Яндекс и раздать сотрудникам под строжайшим NDA. Люди могут попробовать будущее устройство и накидать нам гору замечаний.
Например, в Яндекс.Станции Мини есть датчик жестов. На этапе DVT мы обнаружили, что датчик часто реагирует на домашних животных, которые проходят мимо. Мы поняли, что алгоритм надо улучшать.
Production validation test, PVT
Последний этап перед массовым производством. 80% этой задачи выполняется фабрикой, которая готовится к началу производства. Она убеждается:
- что устройство можно произвести в необходимом количестве за необходимое время,
- что процессы, которые фабрика будет использовать для производства, обеспечивают необходимые показатели по качеству, темпам производства и т. д.
Теоретически, PVT плавно перетекает в этап массового производства. Потому что если этап PVT успешно пройден, это показывает, что девайс можно производить массово.
EVT, DVT и PVT выполняются совместно с фабрикой. Дальше я поговорю о том, почему и каким образом мы с ней взаимодействуем, а не делаем всё в одиночку.
Фабрики
Для этой статьи я стал искать иллюстрацию, которая бы рассказала, какие бывают модели взаимодействия с фабриками. (слова OEM, ODM, или Contract Manufacturing кто-то, возможно, слышал, а кто-то нет). И я понял, что на самом деле это жутко холиварная тема.
Я нашел в интернете множество определений OEM, ODM, и других терминов. Некоторые из них противоречат друг другу. Я не претендую на истину, но считаю, что здесь все написано более-менее честно:
Умные колонки мы делаем примерно по модели JDM. Российская команда Яндекса сделала инженерный прототип девайса. Потом мы начинаем ходить по определенному списку фабрик Китая и говорим: «У нас есть прототип, мы хотим производить такой-то объем устройств — возможно, на вашей фабрике. Давайте подумаем, не хотите ли вы такое делать, и сколько это будет стоить». Мы выбираем фабрику по многим критериям, это тема для отдельного поста.
Вместе с выбранной фабрикой мы начинаем итеративно приводить прототип к девайсу, который будем массово производить. То есть проходим этапы EVT, DVT и PVT. Фабрика нам помогает и направляет нас. Например, советует: «Обратите внимание: вы используете компоненты, которые не оптимальны по цене, мы вам рекомендуем использовать другие варианты». Мы это валидируем, говорим: «Да, давайте поменяем». Или: «Нет, они по качеству не подходят».
Фабрика в этой модели либо производит, либо закупает компоненты для устройства — все или часть из них. Также фабрика готовит технологический процесс производства: придумывает, сколько человек будет стоять на конвейере и в каком порядке расположены операции сборки, разрабатывает оснастку — механизмы, с помощью которых девайс производится.
Пример оснастки — приспособление, натягивающее ткань на пластиковый корпус устройства так, чтобы натяжение было равномерным, без складок и растяжений.
Конечно, фабрика всегда действует с оглядкой на то, сколько устройств за смену мы должны производить и с каким качеством. От этого зависит степень автоматизации, качество оснастки, уровень персонала и прочее. Сборкой, упаковкой и подготовкой к отгрузке тоже занимается фабрика.
Теперь я расскажу, какие конфликты могут возникать между нами и фабрикой, какие шишки мы здесь набили и как начинающие команды могут «подстелить соломки».
Споры между заказчиком и фабрикой
1. Несоответствие ожиданий сторон
Мы миллион раз слышали фразу: «А мы думали, что вы от нас хотите другого». Или: «JBL делает это сам, а у Google другие стандарты». Почему так?
Дело в том, что Яндекс производит устройства на фабриках, где также производят устройства мировые лидеры в области акустики. Для нас это достаточно новый бизнес, многие вещи мы только учимся делать, но ожидания фабрики к нам строятся исходя из многолетнего опыта с крупными акустическими вендорами.
Нужно либо быть похожим на других клиентов фабрик по процессам и стандартам; либо, если у нас другие стандарты, договориться об ожиданиях между фабрикой и нами. И обязательно мотивировать фабрику на встречный диалог, чтобы сотрудники делились своими ожиданиями. Важно узнать, чего они от нас ждут, какие потребуются документы и прочее. Здесь мы плавно переходим к следующему пункту,
2. Нечетко прописанные роли и ответственность
Приведу пример из последнего проекта. Мы гордо притащили на фабрику достаточно сложную плату и говорим: «Ребята, смотрите, мы не потратили ни минуты вашего времени, вот готовая плата, она супер, можно пускать в производство». Но руководитель проекта со стороны фабрики возмутился, был жаркий спор.
Когда мы все успокоились и поговорили, выяснилось, что плату-то мы им нарисовали, но остался открытым вопрос, как ее контролировать на этапе производства, как определить ее работоспособность. И у завода возник гигантский риск, что они будут производить платы, собирать устройства, а на финальных тестах выяснится, что плата не работает.
Поэтому один из ключевых документов, которые возникают в работе с фабрикой, — это roles and responsibility, RNR. В нем фиксируется, кто что делает и какова роль каждой из сторон на каждом этапе. Вот пример реальной таблицы одного из наших проектов:
R — Responsible
A — Approver
S — Supports
C — Consults
I — Informed
Как видите, мы разбили проект на ключевые компоненты. По каждому из них прописаны роли всех участников. Каждая из компаний может быть ответственной, согласующей, поддерживающей, консультирующей или просто информирующей. Кстати, на варианте «I» я хотел сделать акцент. Часто его забывают вставить, но вопрос обмена информацией между участниками очень важен. Если кто-нибудь считает, что вы должны информировать его об изменениях, не забывайте это делать, это уже из личного опыта.
RNR — не панацея. Ничего кроме регулярного общения и поддержания атмосферы открытости и доверия не поможет вам разруливать конфликтные ситуации. Такова ежедневная работа проджект-менеджера — слышать свою команду, слышать команду фабрики и, в частности, поддерживать и налаживать постоянный обмен информацией между сторонами. Одного документа RNR недостаточно.
3. Отсутствие компетенций
Действительно, мы в своих девайсах иногда делаем нечто, что раньше в мире никто не делал. И если вы делаете какую-нибудь необычную вещь — просто заложите себе достаточно ресурсов. Например, мы, насколько мне известно, первыми в мире использовали датчик ToF для управления жестами в Яндекс.Станции Мини. Мы потратили очень много времени: потребовалось не только сделать такое устройство, но и наладить процесс контроля качества этого датчика. Последнее оказалось гораздо более сложным, чем мы могли себе представить.
4. Непонимание мотивации сторон
Еще один пример из производства Станции Мини. Мы запустили массовое производство, померили качество первых нескольких партий, были удовлетворены низким уровнем брака. Но, вижу, директор завода не слишком доволен происходящим. Я пошел с ним поговорить. Выяснилось, что все здорово, но мы обложили девайсы таким количеством уровней тестов, что фабрика не могла выпускать их нужным объемом за смену. Чтобы выполнить наш план, им приходилось выводить ночную смену — которая выше оплачивается. Девайс получился дороже, чем они планировали.
Хорошо, что мы поговорили, разобрались, убрали избыточные тесты и решили проблему. Но глобально надо держать в уме, что у разных участников проекта разные цели. И конечно, реакция сторон на ход проекта тоже будет разной.
Качество и прибыль
Еще раз: у каждого свое видение проекта. С точки зрения фабрики прибыль — это такое банальное уравнение:
В этой формуле нет качества, надо четко отдавать себе в этом отчет.
Фабрике нужны деньги. При этом желательно удешевить производство и стоимость компонентов. Качество — это исключительно головная боль заказчика. Только вас волнует качество. Сделать производство качественным и заставить сотрудников фабрики думать о качестве — ваша задача.
Немного о Китае
Возьмем два популярных заблуждения про Китай.
1. «Есть разные китайцы»
Или: «На твоей фабрике люди работают лучше, чем на моей». Не совсем так. Это зависит во многом от того, был ли у сотрудников опыт работы с западными компаниями. Скорее всего, если фабрика взаимодействовала только с внутренним рынком Китая, она:
- Мало что слышала о лицензировании технологий и проприетарных решениях, которые нельзя копировать. Вам могут предложить сделать что-нибудь, «как у Google»: без лицензии и возни с правами на технологии. Сотрудники фабрики не будут воспринимать это как нечто неприемлемое.
- Не закладывает время и ресурсы на получение сертификации. Предположим, мы хотим обозначить для пользователя, что устройство можно подключить по HDMI. Для этого необходимо провести множество тестов и убедиться, что интерфейс HDMI действительно работает в разных уникальных ситуациях (а затем еще исправить найденные ошибки). Фабрика, в свою очередь, просто разместит порт HDMI в нужном месте и даже не задумается о тестировании.
- Имеет слабое представление об эстетике. Однажды мы отправили подрядчику дизайн коробки для умной розетки Яндекса. Картинка на прототипе коробки, который мы получили в ответ, явно «съехала» при печати: уместилась только часть текста. Когда мы попросили всё переделать, представители фабрики искренне удивились — разве важно, чтобы картинка помещалась целиком?
Есть и другие сложности, с которыми вы можете столкнуться, если выберете фабрику без опыта зарубежных поставок.
2. «На китайцев надо кричать»
Этот миф возник из-за того, что в некоторых регионах страны принято громко разговаривать, и речь на повышенных тонах не является признаком неуважения. Для западного мира такая модель непривычна. Можно попробовать тоже начать говорить громко, главное не ругаться, не давить на людей по-настоящему.
* * *
Итак, мы работаем по схеме JDM: разрабатываем девайс, а потом вместе с фабрикой приземляем его на производство. Конечно, у нас бывают проблемы, которые мы научились решать с помощью аккуратной проработки RNR. Нужно следовать этому документу и регулярно общаться с фабрикой: созваниваться, а лучше устраивать регулярные личные встречи между командами. Учитывайте интересы партнеров по проекту. Если вы делаете что-то впервые, заложите ресурсы с запасом. И помните, что качество — только ваша проблема.
