Это третья из четырех статей о разработке физических продуктов. Если вы пропустили Часть 1: Формирование идеи, или Часть 2: Дизайн, стоит их прочитать. Вскоре вы сможете перейти к Части 4: Валидация. Автор: Ben Einstein. Оригинал Перевод выполнен командами фаблаба FABINKA и проекта РУКИ.
Каждый шаг на стадии конструирования (разработка технических требований, создание функционирующего прототипа, программирование прошивки/софта) нужен чтобы убедиться в том, что продукт надёжно функционирует и его производственная себестоимость оптимальна. Результат процесса инженерной разработки — прототип, который корректно функционирует, но пока не имеет хороших пользовательских характеристик (UX) и визуально не слишком благороден. Конструирование и дизайн продукта почти всегда идут одновременно.
Рисунок 3.1 Этапы конструирования продуктов
Один из лучших показателей хорошо спроектированного продукта — детальность технической документации.
Рисунок 3.2 Место формирования технических требований в цикле разработки продуктов
Технические требования к продукту («spec») — критически важный документ при создании любого физического продукта. В то время как многие стартапы считают любой вид документации необязательным и затратным, я видел, как компании теряли месяцы и десятки тысяч долларов из-за того, что детально не продумали технические требования.
Рисунок 3.3 Категории технических требований
Требования к большинству продуктов могут быть определены семью основными областями:
Рисунок 3.4 Пример сформированных технических требований
Многие крупные компании зависят от гор документации. Эти горы документов обычно многократно заверены и полны таблиц со всеми возможными деталями. Хотя это и необходимо для определённых типов продуктов, для большинства быстрых и гибких компаний такой подход непрактичен.
Рисунок 3.5 Пример рабочей спецификации технических требований
Я нахожу более эффективным полагаться на рабочую спецификацию требований (working spec). Такой документ как правило расшаривается онлайн (к примеру, в Google Drive) и декомпозируется на несколько групп требований. Многие компании постоянно обновляют этот документ, по мере детализации понимания требований к продукту. Хорошей идеей будет продумать все возможные требования к продукту и отметить те, которые вы ещё не знаете, но должны выяснить (жирным шрифтом и пометкой «уточнить»).
Когда вы внесёте в рабочую спецификацию достаточно информации, наступит время ответить на каждое требование техническим решением. Для этого создаётся прототип, который внешне может отличаться от продукта, но работает как продукт и отвечает каждому требованию спецификации.
Рисунок 3.6 Место создания функционирующего прототипа в цикле разработки продуктов
Функционирующий прототип создается для ответов на множество вопросов, возникших при разработке технических требований: основные функции, выбор компонентов, печатные платы, механика, «ощущение» продукта и сборка.
Рисунок 3.7 Итерации конструкции кронштейна для обеспечения основного функционала
Большинство продуктов имеют «основной функционал», который является определяющим для эффективной работы продукта. Для DipJar это считывание карты и проведение транзакции. На фотографии выше вы можете увидеть, как изменялась конструкция кронштейна для считывателя карты и какие конструктивные варианты были протестированы в ходе разработки: (слева направо) от самого грубого напечатанного на 3D принтере кронштейна до прототипа, созданного с помощью пресс-формы. Считывающая головка также была изменена после определения оптимального способа монтажа для более устойчивого считывания магнитной полосы карты.
Рисунок 3.8 Подбор компонентов: пример выбора динамиков
Выбор компонентов может занять несколько месяцев отбора и квалификации (тестирования) для уверенности в том, что они отвечают требованиям функциональности и надёжности. На фотографиях выше — несколько модулей динамиков, которые протестировал DipJar для оптимизации комбинации цены, качества звука, надёжности и доступности/скорости поставки.
Рисунок 3.9 Эволюция печатной платы DipJar
Если в вашем продукте есть печатная плата, потребуется около 5-10 доработок перед запуском в массовое производство. Процесс разработки платы начинается с выбора компонентов, далее — макетирования платы (bread-boards, слева) и затем — создания серии фабричных плат. Основная плата DipJar прошла через 6 итераций перед первым запуском в производство у контрактного производителя (CM, contract manufacturing).
Рисунок 3.10 Работы с корпусом DipJar
Все компоненты и платы должны быть защищены. Если в корпусе используется металл, работа с ним часто требует длительного цикла разработки. Так, на внешний корпус DipJar ушло несколько месяцев.
Рисунок 3.11 Пластиковые детали DipJar
Почти каждый продукт, с которым я работал, имел по крайней мере одну пластиковую деталь. Литые пластиковые детали обычно требуют 8-12 недель разработки и отладки, поэтому нужно как можно быстрее разработать их дизайн и конструкцию. Верхняя панель DipJar изменилась от крайне сложной для литья слева, до финальной версии справа. Были оптимизированы многие параметры: ранее проектные, толщина стенок, окружности, бобышки под крепёж, теплоотводы, оптика, текстура обработки, прочность конструкции.
Рисунок 3.12 Утяжелители для формирования ощущения продукта
Также очень важно «ощущение» продукта (the «feel» of product). Во многих продуктах используют внутренние утяжелители или утолщают стенки для создания такого тактильного ощущения, которое совпадает с визуальным. DipJar имеет относительно высокий центр тяжести, и поэтому его основа утяжелена вырезанным лазером противовесом из стали. Во второй партии для снижения себестоимости стальной противовес был заменен на алюминиевый.
Рисунок 3.13 Сборка
После отбора каждого компонента, проектирования пластиковых частей и ревизии плат, важно оценить собираемость продукта. На ранних стадиях функционирующего прототипа достаточно ответа на вопрос собирается продукт или нет. Чем ближе продукт к массовому производству, тем более важно сфокусироваться на возможных ошибках при сборке и на оптимизации стоимости и времени производства. Проектирование сборки также включает планирование кабельной укладки, выбор клейких веществ, крепежа, выравнивающих и позиционирующих элементов, зазоров и доступности деталей.
Почти все продукты, в которые инвестировала Bolt, имеют и прошивку, и ПО. К сожалению, эти работы обычно должны производиться после создания прототипа, так как ПО зависит от работы аппаратной части продукта.
Рисунок 3.14 Место разработки прошивки и софта в цикле разработки продуктов
Инженеры-электротехники и специалисты по встроенным системам используют разнообразные подходы и последовательности разработки во время работы над прошивкой. Самый распространенный подход «снизу-вверх».
Рисунок 3.15 Прошивка и софт
Процесс начинается на самом нижнем уровне (аппаратная часть) и идет вверх до веб-софта:
1. Аппаратный тест — создание основных функций для проверки корректной работы плат и правильности схем. Чтобы найти основные проблемы первой ревизии используются заливка прошивки, циклично подающееся питание, мигающие светодиоды, подача питания на средства коммуникации и прочее.
2. Команды — проверка всех цифровых компонентов (I2C, SPI, USB, последовательные шины и др.) Это основной функциональный тест, который гарантирует, что компоненты дают корректные отклики.
3. Функции — упаковка каждого набора команд и логических последовательностей в пользовательские функции. В случае DipJar основная функция — ввести сумму в долларах и отобразить ее на LED матрице.
4. Библиотека — разработка групп функций, которые находятся вместе и зависят друг от друга. Например, все функции дисплея или все функции модема.
5. Блок управления— многие продукты работают с многопоточными данными, при этом бывает сложно добиться надежной работы каждого потока. DipJar должен считывать кредитку за несколько секунд, то есть он имеет один поток данных сотовой связи и один поток данных управления матрицей дисплея и звуковой обратной связью.
6. API/сеть — выделенные функции коммуникации с различными веб-сервисами. Многие продукты имеют двустороннюю связь: как оборудование коммуницирует с сервером, так и сервер коммуницирует с оборудованием. Построение организованного, рационального API гарантирует эффективность и стабильность связи.
Рисунок 3.16 Итерации: работа над ошибками и исправление недостатков
Часто после первой сборки работающего прототипа определяется море недостатков. Иногда спецификация имеет неполные/не верные требования, или компоненты могут не соответствовать требованиям спецификации. Обычно создают 3-4 полнофункциональных прототипа, прежде чем двигаться дальше к финальной стадии разработки.
Рисунок 3.17 Финальный функционирующий прототип
В качестве результата работ, прототип должен подтвердить целесообразность серийного производства надёжного продукта. На фото выше – окончательный рабочий прототип с ещё недоработанными деталями (красная стрелка указывает на нечёткие светодиоды, серый цвет пластика, слишком большие швы на металлическом кожухе), но этот продукт уже подключается к сотовой сети и имеет надежный API для работы с картой.
Когда рабочий прототип соответствует всем требованиям спецификации, время подготовиться к производству. Вперёд к Части 4: Валидация
Это третья из четырех статей о разработке физических продуктов. Если вы пропустили Часть 1: Формирование идеи, или Часть 2: Дизайн, стоит их прочитать. Вскоре вы сможете перейти к Части 4: Валидация. Автор: Ben Einstein. Оригинал twitter medium Перевод выполнен командами фаблаба FABINKA и проекта РУКИ.
Часть 3: Конструирование
Каждый шаг на стадии конструирования (разработка технических требований, создание функционирующего прототипа, программирование прошивки/софта) нужен чтобы убедиться в том, что продукт надёжно функционирует и его производственная себестоимость оптимальна. Результат процесса инженерной разработки — прототип, который корректно функционирует, но пока не имеет хороших пользовательских характеристик (UX) и визуально не слишком благороден. Конструирование и дизайн продукта почти всегда идут одновременно.
Рисунок 3.1 Этапы конструирования продуктов
Технические требования (Engineering Specification)
Один из лучших показателей хорошо спроектированного продукта — детальность технической документации.
Рисунок 3.2 Место формирования технических требований в цикле разработки продуктов
Технические требования к продукту («spec») — критически важный документ при создании любого физического продукта. В то время как многие стартапы считают любой вид документации необязательным и затратным, я видел, как компании теряли месяцы и десятки тысяч долларов из-за того, что детально не продумали технические требования.
Рисунок 3.3 Категории технических требований
Требования к большинству продуктов могут быть определены семью основными областями:
- Коммерческие и нормативные — страны продаж и рекомендованная розничная цена (РРЦ, MSRP, manufacturer's suggested retail price), нормативные требования, приемлемая структура прибыли, график обновления продукта (конец срока службы, End-of-life, EOL)
- Аппаратная часть и датчики — полная схема аппаратной системы, список основных компонентов по спецификации (BOM, bill of materials), требования к датчикам
- Электроника — размер плат (PCB, printed circuit boards), объем памяти, требования к процессорам и коммуникациям, размер/время жизни/химический состав элементов питания
- Прошивки и библиотеки — операционная система или встроенная среда, используемая прошивкой, API спецификации, требования к внешним библиотекам
- Программное обеспечение и сеть — стек софта и среда для разработки, требования к серверной инфраструктуре, планы SCM (Software Configuration Management), обработка ошибок
- Долговечность и упаковка — требования к сроку эксплуатации, выносливости различных подсистем, требования к упаковке
- Экология и эксплуатация — рабочие температуры и влажность, описание эксплуатационной надёжности, уставки и допуски, требования к процессам возврата/замены, требования к клиентской поддержке и к запасным частям
Рисунок 3.4 Пример сформированных технических требований
Многие крупные компании зависят от гор документации. Эти горы документов обычно многократно заверены и полны таблиц со всеми возможными деталями. Хотя это и необходимо для определённых типов продуктов, для большинства быстрых и гибких компаний такой подход непрактичен.
Рисунок 3.5 Пример рабочей спецификации технических требований
Я нахожу более эффективным полагаться на рабочую спецификацию требований (working spec). Такой документ как правило расшаривается онлайн (к примеру, в Google Drive) и декомпозируется на несколько групп требований. Многие компании постоянно обновляют этот документ, по мере детализации понимания требований к продукту. Хорошей идеей будет продумать все возможные требования к продукту и отметить те, которые вы ещё не знаете, но должны выяснить (жирным шрифтом и пометкой «уточнить»).
Функционирующий прототип
Когда вы внесёте в рабочую спецификацию достаточно информации, наступит время ответить на каждое требование техническим решением. Для этого создаётся прототип, который внешне может отличаться от продукта, но работает как продукт и отвечает каждому требованию спецификации.
Рисунок 3.6 Место создания функционирующего прототипа в цикле разработки продуктов
Функционирующий прототип создается для ответов на множество вопросов, возникших при разработке технических требований: основные функции, выбор компонентов, печатные платы, механика, «ощущение» продукта и сборка.
Рисунок 3.7 Итерации конструкции кронштейна для обеспечения основного функционала
Большинство продуктов имеют «основной функционал», который является определяющим для эффективной работы продукта. Для DipJar это считывание карты и проведение транзакции. На фотографии выше вы можете увидеть, как изменялась конструкция кронштейна для считывателя карты и какие конструктивные варианты были протестированы в ходе разработки: (слева направо) от самого грубого напечатанного на 3D принтере кронштейна до прототипа, созданного с помощью пресс-формы. Считывающая головка также была изменена после определения оптимального способа монтажа для более устойчивого считывания магнитной полосы карты.
Рисунок 3.8 Подбор компонентов: пример выбора динамиков
Выбор компонентов может занять несколько месяцев отбора и квалификации (тестирования) для уверенности в том, что они отвечают требованиям функциональности и надёжности. На фотографиях выше — несколько модулей динамиков, которые протестировал DipJar для оптимизации комбинации цены, качества звука, надёжности и доступности/скорости поставки.
Рисунок 3.9 Эволюция печатной платы DipJar
Если в вашем продукте есть печатная плата, потребуется около 5-10 доработок перед запуском в массовое производство. Процесс разработки платы начинается с выбора компонентов, далее — макетирования платы (bread-boards, слева) и затем — создания серии фабричных плат. Основная плата DipJar прошла через 6 итераций перед первым запуском в производство у контрактного производителя (CM, contract manufacturing).
Рисунок 3.10 Работы с корпусом DipJar
Все компоненты и платы должны быть защищены. Если в корпусе используется металл, работа с ним часто требует длительного цикла разработки. Так, на внешний корпус DipJar ушло несколько месяцев.
Рисунок 3.11 Пластиковые детали DipJar
Почти каждый продукт, с которым я работал, имел по крайней мере одну пластиковую деталь. Литые пластиковые детали обычно требуют 8-12 недель разработки и отладки, поэтому нужно как можно быстрее разработать их дизайн и конструкцию. Верхняя панель DipJar изменилась от крайне сложной для литья слева, до финальной версии справа. Были оптимизированы многие параметры: ранее проектные, толщина стенок, окружности, бобышки под крепёж, теплоотводы, оптика, текстура обработки, прочность конструкции.
Рисунок 3.12 Утяжелители для формирования ощущения продукта
Также очень важно «ощущение» продукта (the «feel» of product). Во многих продуктах используют внутренние утяжелители или утолщают стенки для создания такого тактильного ощущения, которое совпадает с визуальным. DipJar имеет относительно высокий центр тяжести, и поэтому его основа утяжелена вырезанным лазером противовесом из стали. Во второй партии для снижения себестоимости стальной противовес был заменен на алюминиевый.
Рисунок 3.13 Сборка
После отбора каждого компонента, проектирования пластиковых частей и ревизии плат, важно оценить собираемость продукта. На ранних стадиях функционирующего прототипа достаточно ответа на вопрос собирается продукт или нет. Чем ближе продукт к массовому производству, тем более важно сфокусироваться на возможных ошибках при сборке и на оптимизации стоимости и времени производства. Проектирование сборки также включает планирование кабельной укладки, выбор клейких веществ, крепежа, выравнивающих и позиционирующих элементов, зазоров и доступности деталей.
Прошивка и софт (Firmware and Software)
Почти все продукты, в которые инвестировала Bolt, имеют и прошивку, и ПО. К сожалению, эти работы обычно должны производиться после создания прототипа, так как ПО зависит от работы аппаратной части продукта.
Рисунок 3.14 Место разработки прошивки и софта в цикле разработки продуктов
Инженеры-электротехники и специалисты по встроенным системам используют разнообразные подходы и последовательности разработки во время работы над прошивкой. Самый распространенный подход «снизу-вверх».
Рисунок 3.15 Прошивка и софт
Процесс начинается на самом нижнем уровне (аппаратная часть) и идет вверх до веб-софта:
1. Аппаратный тест — создание основных функций для проверки корректной работы плат и правильности схем. Чтобы найти основные проблемы первой ревизии используются заливка прошивки, циклично подающееся питание, мигающие светодиоды, подача питания на средства коммуникации и прочее.
2. Команды — проверка всех цифровых компонентов (I2C, SPI, USB, последовательные шины и др.) Это основной функциональный тест, который гарантирует, что компоненты дают корректные отклики.
3. Функции — упаковка каждого набора команд и логических последовательностей в пользовательские функции. В случае DipJar основная функция — ввести сумму в долларах и отобразить ее на LED матрице.
4. Библиотека — разработка групп функций, которые находятся вместе и зависят друг от друга. Например, все функции дисплея или все функции модема.
5. Блок управления— многие продукты работают с многопоточными данными, при этом бывает сложно добиться надежной работы каждого потока. DipJar должен считывать кредитку за несколько секунд, то есть он имеет один поток данных сотовой связи и один поток данных управления матрицей дисплея и звуковой обратной связью.
6. API/сеть — выделенные функции коммуникации с различными веб-сервисами. Многие продукты имеют двустороннюю связь: как оборудование коммуницирует с сервером, так и сервер коммуницирует с оборудованием. Построение организованного, рационального API гарантирует эффективность и стабильность связи.
Рисунок 3.16 Итерации: работа над ошибками и исправление недостатков
Часто после первой сборки работающего прототипа определяется море недостатков. Иногда спецификация имеет неполные/не верные требования, или компоненты могут не соответствовать требованиям спецификации. Обычно создают 3-4 полнофункциональных прототипа, прежде чем двигаться дальше к финальной стадии разработки.
Рисунок 3.17 Финальный функционирующий прототип
В качестве результата работ, прототип должен подтвердить целесообразность серийного производства надёжного продукта. На фото выше – окончательный рабочий прототип с ещё недоработанными деталями (красная стрелка указывает на нечёткие светодиоды, серый цвет пластика, слишком большие швы на металлическом кожухе), но этот продукт уже подключается к сотовой сети и имеет надежный API для работы с картой.
Когда рабочий прототип соответствует всем требованиям спецификации, время подготовиться к производству. Вперёд к Части 4: Валидация
Это третья из четырех статей о разработке физических продуктов. Если вы пропустили Часть 1: Формирование идеи, или Часть 2: Дизайн, стоит их прочитать. Вскоре вы сможете перейти к Части 4: Валидация. Автор: Ben Einstein. Оригинал twitter medium Перевод выполнен командами фаблаба FABINKA и проекта РУКИ.
