Как Дукалис помогает приоритизировать задачи в 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 оставляет нужное. Сохраняем фильтр и связываем его с доской Дукалиса.
2. Добавление участников для оценки задач
Все юзеры Дукалиса Импортируются из Jira (только через нее авторизация). Добавляются только пользователи из одной организации в Jira (на одном поддомене).
3. Создание нескольких ролей и их критериев для оценки задач
У нас это разработчики и менеджеры. Каждый по своему смотрит на продукт. Например, только разработчики могут оценить время на разработку, и это критерий с отрицательным весом. А продуктовые менеджеры оценивают по 6 равнозначным критериям.
Каждому критерию можно присвоить вес (коэффициент) и описание (подсказка/напоминалка при заполнении критериев).
4. Время истечения оценок
Оценка важности фичи/задачи, как оказалось, штука непостоянная. То, что было важно месяц назад, сейчас уже может оказаться ненужным. Поэтому мы выставили автоматический сброс оценок Дукалисом каждые 30 дней.
Мы это называем «переоценкой ценностей». Напоминание про заброшенные задачи на дне беклога. И повторное решение выкинуть их или вспомнить что-то важное потерялось. Часто то, что казалось безумно важным месяц назад, через некоторое время окажется бесполезным.
А сама оценка делается в конце каждого еженедельного спринта.
5. Периодическая оценка задач по нужным критериям (в Slack)
Договорились с командой, что по пятницам в 2 часа дня (по Мск) уходит уведомление в Slack, что пора бы дооценить задачки. Новые или те, которые пора переоценить после 30 дней с прошлой оценки.
6. Определение топа задач на нужной доске
После выставления всех оценок и подсчета итого балла выбираем топ-20 задач, обозначенных звездочкой, на которых фокусируемся в спринте.
7. Обсуждение на чем фокусируется команда в текущем спринте
Делаем звонок в начале спринта по тому, кто и что берет в работу. Такой топ не железное требование, но дает команде понимание, что сейчас важно для компании. Часто приоритет для кого-то оказывается неожиданностью: «Ого, а что это за задача? Почему она важна?».
Итог
Весь процесс занимает всего минут 10–20, если разбирать задачи раз в неделю. В любой момент времени можно посмотреть, что у нас сейчас в топе приоритетов, а что нет.
Конечно же, все по-разному смотрят на задачи. Что-то более внимательно оценивается, что-то менее. Но даже на 10 людях система работает каким-то магическим способом, когда они понимают, что большинство задач в общем сводном топе действительно важные.
Если что-то важное не попадает в топ, то дообсуждаем голосом на звонке в начале спринта
Почему называется Дукалис?
Сервис задумывался как внутренний продукт, поэтому выбирали что-то забавное. Попалась картинка Дукалиса в образе Судьи Дреда. Его коронная фраза: «Я есть закон!». Приоритизация — штука жесткая и неприятная, всегда что-то нужно отрезать и искать компромисс. Добродушное лицо Дукалиса смягчает ситуацию.
Хотите попробовать у себя?
Система уже работает у нас целый год, без него уже не представляется работа.
Если вам кажется это полезным для вашей команды продактов / разработки / маркетинга, и вы пользуетесь Jira, то напишите на vit@ducalis.io, заполняйте форму или в личку в фб, сделаю вам бесплатный аккаунт. Буду рад вашему фидбеку.
P.S. это не замена Jira, это хорошее дополнение.
