Привет, Хабр! Меня зовут Василий, я директор SaaS-направления Аспро — руковожу разработкой Аспро.Cloud.

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

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

Спор об оценках вместо спора о важности

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

Задачи в бэклог SaaS-продукта приходят из пяти-шести источников: продукт, продажи, маркетинг, поддержка, клиенты, сама команда. У каждого источника свой язык и своя правда: продажам нужна сделка, продукту — метрика, команде — чистый код. Пока общего знаменателя нет, планирование — перетягивание каната, в котором выигрывает самый настойчивый.

Балл дал знаменатель. Спор «моя задача важнее» превратился в спор об оценках, а оценки можно обсуждать предметно: почему влияние три, а не пять; откуда уверенность восемьдесят процентов; охват — это правда половина пользователей или десятая часть. Такой спор заканчивается решением.

Три правила, без которых балл не заработает:

1. Оценивают вместе. Автор задачи и команда на планировании, вслух. Оценка, выставленная одним человеком в тишине, отражает мнение самого активного участника, и весь механизм вырождается.

2. Шкалы грубые. Влияние — единица, тройка или пятерка. Уверенность — 50, 80 или 100 процентов. Шкала из десяти значений создает иллюзию точности и утраивает споры.

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

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

Слепая зона балла и треки

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

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

Пример трека из — активация новых пользователей. Метрика: доля регистраций, которые за первые 7 дней доходят до первого проекта. Гипотезы в пуле:

• шаблоны проектов на первом входе — у новичка сразу готовая структура;

• подсказки в пустом проекте — что нажать, чтобы получить первый результат;

• письмо на второй день, если первый шаг не сделан;

• упрощение первого шага — короче путь от регистрации до проекта.

Гипотезы проходят общий скоринг на общих основаниях, ничто не заходит в спринт автоматически. Разница тоньше: оценка влияния привязывается к метрике. В задаче фиксируется базовая линия и ожидаемый сдвиг, и спор о влиянии становится таким же предметным, как спор о трудозатратах.

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

Где ломается. Метрика должна сдвигаться тем, что делает команда, — если на нее влияет рекламный бюджет или сезонность, трек врет. Пул из одной гипотезы — это не трек, а задача с красивым описанием, нужно минимум четыре-пять. И проверка «на глаз»: без зафиксированной базовой линии после релиза невозможно сказать, сдвинулось что-то или нет, весь механизм превращается в ритуал.

Где фичи встречаются с деньгами

Хорошо, баллы, треки. А деньги? Сколько принесла фича с подсказками?

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

Рабочая схема у нас такая. Прямую линию «фича → выручка» заменяем цепочкой «фича → метрика → деньги». Активация напрямую денег не приносит, но активный пользователь продлевается чаще и дольше — и эту связь уже видно в данных. У метрики-посредника три требования:

• расстояние до денег в одно-два звена (активация → продления, не дальше);

• реакция видна за одну-две недели после релиза;

• на метрику влияет разработка, а не чужие факторы.

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

Для нас такие модули еще и калибровка: по тому, как команда оценила эффект платной функции, видно, насколько верить ее оценкам по остальному бэклогу.

Срочное, которое никто не планировал

Отдельный класс работы — задачи, которые вламываются в спринт мимо плана. У нас доходит до трети вместимости, чаще меньше.

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

В отчетах срочное выглядит бесплатным: взяли задачу вне плана, время то же. Фактическая цена выше. Срочная задача прерывает нескольких людей сразу — постановщика, исполнителя, тестировщика. Оценка «пара часов» превращается в день у нескольких человек, плюс выпавшая плановая задача, которую тоже кто-то считал и приоритизировал. Тут не стоит пренебрегать базовыми метриками Cycle Time и Lead Time. 

Сначала посчитайте, потом боритесь. Доля незапланированного = трудозатраты по задачам вне плана / вместимость спринта. Посчитайте за три-четыре спринта — получите свою цифру, у нас до трети. Дальше три правила:

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

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

3. Вопрос «вместо чего». Запретить срочное нельзя, обращения клиентов будут всегда. Можно попросить просящего назвать задачу, которая не сделается вместо его. Половина срочного перестает быть срочной.

Что в итоге

Формулу приоритизации выбирают за вечер. Очередь строится дольше и держится не на формуле, а на устройстве: у каждой задачи есть балл и автор, у гипотез — метрика и проверка после релиза, у срочного — бюджет и единый вход, а задачи от продаж привязаны к сделкам и видны за квартал. Балл в этом устройстве — инструмент. Решает правило, которое можно показать любому новому человеку в команде за пять минут.

Место в спринте — это деньги компании. Доставаться оно должно по правилу.