Разработка продуктов на основе идей: от задумки до реализации
Идеи — это основной рабочий объект в бэклоге продукта в Jira Product Discovery. Чтобы обеспечить непрерывную проверку и исследование, мы используем идеи в качестве долгосрочных объектов: на стадии разработки идея уходит из бэклога, но остается в итерациях исследования и поставки, пока не принесет требуемого эффекта.
Успешные команды по продукту используют экспериментальный подход: они постоянно вносят изменения в идею на основе контекста, отзывов пользователей, спецификаций и дизайна. На каждом этапе жизненного цикла идеи они оценивают, что сработало, а что нет, отвечают на ключевые вопросы и проверяют свои предположения, чтобы убедиться, что их вклад соответствует полученным отзывам и подтверждениям.
Идеи: от общих до детальных
Хотя объект, используемый в Jira Product Discovery, называется «идея», он может представлять идею продукта, возможность, проблему, решение и многое другое. Бэклог продукта может быть настроен так, чтобы в нем хранились идеи самых разных масштабов и уровней детализации.
Важно определить эти категории и согласовать их со всеми участниками процесса. Так бэклог продукта не превратится в смесь разнородных элементов, от очень больших до очень маленьких, без какой-либо основы для их классификации и сравнения.
«Валуны», «камни» и «галька»: способ классификации идей
Команда Jira Product Discovery делит идеи на три категории: «валуны», «камни» и «галька».
Boulders (Валуны), Rocks (Камни) и Pebbles (Галька).
- «Валуны»: крупные инвестиции с потенциально большой отдачей, но в то же время с высокой степенью неопределенности
- Пример: крупная новая разработка, добавление фундаментальной характеристики в продукт, крупный инженерный проект
- «Камни»: инвестиции среднего размера с меньшими рисками
- Пример: новые функции, новые эксперименты по адаптации, внесение изменений в продукт на основе отзывов
- «Галька»: некрупная инвестиция (обычно в то, что легко реализовать)
- Пример: небольшие улучшения пользовательского интерфейса, исправления проблем во взаимодействии с пользователем
- Пример: небольшие улучшения пользовательского интерфейса, исправления проблем во взаимодействии с пользователем
Наша команда использует разные представления при обсуждении этих категорий идей:
Представление Boulders (Валуны) в Jira Product Discovery.
Представление Rocks (Камни) в Jira Product Discovery.
Представление Pebbles (Галька) в Jira Product Discovery.
Атрибуты идеи
В Jira Product Discovery каждая идея содержит однострочную сводку, подробное описание, аналитические данные, такие как отзывы клиентов, и ссылки на заявки Jira по реализации этой идеи.
Идея в Jira Product Discovery.
Панель Jira Product Discovery для реализации идеи.
Чтобы каждая идея в бэклоге продукта была максимально полезной и применимой, она должна иметь следующие атрибуты:
Показатель | Суть программы |
|---|---|
| Резюме | Суть программы Краткое изложение сути идеи на одной строке. |
| Описание | Суть программы Подробное описание возможности, проблемы и решения. |
| Поля | Суть программы Различные аспекты идеи: какой цели она служит, на какой стадии находится, какую часть продукта затрагивает. Здесь также содержится информация, помогающая присвоить идее приоритет (например, как она влияет на бизнес и каковы затраты на ее разработку), ссылки на спецификации или модели. |
| Аналитика | Суть программы Аналитические данные, полученные по всем каналам: основные выводы из отзывов пользователей, фрагменты бесед с клиентами и исследовательских отчетов, а также данные продуктовой аналитики, подтверждающие важность идеи. |
| Доставка | Суть программы Ссылки на заявки Jira (эпики или инициативы), в рамках которых идет разработка, связанная с реализацией идеи продукта. |
Для сбора всей этой информации по каждой идее может потребоваться время. Сначала вы можете добавить идею в бэклог вместе с однострочной сводкой, например, обобщив информацию, полученную в ходе беседы с клиентом. Со временем вы соберете больше аналитики на основе опросов пользователей, отзывов отдела продаж или службы поддержки и учитывая изменения в стратегии компании.
Однострочная сводка с отзывом пользователя.
Описание с отзывом пользователя и анализом потенциального влияния на бизнес.
Описание с проверенным решением и идущими работами по реализации.
Описывать идеи можно двумя способами: непосредственно в Jira Product Discovery или связывая проект команды в Jira Product Discovery с другим нашим продуктом, Confluence.
В Jira Product Discovery внесите сводку или определение в поле описания идеи. Для единообразного описания проблем, решений, гипотез и другой информации, связанной с идеей, используйте один из готовых шаблонов или создайте собственный.
Если ваша команда также использует Confluence, вы можете связать идею со страницами Confluence (в описании идеи либо с помощью пользовательских полей гиперссылок). Преимущество этого подхода заключается в том, что так вы сможете использовать все функции совместной работы Confluence, например встроенные комментарии.
Содержание самого описания будет зависеть от категории идеи и этапа работ по ее реализации.
Жизненный цикл идеи
Содержание идеи важно, но не менее важно и то, как она развивается с течением времени. Вот почему важно четко определить этапы реализации каждой идеи в течение ее жизненного цикла. Наличие общего языка для описания этапов жизненного цикла идеи делает общение более продуктивным как внутри команды, так и с заинтересованными сторонами.
В Atlassian мы используем четыре этапа: Wonder (Интерес), Explore (Изучение), Make (Реализация) и Impact (Влияние). У нас все знают, что означает каждый из этих этапов: какой работой занимается команда, какие можно задавать вопросы и какая помощь может понадобиться участникам в тот или иной момент. Такая последовательность характерна для обсуждений внутри команды, с другими группами или с руководителями высшего звена.
При создании решения Jira Product Discovery наша команда использовала этот подход для разработки, проверки и реализации идей. Мы расскажем, как наша команда применяет на практике каждый этап жизненного цикла.
Wonder (Интерес), Explore (Изучение), Make (Реализация) и Impact (Влияние)
Прежде чем начать движение по этапам жизненного цикла, каждая идея «стоит на парковке». На этом этапе она обычно содержит однострочную сводку и информацию, которая привела к ее созданию. Эти сведения могли быть получены на семинаре, из отчета об исследованиях, в ходе беседы с клиентом или от отдела продаж либо службы поддержки.
Активная работа над реализацией идеи проходит в четыре этапа:
- Wonder (Интерес): обсуждение проблем или возможностей, к которым эта идея имеет отношение, на кого они повлияют и какова их важность.
- Explore (Изучение): продумывание потенциальных решений до тех пор, пока не найдется то, которое будет подтверждено отзывами клиентов.
- Make (Реализация): разработка решения и его шлифовка до тех пор, пока оно не удовлетворит потребности достаточного количества клиентов.
- Impact (Влияние): запуск решения, оценка результатов и улучшение его до тех пор, пока вы не получите желаемый бизнес-результат.
Идеи в Jira Product Discovery на разных этапах разработки командой Sirius.
Представление идей на доске в Jira Product Discovery с разбивкой по этапам и по командам.
Эта модель жизненного цикла идеи — не каскадная, то есть этапы не обязательно идут один за другим. Например, на этапе Explore (Изучение) очень часто приходится возвращаться к Wonder (Интерес), поскольку проработка возможных решений помогает лучше понять проблему. Также вероятно, что вы откажетесь от некоторых идей, если после нескольких попыток не найдете подходящего решения.
В следующих разделах мы покажем на примерах, как наша команда следовала этим этапам при создании продукта Jira Product Discovery.
Если вам интересно узнать больше, посмотрите этот доклад:
Wonder (Интерес)
Этап Wonder (Интерес) — это проверка проблемы или возможности.
На этом этапе вы обычно полагаетесь на качественно проведенные интервью с клиентами. На основе этого исследования ваша команда сможет понять, какие преимущества и результаты призвана принести эта идея, оцениваемые с точки зрения полезности для клиентов и бизнеса. Вы также разработаете гипотезу о том, как измерить успех.
Для идей на этом этапе можно воспользоваться шаблоном формулировки проблемы в Jira Product Discovery или создать свой.
Шаблон формулировки проблемы в Jira Product Discovery.
Выводы, которые вы извлекли на этапах Wonder (Интерес), Explore (Изучение), Make (Реализация) и Impact (Влияние) из исследований и бесед с клиентами, можно внести в раздел Insights (Аналитика) на странице идеи:
Поле Insights (Аналитика) в описании идеи в Jira Product Discovery.
Этап Wonder (Интерес) в действии
Так выглядел этап Wonder (Интерес), когда мы создавали Jira Product Discovery. Первоначальная идея этого продукта возникла благодаря следующему:
Интервью с менеджерами по продукту, использующими Jira для управления доставкой программного обеспечения
Исследования, проведенные собственной группой по исследованиям и аналитике Atlassian и такими компаниями, как Gartner и Forrester
Примеры передовых практик разработки продуктов (например, в блогах Марти Кейгана и в книге Терезы Торрес).
Анализ полученных данных подтвердил наши следующие мысли:
- Менеджерам по продуктам приходилось сталкиваться со многими проблемами: от эффективной расстановки приоритетов до убеждения всех в правильности своих дорожных карт.
- Менеджеры по продуктам надеялись, что смогут решить эти проблемы с помощью Jira, но удавалось это плохо, так как решение Jira не предназначено для таких целей.
- Менеджеры по продуктам уделяли главное внимание выпуску функций, хотя они могли бы перенести фокус на исследование их влияния и на бизнес-результаты.
- Управление продуктами становилось ключевой задачей даже в нетехнологических компаниях. Мы поняли, что это отличная возможность и что спрос на такое решение будет большим.
Наша целевая страница, посвященная Jira Product Discovery.
Мы уделили особое внимание проверке гипотезы о спросе, так как наше предположение о нем было самым рискованным. Если бы мы ошиблись, то созданный нами продукт купили бы лишь несколько компаний.
Поэтому, прежде чем написать хоть одну строчку кода, мы создали веб-страницу, рекламирующую продукт.
И наша гипотеза подтвердилась — за две недели 3000 человек присоединились к списку ожидания.
Изучайте
На этапе Explore (Изучение) мы осмысливаем, тестируем и проверяем решения в отношении проблем или возможностей, выявленных на этапе Wonder (Интерес).
Мы знаем, что многие идеи продуктов не будут успешны — и это нормально! Чтобы выявить менее перспективные идеи и освободить место для хороших, Марти Кейган предлагает менеджерам по продуктам учесть четыре ключевых риска. Используйте их при оценке возможных действий в отношении найденных проблем и возможностей.
- Принесет ли решение пользу клиентам? Если нет — например, если у них уже есть лучшие альтернативы — вы рискуете создать решение, которым не будут пользоваться.
- Насколько легко и удобно пользоваться решением? Чтобы решение представляло ценность для клиентов, оно должно быть доступным и простым в использовании. Если получить от него результат очень сложно, вы рискуете выпустить продукт, которым никто не захочет пользоваться.
- Осуществимо ли это решение технически? Сколь бы перспективной ни была идея, ваши разработчики должны обладать необходимыми навыками и технологиями для ее воплощения, иначе вы только зря растратите ресурсы.
- Соответствует ли решение возможностям бизнеса? Впишется ли в ограничения? Скорее всего, действительно удачное решение получится не с первой попытки. Вы должны быть уверены, что бизнес готов вкладывать средства, иначе рискуете потратить время на идею, которая будет задвинута в дальний угол.
Поставьте перед собой цель по максимуму сократить риски и удержаться от вложения слишком больших средств под влиянием интуиции или энтузиазма. Как правило, это происходит, когда функция сначала поставляется, а потом итеративно дорабатывается или тестируется. Лучше действуйте более щадящими методами, например создайте прототипы в Figma и покажите их клиентам, чтобы получить обратную связь еще до начала написания кода.
Если вы решите все же поставить функцию, попробуйте создать реальный прототип со множеством ограничений, протестировать его на небольшой группе первых пользователей и затем дорабатывать в быстрых итерациях. Тогда вам не придется предусматривать все возможные тупиковые ситуации. Если пользователям идея не понравится, вы намного раньше поймете причину и в следующих итерациях будете ее устранять (или откажетесь от идеи совсем, если она так и не сработает).
При наличии больших зон неопределенности проведите на этапе исследования технический спайк. Это разновидность реализации, которая поможет вашей команде понять собственные ограничения, технические возможности и проблемы.
Для идей на этом этапе можно воспользоваться шаблоном «Определение решения» в Jira Product Discovery или создать свой.
Шаблон определения решения в Jira Product Discovery.
В бэклоге продукта привяжите к каждой идее все относящиеся к ней документы, спецификации и дизайны, чтобы они были под рукой во время обсуждения с командой и заинтересованными сторонами. Рекомендуется добавить к каждой идее поле «ссылки», чтобы отслеживать каждый актив (одностраничник, дизайн).
Видеоролик о том, как это сделать.
Исследование в действии
В процессе создания Jira Product Discovery мы проверяли решения с клиентами следующим образом.
Сначала мы показали менеджерам продуктов слайды с разными вариантами решений, чтобы понять, какой им больше понравится. Из этих разговоров мы многое узнали о трудностях наших клиентов и о том, чего им хотелось. Именно поэтому первым «столпом» Jira Product Discovery стала расстановка приоритетов.
💡 Слайды как нельзя лучше подходят для этой стадии проверки: их легко создавать, тестировать и менять.
Потом мы создали прототипы в Figma, показали их пользователям и спросили, как эти решения могли бы им помочь. Первым экспериментальным прототипом было решение, помогающее менеджерам продуктов использовать обратную связь от заинтересованных сторон для расстановки приоритетов.
Несмотря на явную заинтересованность, менеджеры сочли, что, прежде чем решение реально начнет работать, придется изрядно повозиться с настройкой. Поэтому мы отказались от этой идеи.
Собрав такую обратную связь за несколько циклов, мы пришли к решению, которое в итоге и превратилось в Jira Product Discovery — коллективное пространство для обсуждения идей по продуктам.
На этом этапе разговоры с пользователями приобрели совсем другую окраску. Многие спрашивали, когда они смогут получить доступ, поскольку такой инструмент им очень помог бы. Именно тогда мы поняли, что идем верным путем.
Собрав такую обратную связь за несколько циклов, мы пришли к решению, которое в итоге и превратилось в Jira Product Discovery — коллективное пространство для обсуждения идей по продуктам.
На этом этапе разговоры с пользователями приобрели совсем другую окраску. Многие спрашивали, когда они смогут получить доступ, поскольку такой инструмент им очень помог бы. Именно тогда мы поняли, что идем верным путем.
Реализация
На этапе «Реализация» команды разрабатывают и проверяют решения, выбранные на этапе «Исследование». Именно в это время ведется основная работа по разработке.
Результатом этого этапа будет готовое к массовому использованию ПО (новый продукт, функция или улучшение существующего продукта), эффективность и ценность которого доказана внедрением у достаточного количества клиентов.
Когда начнется поставка (на этом этапе или на этапе исследования) вы свяжете идею с заявками на поставку в Jira (рекомендуется делать это не ниже уровня эпиков). Тогда в Jira Product Discovery вы сможете отслеживать прогресс поставки сразу по всем инициативам и командам, связанным с этим продуктом.
Связь между идеей и задачами поставки в Jira.
Если в поставке идеи задействовано несколько команд, работающих над разными проектами в Jira, можно привязать все их заявки на поставку к идее в бэклоге продукта.
Идея, поставляемая тремя разными отрядами в Jira.
Это даст возможность видеть в JPD прогресс поставки сразу по всем инициативам и командам.
Дашбоард текущих задач по продукту.
Дополнительные сведения можно получить в нашем вебинаре «Как связать исследование и поставку в Jira» в разделе Ресурсы.
Помните: вероятность того, что решение сразу принесет ожидаемые результаты, стремится к нулю. Просто как можно раньше начните поставлять ваш продукт клиентам и делайте это часто, продолжая дорабатывать его до желаемого результата. Дополняйте идею аналитическими данными, полученными из разговоров с клиентами. Способ измерения успеха напрямую зависит от типа идеи: новая функция, инициатива по развитию и т. п. Убедитесь, что все это понимают и ваши планы предусматривают возможность итераций.
Реализация в действии
Когда мы создавали Jira Product Discovery и добавляли в продукт важные новые функции, мы тестировали и проверяли их на все больших группах клиентов. Иногда этот процесс длился несколько недель, иногда — несколько месяцев.
| 0 → 10 клиентов | During the Explore phase, we iterated with a small number of pre-selected customers. We worked very closely with these customers to shape the solution together. We kept iterating until we got confirmation from them that the solution solved the problem they were facing. |
| 10 → 100 клиентов | Шаг за шагом мы расширяли круг пользователей нашего решения. Это помогло выявить различные сценарии, которые мы могли упустить на первых порах. Мы продолжали дорабатывать продукт, пока его не стали активно использовать 100 клиентов. |
| 100 → 1000 клиентов | Постепенно мы довели количество клиентов до 1000. Дальше мы анализировали показатели использования по аналитике продукта, количеству заявок на поддержку и поступающей обратной связи. На основе полученных выводов мы улучшали пользовательский интерфейс и исправляли ошибки. Если количество пользователей какой-либо функции было слишком мало, чтобы говорить о полезности, мы анализировали легкость ее обнаружения. |
| Доступ для всех | Наконец мы наладили поддержку, подготовили каналы продаж, оперативные дашбоарды, улучшения производительности и масштабируемости. |
Когда мы работаем над решениями подобного рода, мы обычно заводим для них отдельную страницу в Confluence, которую называем «динамическим журналом функций». Это очень простая страница, которую мы открываем на каждом собрании команды, чтобы обсудить объем текущей итерации. Эта страница часто обновляется по мере понимания, что будет легко или, наоборот, сложно реализовать. Она завязана не столько на отдельные задачи, сколько на опыт работы с продуктом: мы хотим, чтобы все — от команд по продукту до дизайнеров и разработчиков — ориентировались в первую очередь именно на это.
Динамический журнал функций в Jira Product Discovery.
Последствия
Альфа и омега любой модели продукта — результаты. Команды держат их в уме при сортировке идей по приоритетам, а после поставки продолжают отслеживать прогресс их достижения. Именно результатами определяется целесообразность изменения целей и стратегий, а также очередность дальнейших действий.
Даже когда решение уже поставлено, оно никогда не будет по-настоящему «готово». Как только вы добавляете функцию, она становится частью вашего продукта. Ее необходимо непрерывно совершенствовать, чтобы сделать действительно ценной, удобной и понятной для пользователей. Обязательно обращайте внимание на просьбы клиентов, их мнение о новых функциях и частоту упоминания тех или иных функций в заявках на поддержку.
Влияние в действии
Команда Jira Product Discovery для совершенствования функций выполняет ежемесячные и ежеквартальные проверки: мы сравниваем достигнутые результаты с запланированными. Иногда мы ими довольны и почти ничего не меняем, иногда пересматриваем дорожную карту с целью попробовать что-то сделать по-другому.
Вот один из методов, который мы используем. После поставки решения мы создаем соответствующую идею улучшения, в рамках которой собираем информацию, в том числе:
- обратную связь от пользователей;
- сигналы в отзывах, опросах и интервью о том, решает или не решает конкретная функция те проблемы, для решения которых была создана;
- данные об использовании функции из аналитики продуктов, позволяющие понять, действительно ли она используется. Если функция не используется, возможно, пользователи не знают о ней или просто заинтересованы в ней меньше, чем мы рассчитывали.
Представление в Jira Product Discovery для отслеживания отзывов клиентов о поставленных ранее идеях.
Мы регулярно анализируем эти данные, и каждая команда выделяет бюджет на улучшение функций. В дорожной карте каждой команды появляются как новые идеи, так и улучшения существующих.
Прогресс в работе над идеей
В Jira Product Discovery есть набор полей для отражения прогресса по заявкам, связанным с поставкой идеи. Однако сообщать заинтересованным сторонам о прогрессе лучше другим образом. Ведь то, что задачи-эпики выполнены на 60 % или 80 %, еще не отражает реального прогресса команды.
Есть более эффективный способ донести информацию о прогрессе до заинтересованных сторон: отметьте состояние каждой идеи в специальном поле как On track (по графику), At risk (В зоне риска) или Off track (Не по графику) и прокомментируйте эти отметки в описании идеи. Этот базовый прием совместной работы очень эффективен при общении с заинтересованными сторонами в тех случаях, когда вам нужна помощь.
Представление в Jira Product Discovery для демонстрации заинтересованным сторонам прогресса в работе над идеей.
Подробности об идее на странице демонстрации прогресса.
Если вы пользовались Atlas, то уже знакомы с этим подходом. Посмотрите видео о том, как объединить идеи из Jira Product Discovery с проектами Atlas в разделе «Ресурсы». В видео это показано лучше и точнее, чем на приведенных ниже изображениях, где прогресс измеряется в процентах от выполненных заявок в Jira.
Представление Jira Product Discovery, показывающее прогресс в виде доли выполненных заявок в Jira.
Более подробная информация об идее приведена в обзоре прогресса по заявкам.
Что дальше?
Реализуя решения путем разработки идей, их подтверждения и поставки, команды по продукту могут организовывать работу участников и направлять их усилия на достижение бизнес-результатов.
В оставшейся части этого справочника мы подробно объясним, как использовать бэклог продукта, чтобы:
- настраивать каналы обратной связи и собирать данные для подтверждения идей;
- расставлять приоритеты для значимых идей;
- создавать дорожные карты для слаженного взаимодействия между вашими командами и заинтересованными сторонами.
А также приведем примеры того, как все это делаем мы сами — команда Jira Product Discovery — с использованием Jira Product Discovery и других продуктов.
Бэклог продукта
Эффективно управляйте бэклогами продукта, чтобы приоритизировать идеи, улучшить взаимодействие и ускорить разработку продукта.
Обратная связь и аналитика
Узнайте, как интеграция аналитических данных в процесс разработки поможет принимать эффективные решения, учитывать потребности клиентов и в конечном итоге создавать успешные продукты.
