История на примере портала для менторов
В работе над большим проектом легко увлечься и в режиме «вижу цель, не вижу препятствий» сделать что-то масштабное и крутое, но неактуальное или неудобное для сотрудников. Многие слышали про итеративно-инкрементальный подход, когда маленькими шагами с привлечением минимальных ресурсов запускаются пробные продукты и проверяются гипотезы. Но в реальности так не получается, и на запуске приходится испытывать горечь сожаления о потраченных часах работы команды, бюджетах и силах.
В этом посте на примере портала для поиска менторов я поделюсь своей историей борьбы с когнитивными ловушками, которые заставляют делать дорого-богато, а не маленькие шагами.
Я Дима Грачёв, занимаюсь обучением руководителей, а также менеджер продукта менторского портала в VK, соавтор канала про разработку HR-продуктов. Начинаем!
1. Осторожно, водоворот идей – не забудьте принять решение!
Всё началось с идеи создать портал для менторов — раздел в интранете, где коллеги смогут найти опытного ментора по лидерским, продуктовым, техническим вопросам для консультаций в формате один на один. Сама перспектива поработать над чем-то масштабным вдохновляла. Преодолев проектные комитеты, обоснования, презентаци и прочую бюрократию мы с командой были настроены решительно двигаться дальше и создать долгожданный сервис для сотрудников.
Мозговой штурм, все известные и выдуманные боли пользователя тонули на доске Miro, держась за бесконечное число стикеров, стрелочек, возможностей, рисков и ассоциаций. В 2-3 итерации мы придумали будущий путь пользователя, возможные решения, процессы и контрольные точки. Описали поиск ментора от профиля навыков до планирования встречи в специальном менторском календаре — не меньше 200 стикеров в длину.
Вот тут и возникает первая сложность: после часов размышлений, внезапных инсайтов, и гениальных идей мы очень сильно привязываемся к проделанной работе.
Что делать?
На этом этапе нам нужно дать идеям «подышать» и спокойно убрать все решения, которые:
- вызывают наибольшее число сомнений;
- очень сложно реализовать;
- невозможно проверить с помощью простых прототипов и интервью с пользователем;
- не помогают решить ключевую боль пользователя.
Как было у нас
Отсекать лишнее было очень тяжело. Отрезвляющим стало сокращение ресурсов на проект. Чтобы сфокусироваться на главном, мы провели интервью с пользователями. Оказалось, что навыки ментора как отдельная фича пользователю не очень интересны, их легко понять из текстового описания прошлого опыта, а для выбора времени встреч достаточно обычного календаря. Так мы смогли сократить функционал до менторской витрины и подачи заявок.
Для того, чтобы не раздувать свой продукт, важно в какой-то момент принять менеджерское решение, убрать лишние и оставить минимальный набор фичей для старта. В этом помогают разговоры с пользователем и внешние обстоятельства.
Что ещё может помочь?
- используйте матрицу RICE для оценки и приоритизации фичей, она сделает решения объективными;
- привлеките команду разработки, людям со стороны проще оценить актуальность идеи;
- можно показать потенциальным пользователям на интервью получившиеся идеи и попросить их оценить по степени полезности.
2. Вы не в космосе. Продумайте окружение и будущее вашего продукта
Часто мы запускаем новый продукт с ощущением первооткрывателей. Кажется, что мы отправляем ракету в космос, где на тысячи километров вокруг ничего нет. Такая установка ослепляет нас, и мы не видим барьеров и ограничений на стыке с другими проектам. А ведь многие идеи в проекте можно скорректировать или вообще не реализовывать.
Что делать?
После того, как вы продумали свой продукт, отдельно погенерите идеи на тему контекста, в котором существует ваш проект и его участник (в нашем случае ментор и менти), какие есть другие продукты и каковы их текущие и перспективные возможности.
Как было у нас
Мы придумали много интересных решений, но совершенно забыли, в каком контексте существует наш ментор, когда он не исполняет эту роль. Одной из фичей был выделенный календарь, где ментор размечает время, удобное для встреч. Например, он понимает, что вечером в пятницу редко случаются авралы, и поэтому предпочитает встречаться с менти в это время. Выглядит здорово: ментору и менти не нужно искать удобный слот каждый раз назначая встречу, а просто открыть специальный календарь и выбрать время. На самом деле всё планирование уже идёт в его рабочем календаре. Держать в актуальном состоянии дополнительный календарь и помнить, где он хранится, совсем не удобно.
Другой пример — это интеграция менторов в программы обучения. Когда мы запустили менторскую программу, поняли что уместно рекомендовать участникам обучения наставников, специализирующихся по теме тренинга. Но возможность дать ссылку на отфильтрованный по теме список менторов не был заложен в скоуп проекта.
3. Отсутствие монетизации, внутренние ресурсы снимает ограничения
Развитие внутренних продуктов ограничено бюджетом, но в отличие от коммерческих решений, нет жёсткого обязательства отбить вложения выручкой. Существующие KPI искусственно создают стимул, но в действительности, если вы не запустите решение для сотрудников, деньги инвестора не закончатся раньше времени, вам не придётся делать пивот, чтобы сохранить команду стартапа. Таким образом, объективные критерии, которыми руководствуются менеджеры продуктов, такие как прибыль, экономика юнита, не ограничивают вас в принятии решений и вы можете позволить себе немного лишнего.
Что делать?
Идеальное решение — выделиться в отдельную команду «стартапа» со своим бюджетом и ресурсом разработки. Так вы будете принимать действительно важные решения для продукта, ну, или провалите его.
Более практичное решение — запустить практику оценки фичей в бэклоге в story points или часах разработки, а также оценки влияния на вашу ключевую метрику проекта (как провести воркшоп по оценке, расскажем в отдельном материале). Исходя из этих двух вводных можно приоритизировать новые функции в вашем продукте.
Как было у нас
У нас тоже не было четкого бюджета и ограничений, и мы планировали разработку очень условно. Такой подход не позволяет рационально относится к приоритизации бэклога продукта и внимательно следить за запускаемыми фичами. С другой стороны, нам было важно запустить проект в определенные сроки с минимальной функциональностью. Через эту призму мы и принимали решения, каждый раз задавая вопрос: нужна ли эта фича пользователям на старте или без неё можно обойтись?
Завершая
Разработка внутренних продуктов для сотрудников требует быстрого запуска MVP, при этом команды разработки могут попадать в ловушки — из-за с широкого круга идей, игнорирования контекста или отсутствия жестких метрик продукта. Пройденный путь научил меня использовать любую возможность, чтобы проверить возникающие идеи и гипотезы: исследования, аналитика, small talk и нетворкинг-встречи. Уверен, что рекомендации выше помогут избежать ошибок. А в этой статье мы рассказали почему HR-продукты не дотягивают до уровня приложений для заказа такси или банков.
