Строить с эмпатией к клиентам

"Необходимость является матерью изобретения". Это говорит о неразделимости человеческого духа и нашей естественной драйве, чтобы придумать. Как описано в Оксфордском английском словаре: "Когда необходимость чего-то становится императивной, вы вынуждены найти способы получения или достижения его". Мало кто отрицал бы эти универсальные истины о изобретении. Однако, как объясняет статья "Инновации в цифровой экономике ", облачные инновации требуют баланса между изобретением и внедрением.

Если мы продолжаем аналогию, инновации приходят из более расширенной семьи. Эмпатия к клиенту является источником инноваций. Чтобы создать решение, ориентированное на эмпатию к клиентам, которое стимулирует инновации, требуется законная потребность клиентов, что позволяет им постоянно возвращаться к решению критически важных задач. Эти решения основаны на том, что клиенты нуждаются, а не хотят или прихоти. Чтобы найти истинные потребности клиентов, начните с сочувствия и глубокого понимания взаимодействия с клиентом. Эмпатия является недоразвитым навыком для многих инженеров, менеджеров по продуктам и даже бизнес-лидеров. К счастью, разнообразные взаимодействия и быстрый темп роли архитектора облака способствуют этому навыку.

Как вы создаете сочувствие и почему клиентская эмпатия так важна? Сочувствие к клиенту помогает понять и поделиться опытом клиента. От первого выпуска минимального жизнеспособного продукта (MVP) до общедоступной доступности решения рыночного уровня, сочувствие клиентов помогает создавать лучшие решения. Более важно, эмпатия лучше позиционирует команду, чтобы изобретать решения, которые поощряют внедрение. В цифровой экономике команды, занимающиеся продуктами, которые могут наиболее легко сопереживать потребностям клиентов, способны построить более яркое будущее с лучшими инструментами, которые переопределяют и ведут рынок.

Определение предположений для создания с учетом эмпатии к клиентам

Определение предположений является основной частью планирования. Чем больше вы планируете, тем яснее вы можете увидеть, как ваши предположения проникают в основу великой идеи. Предположения обычно являются продуктом самосочувственности. Иными словами, что бы я хотел, если бы я был в этой позиции? При запуске этапа сборки он сводит к минимуму период, в котором предположения могут вторгаться в решение. Этот подход также ускоряет цикл обратной связи с реальными клиентами, создавая более ранние возможности для изучения и усиления эмпатии.

Самые инновационные решения в истории начались с интуитивно понятной веры. Это интуитивное чувство исходит как от существующего опыта, так и от личного наблюдения. Начните с этапа сборки, потому что это позволяет быстро проверить вашу интуицию. Оттуда вы можете развивать более глубокое понимание и более четкое степень сочувствия. При каждой итерации или выпуске решения баланс достигается созданием MVP, демонстрирующих эмпатию к клиентам.

Чтобы обеспечить устойчивость этого акта балансировки, в следующих двух разделах описываются концепции построения с сочувствием и определения MVP.

Определение гипотезы, ориентированной на клиентов

При построении с сочувствием это означает, что вы создаете решение на основе определенных гипотез, которые иллюстрируют конкретную потребность клиента. Следующие шаги сформулируют гипотезу, которая поощряет строительство с сочувствием.

1. При построении с эмпатией клиент всегда в центре внимания. Это намерение может принимать множество форм. Вы можете ссылаться на архетип клиента, конкретный человек или даже фотографию клиента в разгар проблемы, которую вы хотите решить. И помните, что клиенты могут быть внутренними (сотрудниками или партнерами) или внешними (потребителями или бизнес-клиентами). Это определение является первой гипотезой для тестирования: можем ли мы помочь этому конкретному клиенту?
2. Ознакомьтесь с интерфейсом клиента. Построение с сочувствием означает, что вы можете относиться к опыту клиента и понять их проблемы. Это мышление указывает на следующую гипотезу для тестирования: можем ли мы помочь этому конкретному клиенту с этой управляемой задачей?
3. Определите четкое решение для одной задачи. Если вы полагаетесь на опыт людей, процессов и экспертов в предметной области, это может способствовать нахождению решения. После этого можно проверить полную гипотезу: можем ли мы помочь этому конкретному клиенту с этой управляемой задачей через предлагаемое решение?
4. Декларация о ценностях. Какую долгосрочную ценность вы надеетесь предоставить этим клиентам? Ответ на этот вопрос создает полную гипотезу: как будут улучшаться жизни этих клиентов с помощью предлагаемого решения для решения этой управляемой проблемы?

Этот последний шаг является кульминацией гипотезы, основанной на понимании нужд клиента. Он определяет аудиторию, проблему, решение и метрику, с помощью которой необходимо сделать улучшение, все из которых сосредоточены на клиенте. В течение фаз измерения и обучения следует проверить каждую гипотезу. Предвидьте изменения в клиенте, формулировке проблемы или решении по мере того, как команда развивает большее сочувствие к достижимой базе клиентов.

После подтверждения основных предположений позже итерации сосредоточены на тестах роста в дополнение к тестам эмпатии. После сборки, тестирования и проверки сочувствия вы начинаете понимать адресный рынок в масштабе. Вы можете более глубоко понять адресный рынок, расширив стандартную формулу гипотезы, описанную ранее. Затем на основе доступных данных оцените размер общего рынка (число потенциальных клиентов).

Оттуда оцените процент общего рынка, который сталкивается с аналогичной проблемой и, следовательно, может быть заинтересован в решении. Затем у вас есть целевой рынок. Следующая гипотеза, которую необходимо проверить: как будет улучшаться% жизни клиентов с помощью предлагаемого решения для решения этой управляемой проблемы? Небольшая выборка клиентов показывает ведущие показатели, которые свидетельствуют о процентном влиянии на пул заинтересованных клиентов.

Определение решения для проверки гипотезы

Во время серии итераций цикла обратной связи build-measure-learn ваша попытка построить на основе эмпатии определяется МИП.

MVP — это наименьшая единица усилий (изобретение, проектирование, разработка приложений или архитектура данных), необходимая для создания достаточного количества решений для обучения с клиентом. Целью каждого MVP является проверка некоторых или всех предыдущих гипотез и получение отзывов непосредственно от клиента. Результат — это не красивое приложение со всеми функциями, которые необходимы для того, чтобы изменить отрасль. Желаемый результат каждой итерации — это возможность обучения, возможность более глубоко проверить гипотезу.

Timeboxing — это стандартный способ убедиться, что продукт остается бережливым. Например, убедитесь, что ваша команда разработчиков считает, что решение можно создать в одной итерации, чтобы обеспечить быстрое тестирование. Чтобы лучше понять, как использовать скорость, итерации и выпуски для определения минимальных средств, см. статью "Скорость планирования", "Итерации", "Выпуск" и "Пути итерации".

Уменьшение сложности и задержка технических пиков

Дисциплины изобретения, описанные в методологии инноваций, изучают функциональные возможности, которые часто необходимы для реализации зрелых инноваций или решения MVP, готового к масштабированию. Используйте эти дисциплины в качестве долгосрочного руководства по включению функций. Аналогичным образом, используйте их как ориентир при раннем тестировании ценности для клиентов и эмпатии в вашей разработке.

Широкие возможности и различные дисциплины изобретений не могут быть созданы в одной итерации. Для решения MVP может потребоваться несколько выпусков, чтобы включить сложность нескольких дисциплин. В зависимости от инвестиций в развитие может быть несколько параллельных команд, работающих в разных дисциплинах для проверки нескольких гипотез. Разумно поддерживать архитектурное выравнивание между этими командами, однако неразумно пытаться создавать сложные интегрированные решения, пока вы не сможете подтвердить гипотезы о ценности.

Вы обнаруживаете сложность лучше всего в частоте или объеме технических пиков. Технические пики — это усилия по созданию технических решений, которые нельзя легко протестировать с клиентами. Когда ценность и сочувствие клиентов не тестируются, технические пики представляют риск для инноваций и должны быть сведены к минимуму. Для типов проверенных решений, найденных в ходе миграции, технические пики могут быть общими во время внедрения. Но они задерживают тестирование гипотез в инновационных усилиях, и вы должны отложить их всякий раз, когда это возможно.

Неустанный подход к упрощению помогает любому определению MVP. Этот подход означает, что вы удаляете все, что не помогает проверить гипотезу. Чтобы свести к минимуму сложность, уменьшите количество интеграций и функций, которые не требуются для проверки гипотезы.

Создание MVP

При каждой итерации решение MVP может принимать различные фигуры. Общее требование заключается только в том, что выходные данные позволяют измерять и тестировать гипотезу. Это простое требование инициирует научный процесс и позволяет команде строить с сочувствием. Чтобы реализовать этот клиентоцентричный подход, изначальный MVP может полагаться только на одну из дисциплин изобретения.

В некоторых случаях самый быстрый путь к инновациям означает временно избегать этих дисциплин полностью, пока команда по внедрению облака не уверена, что гипотеза точно проверена. От технологической компании, такой как Майкрософт, это руководство может звучать неожиданно. Но он подчеркивает, что потребности клиентов, а не конкретное решение технологии, являются наивысшим приоритетом в решении MVP.

Как правило, решение MVP состоит из приложения или решения для работы с данными с минимальными функциями и ограниченной доводкой. Для организаций, имеющих опыт профессионального развития, этот путь часто является самым быстрым для обучения и итерации. Следующий список включает несколько других подходов, которые команда может принять для создания MVP:

• Прогнозный алгоритм, который является неправильным 99 процентов времени, но который демонстрирует конкретные нужные результаты.
• Устройство Интернета вещей, которое не взаимодействует безопасно в промышленном масштабе, но демонстрирует ценность почти реальных временных данных в процессе.
• Приложение, созданное разработчиком-гражданином для проверки гипотезы или удовлетворения потребностей в меньшем масштабе.
• Ручной процесс, который заново воссоздает преимущества приложения для дальнейшего использования.
• Проводной кадр или видео, который достаточно подробно, чтобы позволить клиенту взаимодействовать.

Разработка MVP не должна требовать огромных объемов инвестиций в развитие. Предпочтительно, вы ограничиваете инвестиции как можно больше, чтобы свести к минимуму количество гипотез, тестируемых в один раз. Затем, в каждой итерации и с каждым выпуском, вы намеренно улучшаете решение в отношении готового к масштабированию решения, представляющего несколько дисциплин изобретений.

Ускорение разработки MVP

Время на рынок имеет решающее значение для успеха любых инноваций. Более быстрые выпуски приводят к более быстрому обучению. Быстрое обучение приводит к продуктам, которые могут быстрее масштабироваться. Иногда традиционные циклы разработки приложений могут замедлить этот процесс. Чаще всего инновации ограничиваются ограничениями на доступный опыт. Бюджеты, руководители и доступность персонала могут создавать ограничения на количество новых инноваций, которые может обрабатывать команда.

Ограничения персонала и желание построить с сочувствием породили быстро растущую тенденцию к разработчикам граждан. Эти разработчики снижают риск и обеспечивают масштаб в сообществе профессиональной разработки организации. Разработчики-граждане являются экспертами по вопросам взаимодействия с клиентами, но они не обучены как инженеры. Эти люди используют средства прототипирования или более легковесные инструменты разработки, которые могут не одобряться профессиональными разработчиками. Эти разработчики, согласованные с бизнесом, создают решения MVP и теории тестирования. При хорошем согласовании этот процесс создает решения для повышения эффективности, которые обеспечивают ценность, но не поддерживают достаточно эффективную гипотезу о масштабируемости. Teams также может использовать решения для проверки прототипа перед началом работы по масштабированию.

В рамках любого плана инноваций команды по внедрению облачных технологий должны диверсифицировать свои портфели, чтобы включить усилия разработчиков граждан. Масштабируя усилия по разработке, вы можете формировать и тестировать больше гипотез при сниженных инвестициях. При проверке гипотезы и выявлении адресного рынка профессиональные разработчики могут затем ужесточить и масштабировать решение с помощью современных средств разработки.

Окончательный этап сборки: проблемы клиента

Когда сочувствие к клиенту сильно, очевидно, что существующая проблема должна быть легкой для идентификации. Боль клиента должна быть очевидной. На этапе разработки команда по внедрению облака работает над решением для создания и проверки гипотезы на основе проблем клиента. Если гипотеза хорошо сформулирована, но проблема клиентов не определена, решение не основано на понимании клиентов. В этом сценарии сборка не является правильной отправной точкой. Вместо этого, инвестировать сначала в строительство сочувствия и обучения от реальных клиентов. Лучший подход к созданию сочувствия и подтверждению боли прост: слушайте ваших клиентов. Инвестируйте время в встречу и наблюдение за ними, пока вы не сможете выявить проблемы, которые часто возникают. После того как вы хорошо понимаете точку боли клиента, вы готовы протестировать гипотезное решение для решения этой боли.

Если не применять этот подход

Существует множество юридических, нормативных требований и отраслевых требований, которые могут потребовать альтернативного подхода. Этот подход может не быть подходящим, если общедоступные выпуски разработки решения:

• Создание риска для времени патента, защиты интеллектуальной собственности или утечки данных клиентов
• Нарушение установленных требований соответствия

Если эти предполагаемые риски существуют, обратитесь к юридическому консультанту перед принятием любого управляемого подхода к управлению выпуском.

Ссылки

Некоторые понятия, описанные в этой статье, опираются на идеи, рассмотренные The Lean Startup Эриком Рис.

Дальнейшие действия

После создания решения MVP можно измерить значение эмпатии и масштабируемое значение. Узнайте, как измерить влияние клиента.