Планировали, планировали и выпланировали
В далёком 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-менеджмента — нужно актуализировать список гипотез, утвердить фичи-кандидаты, прочитать питчи и провести со всеми командами итоговое планирование. Это не так просто, но с другой стороны — это наша работа.
Дисклеймер
Стандартный дисклеймер — никогда бездумно не копируйте никакие процессы, какой бы энтузиазм они поначалу не вызывали. Отрезвляющий чек-лист:
Чем отличается наша компания и компания, в которой родился фреймворк или процесс? Рынок, клиенты, продукт, культура?
Какие культурные тектонические плиты сдвинуть будет невозможно? Какие ещё могут быть барьеры для внедрения?
Достаточны ли наших текущих инструментов для имплементации процесса?
Можем ли мы протестировать гипотезу малыми силами и в случае чего быстро откатиться на исходную точку?
Не развалится ли вся идея, если мы будем точечно модифицировать её отдельные компоненты под себя?
