Разработка продуктов на основе идей: от задумки до реализации
Идеи — это основной рабочий объект в бэклоге продукта в Jira Product Discovery. Чтобы обеспечить непрерывную проверку и исследование, мы используем идеи в качестве долгосрочных объектов: на стадии разработки идея уходит из бэклога, но остается в итерациях исследования и поставки, пока не принесет требуемого эффекта.
Успешные команды по продукту используют экспериментальный подход: они постоянно вносят изменения в идею на основе контекста, отзывов пользователей, спецификаций и дизайна. На каждом этапе жизненного цикла идеи они оценивают, что сработало, а что нет, отвечают на ключевые вопросы и проверяют свои предположения, чтобы убедиться, что их вклад соответствует полученным отзывам и подтверждениям.
Идеи: от общих до детальных
Хотя объект, используемый в Jira Product Discovery, называется «идея», он может представлять идею продукта, возможность, проблему, решение и многое другое. Бэклог продукта может быть настроен так, чтобы в нем хранились идеи самых разных масштабов и уровней детализации.
Важно определить эти категории и согласовать их со всеми участниками процесса. Так бэклог продукта не превратится в смесь разнородных элементов, от очень больших до очень маленьких, без какой-либо основы для их классификации и сравнения.
«Валуны», «камни» и «галька»: способ классификации идей
Команда Jira Product Discovery делит идеи на три категории: «валуны», «камни» и «галька».
«Валуны»: крупные инвестиции с потенциально большой отдачей, но в то же время с высокой степенью неопределенности
Пример: крупная новая разработка, добавление фундаментальной характеристики в продукт, крупный инженерный проект
«Камни»: инвестиции среднего размера с меньшими рисками
Пример: новые функции, новые эксперименты по адаптации, внесение изменений в продукт на основе отзывов
«Галька»: некрупная инвестиция (обычно в то, что легко реализовать)
Пример: небольшие улучшения пользовательского интерфейса, исправления проблем во взаимодействии с пользователем
Наша команда использует разные представления при обсуждении этих категорий идей:
Атрибуты идеи
В Jira Product Discovery каждая идея содержит однострочную сводку, подробное описание, аналитические данные, такие как отзывы клиентов, и ссылки на заявки Jira по реализации этой идеи.
Чтобы каждая идея в бэклоге продукта была максимально полезной и применимой, она должна иметь следующие атрибуты:
Показатель | Суть программы |
|---|---|
Тема | Краткое изложение сути идеи на одной строке. |
Описание | Подробное описание возможности, проблемы и решения. |
Поля | Различные аспекты идеи: какой цели она служит, на какой стадии находится, какую часть продукта затрагивает. Здесь также содержится информация, помогающая присвоить идее приоритет (например, как она влияет на бизнес и каковы затраты на ее разработку), ссылки на спецификации или модели. |
Аналитика | Аналитические данные, полученные по всем каналам: основные выводы из отзывов пользователей, фрагменты бесед с клиентами и исследовательских отчетов, а также данные продуктовой аналитики, подтверждающие важность идеи. |
Доставка | Ссылки на заявки 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 (Влияние): запуск решения, оценка результатов и улучшение его до тех пор, пока вы не получите желаемый бизнес-результат.
Эта модель жизненного цикла идеи — не каскадная, то есть этапы не обязательно идут один за другим. Например, на этапе Explore (Изучение) очень часто приходится возвращаться к Wonder (Интерес), поскольку проработка возможных решений помогает лучше понять проблему. Также вероятно, что вы откажетесь от некоторых идей, если после нескольких попыток не найдете подходящего решения.
В следующих разделах мы покажем на примерах, как наша команда следовала этим этапам при создании продукта Jira Product Discovery.
Если вам интересно узнать больше, посмотрите этот доклад:
Wonder (Интерес)
Этап Wonder (Интерес) — это проверка проблемы или возможности.
На этом этапе вы обычно полагаетесь на качественно проведенные интервью с клиентами. На основе этого исследования ваша команда сможет понять, какие преимущества и результаты призвана принести эта идея, оцениваемые с точки зрения полезности для клиентов и бизнеса. Вы также разработаете гипотезу о том, как измерить успех.
Для идей на этом этапе можно воспользоваться шаблоном формулировки проблемы в Jira Product Discovery или создать свой.
Выводы, которые вы извлекли на этапах Wonder (Интерес), Explore (Изучение), Make (Реализация) и Impact (Влияние) из исследований и бесед с клиентами, можно внести в раздел Insights (Аналитика) на странице идеи:
Этап Wonder (Интерес) в действии
Так выглядел этап Wonder (Интерес), когда мы создавали Jira Product Discovery. Первоначальная идея этого продукта возникла благодаря следующему:
Интервью с менеджерами по продукту, использующими Jira для управления доставкой программного обеспечения
Исследования, проведенные собственной группой по исследованиям и аналитике Atlassian и такими компаниями, как Gartner и Forrester
Примеры передовых практик разработки продуктов (например, в блогах Марти Кейгана и в книге Терезы Торрес).
Анализ полученных данных подтвердил наши следующие мысли:
Менеджерам по продуктам приходилось сталкиваться со многими проблемами: от эффективной расстановки приоритетов до убеждения всех в правильности своих дорожных карт.
Менеджеры по продуктам надеялись, что смогут решить эти проблемы с помощью Jira, но удавалось это плохо, так как решение Jira не предназначено для таких целей.
Менеджеры по продуктам уделяли главное внимание выпуску функций, хотя они могли бы перенести фокус на исследование их влияния и на бизнес-результаты.
Управление продуктами становилось ключевой задачей даже в нетехнологических компаниях. Мы поняли, что это отличная возможность и что спрос на такое решение будет большим.
Мы уделили особое внимание проверке гипотезы о спросе, так как наше предположение о нем было самым рискованным. Если бы мы ошиблись, то созданный нами продукт купили бы лишь несколько компаний.
Поэтому, прежде чем написать хоть одну строчку кода, мы создали веб-страницу, рекламирующую продукт.
И наша гипотеза подтвердилась — за две недели 3000 человек присоединились к списку ожидания.
Изучайте
На этапе Explore (Изучение) мы осмысливаем, тестируем и проверяем решения в отношении проблем или возможностей, выявленных на этапе Wonder (Интерес).
Мы знаем, что многие идеи продуктов не будут успешны — и это нормально! Чтобы выявить менее перспективные идеи и освободить место для хороших, Марти Кейган предлагает менеджерам по продуктам учесть четыре ключевых риска. Используйте их при оценке возможных действий в отношении найденных проблем и возможностей.
Принесет ли решение пользу клиентам? Если нет — например, если у них уже есть лучшие альтернативы — вы рискуете создать решение, которым не будут пользоваться.
Насколько легко и удобно пользоваться решением? Чтобы решение представляло ценность для клиентов, оно должно быть доступным и простым в использовании. Если получить от него результат очень сложно, вы рискуете выпустить продукт, которым никто не захочет пользоваться.
Осуществимо ли это решение технически? Сколь бы перспективной ни была идея, ваши разработчики должны обладать необходимыми навыками и технологиями для ее воплощения, иначе вы только зря растратите ресурсы.
Соответствует ли решение возможностям бизнеса? Впишется ли в ограничения? Скорее всего, действительно удачное решение получится не с первой попытки. Вы должны быть уверены, что бизнес готов вкладывать средства, иначе рискуете потратить время на идею, которая будет задвинута в дальний угол.
Поставьте перед собой цель по максимуму сократить риски и удержаться от вложения слишком больших средств под влиянием интуиции или энтузиазма. Как правило, это происходит, когда функция сначала поставляется, а потом итеративно дорабатывается или тестируется. Лучше действуйте более щадящими методами, например создайте прототипы в Figma и покажите их клиентам, чтобы получить обратную связь еще до начала написания кода.
Если вы решите все же поставить функцию, попробуйте создать реальный прототип со множеством ограничений, протестировать его на небольшой группе первых пользователей и затем дорабатывать в быстрых итерациях. Тогда вам не придется предусматривать все возможные тупиковые ситуации. Если пользователям идея не понравится, вы намного раньше поймете причину и в следующих итерациях будете ее устранять (или откажетесь от идеи совсем, если она так и не сработает).
При наличии больших зон неопределенности проведите на этапе исследования технический спайк. Это разновидность реализации, которая поможет вашей команде понять собственные ограничения, технические возможности и проблемы.
Для идей на этом этапе можно воспользоваться шаблоном «Определение решения» в Jira Product Discovery или создать свой.
В бэклоге продукта привяжите к каждой идее все относящиеся к ней документы, спецификации и дизайны, чтобы они были под рукой во время обсуждения с командой и заинтересованными сторонами. Рекомендуется добавить к каждой идее поле «ссылки», чтобы отслеживать каждый актив (одностраничник, дизайн).
Видеоролик о том, как это сделать.
Исследование в действии
В процессе создания Jira Product Discovery мы проверяли решения с клиентами следующим образом.
Сначала мы показали менеджерам продуктов слайды с разными вариантами решений, чтобы понять, какой им больше понравится. Из этих разговоров мы многое узнали о трудностях наших клиентов и о том, чего им хотелось. Именно поэтому первым «столпом» Jira Product Discovery стала расстановка приоритетов.
💡 Слайды как нельзя лучше подходят для этой стадии проверки: их легко создавать, тестировать и менять.
Потом мы создали прототипы в Figma, показали их пользователям и спросили, как эти решения могли бы им помочь. Первым экспериментальным прототипом было решение, помогающее менеджерам продуктов использовать обратную связь от заинтересованных сторон для расстановки приоритетов.
Несмотря на явную заинтересованность, менеджеры сочли, что, прежде чем решение реально начнет работать, придется изрядно повозиться с настройкой. Поэтому мы отказались от этой идеи.
Собрав такую обратную связь за несколько циклов, мы пришли к решению, которое в итоге и превратилось в Jira Product Discovery — коллективное пространство для обсуждения идей по продуктам.
На этом этапе разговоры с пользователями приобрели совсем другую окраску. Многие спрашивали, когда они смогут получить доступ, поскольку такой инструмент им очень помог бы. Именно тогда мы поняли, что идем верным путем.
Собрав такую обратную связь за несколько циклов, мы пришли к решению, которое в итоге и превратилось в Jira Product Discovery — коллективное пространство для обсуждения идей по продуктам.
На этом этапе разговоры с пользователями приобрели совсем другую окраску. Многие спрашивали, когда они смогут получить доступ, поскольку такой инструмент им очень помог бы. Именно тогда мы поняли, что идем верным путем.
Производство
На этапе «Реализация» команды разрабатывают и проверяют решения, выбранные на этапе «Исследование». Именно в это время ведется основная работа по разработке.
Результатом этого этапа будет готовое к массовому использованию ПО (новый продукт, функция или улучшение существующего продукта), эффективность и ценность которого доказана внедрением у достаточного количества клиентов.
Когда начнется поставка (на этом этапе или на этапе исследования) вы свяжете идею с заявками на поставку в Jira (рекомендуется делать это не ниже уровня эпиков). Тогда в Jira Product Discovery вы сможете отслеживать прогресс поставки сразу по всем инициативам и командам, связанным с этим продуктом.
Если в поставке идеи задействовано несколько команд, работающих над разными проектами в Jira, можно привязать все их заявки на поставку к идее в бэклоге продукта.
Это даст возможность видеть в JPD прогресс поставки сразу по всем инициативам и командам.
Дополнительные сведения можно получить в нашем вебинаре «Как связать исследование и поставку в Jira» в разделе Ресурсы.
Помните: вероятность того, что решение сразу принесет ожидаемые результаты, стремится к нулю. Просто как можно раньше начните поставлять ваш продукт клиентам и делайте это часто, продолжая дорабатывать его до желаемого результата. Дополняйте идею аналитическими данными, полученными из разговоров с клиентами. Способ измерения успеха напрямую зависит от типа идеи: новая функция, инициатива по развитию и т. п. Убедитесь, что все это понимают и ваши планы предусматривают возможность итераций.
Реализация в действии
Когда мы создавали Jira Product Discovery и добавляли в продукт важные новые функции, мы тестировали и проверяли их на все больших группах клиентов. Иногда этот процесс длился несколько недель, иногда — несколько месяцев.
0 → 10 клиентов Доказать ценность | На этапе «Исследование» мы проводили итерации с несколькими предварительно выбранными клиентами. Мы сотрудничали с ними довольно тесно, общими усилиями формируя решение. Мы продолжали итерации до тех пор, пока не получили от клиентов подтверждение, что решение справилось с возникшей у них проблемой. На этой стадии решение доказало свою ценность. Но оно еще далеко от завершения и не учитывает возможные тупиковые ситуации. |
10 → 100 клиентов Сделать полнофункциональным | Шаг за шагом мы расширяли круг пользователей нашего решения. Это помогло выявить различные сценарии, которые мы могли упустить на первых порах. Мы продолжали дорабатывать продукт, пока его не стали активно использовать 100 клиентов. На этой стадии решение уже, как правило, полнофункционально, но его может быть сложно освоить самостоятельно. Например, пользователю может потребоваться видеоурок, чтобы разобраться во всех функциях. |
100 → 1000 клиентов Сделать пригодным для самообслуживания | Постепенно мы довели количество клиентов до 1000. Дальше мы анализировали показатели использования по аналитике продукта, количеству заявок на поддержку и поступающей обратной связи. На основе полученных выводов мы улучшали пользовательский интерфейс и исправляли ошибки. Если количество пользователей какой-либо функции было слишком мало, чтобы говорить о полезности, мы анализировали легкость ее обнаружения. На этом этапе функция должна поддерживать самообслуживание: ее легко найти, пользовательский интерфейс достаточно удобный, есть документация и т. п. |
Общедоступная версия Подготовить к вводу в эксплуатацию | Наконец мы наладили поддержку, подготовили каналы продаж, оперативные дашбоарды, улучшения производительности и масштабируемости. На этом этапе решение должно быть готово к активному массовому использованию. |
Когда мы работаем над решениями подобного рода, мы обычно заводим для них отдельную страницу в Confluence, которую называем «динамическим журналом функций». Это очень простая страница, которую мы открываем на каждом собрании команды, чтобы обсудить объем текущей итерации. Эта страница часто обновляется по мере понимания, что будет легко или, наоборот, сложно реализовать. Она завязана не столько на отдельные задачи, сколько на опыт работы с продуктом: мы хотим, чтобы все — от команд по продукту до дизайнеров и разработчиков — ориентировались в первую очередь именно на это.
Последствия
Альфа и омега любой модели продукта — результаты. Команды держат их в уме при сортировке идей по приоритетам, а после поставки продолжают отслеживать прогресс их достижения. Именно результатами определяется целесообразность изменения целей и стратегий, а также очередность дальнейших действий.
Даже когда решение уже поставлено, оно никогда не будет по-настоящему «готово». Как только вы добавляете функцию, она становится частью вашего продукта. Ее необходимо непрерывно совершенствовать, чтобы сделать действительно ценной, удобной и понятной для пользователей. Обязательно обращайте внимание на просьбы клиентов, их мнение о новых функциях и частоту упоминания тех или иных функций в заявках на поддержку.
Влияние в действии
Команда Jira Product Discovery для совершенствования функций выполняет ежемесячные и ежеквартальные проверки: мы сравниваем достигнутые результаты с запланированными. Иногда мы ими довольны и почти ничего не меняем, иногда пересматриваем дорожную карту с целью попробовать что-то сделать по-другому.
Вот один из методов, который мы используем. После поставки решения мы создаем соответствующую идею улучшения, в рамках которой собираем информацию, в том числе:
обратную связь от пользователей;
сигналы в отзывах, опросах и интервью о том, решает или не решает конкретная функция те проблемы, для решения которых была создана;
данные об использовании функции из аналитики продуктов, позволяющие понять, действительно ли она используется. Если функция не используется, возможно, пользователи не знают о ней или просто заинтересованы в ней меньше, чем мы рассчитывали.
Мы регулярно анализируем эти данные, и каждая команда выделяет бюджет на улучшение функций. В дорожной карте каждой команды появляются как новые идеи, так и улучшения существующих.
Прогресс в работе над идеей
В Jira Product Discovery есть набор полей для отражения прогресса по заявкам, связанным с поставкой идеи. Однако сообщать заинтересованным сторонам о прогрессе лучше другим образом. Ведь то, что задачи-эпики выполнены на 60 % или 80 %, еще не отражает реального прогресса команды.
Есть более эффективный способ донести информацию о прогрессе до заинтересованных сторон: отметьте состояние каждой идеи в специальном поле как On track (по графику), At risk (В зоне риска) или Off track (Не по графику) и прокомментируйте эти отметки в описании идеи. Этот базовый прием совместной работы очень эффективен при общении с заинтересованными сторонами в тех случаях, когда вам нужна помощь.
Если вы пользовались Atlas, то уже знакомы с этим подходом. Посмотрите видео о том, как объединить идеи из Jira Product Discovery с проектами Atlas в разделе «Ресурсы». В видео это показано лучше и точнее, чем на приведенных ниже изображениях, где прогресс измеряется в процентах от выполненных заявок в Jira.
Что дальше?
Реализуя решения путем разработки идей, их подтверждения и поставки, команды по продукту могут организовывать работу участников и направлять их усилия на достижение бизнес-результатов.
В оставшейся части этого справочника мы подробно объясним, как использовать бэклог продукта, чтобы:
настраивать каналы обратной связи и собирать данные для подтверждения идей;
расставлять приоритеты для значимых идей;
вы могли создавать дорожные карты для слаженного взаимодействия между командами и заинтересованными сторонами.
Кроме того, мы приведем примеры того, как все это делаем мы сами, команда Jira Product Discovery, с использованием Jira Product Discovery и других продуктов.