{"id":4879,"title":"\u0427\u0442\u043e \u043c\u043e\u0436\u043d\u043e \u0443\u0441\u043f\u0435\u0442\u044c, \u043f\u043e\u043a\u0430 \u0432\u044b \u0447\u0438\u0442\u0430\u0435\u0442\u0435 \u044d\u0442\u0443 \u0441\u0442\u0430\u0442\u044c\u044e","url":"\/redirect?component=advertising&id=4879&url=https:\/\/vc.ru\/otpbank\/266952&hash=82572a4a372a00657a2afc359f19a24c0bd24be8cecbd743f0681209c07c9a3a","isPaidAndBannersEnabled":false}
Павел Бородин

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

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

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

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

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

Почему это важно?

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

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

В этом случае разработка похожа на плавание по океану без штурмана, компаса, звезд и секстанта. Вы движетесь вслепую, кружите на одном месте или даже возвращаетесь обратно. На продуктовом языке - ваши 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 недель, таким образом, чтобы отличия превышали статистическую погрешность

Оцениваем “бизнес вес” в цифрах

planio

Речь о методах 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. Революционный метод управления проектами”.

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

{ "author_name": "Павел Бородин", "author_type": "self", "tags": [], "comments": 1, "likes": 2, "favorites": 8, "is_advertisement": false, "subsite_label": "unknown", "id": 167257, "is_wide": true, "is_ugc": true, "date": "Thu, 15 Oct 2020 12:48:41 +0300", "is_special": false }
0
1 комментарий
Популярные
По порядку
0

Очень интересная подача и авторский стиль изложения! Было интересно, спасибо :) 

Ответить
Читать все 1 комментарий
Уверенность Безоса: чем основатель Amazon поражает собеседников Статьи редакции

Перевод издания «Идеономика».

EPA
31 июля завершается приём заявок в 1-й этап отбора программы B2C Future Solutions
Из-за шума животные уходят из городов и лесов, а у людей он вызывает стресс: как исследователи борются за тишину Статьи редакции

Организация Quiet Parks International открывает «тихие парки» по всему миру, пытается защитить леса от шума, привлечь туристов и инвестиции.

Директор QPI по диким паркам в Азии Лайла Чин-Хуэй Фань Wired
Как сделать классное мобильное приложение #Аэрофлот?
Как подготовиться к жизни без cookies: рекомендации маркетологам

О технологии Federated Learning of Cohorts (FLoC), которая заменит cookies, Google объявил еще в начале года. Недавно компания анонсировала перенос запуска технологии на 2023 год, и теперь у рынка интернет-маркетинга есть 2 года, чтобы найти альтернативу работе с данными. Как выглядит ситуация сейчас и что делать маркетологам — в обзоре от AiData.

«Подрядчики запустили рекламу и ‟потеряли” 350 млн рублей»: почему на digital-рынке врут, косячат и крадут

13 историй о том, какие иллюзии есть у заказчика онлайн-рекламы, когда он поручает маркетологам задачи.

Грущу из-за всего, что осознал
Альфа банк самовольно закрыл зарплатный счет

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

Как успешно пройти испытательный срок?

Свершилось – вы получили работу мечты! Но впереди еще три месяца испытательного срока. Это время дается вам и работодателю, чтобы определиться, насколько вы друг другу подходите. Как использовать это время с максимальной для себя пользой? Рассказывает главный специалист отдела подбора персонала Ольга Шабалина. Как всегда, упаковали полезные…

Как превратить юристов из бюрократов в опору компании

Бывает, что корпоративные юристы — люди, которые не показываются из кабинета и иногда вставляют палки в колёса другим отделам. Но в «Фоксфорде» они сами ходят к бизнес-заказчикам и предлагают идеи. Юрист онлайн-школы «Фоксфорд» Катя Кулакова рассказывает, как работает юридический отдел, который живёт интересами компании.

Катя Кулакова, юрист онлайн-школы "Фоксфорд"
Лондон: не всегда мечта для программиста. Как живется в столице Британии во время коронавируса

Мы поговорили с ним о жизни IT-специалиста в Лондоне: о пинг-понге с карантинами и переездами, о местных (некомфортных) оупенспейсах, самом старом в мире метро, проблемах с электросамокатами и лондонском тумане. И о том, кому здесь все-таки стоит жить. Передаю Анатолию слово!

Жиросжигание и жирапотери — это разные вещи. Что важнее?

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

null