Согласуйте свои технические и продуктовые команды с канвой технологического продукта

Послушайте аудиоверсию этой статьи.

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

• Продукция не соответствует требованиям.
• Доставка функций продукта занимает больше времени, чем планировалось.
• Команды очень мало взаимодействуют и общаются еженедельно.
• Технической команде приходится «переделывать» свою инфраструктуру из-за запросов на новые продукты.
• Темпы развития кажутся медленными по сравнению с конкурентами.
• Техническая команда часто спрашивает: « Почему вы не сказали нам об этом раньше? ”

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

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

Один из способов легко достичь согласованности между продуктовыми и технологическими командами — использовать структурированную технологическую канву продукта.

Что такое технологическая канва продукта?

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

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

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

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

Когда использовать шаблон технологического продукта?

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

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

Давайте рассмотрим более подробный пример того, как технологическая канва продукта используется в гипотетическом новом проекте программного обеспечения, чтобы мы могли увидеть ее в действии и научиться ее использовать.

Как использовать шаблон технологического продукта

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

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

Настройка

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

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

Шаг 1: Определите показатели успеха

Как вы собираетесь измерить, работает ли ваш общий план? Каковы цели бизнеса? Это может быть доход на каждом этапе выпуска или количество загрузок приложения. Если вы знакомы с бережливой канвой, возможно, вы уже определили такие цифры. Скопируйте эту информацию в этот раздел. В этом примере я использовал следующие две метрики успеха: «Подключить 1000 человек за первый год» и «Создать наш бренд в Лос-Анджелесе» — одну количественную и одну качественную метрику.

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

Шаг 2. Заполните разделы «Видение продукта» и «Выпуск продукта».

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

В примере с нашим приложением наше видение продукта звучит так: «Обеспечить общение в реальном времени между людьми, живущими по соседству, для укрепления сообщества». После этого в выпусках продуктов мы могли бы сказать, что версия 1 — это «чтобы определить ваше текущее местоположение, показать, кто находится поблизости, и связаться с их адресом электронной почты». V2 может быть «показывать, кто находится поблизости, и разрешать чат в реальном времени». V3 может быть «для обеспечения конфиденциальности и монетизации». Эти итерации продукта будут введены в холст, как показано ниже. Держите холст как можно проще, чтобы люди могли видеть общую картину. Холст также предназначен для того, чтобы запечатлеть долгосрочное видение. Имейте в виду, что это может быть первый раз, когда техническая группа видит такую ​​четкую картину вашего продукта, поэтому потратьте достаточно времени, чтобы убедиться, что они понимают каждый выпуск и сопутствующие требования.

Шаг 3: Сопоставьте видение технологии с видением продукта

Теперь пришло время получить информацию от технологической группы и определить их видение того, как будет развиваться технологическая архитектура. Начните с Технологического видения, заявления, которое обрисовывает в общих чертах картину развития и которое может пережить изменения инструментов поставщика. В примере с нашим приложением в технологическом видении может быть указано: «Использовать возможности геолокации устройств, которые предоставляют информацию о местоположении, и использовать бессерверные микросервисы для обеспечения возможностей совместной работы в облаке». На данный момент мы не выбираем конкретный инструмент. Думайте о технологическом видении как о большой идее о том, как технологии помогут здесь и какие инновации мы стремимся внедрить, которые обеспечат конкурентное преимущество, а также технологическую взлетно-посадочную полосу, которая может привести нас к нашему видению.

Шаг 4: Сопоставьте технологические планы с целями продукта

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

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

В нашем примере приложения мы рассматриваем потребности продукта в поле «Выпуск продукта 1». Основываясь на этих требованиях, мы можем сказать, что технологический план 1 — это «Разработка прогрессивного веб-приложения с использованием Ionic для включения кроссплатформенного приложения. Используйте возможности геолокации устройства. Синхронизация с серверной частью Firebase. Воспользуйтесь почтовым сервисом SendGrid». Технологический план и цели, описанные здесь, должны быть достаточными для достижения целей продукта. Убедитесь, что команда не переусердствует там, где не существует целей продукта.

На этом этапе мы, наконец, можем увидеть всю мощь холста — именно так мы объединяем команды. Мы согласовываем цели продукта с технологическим планом. А эта полоска посередине? Это интерфейс , который нужен менеджеру по продукту для активного управления между командами.

Точно так же технологический план 2 будет «Реализовать аутентификацию пользователей с использованием авторизации Facebook/Google, внедрить чат в реальном времени с базой данных Firebase и интерфейсом чата». Технологический план 3 будет заключаться в «внедрении методов скрытия конфиденциальности/GPS и покупки в приложении для обновлений приложения».

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

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

Шаг 5: Определите риски и ресурсы

Наконец, после того как вы решили, как вы собираетесь создавать продукт с точки зрения технологической архитектуры, рекомендуется обсудить риски и ресурсы. В нашем примере мы могли бы сказать о рисках: «Есть вероятность, что прогрессивное веб-приложение будет недостаточно быстрым». Если это так, мы могли бы перейти к разработке приложений React или Native. Для ресурсов нам понадобятся люди с набором навыков в «Ionic, PWA, геолокации и Firebase».

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

Полная картина

Вот завершенный пример холста технологического продукта, основанный на нашем гипотетическом примере приложения выше:

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

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

Заключение: повторите канву своего технологического продукта

Пять шагов создания канвы технологического продукта:

1. Определите показатели успеха
2. Заполните разделы «Видение продукта» и «Выпуск продукта».
3. Сопоставьте видение технологии с видением продукта
4. Сопоставьте технологические планы с целями продукта
5. Определите риски и ресурсы

Очень важным преимуществом канвы является то, что она позволяет командам определить «минимальную» технологию, которую необходимо применить или разработать на каждом этапе. Это помогает команде разработчиков быть в курсе необходимых технологических усилий и любых предстоящих задач. Разработка продукта не замедляется из-за отсутствия технических возможностей, потому что технические планы синхронизированы и предусматривают достаточное количество шагов вперед. В примере с приложением мы будем обучать нашу команду или находить эксперта по технологии SignalR по мере приближения к выпуску версии 1, чтобы мы были готовы к выпуску версии 2, где требуется этот навык.

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