Планировали, планировали и выпланировали

8e904ad4def1d06fe3dc57cedd7adfe6.jpg

В далёком 2020 году мы решили отказаться от Скрама и перейти на канбаноподобную модель с парой элементов из фреймворка LeanDS. Это решило как минимум часть проблем, про которые я говорил в докладе — тенденция к выгоранию, искусственные разрывы экспериментов между спринтами, разрушение спринтов из-за внезапных задач, ухудшение качества кода и документации. И чуть ли не самое главное — после отказа от некоторых скрам-ритуалов значительно упали затраты времени и энергии на не особо нужные встречи и споры.

Спустя примерно два с половиной года и какое-то количество не самых удачных процессных экспериментов (например, OKR и квартальные цели) стало ясно, что что-то или сломалось, или изначально работало не очень хорошо. Вот примеры проблем, с которыми все четыре продуктовые команды (так мы называем ML-команды по разными направлениям — маммография, рентген лёгких, КТ лёгких, КТ мозга) регулярно сталкивались в пост-скрамной эпохе:

  • Непрозрачное решение продуктовых вопросов и развилок. Важные продуктовые вопросы могли решаться абсолютно по-разному — то где-то в глубине тредов Маттермоста между исполнителями, то по внезапной хотелке кого-то из топ-менеджмента. При этом не было никакого чёткого разделения, что должно решаться на уровне команды, а что — выше.

  • Затягивание фичей. Некоторые фичи могли делаться неделями и месяцами из-за нечёткого скоупа и постановки или кучи отвлекающих факторов.

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

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

Весной в одном из тимлидских каналов Олег Сорока написал про подход Basecamp, описанный в книге Shape Up. Беглый просмотр оглавления меня заинтересовал, и я начал чтение.

Shape Up

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

В Shape Up нет спринтов (ну почти), дейликов, бэклогов, канбана, командных метрик, эстимейтов, и даже код-ревью и QA опциональны. Вместо этого есть:

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

  • Шейпинг проектов с учётом аппетитов.

  • Автономные команды с полной ответственностью за фичи.

  • Беттинг (ставки) на проекты (фичи).

Много английских слов, давайте разбираться.

Основной принцип — каждая фича (проект, идея, гипотеза, выбирайте, что более релевантно для вас) должна быть предварительно зашейплена, то есть сформирована. По каждой фиче должен появиться некий документ (питч), который содержит ключевую информацию — ценность идеи, какие проблемы решает, основные элементы решения без технических деталей, список рисков. Шейпингом проекта может заниматься кто угодно, но в Basecamp это отдельная роль. Важное отличие от условного Скрама — мы не делаем временные оценки на запил фичи, вместо этого для каждой фичи мы устанавливаем аппетит — сколько времени мы готовы потратить, чтобы получить эту ценность. Этот аппетит становится верхним лимитом на скоуп и на возможные решения. Чтобы не переусложнять, аппетитов у них бывает только два вида — большой (вся команда работает весь цикл) и маленький (2–3 человека работают две недели).

Централизованного бэклога нет, вместо этого во время кулдауна (двухнедельный перерыв между циклами) формируется набор питчей, при этом по желанию можно воскрешать и дорабатывать старые питчи. Итоговый набор питчей обсуждается на C-level встрече (например, CEO, CTO и CPO) и принимается решение о том, на какие фичи компания готова сделать «ставку» (в виде людей и времени) на следующие шесть недель. Если на фичу сделана ставка, то мы не должны прерывать команду никакими сторонними задачами. Если таких задач много — нужно либо создать отдельную Ops-команду, либо проанализировать причины появления таких задач.

Сформированные фичи передаются командам без какого-либо распила на таски, дальше начинается их автономная работа во время цикла. Команда изучает проект, создаёт дизайн решения, «открывает», какие таски нужно будет сделать для завершения проекта. Код-ревью и QA не являются барьером для деплоя. В книге несколько глав посвящено вещам типа визуализации работы и коммуникации с командой, здесь я это опущу.

Отдельно стоит сказать про кулдаун — в эти две недели команда может заниматься чем угодно на своё усмотрение — порефакторить, почитать статьи, улучшить внутренние инструменты или доделать какие-то хвосты.

Особенности внедрения

Звучит прикольно, не так ли?

  • Работа попадает командам в понятном и чётко оформленном, но не разжёванном виде.

  • Отсутствует захламлённый бэклог, вместо этого фокусируемся на 1–2 важнейших в данный момент задачах, при этом их выбор прозрачен благодаря процедуре беттинга.

  • Очень удобно заранее знакомиться с предлагаемыми фичами с помощью питчей.

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

При этом мне сразу было ясно, что в «чистом» виде внедрить такой процесс будет трудно:

  • Basecamp — классическая продуктовая B2B-компания, их главная единица труда — новая фича для клиента. У нас всё не совсем так — в основном мы занимаемся улучшением качества (метрик) наших ИИ-систем, хотя и классические продуктовые фичи тоже имеются.

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

  • В целом для компании и отдела это был бы большой культурный сдвиг — нужно писать на всё питчи, брать в работу только проработанные задачи, а не работать в стиле «срочно пилим вот эту херню».

  • У нас четыре продуктовых команды, желательно как-то синхронизировать все циклы между ними. А ещё есть команда бэкенда, которая работает по Скраму недельными спринтами и не планирует никаких изменений.

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

Теперь всё процессные новшества оформляются в виде таких карточек

Теперь всё процессные новшества оформляются в виде таких карточек

Что получилось?

Стоит признать, что внедрение шло достаточно тяжёло. Лиды, которые выступают в роли шейперов, не успевали расписывать фичи, мы (ML-менеджмент) не успевали с ними знакомиться, постоянно залетали какие-то задачи, народ массово ушёл в отпуск летом, и циклы выходили какими-то недоциклами.

К октябрю мы с потом и кровью мы вышли на текущий процесс, сейчас он выглядит примерно так:

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

  • Всё-таки добавили нечто вроде общего бэклога, в котором складируются все идеи от самих команд, от бизнеса, внешние задачи от заказчиков. По итогам цикла из него исключаются завершённые фичи.

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

  • Лиды команд расписывают «питчи» по фичам-кандидатам, по желанию добавляют те фичи, которые считают важными, а мы их почему-то не включили в список.

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

  • В середине цикла происходит синхронизация по текущему статусу и необходимым изменениям.

Карточка фичи, она же питч

Карточка фичи, она же питч

Процесс явно можно улучшать и дальше — добавить больше структуры, доработать шаблон карточки фичи, проводить встречи более динамично, но что мы получили уже сейчас:

  • Более прозрачный процесс формирования целей для команд, снижение разрыва между стратегией и тактикой.

  • Работа команды стало более прозрачной, измеряемой и понятной для ML-менеджмента. Стало легче влиять на направление движения команды.

  • Одновременная фокусировка на 1–2 наиболее важных направлениях.

  • Срочные залетающие задачи могут быть сделаны за счёт сокращения скоупа дополнительных фичей.

  • Кулдаун позволяет выдохнуть и избавиться от ощущения бесконечной гонки за фичами.

  • Залетающие задачи остались, но проходят обязательный фильтр. Если их срочность мнимая, они уходят в следующий цикл или вообще не делаются.

  • Другие команды получают чёткую информацию о планах ML на месяц.

Конечно, не всё пока идеально, и мы размышляем о том, как убрать эти недостатки:

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

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

  • Неделя кулдауна достаточно утомительная для ML-менеджмента — нужно актуализировать список гипотез, утвердить фичи-кандидаты, прочитать питчи и провести со всеми командами итоговое планирование. Это не так просто, но с другой стороны — это наша работа.

Дисклеймер

Стандартный дисклеймер — никогда бездумно не копируйте никакие процессы, какой бы энтузиазм они поначалу не вызывали. Отрезвляющий чек-лист:

  • Чем отличается наша компания и компания, в которой родился фреймворк или процесс? Рынок, клиенты, продукт, культура?

  • Какие культурные тектонические плиты сдвинуть будет невозможно? Какие ещё могут быть барьеры для внедрения?

  • Достаточны ли наших текущих инструментов для имплементации процесса?

  • Можем ли мы протестировать гипотезу малыми силами и в случае чего быстро откатиться на исходную точку?

  • Не развалится ли вся идея, если мы будем точечно модифицировать её отдельные компоненты под себя?

© Habrahabr.ru