Как управлять командой, ориентироваться на метрики и не залезть на «дохлую лошадь»: топовые спикеры о разработке IT-продуктов

Мы продолжаем цикл материалов о секции омского VII Международного ИТ-форума «Предпринимательство в сфере IT», которая прошла в «Точке кипения — Омск» на Жукова, 21. 

В прошлый раз мы писали о треке «Сервисы», где эксперты делились успешными способами решений актуальных проблем в сфере IT. Трек «Продукты», о котором мы расскажем на этот ращ, прошёл 19-го февраля в той же «Точке кипения». 

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

Главным организатором секции стал Алексей Коровянский, технический директор Effective. В роли организаторов трека выступили генеральный директор и event-менеджер 7bits Анна Тарасенко и Сабина Мамедова. 

Первой выступила product-менеджер Альфа-Банка Виктория Дубешко. Она рассказала, как управлять продуктом, работать с командой и использовать метрики. 

— Я расскажу о продуктовой разработке на примере создания медицинской карты — приложении, в котором собрана информация об анализах и приёмах у врачей. 

Продуктовая команда состоит из product owner, возможно, менеджера по проектам и scrum-мастера. Сама разработка делится на девять этапов:

1. Продуктовый research: формирование цели, анализ рисков и MVP. Для этого этапа существуют предпосылки:

• разрозненность данных;
• жизнь в телефонах;
• усталость врачей от бумажной работы;
• развитие медицинских проектов Сбербанка; это повод вернуть пользователей в приложение.

После первичного анализа трендов и конкурентов наша команда провела 20 интервью и разослала 200 анкет, а для проверки новой «кнопки» провели 40 интервью и разослали уже 1000 анкет. 

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

Следующий шаг для описания целевой аудитории — выявить  места её обитания. Здесь помогла методология 5W:

• Что?
• Кто?
• Почему?
• Когда?
• Где?

После сбора данных я должна подробно довести до команды потребности аудитории. Это нужно для микроменеджмента по ходу разработки.

2. Поиск заинтересованных сторон: что нужно бизнесу и клиентам.

3. Формулирование конечных целей и управление ожиданиями: релиз MVP без закрытия мелких багов. 

4. Создание и принятие плана реагирования. Рисками занимается продакт.

5. Формирование списка фич для MVP и планирование объёма продукта. Важно определить основные функции, без которых он не может работать. 

Затем идёт приоритезация задач. Нужно понимать, какая задача принесёт больше денег, повысит качество клиентского опыта или привлечёт большую аудиторию.

6. Формирование команды: использование инструментов найма и наблюдение за процессами. Этим занимается продакт.

Ментальная карта (метод структуризации с использованием графической записи в виде диаграммы — прим. ред.) должна быть доступна всем заинтересованным членам команды. Она может содержать информацию о продукте и структуре команды. 

Продакт прорабатывает DOR (definition of readiness, критерий готовности задачи к тому, чтобы взять её в работу — прим. ред.). Он проводит регулярные встречи c сотрудниками: p2p, onboarding, ревью 360. 

7. Дизайн. Если есть штатный исследователь в команде, продакт собирает общую встречу по UX/UI. 

8. Оценка сроков по покер-планированию. 

9. Разработка кода и тестирование медицинской карты.

Существует три принципа выбора метрик:

1. Постановка проектных или продуктовых целей в компании. Достижение 80% клиентских метрик — это хороший результат.

2. Уровень зрелости продукта и команды. Я выделяю три типа зрелости: 

• MVP. Доставляем идею как можно быстрее до пользователя и проверяем гипотезу; 
• PMF. Принимаем решение на основе 15-ти метрик и отчётов; 
• Scale (масштабирование). Уходим от ручной загрузки, ежедневно мониторим показатели и смотрим на конверсии.

3. Ситуативное решение болей. 

60% фокуса продукта — исследование клиентов и конкурентов. Остальное занимает анализ метрик. 

На этапе MVP у меня было три вида метрик:

1. Продуктовые или бизнесовые: retention, MAU, SLA, данные и их источники, конверсия;
2. Командные;  
3. Технические.

Продакты измеряют качественные и количественные метрики. Первые дают гипотетические данные, которые помогают понять поведение пользователей. Качественные — низкие объёмы данных: интервью с пользователем и опрос фокус-группы. 

Продуктовые метрики:

• Customer acquisition cost — отражает совокупные затраты компании на привлечение одного пользователя;
• Life time value — показывает прибыль, которую приносит пользователь за всё время работы с ним;
• Churn Rate — показывает, какой процент клиентов прекратили подписку или оплату услуг за определенное время;
• Утилизация — оценивает работу администраторов;
• Конверсия — показывает отношение пользователей, которые совершили целевое действие, к общему количеству посетителей сайта в процентах;
• Session Duration — показывает среднее количество страниц, просмотренных за сеанс;
• Happiness — отражает пользовательское удовлетворение продуктом;
• Engagement — показывает уровень вовлечения пользователей;
• Adoption — показывает новых пользователей продукта.

Есть и метрики работы команды:

• Time to market — время на реализацию задач, которое зависит от эффективности;
• время на технический анализ;
• количество выложенных задач;
• время пребывания задач в статусах;
• объем бэклога и технического долга.

Бывает и избыток метрик, который снижает продуктивность команды. Число показателей лучше сокращать. 

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

Директор направления поверхностей для бизнеса SberDevices Михаил Пайсон рассказал, что должен уметь product-менеджер, какими качествами и образом мышления обладать, чтобы управлять разработкой продукта. 

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

Основные характеристики успешного продукта:

• ценность,
• прибыльность,
• масштабируемость.

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

Какими качествами он должен обладать:

• целеустремлённость,
• ответственность,
• честность с самим собой. 

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

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

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

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

Технический директор Channex.io Андрей Юдин решил рассказать, как они создали систему управления отелями The Booking Factory. Небольшой спойлер: для этого команда разработки слушала собственную «боль».

— Цель моего доклада — рассказать о процессе создания продукта для отелей.

Боль — ощущение физических или эмоциональных страданий. Есть три пути решения проблемы:

1. Смирение и терпение.

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

3. Собственный продукт, который мы решили разработать.

За первые две недели мы реализовали простенький прототип и попробовали его внедрить в отель. Менеджеры были довольны. Но это был не рабочий продукт, а метод проверки гипотез. 

Когда убедились, что это кому-то надо, стали обновлять каналы продаж. В нашем случае это был небольшой отель, который продавался на 20-ти каналах, где данные вносили вручную даже ночью. Если этого не делать, будет двойная продажа. И мы нашли решение — channel manager. Это такой прокси между отелем и клиентом. Мы автоматизировали работу с ценами, ограничениями и сезонами. 

Следующая проблема — обработка платежей. Списание денег с банковской карты делал бухгалтер, что занимало много времени. Мы подключили платёжные системы и решили проблему.

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

Затем возникла проблема продаж. Поняли, что люди не покупают продукт из-за непонятного процесса перехода на наше решение. Мы были вынуждены парсить отчёты о предстоящих заселениях из всех форматов, которые были у клиентов, чтобы облегчить им внедрение. 

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

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

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

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

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

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

После выступлений, как и на треке «Сервисы», прошла интересная дискуссия, во время которой обсудили обучение и начало деятельности product-менеджера. Выступали как спикеры, так и участники конференции. Посмотреть обсуждение можно на YouTube-канале «ИТ-Кластер Омск» по этой ссылке (таймкод: 4:35:10). 

На треке прошёл и интерактив по продуктовому мышлению, на котором проектировали product-сообщество, учились считать продуктовые метрики и решали продуктовые кейсы. Посмотреть его можно на по этой ссылке (таймкод: 3:36:12).

Это не последний материал, который рассказывает о прошедшей секции. Впереди вас ждёт интервью с хедлайнером конференции Максимом Десятых, сооснователем и членом Совета директоров многомиллиардного холдинга red_mad_robot, которое выйдет в ближайшее время.

Ярослав Загородников