Узнайте, как команды по всей компании могут использовать Guru, чтобы сделать процесс разработки, выпуска и продвижения продукта более ясным и структурированным.
Экспертиза продукта не появляется за одну ночь. Весь процесс разработки продукта формирует «экспертов» вокруг определенных функций и особенностей и является основой всей документации, которая предшествует и следует за их выпуском.
Команды, использующие Guru для реализации продукта, осознают важность наличия единого источника правды для знаний, охватывающий весь жизненный цикл выпуска продукта — от ранней разработки до постоянной поддержки и обслуживания. Обеспечивая каждое подразделение согласованным, надежным местом для размещения проверенной экспертами информации, все участники этих межфункциональных процессов могут выполнять свою работу лучше. Давайте рассмотрим недавний выпуск функции в Guru в качестве примера реализации продукта в действии.
В течение января наша недавно образованная команда по монетизации под работала над первой частью обновления опыта выставления счетов в Guru. Этот проект включал в себя обычную команду по разработке продукта — управление продуктом, дизайн, инженерное дело и маркетинг продукта — а также несколько других заинтересованных сторон, включая финансы, поддержку и продажи. Это было техническое обновление, которое требовало плотной связи и координации между всеми вовлеченными командами, а также значительной подготовки, чтобы продемонстрировать нашим коллегам, работающим с клиентами, как уверенно говорить об этих изменениях. Следующие три этапа обобщают основные способы использования Guru для реализации продукта вокруг таких выпусков функций, как этот.
Этап 1: Планирование и разработка функции
Реализация продукта действительно начинается с момента, когда проект команды по продукту получает зеленый свет. Это может быть небольшое улучшение функциональности, редизайн страницы или совершенно новая функция. С момента, когда спецификации проекта составляются менеджером по продукту (PM) и передаются их инженерам, дизайнерам и другим заинтересованным сторонам, всем нужен доступ к надежной, актуальной документации от различных авторов.
Наше планирование началось в декабре, когда наши менеджеры по продукту определили несколько ключевых мест в нашем процессе выставления счетов и оформления заказа, которые нуждались в обновлении. С этого момента они разработали план проекта и начали составлять раннюю спецификацию функции для первого проекта в серии. Когда они были готовы поделиться с командой, они запланировали встречу, чтобы ознакомить команду с предложенными изменениями и обсудить сроки. С этого момента было критически важно, чтобы все, участвующие в проекте, имели доступ ко всем связанным документам, включая спецификации проекта, дизайны, сопутствующую документацию по выставлению счетов и многое другое.
Поскольку эти документы часто меняются и могут добавляться постоянно в течение ранних этапов проекта, важно иметь надежный источник правды, к которому команда может вернуться. Чтобы убедиться, что у всех есть единое место для обмена и доступа к этим ресурсам, мы создали Карточку активных ресурсов проекта, которую можно поделиться с командой. Мы поместили это в Базу пода по монетизации, где все соответствующие заинтересованные стороны имеют доступ к созданию.
Мы рассматриваем выпуски функций как командный спорт в Guru. По мере завершения разработки нам нужно убедиться, что мы выполнили все требования, протестировали потенциальные проблемы для клиентов и правильно проинформировали наши команды, делающие клиентский контакт, о предстоящих изменениях. Поскольку это фаза, на которой информация скорее всего быстро меняется, крайне важно, чтобы все знания были проверены соответствующими экспертами.
Для нашего недавнего проекта по выставлению счетов мы выделили одну неделю для команды и наших заинтересованных сторон, чтобы провести контроль качества (QA) и протестировать новый клиентский опыт перед выходом в прямой эфир. Так как это был особенно технический проект, в процессе подготовки к тестированию было несколько шагов, включая включение флагов функций и прохождение определенного набора шагов по воспроизведению оформления заказа. Чтобы убедиться, что у всех есть вся информация, необходимая для участия в тестировании, наш ведущий инженер по проекту подготовил Карточку с пошаговыми инструкциями для участия в QA. Мы отправили эту Карточку в наш Под и заинтересованные стороны через объявление, чтобы убедиться, что они её прочитали, прежде чем начать тестирование.
В процессе QA также было важно уведомить наши команды, работающие с клиентами, о предстоящих изменениях, чтобы подготовить их к любым вопросам, которые могут возникнуть у потенциальных клиентов или клиентов. Хотя эти изменения в основном сосредоточены на удобстве и надежности (в отличие от более масштабных изменений интерфейса), некоторые части старого опыта выставления счетов будут изменены в рамках этого проекта. Чтобы сообщить об этих изменениях заранее, мы обновили нашу Карточку с разбиением по функциям выставления счетов.
Вы заметите, что это первый раз в процессе, когда мы используем слово обновление вместо создание, и это намеренно. Мы используем Карточки с разбиением по функциям как живой источник правды о функциях для наших команд, работающих с клиентами, что означает, что такая Карточка существует для всех наших активных функций в любое время.
Когда мы обновляем и улучшаем существующую функцию, мы соответствующим образом обновляем и улучшаем Карточку с разбиением по функциям. Это предотвращает старую проблему, когда сотрудник по продажам не уверен, что смотрит на устаревшую документацию о функции, и зажигает инженеров в панике, находясь на звонке. Они могут быть уверены, что Карточка о странице выставления счетов, на которую они полагались в прошлом году, столь же точна в этом году, как это заверено командой, работающей над улучшениями.
Этап 3: Выпуск и дальше
Наиболее очевидное применение реализации продукта может быть связано с запуском новой или улучшенной функции. От обзоров, таких как вышеупомянутая Карточка с разбиением по функциям, до высоких технических, специфических вопросов и ответов по устранению неполадок, многое важно для обеспечения того, чтобы команды, работающие с клиентами, были оснащены всем необходимым для продаж и поддержки каждого выпуска. И по мере того как функции модернизируются и улучшаются со временем, остается критическим, чтобы вся документация оставалась актуальной и отражала текущее состояние продукта.
Неудивительно, что страницы выставления счетов очень сложные и тонкие, что означает, что потенциальных вопросов, которые могут возникнуть у клиентов по мере завершения оформления заказа, предостаточно. Хотя наш процесс выставления счетов не является тем, о чем команда по продажам, скорее всего, будет говорить слишком подробно, это область, в которой наша команда поддержки часто помогает клиентам. Чтобы подготовиться к этому запуску и дополнительным предстоящим улучшениям нашего процесса оформления заказа, наш ведущий инженер по проектам работал с нашим специалистом по поддержке клиентов, чтобы составить список технических часто задаваемых вопросов, который будет пополняться по мере появления новых вопросов. Это дает не только команде поддержки, но и любому, кто отвечает на вопросы клиентов о выставлении счетов, постоянное место для первой проверки перед тем, как обращаться к нашей команде (и затем добавлять к технической FAQ Карточке!).
В дополнение к обновлению Карточки FAQ по мере прогресса итераций, Карточка с разбиением по функциям тоже остается актуальной. В дополнение к указанию официальной даты запуска и важных тем для обсуждения о новой системе выставления счетов, мы также будем ссылаться на другие связанные Карточки и ресурсы, так же как и на этот блог. Создавая единую точку доступа ко всей доступной информации о функции, мы даем нашим командам, работающим с клиентами, уверенность общаться с клиентами и потенциальными клиентами с хорошо информированной точки зрения.
Чтобы завершить этот цикл, мы не можем забыть о том, как отзывы клиентов и рынка играют важную роль в цикле разработки продукта. Когда наши команды представляют новые и усовершенствованные функции нашим существующим клиентам и нашему рынку, мы собираем ценную информацию о том, что помогает им лучше работать, и на чем они надеются увидеть наш фокус в будущем. Документирование и обмен этой информацией с нашей командой по продукту является важной частью нашего итеративного процесса разработки и помогает нам доставить максимальную ценность нашим клиентам. А документация о том, как делиться различными способами обратной связи (записи звонков, электронные письма и т. д.) хранится в — вы угадали — Guru.
Экспертиза продукта не появляется за одну ночь. Весь процесс разработки продукта формирует «экспертов» вокруг определенных функций и особенностей и является основой всей документации, которая предшествует и следует за их выпуском.
Команды, использующие Guru для реализации продукта, осознают важность наличия единого источника правды для знаний, охватывающий весь жизненный цикл выпуска продукта — от ранней разработки до постоянной поддержки и обслуживания. Обеспечивая каждое подразделение согласованным, надежным местом для размещения проверенной экспертами информации, все участники этих межфункциональных процессов могут выполнять свою работу лучше. Давайте рассмотрим недавний выпуск функции в Guru в качестве примера реализации продукта в действии.
В течение января наша недавно образованная команда по монетизации под работала над первой частью обновления опыта выставления счетов в Guru. Этот проект включал в себя обычную команду по разработке продукта — управление продуктом, дизайн, инженерное дело и маркетинг продукта — а также несколько других заинтересованных сторон, включая финансы, поддержку и продажи. Это было техническое обновление, которое требовало плотной связи и координации между всеми вовлеченными командами, а также значительной подготовки, чтобы продемонстрировать нашим коллегам, работающим с клиентами, как уверенно говорить об этих изменениях. Следующие три этапа обобщают основные способы использования Guru для реализации продукта вокруг таких выпусков функций, как этот.
Этап 1: Планирование и разработка функции
Реализация продукта действительно начинается с момента, когда проект команды по продукту получает зеленый свет. Это может быть небольшое улучшение функциональности, редизайн страницы или совершенно новая функция. С момента, когда спецификации проекта составляются менеджером по продукту (PM) и передаются их инженерам, дизайнерам и другим заинтересованным сторонам, всем нужен доступ к надежной, актуальной документации от различных авторов.
Наше планирование началось в декабре, когда наши менеджеры по продукту определили несколько ключевых мест в нашем процессе выставления счетов и оформления заказа, которые нуждались в обновлении. С этого момента они разработали план проекта и начали составлять раннюю спецификацию функции для первого проекта в серии. Когда они были готовы поделиться с командой, они запланировали встречу, чтобы ознакомить команду с предложенными изменениями и обсудить сроки. С этого момента было критически важно, чтобы все, участвующие в проекте, имели доступ ко всем связанным документам, включая спецификации проекта, дизайны, сопутствующую документацию по выставлению счетов и многое другое.
Поскольку эти документы часто меняются и могут добавляться постоянно в течение ранних этапов проекта, важно иметь надежный источник правды, к которому команда может вернуться. Чтобы убедиться, что у всех есть единое место для обмена и доступа к этим ресурсам, мы создали Карточку активных ресурсов проекта, которую можно поделиться с командой. Мы поместили это в Базу пода по монетизации, где все соответствующие заинтересованные стороны имеют доступ к созданию.
Мы рассматриваем выпуски функций как командный спорт в Guru. По мере завершения разработки нам нужно убедиться, что мы выполнили все требования, протестировали потенциальные проблемы для клиентов и правильно проинформировали наши команды, делающие клиентский контакт, о предстоящих изменениях. Поскольку это фаза, на которой информация скорее всего быстро меняется, крайне важно, чтобы все знания были проверены соответствующими экспертами.
Для нашего недавнего проекта по выставлению счетов мы выделили одну неделю для команды и наших заинтересованных сторон, чтобы провести контроль качества (QA) и протестировать новый клиентский опыт перед выходом в прямой эфир. Так как это был особенно технический проект, в процессе подготовки к тестированию было несколько шагов, включая включение флагов функций и прохождение определенного набора шагов по воспроизведению оформления заказа. Чтобы убедиться, что у всех есть вся информация, необходимая для участия в тестировании, наш ведущий инженер по проекту подготовил Карточку с пошаговыми инструкциями для участия в QA. Мы отправили эту Карточку в наш Под и заинтересованные стороны через объявление, чтобы убедиться, что они её прочитали, прежде чем начать тестирование.
В процессе QA также было важно уведомить наши команды, работающие с клиентами, о предстоящих изменениях, чтобы подготовить их к любым вопросам, которые могут возникнуть у потенциальных клиентов или клиентов. Хотя эти изменения в основном сосредоточены на удобстве и надежности (в отличие от более масштабных изменений интерфейса), некоторые части старого опыта выставления счетов будут изменены в рамках этого проекта. Чтобы сообщить об этих изменениях заранее, мы обновили нашу Карточку с разбиением по функциям выставления счетов.
Вы заметите, что это первый раз в процессе, когда мы используем слово обновление вместо создание, и это намеренно. Мы используем Карточки с разбиением по функциям как живой источник правды о функциях для наших команд, работающих с клиентами, что означает, что такая Карточка существует для всех наших активных функций в любое время.
Когда мы обновляем и улучшаем существующую функцию, мы соответствующим образом обновляем и улучшаем Карточку с разбиением по функциям. Это предотвращает старую проблему, когда сотрудник по продажам не уверен, что смотрит на устаревшую документацию о функции, и зажигает инженеров в панике, находясь на звонке. Они могут быть уверены, что Карточка о странице выставления счетов, на которую они полагались в прошлом году, столь же точна в этом году, как это заверено командой, работающей над улучшениями.
Этап 3: Выпуск и дальше
Наиболее очевидное применение реализации продукта может быть связано с запуском новой или улучшенной функции. От обзоров, таких как вышеупомянутая Карточка с разбиением по функциям, до высоких технических, специфических вопросов и ответов по устранению неполадок, многое важно для обеспечения того, чтобы команды, работающие с клиентами, были оснащены всем необходимым для продаж и поддержки каждого выпуска. И по мере того как функции модернизируются и улучшаются со временем, остается критическим, чтобы вся документация оставалась актуальной и отражала текущее состояние продукта.
Неудивительно, что страницы выставления счетов очень сложные и тонкие, что означает, что потенциальных вопросов, которые могут возникнуть у клиентов по мере завершения оформления заказа, предостаточно. Хотя наш процесс выставления счетов не является тем, о чем команда по продажам, скорее всего, будет говорить слишком подробно, это область, в которой наша команда поддержки часто помогает клиентам. Чтобы подготовиться к этому запуску и дополнительным предстоящим улучшениям нашего процесса оформления заказа, наш ведущий инженер по проектам работал с нашим специалистом по поддержке клиентов, чтобы составить список технических часто задаваемых вопросов, который будет пополняться по мере появления новых вопросов. Это дает не только команде поддержки, но и любому, кто отвечает на вопросы клиентов о выставлении счетов, постоянное место для первой проверки перед тем, как обращаться к нашей команде (и затем добавлять к технической FAQ Карточке!).
В дополнение к обновлению Карточки FAQ по мере прогресса итераций, Карточка с разбиением по функциям тоже остается актуальной. В дополнение к указанию официальной даты запуска и важных тем для обсуждения о новой системе выставления счетов, мы также будем ссылаться на другие связанные Карточки и ресурсы, так же как и на этот блог. Создавая единую точку доступа ко всей доступной информации о функции, мы даем нашим командам, работающим с клиентами, уверенность общаться с клиентами и потенциальными клиентами с хорошо информированной точки зрения.
Чтобы завершить этот цикл, мы не можем забыть о том, как отзывы клиентов и рынка играют важную роль в цикле разработки продукта. Когда наши команды представляют новые и усовершенствованные функции нашим существующим клиентам и нашему рынку, мы собираем ценную информацию о том, что помогает им лучше работать, и на чем они надеются увидеть наш фокус в будущем. Документирование и обмен этой информацией с нашей командой по продукту является важной частью нашего итеративного процесса разработки и помогает нам доставить максимальную ценность нашим клиентам. А документация о том, как делиться различными способами обратной связи (записи звонков, электронные письма и т. д.) хранится в — вы угадали — Guru.
Опробуйте мощь платформы Гуру на практике - пройдите интерактивный тур по нашему продукту
.webp)
