Приоритизация задач на разных стадиях развития компании

Руководитель управления сервисов поиска недвижимости компании «Метр квадратный» рассказывает, как со временем для бизнеса приобретают значимость новые задачи

Я работаю в компании с самого основания и сегодня расскажу о приоритизации задач на разных этапах становления нашего проекта.

Экосистема недвижимости «Метр квадратный» – молодая компания со своим центром разработки, которая за 1,5 года выросла из стартапа в составе 5 человек до бизнеса, в котором работают 320 сотрудников. За это время в продуктовой разработке мы сменили три парадигмы, что и позволило нам эволюционировать так быстро.

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

Здесь возникает первый осознанный бэклог, и главное – не усложнить себе задачу. Приоритизация на этом этапе — бинарная, и достаточно будет создать Excel или Google Docs с перечнем всех планируемых функций. Мы понимали, что годовое планирование с привязкой по фичам в нашем проекте не сработает, поэтому начали с того, что определили ключевую функциональность — список идей, без которых продукт не может быть назван даже MVP (минимально жизнеспособный продукт) — и сосредоточились на них.

Мы использовали подход классического проектного планирования — waterfall, отделяли важное от неважного и начинали с необходимого. Например, база недвижимости не может работать без поиска или карточки объекта, а также без фильтров по комнатности или цене.

Основные метрики: Happiness (Customer Feedback), Engagement (Open Rate)

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

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

При дизайне спринтов мы опирались на гибкие методологии. В основу лег метод управления проектами Scrum с классической ICE-приоритизацией — Impact (влияние), Confidence (уровень уверенности в оценках), Effort (усилия).

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

Перед каждым планированием у нас вставал важный вопрос: какой функционал наращивать в первую очередь? И ICE позволял нам понять, что будет наименее затратно, но наиболее ценно пользователям. Мы оценивали каждую функциональность по трем параметрам: Impact был за продуктовым менеджером, Confidence — за тимлидами, Effort — за командой. Затем при перемножении параметров мы получали общий ICE Score. Так рождалась минимальная приоритизация.

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

На этом этапе квартальное планирование превратилось в формальность — команды одинаково понимали систему координат.

Совет: Используйте ICE Score, чтобы определить, какие фичи будут наименее затратны с помощью разработки, но наиболее ценны пользователям. Это простой и эффективный инструмент на начальных этапах.

Наш лайфхак по оценке приоритизации функциональностей

Основная сложность с ICE состояла в том, что мы не понимали, в чем оценивать наши фичи? Самое простое решение — делать это в понятной системе координат. Мы придумали взять размеры одежды, ведь все мы ходим в магазины и понимаем, чем S отличается от M, L и XL. Хитрость была в том, чтобы к каждому размеру приравнять число последовательности Фибоначчи, начиная с 3го ряда. Это позволило командам сфокусироваться на размерах задач. Менеджеры оценивали Impact на основе результатов исследований Cusdev и JTBD. Команда разработчиков оценивала Effort на основе уже решенных задач. Затем мы смотрели, насколько эти две оценки совпадали с реальностью и указывали Confidence, которая была корректировочной. Так мы получали список самых простых, но самых полезных фич, которые надо делать в первую очередь.

Основные метрики: Adoption (User Grow, MAU), Retention, Task Success (Conversion Rate)

Сейчас продукт активно развивается, мы перешли в стадию становления, где нашим главным критерием являются четкие бизнес-показатели. На этом этапе ICE перестает работать, и самым логичным становится переход к методу управления проектами OKR («цели и ключевые результаты»). Мы ставим квартальные цели, а способ достижения выбирает команда. Такой подход формирует осознанную ответственность за результат. Помогает то, что к этому моменту наши команды наработали знание о способах и метриках, которые влияют на показатели продукта.

Несмотря на уже полученный опыт, мы продолжаем следить за динамикой показателей после каждого изменения продукта, а если ситуация позволяет, подтверждать решения A/B тестами. Мы формируем пирамиду метрик, где учитываются как продуктовые, так и бизнес-показатели.

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

Так, например, на этом этапе команда поиска интегрировала ипотечный брокер в карточку объекта, что дало нам заметный бизнес-результат.

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

Основные метрики: Revenue, ROI, CAC, HEART