Всем привет! Меня зовут Артем — за последние 10 лет поработал в больших компаниях, стартапах, консалтинге на позиции продакта и проджекта. Сегодня расскажу про мой подход работы с бизнесом и технической командой и про то, как превратить хаотичный поток задач в предсказуемый фреймворк. 

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

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

Тогда я пришел к фреймворку «Квотирование» — методу, который делает дорожную карту предсказуемой в любой среде: в стартапе, enterprise, консалтинге. 

Лучше всего, перед формированием дорожной карты использовать RICE для расстановки приоритетов, а только потом положить задачи на дорожную карту.

Универсальная схема может выглядеть так:

100% ресурса команды распределяются на 4-5 стримов. Для простоты объяснения, представим, что команда в месяц в среднем может делать 10 тасок = 100%. Тогда распределение задач выглядит следующим образом:

1. Бизнес-фичи: 40%.

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

2. Техдолг: 20%.

   Покажите мне тимлида, который вам не скажет “спасибо” за такую “щедрость”.

3. Техническое развитие продукта: 20%.

   Вся техническая часть (интеграции с DWH, переезд с PG на Click и подобные инженерные вещи) будет прямиком улетать на этот стрим. Он очень сильно пересекается с с предыдущим стримом — так и надо. Это позволит гибко встроить задачи на пересечении бэкэнда и ценности для бизнеса.
   Обычно я сюда встраиваю все большие таски на разработку бэка, задачи от отдела безопасности и прочее. 

4. Баги: 10%.

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

5. Запас (риски): 10%.

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

10% — условная величина в нашем примере. В последнем продукте мы очень хорошо сработались с командой и отлично лавировали среди задач, успевая делать почти все. Поэтому запас мы почти всегда забирали под инженерные задачи. Во время работы в консалтинге с высоким уровнем неопределенности я закладывал около 30% на риски. И то мы почти всегда вылетали за сроки из‑за сложностей с согласованием или другими проблемами. 

Важно отметить: задачи конкурируют только внутри своего потока. Это значит, что к ним внутри стрима может быть применен свой уникальный метод приоритезации. Например, исправление багов не всегда несет за собой финансовую выгоду, но разрабатывать решение с большим количеством ошибок никому не хочется. Поэтому для стрима с багами я использую обычный каунтер с сегментацией по JTBD (метод автоматической обработки обращений в чат поддержки с подсчетом количества обращений по сегментам)
Если в рамках планирования ближайших спринтов вы не израсходуете этот лимит — можно наполнить его багами или другими задачами. 

Что происходит после такой работы?

Прилетает новая задача — смотришь, к какому стриму она относится. Далее — есть ли там квота или место для нее? — если нет — значит она идет в следующий спринт. Благодаря тому, что такая дорожная карта есть в Confluence и все ее могут посмотреть — кросс‑команды могут на нее ориентироваться даже без вашего участия — главное вовремя актуализировать этот артефакт.

В такой конфигурации никто не обижается, если «сказать нет» — правила одинаковы для всех. 

Как квотирование решает проблемы и какие плюсы дает:

1. Принцип открытости разработки — помогает в одном артефакте «рассказать» про ваш вектор движения. Принцип прозрачности еще не повредил ни одному проекту.

2. Нет больше «свалки задач» — все задачи на своем месте + появляется прозрачный ориентир по срокам выполнения.

3. Предсказуемые сроки реализации и понятные приоритеты

4. Не нужно ежедневно «отбиваться» от задач

5. Поднимет ваше доверие внутри команды

Квотирование — это не про проценты. Это про то, как сделать работу команды и развитие продукта прозрачной, честной и предсказуемой с учетом интересов стейкхолдеров разного уровня.

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

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