Разработка ориентированных на клиента решений

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

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

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

Определение предположений для создания с помощью эмпатии клиентов

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

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

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

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

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

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

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

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

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

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

При каждой итерации цикла обратной связи "сборка-измерение-изучение" MVP будет отражать успешность вашей попытки проектирования с ориентацией на клиента.

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

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

Снижение сложности и оттягивание технических пиковых нагрузок

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

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

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

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

Создание MVP

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

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

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

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

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

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

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

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

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

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

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

Когда не следует применять этот подход

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

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

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

Ссылки

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

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

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