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