«РМ и заказчик бегут в разные стороны». Как много боли в этой фразе, ведь она означает, что команда тратит ресурсы впустую. Но этого можно избежать.
Павел Хариков — Head of IoT в VEON Group (Kyivstar, Beeline). У него больше 10 лет опыта проектного и портфельного менеджмента в международных компаниях. Павел работал над масштабными проектами с бюджетом до $150 млн, а в Laba он ведет курс «Проджект-менеджмент 2.0».
Нам Павел рассказал, как определять ключевые метрики успешности и готовить финансовый отчет по проекту.
Какие существуют метрики успешности
Универсальные для РМ — сроки, бюджет и охват. Но останавливаться на них — большая ошибка. Ключевыми метриками должны быть те, которые оценивают соответствие целям заказчика. Их нужно определять на ранних этапах проекта, потому что от них зависит реализация. Когда РМ понимает, что для клиента важно и ценно, он будет принимать соответствующие решения.
Например, в IT специфические метрики делятся на два вида:
- те, что показывают прибыльность реализованного решения
- те, что показывают, в какой степени это решение популярно и насколько получается удержать аудиторию
Есть метрики, которые относятся не только к IT, но и к другим сферам, в том числе к банкам и телекому.
- ARPU (Average Revenue Per User) — средний чек на пользователя или на клиента. Это важный показатель, ведь когда заказчик планирует реализацию какого-то функционала, он рассчитывает на определенные доходы.
- Также принято считать Paying Users, ведь могут быть и пользователи только бесплатной части функционала. Эта метрика показывает жизнеспособность продукта и равна числу платящих юзеров за период. Тревожным звоночком может быть ситуация, если большую часть дохода приносят лишь несколько пользователей. Потеря каждого из них способна сделать проект убыточным.
- LTV (lifetime value — пожизненная ценность) — это предполагаемый чистый доход от всех взаимодействий клиента с продуктом за все время его использования. Определяет целесообразность продукта.
Есть метрики, которые помогают понять, насколько у проекта получается мотивировать аудиторию остаться:
- Retention rate (удержание пользователей) — способность компании удерживать своих потребителей в течение определенного времени.
- Churn rate (показатель ушедших пользователей) — процент юзеров, которые отказались использовать в будущем предложенный сервис.
Например, KPI конкретного проекта для большого системного бизнеса может быть снижение Churn rate всего на 1,5%, что очень существенно для финансовых показателей компании.
Как определить метрики в IT-сфере: пример
Допустим, вы взяли проект по созданию приложения для вызова такси. Здесь у вас точно будет два типа пользователей: пассажиры и водители. Программа должна удовлетворять их потребности, а метрики — учитывать цели по каждой из категорий юзеров.
Следовательно, можно ориентироваться на такой набор метрик:
Проектные:
- срок реализации (допустимые отклонения от базового плана)
- выполнение бюджета (допустимые отклонения)
Доходные:
- Revenue — общий доход от сервиса.
- ARPU пассажиров, чтобы понимать, сколько каждый пользователь приносит в среднем.
- Paying Users, чтобы видеть, какой процент юзеров прибегает к платным активностям.
- Lifetime value (LTV) покажет доход от клиента за время пользования приложением. Косвенно этот параметр определяет максимальные затраты на привлечение новых юзеров.
- CAC (Customer Acquisition Cost) — стоимость привлечения одного пользователя. Необходимо сравнить с LTV: 1/1 (или ниже) — нужно срочно что-то предпринимать, иначе компания разорится, 2/1 — уже неплохо, 3/1 (и выше) — можно инвестировать больше в привлечение новых пользователей и проект способен себе это позволить.
Хотите получать дайджест статей?
Активная база / удержание:
- MAU-P (Monthly Active Users-Passengers) — количество активных пользователей-пассажиров. Можно анализировать за разные периоды (день / неделя / 3 месяца).
- MAU-D (Monthly Active Users-Drivers) — количество активных пользователей-водителей. Если критично снизится — некому будет возить людей.
- Churn rate — Passengers — сколько пассажиров перестало пользоваться приложением. Рост этого показателя говорит о том, что необходимо изменить цену, функционал, дизайн, коммуникации и т. д.
- Churn rate — Drivers — сколько водителей перестало пользоваться приложением. Рост этого показателя сигнализирует о том, что нужно пересмотреть условия партнерства.
- Average trip evaluation (средняя оценка поездки) — искусственная метрика под конкретный пример. Она показывает, насколько качественно водители соблюдают правила обслуживания клиентов (езда по ПДД, чистота авто, маска, исправность ремней безопасности).
Не менее важно измерять NPS (Net Promoter Score — Индекс поддержки потребителя). Он говорит о том, насколько люди готовы рекомендовать ваше приложение своим знакомым. От NPS зависит лояльность клиентов. Сюда входит и комфортность использования нашего приложения, и соотношение «цена — качество».
Что будет, если РМ не зафиксирует результаты
Сформулировав цели проекта с помощью KPI и метрик, проджект-менеджер (PM) должен согласовать их с ключевыми стейкхолдерами и заказчиком. Это важно сделать именно на старте проекта, прежде чем команда начнет тратить ресурсы. Без общего понимания РМ и заказчик будут бежать в разные стороны.
Как показывает практика, если РМ не зафиксирует результаты проекта, то стейкхолдеры и клиент сделают это субъективно. Так что лучше возглавить эту историю, чтобы не поставить под удар карьеру проджект-менеджера и всей команды.
Все процессы по проектному управлению — живые. Они происходят не в вакууме, а в организации с определенной оргструктурой и взаимодействиями между людьми. Если эти процессы не корректировать, то развития не будет. Финальный отчет (ФО) — как раз способ определить проблемы и предложить решения.
Проблемы, с которыми сталкивается project manager
Подписаться на подкаст «Умных любят»
Зачем фиксировать результаты проекта: топ-3 фактора
#1. Ретроспектива и рефлексия. Для РМ это возможность разобраться, что он делает неправильно и как можно работать эффективнее.
#2. Накопление опыта организации. Проджект-менеджер должен иметь возможность не начинать с нуля, а использовать наработки предыдущих РМ компании. Это глобальная цель финального отчета по проекту.
#3. Фиксация результатов конкретного проекта, чтобы не было возможности трактовать их по-разному.
Как создать эффективный финальный отчет
В ФО обязательно фиксируйте, что планировалось и что получилось в итоге. Де-факто ФО — это ретроспектива (или post-mortem analysis — он работает по принципу «вскрытие покажет»), в которой мы описываем:
- плановый и фактический срок реализации
- причины сдвигов по времени. Важно: если проект велся корректно, то любое смещение срока реализации должно было фиксироваться запросом на изменение. Подобные решения РМ не принимает — он может только все подготовить, предложить опции дальнейших действий, но последнее слово остается за спонсором
- отчет по расходам (сколько планировали и сколько в итоге потратили)
- риски (нужно указать, какие контрмеры были эффективны, а какие — нет). Важно также отметить риски, которые не были идентифицированы, но случились в процессе. Помогает всем последующим РМ в работе с другими проектами
- команду (какие скилы и опыт получили, какая текучка, были ли проблемы с наймом)
- опыт по закупкам (каких подрядчиков привлекали и как с ними работалось)
- опыт коммуникации (насколько заказчик и команда могли эффективно взаимодействовать)
- рефлексию РМ относительно своей работы
Вот 4 ключевых вопроса, на которые РМ должен ответить после окончания проекта:
1. Что бы он делал иначе?
2. Что бы он перестал делать?
3. Что бы он делал больше?
4. Что бы он делал меньше?
Musthave-инструменты для РМ
Из моего опыта работы в телеком и банковской сфере, очень гибкие отчеты позволяет строить продукт Power BI от Microsoft. Для получения финансовых метрик предварительно необходимо проработать с бухгалтерией, какие данные и из каких отчетов нужны.
Чтобы составлять ФО было несложно, важно вести проект правильно с самого начала. Ведь кроме рефлексии РМ по проделанной работе, в ФО входит собранная в один документ история трансформаций. Если что-то в ходе проекта менялось (сроки, бюджет), такие моменты должны фиксироваться.
Все эти данные проджект-менеджеру нужно держать под рукой в виде простой таблицы в Excel с информацией:
- дата согласования изменения
- описание и причины, по которым возникла необходимость его вносить
- сроки/бюджет реализации проекта до изменения
Весь бизнес-контент в удобном формате. Интервью, кейсы, лайфхаки корп. мира — в нашем телеграм-канале. Присоединяйтесь!
- сроки/бюджет реализации проекта в результате изменения
- кто согласовал изменение
- файл с протоколом совещания, где было принято решение, или письмо с подтверждением либо ссылка на документ в системе электронного документооборота. Здесь подходит любой принятый в организации способ фиксировать договоренности
Проджект-менеджеру будет сложно объяснить, почему проект затянут, бюджет превысили, сделана только часть функционала, а запросов на изменение не было.
Инструменты, с помощью которых составляется ФО, зависят от организации: это может быть файл Word, презентация или другой удобный формат. Но важно иметь базу всех документов, которые собирались в ходе проекта. Многим удобно вести все в Confluence или в Jira, тогда вся информация скапливается в базе знаний проекта. Оттуда легко по категориям взять данные и собрать в ФО.
Хотите получать дайджест статей?
