Почему 90% компаний терпят неудачу в исследованиях и разработках бытовой техники? Получите экспертную техническую консультацию сегодня.

Многие проекты по исследованию и разработке бытовой техники терпят неудачу не потому, что команде инженеров не хватает навыков. Они терпят неудачу, когда идея продукта, потребности клиентов, технический план, целевые затраты и производственный процесс движутся в разных направлениях. Я видел, как команды тратили месяцы на доработку двигателя, платы управления или конструкции корпуса, прежде чем проверить, решает ли продукт четкую бытовую проблему. Прототип может работать в испытательной комнате, но плохо работать в маленькой квартире, на влажной кухне или в доме с нестабильным электроснабжением. Этот разрыв может привести к перепроектированию, задержке производства, росту затрат и слабой реакции рынка. Оптимизированный процесс разработки устройств с самого начала объединяет исследования, проектирование, тестирование и производство. Я начинаю с определения проблемы пользователя. Команда может сказать: «Нам нужна более тихая стиральная машина». Это предложение слишком широкое. Спрашиваю: - Насколько громкое нынешнее изделие? - Когда шум беспокоит пользователя? - Проблема в вибрации двигателя, потоке воды, перемещении корпуса или установке? - Согласятся ли пользователи на более высокую цену за меньший уровень шума? - Есть ли на целевом рынке разные типы этажей или планировки помещений? Эти вопросы превращают общую идею продукта в краткое описание дизайна. Краткое описание должно включать четкую группу пользователей, измеримую проблему, ожидаемую производительность, целевую стоимость, потребности в обслуживании и требования безопасности. В полезном описании может быть указано: «Продукт должен снижать шум стирки во время ночных циклов для пользователей квартир, поддерживать стабильную производительность уборки, соответствовать стандартным местам установки и оставаться в пределах запланированной производственной себестоимости». Это дает команде исследований и разработок единое направление. Это также снижает риск разработки функций, которые кажутся привлекательными, но не имеют особой ценности для пользователей. Затем я проверяю техническую осуществимость, прежде чем приступить к детальному проектированию. Проекты устройств часто зависят от совместной работы нескольких систем. Холодильник может потребовать контроля охлаждения, изоляции, воздушного потока, датчиков, программного обеспечения, дверных уплотнителей, дренажа и управления шумом. Небольшое изменение в одной области может повлиять на другую. Команда должна проанализировать: - Доступные компоненты и возможности поставщика - Потребляемую мощность и региональные стандарты - Воздействие тепла, влаги, вибрации и пыли - Размеры продукта и ограничения на установку - Требования к программному обеспечению и системе управления - Доступ для ремонта и запасные части - Производственное оборудование и время сборки. Концепция, которая на бумаге выглядит простой, может потребовать новой формы, специального компонента или новой производственной линии. Эти потребности должны появиться на ранней стадии плана проекта, а не после завершения прототипа. Анализ проекта с участием специалистов по проектированию, закупкам, качеству, обслуживанию и производству может выявить эти риски. Каждая команда видит свою часть продукта. Сервисный инженер может заметить, что фильтр невозможно заменить, не сняв всю переднюю панель. Заводской инженер может обнаружить, что прокладка кабеля замедляет сборку. Эти выводы могут предотвратить последующую доработку. Я использую поэтапные прототипы вместо того, чтобы рассматривать один прототип как доказательство того, что продукт готов. Ранний прототип должен отвечать на основные вопросы о размере, расположении, движении, нагреве, звуке и взаимодействии с пользователем. Он не обязательно должен выглядеть как конечный продукт. Более поздний прототип должен протестировать всю систему. Команда может проверить: - Непрерывную работу - Потребление энергии - Шум и вибрацию - Поток воды и воздуха - Контроль температуры - Срок службы дверей и кнопок - Поведение программного обеспечения - Чистку и обслуживание - Реакцию на неправильное использование Тестирование должно отражать реальные дома. Посудомоечная машина может хорошо работать с чистой водой и аккуратно расставленной посудой в лаборатории. Пользователи могут загружать смешанную посуду, выбирать короткие циклы, открывать дверцу во время работы или оставлять остатки пищи на тарелках. Эти условия могут выявить проблемы, которые не упускаются при контролируемом тестировании. Отзыв батареи Samsung Galaxy Note 7 показал, как безопасность батареи, контроль поставщиков и проверка могут повлиять на запуск продукта. Этот случай не был проектом по производству бытовой техники, однако он дает полезный урок командам, занимающимся разработкой устройств: компонент может пройти один набор проверок, в то время как весь продукт все еще требует более широкого тестирования и более тщательного анализа отказов. Хорошая команда исследований и разработок также планирует злоупотребления. Пользователи могут заблокировать выход воздуха, разместить микроволновую печь слишком близко к стене, перегрузить стиральную машину или игнорировать предупреждение фильтра. Продукт должен реагировать безопасно и сообщать о проблеме понятным языком. Инструкции должны помогать пользователям действовать, а не только описывать технические особенности. Я уделяю пристальное внимание изменениям стоимости во время разработки. Проект может достичь своих целей по производительности, но все равно потерпеть неудачу как бизнес-продукт, если структура затрат больше не работает. Команда должна отслеживать: - Стоимость компонентов - Стоимость оснастки и пресс-форм - Время сборки - Упаковка - Место для транспортировки - Гарантийные обязательства - Трудозатраты на обслуживание - Ожидаемые запасные части - Поддержка программного обеспечения Более дешевый компонент может вызвать необходимость обращения в сервисный центр. Более прочный материал может уменьшить повреждения во время транспортировки. Дисплей большего размера может улучшить удобство использования, но увеличить энергопотребление и стоимость ремонта. Этот выбор следует рассматривать как часть целостного продукта, а не как отдельные позиции. Производство должно присоединиться к проекту до того, как конструкция будет исправлена. Я ищу простые пути сборки, четкую прокладку кабелей, доступные винты, стабильные соединения и меньшее количество ненужных вариаций деталей. Если техническому специалисту приходится использовать несколько инструментов для выполнения одной рутинной задачи, возможно, проекту потребуется еще один пересмотр. Пилотное производство может выявить проблемы, которые не проявляются в компьютерных моделях. Детали могут соответствовать цифровому чертежу, но их становится сложно установить, если допуски перекрываются. Уплотнение может работать на одном блоке и протекать на другом из-за непостоянного метода сборки. Эти выводы должны привести к обновлению конструкции и контролю процессов. Проекту также необходимы точки принятия решений. На каждом этапе команда должна задаваться вопросом: — Решает ли продукт выбранную пользователем проблему? - Протестированы ли основные технические риски? - Может ли завод построить его со стабильным качеством? - Могут ли сервисные бригады безопасно отремонтировать его? - Остается ли стоимость в пределах утвержденного диапазона? - Подтверждаются ли утверждения данными испытаний? - Подходит ли продукт для целевого рынка? Если ответ не ясен, команде следует сделать паузу и собрать доказательства. Продолжение, поскольку время и деньги уже потрачены, может привести к более крупным потерям позже. Моя точка зрения проста: исследования и разработки устройств работают лучше всего, когда команды относятся к неудачам как к информации во время разработки, а не как к неожиданности после запуска. Неудачный тест может защитить проект. Недооцененный риск может нанести ущерб продукту, бюджету и доверию клиентов. Сильное руководство не заменяет знаний продуктовой команды. Это дает структуру знаний. Цель состоит в том, чтобы объединить исследования пользователей, проектирование устройств, тестирование прототипов, проверки соответствия, производство, планирование затрат и сервисную поддержку в один практический процесс. Надежное устройство не создается путем добавления дополнительных функций. Это результат решения определенной проблемы, тестирования всей системы, изучения фактических данных и принятия взвешенных решений перед массовым производством.

Многие идеи по поводу бытовой техники начинаются с простого наблюдения: чистка кухонного инструмента занимает слишком много времени. Стиральная машина использует больше воды, чем необходимо. Небольшая бытовая техника решает одну проблему, но создает другую. Разрыв между хорошей идеей и продаваемым продуктом часто возникает из-за неясных потребностей пользователей, высоких производственных затрат, слабого тестирования или дизайна, который выглядит полезным, но не подходит для повседневной жизни. Я подхожу к разработке продукта, задавая один практический вопрос: Какую проблему этот продукт решит для конкретной группы пользователей? Этот вопрос помогает превратить приблизительную концепцию в план продукта с четкой целью. ## Начните с повседневной проблемы пользователя. Идея устройства должна быть связана с повторяющейся задачей, а не только с преходящей тенденцией. Я смотрю на моменты, которые вызывают разочарование: - Приготовление еды занимает слишком много времени - Трудно чистить устройство - Прибор занимает слишком много места - Шум делает продукт неприятным в использовании - Управление сбивает с толку - Потребление энергии или воды слишком велико - Изделие не подходит для небольших домов - Трудно заменить детали Полезная идея часто появляется в обычных условиях. Например, многим людям, живущим в небольших квартирах, может понадобиться компактное устройство для приготовления пищи, которое выполняет несколько основных задач, не занимая при этом кухонную стойку. Продукт не требует десяти функций. Ему требуется небольшое количество функций, которые хорошо работают и просты для понимания. Я предпочитаю описывать проблему в одном предложении: «Я хочу помочь [определенной группе пользователей] выполнить [ежедневную задачу] с меньшими затратами [времени, усилий, шума, пространства или отходов]». Это предложение придает концепции четкое направление. ## Проверьте, имеет ли идея четкий рынок. Продукт может решить реальную проблему, но при этом не будет работать, если целевой рынок слишком широк. «Все, кто готовит» — бесполезная отправная точка. Более сильной аудиторией могут быть: - Студенты, живущие в совместном жилье - Родители, готовящие еду для маленьких детей - Пожилые люди, предпочитающие простое управление - Домовладельцы с ограниченным кухонным пространством - Небольшие кафе, которым необходимо компактное оборудование - Люди, которые готовят свежую еду для одного или двух человек У каждой группы разные потребности. Кафе может заботиться о скорости и объеме обслуживания. Пользователя старшего возраста может больше интересовать читаемость элементов управления и простота очистки. Студент может сосредоточиться на размере, цене и хранении. Я изучаю обзоры продуктов, вопросы клиентов, запросы в поддержку и публичные обсуждения. Эти источники часто выявляют небольшие проблемы, которые упускают из виду продуктовые команды. Клиент не может жаловаться на основную функцию. Они могут жаловаться на то, что крышку трудно снять, дисплей слишком яркий ночью или кабель питания слишком короткий. Эти детали могут определять дизайн. ## Превратите идею в краткое описание продукта Краткое описание продукта сохраняет фокус проекта. Обычно я включаю: - Целевой пользователь - Основная проблема - Основная функция - Вспомогательные функции - Размер продукта - Ожидаемая частота использования - Метод очистки - Требования безопасности - Целевой ценовой диапазон - Канал продаж - Основные потребности в упаковке Основная функция должна быть легко объяснима. Если продукту требуется подробное описание, прежде чем люди его поймут, возможно, над концепцией потребуется дополнительная работа. Например, прибор для приготовления пищи можно описать так: «Компактное настольное устройство, которое готовит блюда на одну порцию и использует съемные части для облегчения очистки». Это заявление ставит перед командой разработчиков несколько четких задач. Прибору необходим компактный корпус, подходящая производительность приготовления, емкость на одну порцию, съемные компоненты и процесс очистки, не требующий дополнительной работы. ## Прежде чем добавлять функции, создайте простой прототип. Многие проекты устройств становятся дорогостоящими, поскольку до тестирования основной функции добавляется слишком много функций. Я предпочитаю начинать с базового прототипа. Он может использовать грубый корпус, стандартные компоненты или простую рабочую модель. Целью не является создание готового продукта. Цель – ответить на практические вопросы: - Выполняет ли прибор свою основную задачу? - Могут ли пользователи понять элементы управления? - Соответствует ли размер предполагаемому помещению? - Изделие создает слишком много тепла или шума? - Могут ли пользователи очищать детали без специальных инструментов? - Обеспечивает ли конструкция безопасное использование? Простой прототип может выявить проблемы на ранней стадии. Концепция блендера может хорошо работать на компьютерном чертеже, но при тестировании производить слишком сильную вибрацию. Компактная духовка может поместиться на стойке, но на маленькой кухне ее дверцу будет трудно открыть. Эти выводы полезны, поскольку они предшествуют большим затратам на оснастку и производство. ## Тестируйте продукт с нужными пользователями. Отзывы друзей могут быть полезны, но они не должны быть единственным источником отзывов. Друзья могут быть вежливыми, знакомыми с этой идеей или готовыми игнорировать небольшие проблемы. Я предпочитаю проводить тестирование с людьми, которые соответствуют целевому клиенту. Я прошу их выполнять обычные задачи без подробных инструкций. Я смотрю, где они делают паузу, нажимают не ту кнопку, поднимают не ту деталь или просят о помощи. Полезные тестовые вопросы включают в себя: - Как вы думаете, что делает этот прибор? - Для чего бы вы это использовали? - Какая часть кажется трудной? - Как бы ты его почистил? - Что помешало бы вам его купить? - Какую функцию вы бы удалили? - Что заставило бы вас использовать его чаще? Пользователь может сказать, что продукт выглядит привлекательно, но все же избегать его, поскольку съемную чашу трудно мыть. Такой ответ может привести к лучшему дизайнерскому решению, чем общий комментарий типа «Мне это нравится». ## Планируйте затраты до начала производства Сильная идея продукта должна соответствовать реалистичной структуре затрат. Я рассматриваю основные статьи затрат: - Материалы - Электронные детали - Двигатель или система отопления - Инструменты - Сборка - Тестирование - Упаковка - Доставка - Поддержка клиентов - Запасные части Конструкция с множеством нестандартных компонентов может выглядеть уникальной, но это может увеличить производственные риски и сложность ремонта. Стандартные детали могут помочь контролировать затраты, если они отвечают требованиям производительности и безопасности продукта. Я также рассматриваю сборку на этапе проектирования. Сборка и обслуживание продукта с меньшим количеством винтов, свободным внутренним доступом и хорошо спланированной проводкой может занять меньше времени. Это может поддержать более практичный план продукта, не ухудшая впечатления пользователя. ## Относитесь к безопасности и обслуживанию как к части конструкции. Приборы взаимодействуют с теплом, электричеством, водой, лопастями, давлением и движущимися частями. Безопасность следует учитывать на самой ранней стадии проектирования. План продукта должен охватывать: - Изоляцию - Контроль тепла - Водонепроницаемость - Защита от перегрузки - Устойчивое размещение - Четкие предупреждения - Требования безопасности детей, если это необходимо - Инструкции по безопасной очистке - Запасные части - Материалы для поддержки клиентов Я также спрашиваю, что происходит после продажи. Могут ли пользователи найти запасное уплотнение? Смогут ли они понять сообщение об ошибке? Может ли сервисная группа получить доступ к ключевым деталям, не повредив продукт? Устройство, которое легче обслуживать, может обеспечить лучший долгосрочный опыт, чем то, которое выглядит безупречным только при запуске. ## Используйте небольшой план запуска Полномасштабное производство — не всегда лучший способ проверить спрос. Небольшой запуск может помочь собрать отзывы от первых пользователей, в то время как команда разработчиков следит за возвратами, вопросами поддержки и повторными жалобами. Содержание запуска должно объяснять: - Для кого предназначен продукт - Какую задачу он поддерживает - Как он работает - Что он не делает - Как его чистить и обслуживать - Что входит в комплект поставки - Где пользователи могут получить поддержку Четкая информация помогает людям сделать подходящий выбор. Это также уменьшает путаницу после покупки. Страница продукта может быть ориентирована на естественные поисковые фразы, такие как «компактный кухонный прибор», «легко очищаемый пищевой прибор» или «разработка прототипа прибора», если эти фразы соответствуют реальному продукту. Условия поиска должны соответствовать вопросу читателя, а не появляться как повторяющиеся ключевые слова. ## Извлекайте уроки из каждого цикла тестирования. Разработка продукта редко движется по прямой линии. Прототип может показать, что основная функция работает, а ручка, элементы управления или процесс очистки требуют еще одного этапа проектирования. Я рассматриваю каждый тест как источник информации о продукте. Неудачный тест может выявить: - Функция, которая не нужна клиентам - Размер, который не подходит для обычного дома - Система управления, которая вызывает путаницу - Материал, который трудно чистить - Стоимость, которая не соответствует целевому рынку. Самые сильные идеи бытовой техники не всегда обладают наибольшим количеством функций. Это идеи, которые решают ясную проблему, соответствуют реальной рутине и остаются практичными в производстве, использовании, очистке и поддержке. Когда я превращаю концепцию устройства в продукт, я сосредотачиваюсь на полном опыте. Хороший результат должен иметь смысл еще до покупки, быть простым во время использования и оставаться управляемым после того, как продукт доставлен домой покупателю.

Многие команды исследователей и разработчиков испытывают трудности не потому, что им не хватает идей. Им приходится бороться, потому что путь от идеи до протестированного продукта неясен. Проект может начаться с четкой концепции, а затем замедлиться, потому что технические цели слишком широки, план тестирования неполн или команда не может решить, какие компромиссные решения принять. Наем большего количества людей может не решить проблему, если недостающим элементом является целенаправленное техническое руководство. Именно здесь технический консультант может поддержать работу. Я помогаю командам исследований и разработок превратить открытые вопросы в четкие технические действия. Цель не в том, чтобы взять под контроль проект. Цель состоит в том, чтобы дать команде надежный способ оценить варианты, сократить количество доработок, которых можно избежать, и двигаться вперед, располагая более качественной информацией. ### Начинайте с проблемы, а не с продукта В описании продукта часто говорится, что компания хочет создать. Не всегда достаточно подробно объясняется техническая проблема. Прежде чем предложить путь проектирования, я задаю такие вопросы, как: - Каким потребностям пользователя отвечает продукт? - Какие целевые показатели важнее всего? - Какие ограничения связаны со стоимостью, материалами, размером, безопасностью или производством? - Какие предположения были проверены? - Что должен доказать первый прототип? Эти вопросы помогают отделить полезные требования к продукту от смутных предпочтений. Например, команда, разрабатывающая компактный датчик качества воды, может сказать, что устройству нужна «высокая точность». Эта фраза не создает проверяемую цель. Более четкие требования могли бы определить вещества, подлежащие измерению, приемлемый диапазон показаний, условия пробы, время отклика и метод испытания. Как только необходимость становится ясна, инженерные работы становится легче планировать. ### Превратите неопределенность в технический план. Команды исследований и разработок часто тратят слишком много времени на обсуждение решений, прежде чем узнают, какие вопросы наиболее важны. Я помогаю организовать неизвестное в практический план: 1. Перечислите технические предположения. 2. Отметьте предположения, которые могут повлиять на стоимость, безопасность, сроки или функциональность продукта. 3. Разработайте тест для каждого высокоэффективного предположения. 4. Установите четкий результат для каждого теста. 5. Запишите, что означает результат для следующего проектного решения. Такой подход дает команде последовательность работы вместо длинного списка идей. Устройству с батарейным питанием может потребоваться корпус меньшего размера, более длительное время работы и лучший контроль тепла. Эти цели могут противоречить друг другу. Консультант может помочь команде сравнить варианты батарей, энергопотребление, температурные ограничения и изменения в корпусе, прежде чем пересмотр конструкции станет трудным. Цель не в том, чтобы предсказать каждую проблему. Это значит найти вопросы, которые заслуживают внимания, прежде чем они станут дорогостоящими изменениями. ### Выбирайте инструменты и методы, подходящие для проекта Технический консультант не должен рекомендовать инструмент просто потому, что он знаком. Правильный метод зависит от стадии продукта, навыков команды, доступных данных, бюджета и производственного плана. Моделирование может помочь на ранней стадии выбора конструкции, а физический прототип может предоставить более подробную информацию о детали, на которую влияет поведение материала или условия сборки. Я рассматриваю такие факторы, как: - Готовность проекта - Качество доступных измерений - Требуемая точность испытаний - Программное обеспечение и оборудование команды - Ожидаемый производственный процесс - Время, необходимое для повторения испытания. Небольшой прототип может ответить на узкий вопрос с меньшими затратами, чем полная сборка продукта. Четко определенный стендовый тест может выявить больше, чем сложная модель, построенная на слабых предположениях. Хорошая техническая работа не измеряется количеством используемых инструментов. Он измеряется тем, насколько хорошо метод поддерживает четкое решение. ### Соедините исследования и разработки с производством Конструкция может работать в лаборатории, но при этом создавать проблемы во время производства. Я рассматриваю взаимосвязь между выбором дизайна и производственными потребностями на ранних этапах процесса. Сюда могут входить допуски деталей, поставка материалов, этапы сборки, методы контроля, доступ для обслуживания и изменения объема продукции. Представьте себе команду, создающую индивидуальный корпус для электронного устройства. Форма может выглядеть подходящей в прототипе, но метод производства может привести к деформации, затруднению сборки или нестабильной посадке. Техническая проверка может выявить эти риски до того, как команда приступит к разработке оснастки или более крупному производственному циклу. Этот тип проверки не заменяет работу производителей или команд качества. Это помогает группам обмениваться одной и той же технической информацией. ### Принимайте решения, которые команда может пересмотреть. Изменения в проектах НИОКР. Новые результаты испытаний могут поставить под сомнение ранние предположения. Поставщик может изменить материал. Клиент может запросить другую функцию. Я призываю команды вести простую запись: - Принятого решения - Используемых данных - Используемых ограничений или предположений - Лица, ответственного за следующее действие - Условия, которые могут стать причиной пересмотра. Эта запись помогает предотвратить повторные дебаты. Это также дает новым членам команды более четкое понимание проекта. Краткого технического примечания может быть достаточно. Формат имеет меньшее значение, чем привычка связывать решения с доказательствами. ### Привлечение консультанта на нужном этапе Консультант может повысить ценность в нескольких моментах: - Когда идея продукта требует технического определения - Когда команда сравнивает пути проектирования - Когда прототипы выходят из строя без четкой причины - Когда тестирование не соответствует требованиям к продукту - Когда проект готовится к производству - Когда внутренним инженерам требуется внешняя проверка Чем раньше начинается поддержка, тем больше вариантов может быть у команды. Поддержка на поздней стадии проблемы все равно может помочь, хотя доступный выбор может быть уже. Я предпочитаю начинать с целенаправленного обсуждения, обзора существующих документов и четкого списка вопросов. Это дает обеим сторонам практическое представление о работе, прежде чем предлагать более широкий объем. Хороший технический консультант не обещает, что каждый проект будет простым. Полезный консультант помогает команде понять работу, проверить ее предположения и сделать выбор в пользу дизайна, имея более убедительные доказательства. Когда у НИОКР есть четкий технический путь, команда может тратить меньше времени на реагирование на путаницу и больше времени на создание продукта, который соответствует ее цели, ограничениям и производственным потребностям. Свяжитесь с нами сегодня, чтобы узнать больше, Мэн: 1024097560@qq.com/WhatsApp +8613819037023.

Карл Т. Ульрих и Стивен Д. Эппингер, 2016 г. Проектирование и разработка продукции Дон Норман, 2013 г. Проектирование повседневных вещей, Международная организация по стандартизации, 2019 г. Эргономика взаимодействия человека и системы, часть 210. Человеко-ориентированное проектирование интерактивных систем, Международная электротехническая комиссия, 2020 г. Безопасность бытовых и аналогичных электроприборов, часть 1. Общие требования Питер Дж. Кейган и Крейг М. Фогель, 2002 г. Создание революционных продуктов Инновации на основе планирования продукта до утверждения программы Тимоти Л. Кесслер 2018 г. Разработка продукции и управление ею Свод знаний