Исследования и разработки, которые действительно приносят результаты. Посмотрите данные внутри.

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

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

Многие команды исследователей и разработчиков испытывают трудности не потому, что им не хватает идей. Им приходится бороться, потому что связь между идеей и реальной потребностью пользователя слаба. Концепция может выглядеть многообещающе на собрании. Результаты теста могут оказаться положительными в небольшой выборке. Продукт все равно может потерпеть неудачу, если клиенты используют его в разных условиях, с разными привычками, бюджетами и ожиданиями. Я считаю, что лучшие исследования и разработки начинаются с лучших вопросов. Какую проблему мы решаем? Кто с этим сталкивается чаще всего? Какие доказательства подтверждают предлагаемое решение? Какой результат покажет, что идею необходимо изменить? Реальные данные дают этим вопросам более четкое направление. Я использую данные на протяжении всего процесса исследований и разработок, а не только на этапе отчетности. Отзывы клиентов могут выявить повторяющиеся болевые точки. Данные об использовании продукта могут показать, где люди останавливаются, колеблются или меняют свое поведение. Результаты испытаний могут выявить различия между лабораторными показателями и ежедневным использованием. Этот процесс можно построить на основе нескольких практических шагов: - Определите проблему пользователя, прежде чем обсуждать функции. - Собирайте данные из более чем одного источника. - Отделяйте факты от предположений. - Тестируйте одну ключевую идею за раз. - Запишите как положительные, так и отрицательные результаты. - Обновляйте план продукта при изменении доказательств. Такой подход помогает сократить напрасную работу. Это не устраняет неопределенности и не должно обещать, что каждое испытание будет успешным. Полезный тест может дать плохой результат и при этом защитить команду от дальнейших инвестиций в неправильном направлении. Качество данных также имеет значение. Большой набор данных не всегда дает полезный ответ. Если из выборки исключены важные группы пользователей, результат может поддержать решение, которое работает только для узкой аудитории. Если данные собираются в одном месте, они могут не отражать эффективность продукта в других местах. Я предпочитаю спрашивать, откуда взялись данные, как они были собраны и чего они не могут показать. Публичный пример можно увидеть в рекомендательной работе Netflix. Поведение пользователей при просмотре помогает компании улучшить представление контента, но просмотр данных сам по себе не объясняет каждый выбор. Контекст, качество контента, использование устройства и личные предпочтения также влияют на результат. Урок прост: данные могут определять решения по продукту, в то время как человеческие потребности по-прежнему требуют внимания. Тот же принцип применим к разработке продуктов, программного обеспечения, медицинским исследованиям, производству и потребительским услугам. Панель мониторинга может показывать, что пользователи покидают процесс на определенном этапе. Интервью могут объяснить, почему. Тестирование прототипа может показать, что изменение улучшает одну задачу, одновременно усложняя другую. Хорошие исследования и разработки соединяют эти части. Я также рекомендую установить четкие точки принятия решения до начала тестирования. Команда может договориться о том, какой результат поддерживает продолжение разработки, какой требует изменений, а какой предполагает прекращение идеи. Это снижает вероятность того, что личные предпочтения будут определять следующий шаг. Тщательный исследовательский процесс оставляет записи: - Исходное предположение - Источник данных - Условия испытаний - Наблюдаемый результат - Пределы результата - Следующее решение по продукту Эта запись помогает новым членам команды понять, почему был сделан выбор. Это также предотвращает тестирование одного и того же вопроса без изучения предыдущей работы. Улучшение НИОКР не достигается за счет сбора данных ради самого по себе. Это достигается за счет использования соответствующих доказательств на нужном этапе, прислушивания к мнению пользователей и готовности корректировать план. Когда исследования сопоставляются с реальными данными, идеи становится легче тестировать, риски продукта становятся легче увидеть, а решения становятся более связанными с людьми, которые будут использовать результат.

Многие команды исследований и разработок тратят месяцы на создание продуктов, прежде чем узнают, нужны ли они клиентам. Результат может оказаться дорогостоящим: задержки с запуском, неясное направление продукта и техническая работа, не поддерживающая бизнес-цели. Я считаю, что исследования и разработки должны осуществляться на основе фактических данных, а не предположений. Сильная идея требует большего, чем просто встреча, прогноз или уверенное мнение. Необходимо доказать, что клиенты столкнулись с проблемой, что предлагаемое решение может работать и что бизнес может его поддержать. Исследования и разработки, основанные на доказательствах, прокладывают четкий путь от ранней идеи до решения о продукте. ## Начните с проблемы клиента. Я начинаю с вопроса, чего пользователи пытаются достичь и где текущий процесс дает сбой. Клиент может сказать: «Нам нужна более быстрая панель управления». Этот запрос полезен, но он не объясняет всей проблемы. Реальная проблема может заключаться в медленном обновлении данных, нечетких отчетах или слишком большом количестве ручных действий, прежде чем можно будет принять решение. Интервью с клиентами, записи службы поддержки, звонки по продажам, обзоры продуктов и данные об использовании могут выявить закономерность, лежащую в основе запроса. Один комментарий может быть интересен. Повторяющееся поведение является более сильным доказательством. Процесс практического исследования может включать в себя: - Общение с пользователями из разных групп клиентов. - Просмотр обращений в службу поддержки и причин отмены. - Наблюдение за тем, как люди выполняют текущую задачу. - Измерение времени, ошибок и повторяющейся ручной работы. - Сравнение того, что говорят пользователи, с тем, что они на самом деле делают. Это помогает команде определить проблему понятным языком. Вместо того, чтобы сказать: «Клиентам нужно больше функций», я могу написать: «Менеджеры по эксплуатации тратят два часа каждую неделю на объединение данных из трех систем, прежде чем они смогут одобрить покупку». Это заявление дает команде исследований и разработок то, что они могут протестировать. ## Превратите предположения в проверяемые вопросы Каждая идея продукта содержит предположения. Команда может предположить, что клиенты изменят свой рабочий процесс, заплатят за новую функцию или доверят автоматическим рекомендациям. Эти предположения должны быть очевидны до начала разработки. Я часто делю их на четыре группы: - Ценность для клиента: решает ли решение проблему, которая волнует пользователей? - Техническое соответствие: может ли команда создать и поддерживать его? - Ценность для бизнеса: может ли продукт обеспечить достижение целей по доходам, удержанию или затратам? - Внедрение: смогут ли пользователи понять и использовать решение? Каждое предположение нуждается в проверке. Кликабельный прототип может проверить, понимают ли пользователи новый рабочий процесс. Небольшой технический эксперимент может проверить производительность системы. Разговор о ценах может показать, связывают ли покупатели эту идею с ценностью для бизнеса. Целью не является создание идеального продукта с самого начала. Цель состоит в том, чтобы узнать, что должно быть правдой, прежде чем будут выделены дополнительные ресурсы. ## Постройте наименьшее полезное доказательство. Доказательство не всегда требует полного продукта. Когда Dropbox разрабатывал свой первый продукт, команда использовала видео, чтобы показать, как может работать синхронизация файлов. Видео помогло людям понять происходящее еще до того, как вся система была готова. Этот тип теста может снизить неопределенность, не требуя большой сборки. Небольшое доказательство может принимать разные формы: - Каркас пользовательского опыта - Ручное обслуживание за простым интерфейсом - Ограниченная версия программного обеспечения - Технический прототип - Образец отчета с использованием данных клиентов - Контролируемое испытание с небольшой группой пользователей. Правильный формат зависит от вопроса. Если мне нужно знать, понимают ли пользователи процесс, я использую прототип. Если мне нужно проверить скорость или производительность системы, я использую техническую модель. Если мне нужно узнать, создает ли услуга ценность, я могу запустить этот процесс вручную, прежде чем автоматизировать его. Такой подход защищает команду от необходимости тратить месяцы на решение неправильной проблемы. ## Установите правила доказательства перед тестом. Тест становится более полезным, когда команда согласовывает, что будет означать результат. Например: - Как минимум шесть из десяти целевых пользователей выполняют задачу без посторонней помощи. - Пробные пользователи повторяют рабочий процесс в течение периода тестирования. - Система реагирует в течение согласованного времени при определенной нагрузке. - Клиенты определяют явную выгоду для бизнеса. - Стоимость доставки остается в пределах запланированного диапазона. Эти меры не обязательно должны быть идеальными. Они должны быть достаточно ясными, чтобы направлять решение. Тест, который дает только положительные отзывы, все равно может оказаться слабым, если пользователи не вернутся к продукту. Прототип, который выглядит хорошо, может не доказать, что технология может поддерживать реальное использование. Доказательства должны быть связаны с решением, которое должна принять команда. ## Объединив команды НИОКР и бизнес-группы в одном процессе НИОКР могут создать надежное техническое решение, которое не примут клиенты. Продажи могут выявить спрос, который текущий продукт не может удовлетворить. Маркетинг может описать потребность рынка, которая не была проверена на реальных пользователях. Работа, основанная на доказательствах, дает этим командам общий набор фактов. Менеджеры по продукту могут объяснить проблему клиента. Инженеры могут определять технические ограничения. Отделы продаж могут делиться отзывами покупателей. Финансовые группы могут помочь оценить затраты и влияние на бизнес. Каждая группа видит свою часть решения. Краткий обзор после каждого теста может ответить на три вопроса: - Что мы ожидали узнать? - Что показали доказательства? - Что нам следует изменить дальше? Это позволяет сосредоточить обсуждение на обучении, а не на личных предпочтениях. ## Отслеживайте обучение, а не только доставку Многие команды измеряют прогресс по заполненным заявкам, выпущенным функциям или затраченным часам. Эти цифры показывают активность, но не всегда отражают ценность продукта. Я также отслеживаю сигналы обучения: - Какое предположение было проверено - Сколько пользователей приняло участие - Какое поведение изменилось - Какие проблемы появились - Какое решение последовало - Какая работа была остановлена ​​или скорректирована. Остановка слабой идеи может быть полезным результатом исследований и разработок. Это не позволяет больше времени и бюджета тратить на продукт с ограниченным спросом. Команда, которая учится на раннем этапе, может перенаправить свои усилия, сохраняя при этом стоимость изменений управляемой. ## Переход от доказательства к взвешенному запуску Когда первые данные подтверждают идею, команда может расширить тестирование. Размеренный запуск может начаться с одной группы клиентов, одного рынка или одного варианта использования. Команда может наблюдать за внедрением, потребностями в поддержке, производительностью системы и результатами клиентов, прежде чем сделать продукт более широко доступным. Это не устраняет риск. Это позволяет легче увидеть риск и управлять им. Моя точка зрения проста: НИОКР не должны ждать определенности, потому что уверенность редко бывает до запуска. Лучшая цель — заменить слабые предположения более сильными доказательствами на каждом этапе. Когда потребности клиентов, технические результаты и бизнес-показатели направлены в одном направлении, решения по продукту становится легче объяснить. Команда знает, зачем она строит, чему ей нужно научиться и когда необходимы изменения. Именно так НИОКР продвигают бизнес вперед: не за счет увеличения активности, а за счет доказательств, которые определяют следующее решение. Мы имеем большой опыт работы в сфере промышленности. Свяжитесь с нами для получения профессионального совета: Хуан: info@nb-chuanghan.com/WhatsApp +8618868399669.

1. Купер, Роберт Г. (2019) Драйверы успеха в разработке новых продуктов 2. Райс, Эрик (2011) Бережливый стартап 3. Кристенсен, Клейтон М. (1997) Дилемма инноватора 4. Кейган, Марти (2017) Вдохновленный: как создавать технологические продукты, которые полюбят клиенты 5. Бланк, Стив и Дорф, Боб (2012) Стартап Руководство пользователя 6. Норман, Дон (2013) Дизайн повседневных вещей.