Приоритизация задач на разных стадиях развития компании
Руководитель управления сервисов поиска недвижимости компании «Метр квадратный» рассказывает, как со временем для бизнеса приобретают значимость новые задачи
Я работаю в компании с самого основания и сегодня расскажу о приоритизации задач на разных этапах становления нашего проекта.
Экосистема недвижимости «Метр квадратный» – молодая компания со своим центром разработки, которая за 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
Благодарю за разбор. 👍
Какие следующие шаги?
Четвёртый этап уже проектируется?
Александр, спасибо.
Следующий шаг масштабировать систему на все продуктовые команды компании.
Четвертый этап начнем проектировать из потребностей, когда текущий формат не будет покрывать весь спектр стратегических задач.
Украли идею (слово в слово) из презентации основателей Ревизор Недвижимости.ру (Rendv.ru), и имея финансовые средства реализовали. Стартап по-русски. Конечно, зачем вкладывать в кого-то, когда можно украсть и реализовать на свои деньги. Новаторы хреновы!!! Немощи!!! У самих мозгов не хватает, так воруют!!!
Я, как время будет, интересную статью про это напишу от первого лица и про весь российский «венчур» в стартапы и про подобных инвесторов!!!Как люди, которые воруют идеи у стартапов вместо того, чтобы помогать им их развивать и реализуют на собственные или привлечённые средства под якобы своей идеей.
дошел до первой "арфаГрафической" Ашипки и бросил читать - не потому что грамарНаци, потому что - давать советы Капитана Очевидность, это не шарман. Не вдохновило - получил, лишь отторжение, заметь - я не носитель языка Достоевского, Пушкина.
Коллега, будет здорово, если Вы укажете нам на ошибку в тексте. Хуже было бы обнаружить баг в нашем продукте, согласны?:)
Не согласны
прошу прощения - моя ошибка, можете ставить минусы за мой каммент
Интересный поэтапный разбор.
Не совсем поняла один момент. Антон, подскажи, а зачем вы сначала брали размеры одежды, а потом трансформировали их в числа Фибоначчи? Почему бы сразу не использовать их? Или я не так интерпретировала?)
Люда, привет. Рад тебя видеть на просторах VC. Ответ простой. Для того чтобы складывать финальный ice score нужны числа, а командам легче было планироваться в майках, так и появилась связка:
XS - 1
S - 2
M - 3
L - 5
XL - 8
XXL - 13
Супер, а как вы относитесь к приоритезации приоритезации? Что, по-вашему, нужно приоритезировать в порядке приоритета?
Комментарий удален модератором
Уверен, если приоритизировать правильное написание слова "приоритизация" (в этом слове нет буквы "е"), то все будут относиться отлично!
Солидарен!
Очень интересный пост, спасибо!
Только не сложилось в голове: насколько я понял теорию, ICE - это именно про приоритизацию (что более важно, а что - менее), а OKR - это про постановку целей (куда движемся).
То есть, поставив цель по OKR, всё равно же надо решать, какую фичу в первую очередь делать.
Как в итоге после постановки целей по OKR решали, что из бэклога брать и в каком приоритете?