Как расставлять приоритеты между запросами от пользователей, поддержки и стратегическими задачами?

Полина Милютина:
«Как в одной очереди расставлять приоритеты между задачами для пользователей и для техподдержки, как их сравнивать? Не всегда получается оценить пользу для пользователей от того, что будет сделано для техподдержки. Есть какие-то правила?»

Отвечает Дмитрий Абрамов, Head of Product в Skyeng.

«Какие могут быть правила в продакт менеджменте? Мы работаем в максимально нестабильной, неизвестной среде, в зоне высокой неопределенности. Тут нет и не может быть правил и нужно это хорошо понимать. Нет экспертов, которые скажут «делай а-b-c и получишь успешный результат», иначе не нужны были бы продакт менеджеры.

Но есть разные полезные практики, которые можно использовать.

Давайте порассуждаем, почему мы не можем оценить пользу от задач для техподдержки. Возможно, мы не до конца понимаем, на какие метрики смотреть. Удобный способ — считать всё в деньгах. Например, мы делаем функцию, которая облегчает поиск информации сотруднику техподдержки в каждом пятом запросе на 1 минуту. У вас 20 сотрудников службы поддержки, которые обрабатывают 100 запросов в день.

100*20/5 = 400 минут в день *22 (рабочих дня) *12 (месяцев) = 105600 минут или 10 человекодней поддержки в год. С зарплатой 40 000 ₽ в месяц вы получаете экономию ~20 000 ₽ за год, что довольно скромно. Это просто пример, практически всё можно посчитать.

Другой вопрос, нужно ли это считать? Однозначного ответа и тут нет, ведь подсчет иногда стоит не меньших денег, чем реализация (особенно если раньше мы не собирали эти метрики и даже не знаем, где их взять). В зависимости от целей продакт может принять более простое решение — разделить усилия на внутренние и продуктовые задачи и сделать две очереди для этих типов. Приоритизировать продуктовые задачи несложно, внутренние тоже, можно даже по разным метрикам. А соотношение внутренних и продуктовых задач можно просто задать процентом. Например, каждую пятую задачу берем из очереди внутренних задач. Всё, проблема решена!

Бывает, что таких правил недостаточно, особенно если есть очередь с багами. Можно тратить не более 20% времени на баги, но как быть, если баг мешает всем пользователям оплатить продукт? Конечно, его надо срочно чинить. В этом случае неплохо бы разработать определенные критерии критичного бага: если ошибка им соответствует, для нее используют отдельные правила.

Самое главное в любой приоритизации: она должна быть прозрачна для всех участников процесса. Сделайте принципы явными, опишите их и корректируйте, если поняли, что они неидеальны. Помните, что главное уметь отвечать на простой вопрос: «Какая одна задача самая полезная для компании в данный момент?». Не надо искать волшебную таблетку — где-то принято считать ROI каждого мелкого изменения, а где-то можно пренебречь измерениями, если стоимость разработки не слишком велика».