Как «Дукалис» помогает приоритизировать задачи в Jira

CEO прибежал с новым видением продукта через фичу A, важный клиент требует настройку B, модный блог пишет про использование C, инвесторы подкинули идею сделать X, маркетинг требует Y, а разработчики меняют базу данных на Z. Компания должна уметь говорить «нет» большинству идей фичей, пропускать через фильтр целей, принципов и ценностей. Эту историю описывал Дез Трейнор из Intercom.

Хитен Ша честно признался, что проблемы с приоритизацией погубили его KissMetricks. Он, как бомбами, закидывал команду «гениальными идеями», которые разрывали все планы, тянули команду в разные стороны, и в итоге продукт потерял все позиции на рынке.

На днях Steli Efti из Close.io написал пост про важность овер-коммуникации в распределенной команде. Важно понимать не только, кто и над чем трудится, а зачем: что эта идея, фича или статья принесет компании в данный момент времени. Важно посмотреть на нее с разных сторон.

Делать ненужные задачи — самое большое воровство времени в компании.

Мы тоже оказались в подобной ситуации. Команда разработки брала задачи, про которые продуктовая команда спрашивала: «Зачем это вообще делать? Приоритеты уже давно поменялись!»

С чем столкнулись мы

Мы пытались делать еженедельные обсуждения. Записывали важные задачи в Google Keep. Использовали маркеры приоритетов в Jira. Систему спринтов. Все это не помогало, ненужные задачи продолжали случайно доставаться из беклога и переходили в разработку.

Нам помогла методология взвешенных оценок приоритизации задач, которую мы спроектировали сначала в Google Spreadsheets. А позже перенесли в отдельный продукт — «Дукалис». Он стал учитывать наши разные и изменяющиеся взгляды на приоритеты компании — и в любой момент времени показывал самый важный топ задач, над которыми стоит работать.

Главный экран с самыми важными задачами в компании​

Как «Дукалис» решает проблему неверных приоритетов

Каждую неделю вся команда субъективно выставляет баллы от 0 до 3 для каждой задачи по критериям, важным для конкретного проекта.

Каждый раз отвечая на вопросы вроде:

  • Как эта фича повлияет на продажи для клиентов?
  • Как эта идея уменьшит время на обслуживание клиентов?
  • А насколько долго это делать?
  • Насколько массово пригодится фича?

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

У нас получилось:

  • Sales. Помогает в продажах. Влияет на деньги, проще делать демо, клиентам понятнее, клиент не хочет покупать без этой фичи.
  • Activation. Показывает выгоду от продукта. Помогает лучше разбираться в продукте. Клиенту понятнее как пользоваться самому.
  • Retention. Будет заставлять пользователя возвращаться в продукт.
  • Service. Упрощает работу с клиентом нашей команды. Позволяет правильно настроить что-то для клиента.
  • Fb Ads. Позволит запускать больше фб рекламы через нас. Чтобы стать Facebook Marketing Parter, нужно увеличить этот показатель.
  • Mass. На много ли клиентов, ивентов или денег влияет фича.
Пример заполнения оценок по критериям в задаче

Критерии от 0 до 3 означают важность:

  • 3 — must have;
  • 2 — should have;
  • 1 — could have;
  • 0 — won't have.

Интерфейс старались сделать максимально быстрым. Заполнить оценки, вспомнить задачи и критерии можно было за несколько секунд.

Как устроен «Дукалис»

Создание разных досок для оценки задач. Доска — это граница оценки задач. Кто, что и как оценивает. Это могут быть одни и те же люди и даже те же задачи, но, например, другие критерии. У нас два проекта: фичи Tendee и фичи самого «Дукалиса». На каждой из досок все параметры разные.

Как именно работает «Дукалис»

1. Импорт нужных задач из Jira

Далеко не все задачи требуют оценки. Убираем задачи со статусами «в разработке», «на тесте» или «сделанные». Фильтр в Jira оставляет нужное. Сохраняем фильтр и связываем его с доской «Дукалиса».

Пример фильтра в Jira, чтобы оставить только задачи, требующие оценки

2. Добавление участников для оценки задач

Все юзеры «Дукалиса» импортируются из Jira (только через нее авторизация). Добавляются только пользователи из одной организации в Jira (на одном поддомене).

Дукалис связывается с пользователями Jira ​

3. Создание нескольких ролей и их критериев для оценки задач

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

Каждому критерию можно присвоить вес (коэффициент) и описание (подсказка/напоминалка при заполнении критериев).

Создание своего набора критерия оценок

4. Время истечения оценок

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

Мы это называем «переоценкой ценностей». Напоминание про заброшенные задачи на дне беклога. И повторное решение выкинуть их или вспомнить что-то важное потерялось. Часто то, что казалось безумно важным месяц назад, через некоторое время кажется бесполезным.

А сама оценка делается в конце каждого еженедельного спринта.

Время «про​тухания оценок»

5. Периодическая оценка задач по нужным критериям (в Slack)

Договорились с командой, что по пятницам в 2 часа дня (по мск) уходит уведомление в слэк, что пора бы дооценить задачки. Новые или же те, которые пора переоценить после 30 дней с прошлой оценки.

Пример уведомления в слэк, про оценку задач​

6. Определение топа задач на нужной доске

После выставления всех оценок и подсчета итогового балла выбираем топ-20 задач, обозначенных звездочкой, на которых фокусируемся в спринте.

​Экран агрегированного топа задач

7. Обсуждение на чем фокусируется команда в текущем спринте

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

Итог

Весь процесс занимает всего минут 10-20, если разбирать задачи раз в неделю. В любой момент времени можно посмотреть, что у нас сейчас в топе приоритетов, а что нет.

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

Если что-то важное не попадает в топ, то дообсуждаем голосом на звонке в начале спринта

Почему называется «Дукалис»?

Система приоритизации задач «Дукалис»

Он задумывался как внутренний продукт, поэтому выбирали что-то забавное. Попалась картинка Дукалиса в образе Судьи Дреда. Его коронная фраза: «Я есть закон!». Приоритизация — штука жесткая и неприятная, всегда что-то нужно отрезать и искать компромисс. Добродушное лицо Дукалиса смягчает ситуацию.

Хотите попробовать у себя?

Система уже работает у нас целый год, без него уже не представляется работа.

Если вам кажется это полезным для вашей команды продактов / разработки / маркетинга, и вы пользуетесь Jira, то напишите на [email protected], заполняйте форму или в личку в фб, сделаю вам бесплатный аккаунт. Буду рад вашему фидбеку.

P.S. Это не замена Jira, это хорошее дополнение.

0
15 комментариев
Написать комментарий...
Артем Васенин
Ответить
Развернуть ветку
Stanislav K

Андрюха у нас труп...

Ответить
Развернуть ветку
Vitaliy Myshlaev
Автор
Ответить
Развернуть ветку
Макс

Андрюха, у нас баг, возможно привнесенный, по коду глянь

Ответить
Развернуть ветку
Vitaliy Myshlaev
Автор

так и есть. Хотите экаунт вам сделаем бесплатно?

Ответить
Развернуть ветку
Marat Garifullin

Мы в компании Клиентская база, разработали аналогичную систему, на нашей же платформе www.clientbase.ru , но из отличий есть:
- у вас только положительные баллы при голосовании, от 0 до 2, мы же добавили и отрицательные, от -2 до 2, чтобы можно было уравновесить спорную идею, а не только воздержаться.
- добавлен вес сотрудников, который учитывается при голосовании, коэффициент от 1 до 3, в зависимости от знаний и опыта
- предложения сразу разбиваются по проектам, чтобы можно было проанализировать предложения по каждому из проектов

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

Но в плане нейминга, вы, конечно, на 100 шагов впереди, потому, что у нас называется просто голосование по предложениям, даже задумались о своем названии теперь :).

Ответить
Развернуть ветку
Vladislav Proshinsky

вес сотрудника критичен! круто

Ответить
Развернуть ветку
Vitaliy Myshlaev
Автор

круто! здорово, что мы не одни! Давайте дружить стартами. 

Ответить
Развернуть ветку
Egor Zubarev

За название однозначно + 

Ответить
Развернуть ветку
Anton Ingachev

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

Ответить
Развернуть ветку
Anastasia Chirkova

Почему? Использовать изображение персонажа в продукте, конечно, никто не будет. А какие вопросы могут быть к названию? Дукалис — не уникальная фамилия персонажа сериала. Латиницей вообще другое значение. 

Ответить
Развернуть ветку
Anton Ingachev

Кажется все описано в разделе "Почему называется «Дукалис»?" - что там больше одного вполне конкретного персонажа использовано. По этой же статье понятно, что такой подход находит отклик у пользователей/потенциальных пользователей. И, вероятно, его захочется масштабировать, а не какой-то логитип и название типа "приоритезатор". Но одно дело постить в Facebook и на VC, другое дело запускать это как основной способ продвижения.

Ответить
Развернуть ветку
Антон Бельчиков

Бро, ну ты красавчик!

Ответить
Развернуть ветку
Alexander Kapul

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

Ответить
Развернуть ветку
Vitaliy Myshlaev
Автор

есть, просто не указан в примере. Есть и вес очень большой.

Ответить
Развернуть ветку
12 комментариев
Раскрывать всегда