Как приоритизировать фичи

Все что написано ниже, мнение автора и не является неоспоримыми постулатами.

Эта статья для “молодых” основателей стартапов, предпринимателей, продактов, а также всех остальных, кто как и я когда-то, выбирал приоритетные задачи, исходя из “внутренних” ощущений.

Наибольшую ценность от статьи вы получите, если самостоятельно доберетесь до значений всех непонятных терминов в тексте.

Тем, кому не приятен стиль изложения - мои глубочайшие извинения. Не стреляйте в пианиста, он играет как умеет.

Как для команд, так и для отдельных программистов и менеджеров расстановка приоритетов в разработке продукта - одна из наиболее важных и трудоемких задач.

Можно отрицать её наличие и делать так, как велит вам сердце.

В этом случае разработка похожа на плавание по океану без штурмана, компаса, звезд и секстанта. Вы движетесь вслепую, кружите на одном месте или даже возвращаетесь обратно. На продуктовом языке - ваши LTV, APC, AvCheck, С1 не меняются.

Допустим, у вас четкое видение аудитории и продукта. Интуитивно выбирается верный курс и вы открываете “Америку”. Для стартапа это ошибка выжившего. Только хуже. 2-3% “поймают” ошибку и доплывут, а остальные обойдутся и найдут покой на дне морском.

В работающих продуктах “Америки” давно открыты и остается только “оптимизировать логистику”. Как вариант - выкопать Панамский канал.

При “оптимизации логистики” по велению сердца, т.е. при улучшении параметров, без понимания механики влияния проделанной работы на результат, продукт неизбежно попадет в зону штиля и останется дрейфовать в ожидании нового озарения. В то же время более прозорливые конкуренты посмотрят на карту, поймают течение и пойдут в нужную сторону.

Пока вы стоите - косты тянут вас вниз, конкуренты уходят в отрыв и шанс получить долю рынка или сохранить свою снижается.

Не хочу чтобы после прочтения “пессимизма” выше сложилось впечатление, что призываю напрочь отбросить интуицию и следовать “математике” оценочных методов. Это все равно, что вернуться к диаграммам Ганта после Скрама и Аджайла.

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

За фичу будем считать функцию программы, написанную из юзер стори или JTBD и соответствующую принятым в команде критериям завершенности.

Критерии завершенности (Definition of Ready) - набор условий, при которых фича уйдет в спринт, т.е. она ясная, выполняемая, проверяемая. По окончанию спринта такая фича будет соответствовать критериям готовности (Definition of Done). По минимуму добавим к вышесказанному - код работает, тесты пройдены и быть может даже есть документация if you know that i mean. (~ ст.300 SCRUM)

Далее речь пойдет о приоритезация фич в бэклоге. Термин пришел к нам из SCRUM = Agile, а значит важно соблюдать сами принципы, а не следовать “букве закона”. Agile у каждого свой.

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

Включает:

• функции продукта в формате User Story;
• баги;
• то что влияет на ход работы (тех работы, обучение, обновление софта).

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

User Stories («пользовательские истории», далее US) упорядочены в зависимости от их «бизнес веса». Верхние позиции должны быть более подробно и четко описаны, чтобы любой человек в вашей команде и со стороны заказчика понимал итог одинаково.

Самый главный приоритет - “бизнес вес” фичи.

“Вроде изян” (Кто не в теме, смотрим универсальную таблицу оценки задач).

Важно понимать, что “Бизнес вес” - величина переменная и зависит от цели продукта на данном этапе.

Пример целей для стартапа.

Упростим 100-500 теорий расчета “как заработать” для стартапа до одной. Важно то, что принесёт нам денег на ближайшем отрезке пути или приблизит нас к отрезку когда эти деньги будут. Варианты отрезков навскидку:

• Привлечь первого клиента
• Получить первую оплату
• Получить первые инвестиции (выполнить KPI)
• …
• Получить 100, 1000, 10k клиентов, 10k DAU и т.п.
• Получить раунд
• ...

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

Пример 2. Мы резко растем (так бывает, что некоторым везет или их гроу тим качает по AAARRR)

Маркетинг старается, льются деньги в рекламу.

Мы следим на конверсиями (особенно c0) и ретеншеном.

Приоритет на онбординг и удержание.

Пример 3. Рынок стоит (и мы с ним)

Стратегия - удержать пользователей или переманить у конкурентов.

Саппорт, управление клиентским успехом, активная работа по фичам из User Research (КастДева по русски).

Что хотел сказать - для каждого продукта в разные моменты времени бизнес-вес сильно отличается и это крайне важно не упустить.

Следовать цели - понятное, логичное и необходимое решение. Но достаточно ли оно?

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

• Видите его здесь и сейчас (кнопка, функция, ответ на API запрос, графика)
• Влияние фичи на метрики в течение 1-2 недель, таким образом, чтобы отличия превышали статистическую погрешность

Речь о методах RICE / ICE

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

Мне эти методы не особо нравились, и только недавно понял почему.

Они не учитывают имеющиеся ограничения.

Чаще всего небольшие компании ограничены производительностью отдела разработки и датой релиза.

Решение этой задачи - добавить к формулам дополнительные переменные.

Одна из них - затраты, которые потребуется для разработки. Можно в деньгах или часах на первом этапе. Не забудьте привести их к общему знаменателю метода.

Другая переменная - время, которое требуется для сбора и валидации данных. А/B тест - работы на 2 часа, узнать эффект - зависит от трафика. На Озоне час, у меня 2 месяца.

Метод с учетом затрат используют многие, как это выглядит. смотрите на картинке.

Мой опыт - разработка SaaS ERP для сервисных центров по ремонту цифровой техники. История началась в 2012 году и продолжается до сих пор.

Расстановка приоритетов сильно зависит от количества задач в бэклоге. Если их одна или две, то альтернатив нет и задумываться особо не о чем.

Это плохо. И так было у нас, пока продукт развивался только по моему видению.

Но, количество задач выросло. И не потому, что начал спрашивать о болях клиентов, а так как команда не успевала делать все, что я придумывал. При этом в задачах даже не было четкого описания. В 13-ом году мне казалось что разработчики должны все понимать даже по сокращенной версии US. Святая простота :)

Затем, во ФРИИ, мне объяснили, что так дело не пойдет, надо получать прибыль и на первое место вышли задачи, которые непосредственно влияли на доход.

• Управление тарифами
• Интеграция с партнерскими программами
• Функции, которые добавляли ценность продукту и позволяли вводить новые тарифы

Мозг начал напрягаться и считать отдачу от решения каждой задачи. Появились зачатки документации на продукт и задачи стали оцениваться по времени исполнения. Мы их немного обсуждали с командой и пускали в работу. О подробной проработке до поступления в разработку речи не еще не шло и реальные сроки огорчали. Я не то чтобы потерял веру в разработчиков, но сам процесс и его сроки стали вызывать огромные сомнения.

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

Начал писать подробные ТЗ и прикладывать прототипы, как это должно работать. Мы сменили систему управления на райк с его канбан досками и папками\проектами.

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

Единственное, что прерывало этот порядок - найденный баг.

Чем правильнее учился ставить приоритеты, тем продуктивнее становился наш аджайл. А потом я узнал про Скрам. Но это уже другая история

В настоящий момент, с учетом состояния рынка и основной задачи, речь идет только о поддержке пользователей и доработке функционала в узких местах. US набираем раз в неделю / две, с небольшим запасом. Часть прорабатываю сразу, часть идет в очередь (штук 20-25). Находится баг - он в приоритете.

В конце статьи подкинули интересную идею, которая не подходит лидерам рынка, но для остальных жизнеспособна.

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

То есть, при расчете приоритета посчитаем, как часто используют эту фичу наши конкуренты.

Для этого я поговорил с тремя людьми, которые так или иначе влияют на расстановку приоритетов. Названия своих компаний они предпочли не афишировать.

В опросе участвовали руководитель проекта одного известного банка, аккаунт менеджер студии заказной разработки и тимлид финансового стартапа в Сингапуре. Ребята, и их компании с громкими именами, достойные со всех точек зрения. Беседы заняли 1,5 часа, тут только выжимка.

В подавляющем большинстве РФ компаний разработка проектная, делается по ватерфолу \ каскаду с диаграммами Ганта.

Это значит, что практически ВСЕ приоритеты расставляются после сбора требований и планирования архитектуры. Худший вариант таких историй - продукт можно увидеть в работе, только когда он будет готовым.

Но, думаю у ребят все продумано таким образом, чтобы получать обратную связь от заказчика по окончанию каждого цикла.

Внутри проекта история куда интереснее и ближе к истине. Основные вехи декомпозируют на осязаемые и оцениваемые. К оценке привлекается QA, как самый активный пользователь продукта в команде, используется planning poker.

Разумеется регулярные ежедневные митинги на 15-20 минут.

Как итог - приоритет на технических нюансах. Что, как и в какой последовательности выполнять. Глобально проект от этого не выигрывает, но минимизируют простои, а “затыки” в разработке выявляются максимально быстро.

В сингапурском стартапе задача ставится бизнес-аналитиками. Они находится в постоянном контакте с пользователями и выясняют их реальные проблемы. В рамках вышесказанного, BA определяет бизнес-вес, после чего знакомит команду с задачами.

US двигается по канбан доске в Jira. Обычно в бэклоге порядка 100 задач, но для конкретного исполнителя не более 5-6. Это те задачи, которые планируются в ближайший релиз. Их выполнение может прерываться правками багов или короткой доработкой. В компании 3 команды, но их задачи пересекаются не часто.

К сожалению поговорить с БиЭй не вышло, а так очень хотелось знать что творилось на старте продукта.

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

• Прочитал бы “User Story Mapping” Пэттона (в очереди)
• Набрал в свой бэклог максимум задач, чтобы было над чем думать
• Разобрал задачи по эпикам (наборам историй / джобов от одного пользователя / целевой аудитории)
• На “глаз” определил бизнес-вес каждой задачи на данном этапе развития продукта
• Оценил наиболее значимые задачи количественно
• Подробно расписал верхушку бэклога
• Обсудил и оценил лидеров с командой, уточнил подзадачи и детали UI. Если все ок, то в разработку
• Оценил эффект от реализации
• С учетом эффекта переоценил бы следующий набор задач
• Повторил с пункта 2

На написание статьи меня подтолкнуло обучение в Product University, за что им огромный респект и уважуха.

Тяжело в учении, а на работе за пробелы в знаниях вы и компания заплатите временем и деньгами.

При подготовке материала использовался личный опыт и материалы из книги Джеффа Сазерленда “Scrum. Революционный метод управления проектами”.

Если есть замечания по теме или хотите поделиться опытом, оставляйте комментарии.