Дізнайтеся, як команди в компанії можуть використовувати Guru для того, щоб зробити цикл розвитку продукту, випуску та просування зрозумілішим і охайнішим.
Експертиза продукту не з'являється раптово. Весь процес розробки продукту формує 'експертів' навколо певних функцій та можливостей і є основою всієї документації, яка передує та слідує за їх випуском.
Команди, що використовують Guru для реалізації продукту, усвідомлюють важливість наявності єдиного джерела правди для знань, що охоплюють весь життєвий цикл випуску продукту – від ранньої розробки до постійної підтримки та обслуговування. Давши кожному відділу одне узгоджене, надійне місце для розміщення інформації, перевіреної експертами, усі залучені до цих крос-функціональних процесів можуть працювати ефективніше. Давайте пройдемося по недавньому випуску нової функції в Guru як приклад реалізації продукту в дії.
Протягом січня наша новостворена група Монетизації pod працювала над першою частиною вдосконалення досвіду виставлення рахунків у Guru. Цей проект включав звичну команду розробки продукту – управління продуктом, дизайн, інженерія та маркетинг продукту – а також кілька інших зацікавлених сторін, включаючи фінанси, підтримку та операції з продажу. Це було технічне оновлення, яке вимагало тісної комунікації та координації між усіма залученими командами, а також значної підготовчої роботи для того, щоб наші колеги, які контактують з клієнтами, впевнено говорили про ці зміни. Наступні три фази відображають основні способи, якими ми використовуємо Guru для реалізації продукту стосовно випуску нових функцій, таких як ця.
Фаза 1: Планування і розробка функції
Реалізація продукту насправді починається в той момент, коли проект команди продукту отримує зелене світло. Це може бути незначне покращення функціональності, редизайн сторінки або абсолютно нова функція. З моменту, коли технічні характеристики проекту складаються Менеджером продукту (PM) і передаються їх інженерам, дизайнерам і іншим зацікавленим сторонам, усі повинні мати доступ до надійної, актуальної документації від різних авторів.
Наше планування розпочалося в грудні, коли наші PM визначили кілька ключових місць у нашій системі виставлення рахунків та процесах оформлення замовлень, які потребували оновлення. Звідти вони склали план проекту і почали розробляти ранню технічну специфікацію для першого проекту в серії. Коли вони були готові поділитися з командою, вони запланували стартову зустріч, щоб ознайомити команду з запропонованими змінами і обговорити терміни. З цього моменту було критично важливо, щоб усі, хто залучений до проекту, мали доступ до всіх супутніх документів, включаючи технічні специфікації проекту, дизайни, документацію щодо виставлення рахунків і багато іншого.
Оскільки ці документи часто змінюються і можуть часто доповнюватися протягом ранніх етапів проекту, важливо мати надійне джерело правди, до якого команда може повертатися. Щоб всі мали одне місце для збору і доступу до цих ресурсів, ми створили Картку активних ресурсів проекту, щоб поділитися з командою. Ми помістили це в Дошку Pod з монетизації, де всі відповідні зацікавлені сторони мають доступ до авторських прав.
Ми вважаємо випуски функцій командним спортом у Guru. Оскільки ми наближаємося до завершення розробки, ми повинні переконатися, що ми виконали всі вимоги, протестували на потенційні труднощі для клієнтів і належно прокомунікували майбутні зміни нашим командам, які контактують з клієнтами. Оскільки це фаза, на якій інформація найімовірніше швидко змінюється, важливо, щоб усі знання підтверджувалися відповідними експертами.
Для нашого недавнього проекту з виставлення рахунків ми виділили один тиждень для команди та наших зацікавлених сторін, щоб провести оцінювання якості (QA) та протестувати новий досвід клієнтів перед запуском. Оскільки це був особливо технічний проект, було кілька етапів, пов'язаних з налаштуванням і готовністю середовищ до тестування, включаючи активацію функціональних прапорців і проходження через конкретний набір кроків перевірки. Щоб забезпечити, що всі мають всю необхідну інформацію для участі в тестуванні, наш керівник інженерної команди створив Картку з покроковими інструкціями для участі в QA. Ми надіслали цю Картку нашій групі та зацікавленим сторонам через анонс, щоб упевнитися, що вони прочитали її перед тестуванням.
Поки триває QA, також важливо сповістити наші команди, які контактують з клієнтами, про майбутні зміни, щоб підготувати їх до можливих запитань з боку клієнтів або потенційних покупців. Хоча ці зміни в основному зосереджені на зручності використання та надійності (в порівнянні з більшою зміною інтерфейсу), деякі частини застарілого досвіду виставлення рахунків будуть змінені в рамках цього проекту. Щоб повідомити про ці зміни з достатнім запасом часу для перегляду та запитань, ми оновили нашу Картку розподілу функцій виставлення рахунків.
Ви помітите, що це перший раз у процесі, коли ми використовуємо слово оновити замість створити, і це навмисно. Ми використовуємо Картки розподілу функцій як живе джерело правди про функції для наших команд, які контактують з клієнтами, що означає, що одна існує для всіх наших активних функцій у будь-який час.
Коли ми оновлюємо й вдосконалюємо існуючу функцію, ми оновлюємо та вдосконалюємо відповідно Картку розподілу функцій. Це запобігає старій проблемі, коли продавець не впевнений, чи дивиться він застарілу документацію про функцію і панікує, пишучи в Slack інженерам під час дзвінка. Вони можуть бути впевнені, що Картка про сторінку виставлення рахунків, на яку вони покладалися минулого року, настільки ж точна цього року, як підтверджено командою, що працює над вдосконаленнями.
Фаза 3: Випуск і далі
Найочевидніше застосування реалізації продукту може бути пов'язане з випуском нової або вдосконаленої функції. Від оглядів, як-от Картка розподілу функцій вище, до дуже технічних, специфічних питань з усунення неполадок, багато чого потрібно для забезпечення того, щоб команди, які контактують з клієнтами, були забезпечені всім необхідним для продажу та підтримки кожного випуску. І оскільки функції покращуються з часом, критично важливо, щоб вся документація залишалася актуальною та відображала нинішній стан продукту.
Не дивно, що сторінки виставлення рахунків є надзвичайно складними та наносять багато деталей, що означає, що не бракує потенційних запитань, які можуть виникнути у клієнтів під час завершення процесу оформлення замовлення. Хоча наш досвід виставлення рахунків навряд чи глибоко обговорюватиметься нашою командою продажів, це сфера, в якій наша команда підтримки часто допомагає клієнтам. Щоб підготуватися до цього запуску та додаткових поліпшень нашого досвіду оформлення замовлень, наш керівник інженерної команди працював із нашим чемпіоном підтримки клієнтів, щоб скласти список технічних питань, на які відповідаємо, які поповнюються новими запитаннями. Це надає не лише команді підтримки, але й усім, хто відповідає на запитання клієнтів про виставлення рахунків, єдине місце, щоб перевірити спочатку, перш ніж звертатися до нашої команди (а потім додавати до Картки технічних питань!).
Крім того, що Картка питань підтримується в актуальному стані в процесі ітерацій, Картка розподілу функцій також залишається вічною. Крім зазначення офіційної дати випуску та важливих контактних тем щодо нового досвіду виставлення рахунків, ми також посилаємося на інші пов'язані картки та ресурси, такі як цей блог-пост. Створюючи єдине місце для доступу до всієї доступної інформації про функцію, ми даємо нашим командам, які контактують з клієнтами, впевненість у спілкуванні з клієнтами та потенційними покупцями з максимально обізнаною перспективою.
Щоб замкнути це коло, ми не можемо забути про те, як відгуки клієнтів і ринку відіграють важливу роль у циклі розвитку продукту. Коли наші команди впроваджують нові та вдосконалені функції для наших існуючих клієнтів та нашого ринку, ми збираємо цінну інформацію про те, що допомагає їм працювати краще і на чому їм хотілося б, щоб ми зосередились в наступному. Документування та обмін цією інформацією з нашою командою продукту є важливою частиною нашого ітераційного процесу розробки і допомагає нам надати нашим клієнтам максимум цінності. Документація щодо того, як ділитися різними формами зворотного зв'язку (записи дзвінків, електронна пошта тощо) зберігається в – ви здогадались – Guru.
Експертиза продукту не з'являється раптово. Весь процес розробки продукту формує 'експертів' навколо певних функцій та можливостей і є основою всієї документації, яка передує та слідує за їх випуском.
Команди, що використовують Guru для реалізації продукту, усвідомлюють важливість наявності єдиного джерела правди для знань, що охоплюють весь життєвий цикл випуску продукту – від ранньої розробки до постійної підтримки та обслуговування. Давши кожному відділу одне узгоджене, надійне місце для розміщення інформації, перевіреної експертами, усі залучені до цих крос-функціональних процесів можуть працювати ефективніше. Давайте пройдемося по недавньому випуску нової функції в Guru як приклад реалізації продукту в дії.
Протягом січня наша новостворена група Монетизації pod працювала над першою частиною вдосконалення досвіду виставлення рахунків у Guru. Цей проект включав звичну команду розробки продукту – управління продуктом, дизайн, інженерія та маркетинг продукту – а також кілька інших зацікавлених сторін, включаючи фінанси, підтримку та операції з продажу. Це було технічне оновлення, яке вимагало тісної комунікації та координації між усіма залученими командами, а також значної підготовчої роботи для того, щоб наші колеги, які контактують з клієнтами, впевнено говорили про ці зміни. Наступні три фази відображають основні способи, якими ми використовуємо Guru для реалізації продукту стосовно випуску нових функцій, таких як ця.
Фаза 1: Планування і розробка функції
Реалізація продукту насправді починається в той момент, коли проект команди продукту отримує зелене світло. Це може бути незначне покращення функціональності, редизайн сторінки або абсолютно нова функція. З моменту, коли технічні характеристики проекту складаються Менеджером продукту (PM) і передаються їх інженерам, дизайнерам і іншим зацікавленим сторонам, усі повинні мати доступ до надійної, актуальної документації від різних авторів.
Наше планування розпочалося в грудні, коли наші PM визначили кілька ключових місць у нашій системі виставлення рахунків та процесах оформлення замовлень, які потребували оновлення. Звідти вони склали план проекту і почали розробляти ранню технічну специфікацію для першого проекту в серії. Коли вони були готові поділитися з командою, вони запланували стартову зустріч, щоб ознайомити команду з запропонованими змінами і обговорити терміни. З цього моменту було критично важливо, щоб усі, хто залучений до проекту, мали доступ до всіх супутніх документів, включаючи технічні специфікації проекту, дизайни, документацію щодо виставлення рахунків і багато іншого.
Оскільки ці документи часто змінюються і можуть часто доповнюватися протягом ранніх етапів проекту, важливо мати надійне джерело правди, до якого команда може повертатися. Щоб всі мали одне місце для збору і доступу до цих ресурсів, ми створили Картку активних ресурсів проекту, щоб поділитися з командою. Ми помістили це в Дошку Pod з монетизації, де всі відповідні зацікавлені сторони мають доступ до авторських прав.
Ми вважаємо випуски функцій командним спортом у Guru. Оскільки ми наближаємося до завершення розробки, ми повинні переконатися, що ми виконали всі вимоги, протестували на потенційні труднощі для клієнтів і належно прокомунікували майбутні зміни нашим командам, які контактують з клієнтами. Оскільки це фаза, на якій інформація найімовірніше швидко змінюється, важливо, щоб усі знання підтверджувалися відповідними експертами.
Для нашого недавнього проекту з виставлення рахунків ми виділили один тиждень для команди та наших зацікавлених сторін, щоб провести оцінювання якості (QA) та протестувати новий досвід клієнтів перед запуском. Оскільки це був особливо технічний проект, було кілька етапів, пов'язаних з налаштуванням і готовністю середовищ до тестування, включаючи активацію функціональних прапорців і проходження через конкретний набір кроків перевірки. Щоб забезпечити, що всі мають всю необхідну інформацію для участі в тестуванні, наш керівник інженерної команди створив Картку з покроковими інструкціями для участі в QA. Ми надіслали цю Картку нашій групі та зацікавленим сторонам через анонс, щоб упевнитися, що вони прочитали її перед тестуванням.
Поки триває QA, також важливо сповістити наші команди, які контактують з клієнтами, про майбутні зміни, щоб підготувати їх до можливих запитань з боку клієнтів або потенційних покупців. Хоча ці зміни в основному зосереджені на зручності використання та надійності (в порівнянні з більшою зміною інтерфейсу), деякі частини застарілого досвіду виставлення рахунків будуть змінені в рамках цього проекту. Щоб повідомити про ці зміни з достатнім запасом часу для перегляду та запитань, ми оновили нашу Картку розподілу функцій виставлення рахунків.
Ви помітите, що це перший раз у процесі, коли ми використовуємо слово оновити замість створити, і це навмисно. Ми використовуємо Картки розподілу функцій як живе джерело правди про функції для наших команд, які контактують з клієнтами, що означає, що одна існує для всіх наших активних функцій у будь-який час.
Коли ми оновлюємо й вдосконалюємо існуючу функцію, ми оновлюємо та вдосконалюємо відповідно Картку розподілу функцій. Це запобігає старій проблемі, коли продавець не впевнений, чи дивиться він застарілу документацію про функцію і панікує, пишучи в Slack інженерам під час дзвінка. Вони можуть бути впевнені, що Картка про сторінку виставлення рахунків, на яку вони покладалися минулого року, настільки ж точна цього року, як підтверджено командою, що працює над вдосконаленнями.
Фаза 3: Випуск і далі
Найочевидніше застосування реалізації продукту може бути пов'язане з випуском нової або вдосконаленої функції. Від оглядів, як-от Картка розподілу функцій вище, до дуже технічних, специфічних питань з усунення неполадок, багато чого потрібно для забезпечення того, щоб команди, які контактують з клієнтами, були забезпечені всім необхідним для продажу та підтримки кожного випуску. І оскільки функції покращуються з часом, критично важливо, щоб вся документація залишалася актуальною та відображала нинішній стан продукту.
Не дивно, що сторінки виставлення рахунків є надзвичайно складними та наносять багато деталей, що означає, що не бракує потенційних запитань, які можуть виникнути у клієнтів під час завершення процесу оформлення замовлення. Хоча наш досвід виставлення рахунків навряд чи глибоко обговорюватиметься нашою командою продажів, це сфера, в якій наша команда підтримки часто допомагає клієнтам. Щоб підготуватися до цього запуску та додаткових поліпшень нашого досвіду оформлення замовлень, наш керівник інженерної команди працював із нашим чемпіоном підтримки клієнтів, щоб скласти список технічних питань, на які відповідаємо, які поповнюються новими запитаннями. Це надає не лише команді підтримки, але й усім, хто відповідає на запитання клієнтів про виставлення рахунків, єдине місце, щоб перевірити спочатку, перш ніж звертатися до нашої команди (а потім додавати до Картки технічних питань!).
Крім того, що Картка питань підтримується в актуальному стані в процесі ітерацій, Картка розподілу функцій також залишається вічною. Крім зазначення офіційної дати випуску та важливих контактних тем щодо нового досвіду виставлення рахунків, ми також посилаємося на інші пов'язані картки та ресурси, такі як цей блог-пост. Створюючи єдине місце для доступу до всієї доступної інформації про функцію, ми даємо нашим командам, які контактують з клієнтами, впевненість у спілкуванні з клієнтами та потенційними покупцями з максимально обізнаною перспективою.
Щоб замкнути це коло, ми не можемо забути про те, як відгуки клієнтів і ринку відіграють важливу роль у циклі розвитку продукту. Коли наші команди впроваджують нові та вдосконалені функції для наших існуючих клієнтів та нашого ринку, ми збираємо цінну інформацію про те, що допомагає їм працювати краще і на чому їм хотілося б, щоб ми зосередились в наступному. Документування та обмін цією інформацією з нашою командою продукту є важливою частиною нашого ітераційного процесу розробки і допомагає нам надати нашим клієнтам максимум цінності. Документація щодо того, як ділитися різними формами зворотного зв'язку (записи дзвінків, електронна пошта тощо) зберігається в – ви здогадались – Guru.
Досвідчіть силу платформи Guru особисто – пройдіть наш інтерактивний тур продуктом
.webp)
