Решаемые проблемы: как внедрить Kanban и не поседеть

Руководитель проектов Agima Екатерина Чернышева рассказывает, какие блокеры возникают в команде, если рабочие процессы не настроены.

Привет! Я Катя, руководитель проектов в AGIMA. В 2020 году меня подключили к работе с небольшой командой, которая разрабатывала мобильное приложение для крупного онлайн-магазина одежды. Проект сразу показался мне сложным и интересным одновременно.

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

С другой стороны, на проекте был неконтролируемый поток задач, не было приоритетов. Задачи валились откуда угодно, оценивалось не всё и не всегда, не было плана релиза и т.д. Поэтому накопились технический долг и дефекты, а бизнес-задачи не выпускались в продакшен по несколько месяцев.

В этой статье разберу эти проблемы и расскажу, как мы исправляли ситуацию.

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

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

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

И в первую очередь мы выявили три большие взаимосвязанные проблемы. Вместе с методологом и командой мы начали их решать.

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

Это было неправильно. У нас копился технический долг, в бэклоге была неразбериха. Разработчики пытались делать всё и сразу. При такой системе прогнозировать результат и сроки сложно или почти невозможно.

Первым делом мы настроили версионность. С этого момента объем спринта определялся на планировании. Мы заранее решали, какие фичи разработаем и какие дефекты поправим. При этом исходили из объема задач — в спринт не могло попасть больше, чем мы можем сделать. Мы четко следили за культурой ведения доски в Jira. Установили WIP-лимиты: 2 задачи в разработке, 1 в ревью, 1 в тестировании на исполнителя. Лучше вносить изменения в продукт постепенно, но регулярно, чем в большом количестве, но без системы со сдвигом поставок и неопределенным составом релиза.

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

Еще более важной целью было убедить в этом бизнес-заказчика. Много сил и времени ушло, чтобы объяснить, почему нельзя переполнять спринт новыми функциями. Убеждали на срезах, совещаниях, созвонах. По их итогам готовили митинг-репорты — ключевой элемент коммуникации. После каждого совещания все участники получали письмо с подробным описанием принятых решений. Если в дальнейшем возникали вопросы или конфликты, нам было на что сослаться. Задачи на планировании мы выбирали вместе с бизнес-заказчиком. При планировании спринта внедрили систему эпиков. Вывели ее на отдельную Канбан-доску с приоритезацией по положению в колонке. Это помогало нам не тормозить важные бизнес-процессы, при этом следить и за качеством продукта, и за процессом. Перед этим мы определили, что в каждый спринт берем не более 20% задач, связанных с техническим долгом и дефектами. Остальное — бизнес-задачи.

Еще сделали таблицу наполненности спринтов и закрепили ее в общем пространстве Confluence. В ней мы помечали, когда задача поступила и когда будет реализована (то есть планируемая дата релиза).

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

Инструменты: Канбан-доски в Jira, система эпиков, митинг-репорты, встречи по планированию, WIP-лимиты, таблица наполненности спринтов в Confluence, взаимозаменяемость специалистов, процентное соотношение задач в спринте, теги версионности.

Всё это сделало работу более прозрачной и четкой. Длина спринта сократилась до 2,5 недель, а эффективность выросла. Мы начали быстрее разбирать бэклог и технический долг, а метрики по проекту улучшились.

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

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

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

Распределение ответственности внутри команды стало одним из принципов нашей работы. Мысль о том, что все в равной степени отвечают за итоговый продукт, сделало процесс более цельным. Заодно это помогло сократить количество узких мест. Объясню на примере: теперь каждый член команд мог в меру возможностей и умений взять на себя обязанности другого. Взаимозаменяемость сделала процесс более продуктивным. А заодно каждый человек увидел свои зоны роста.

Я сделала обязательной обратную связь от коллег. Раз в 2–3 недели проводила опросы, чтобы понять, как люди себя чувствуют в коллективе. Это были созвоны, анкеты в Google-формах. Иногда общалась с нашими руководителями и тимлидами, с руководителями от заказчика. Цель была одна — понимать потребности команды и создавать комфортную атмосферу.

Инструменты: ретроспективы в Miro, опросы в Google-формах, встречи One-on-one, взаимозаменяемость в команде, дейли и ретро с разными ведущими.

Удалось стабилизировать команду, ребята начали мыслить позитивно. Мы уменьшили стресс за счет изменения в процессах — теперь нет цейтнота и переработок. В итоге команда увеличилась почти втрое. На старте нас было 5–7 человек, а сейчас — более 15.

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

После того как наладили версионность и объяснили всем принципы пополнения спринта, стало проще. Но чтобы проблема полностью ушла и отношения наладились, мы ввели правило «трех ног». Раз в месяц-два мы встречались с руководителем компании-заказчика и моим руководством на срезах. Мы вместе обсуждали, что сейчас хорошо, а что плохо. Все получали полезную обратную связь.

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

Чтобы этого избежать, мы начали проводить с руководителями заказчика встречи по пополнению бэклога. Изначально проводили их раз в спринт, но этого оказалось мало. Поэтому сейчас они проходят в начале каждой недели. На этих встречах мы используем покер планирования — методику оценки задач. Теперь проще достигать договоренностей по объему работы, которую мы берем в спринт.

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

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

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

Моя личная цель состояла в том, чтобы не просто выстроить процессы, а сделать их удобными для всех. Все изменения, которые описаны в статье, проходили не без сопротивления со стороны команды. Особенно это чувствовалось, когда она стала полноценной гибридной и пришлось организовывать работу одновременно у моих коллег из AGIMA и у сотрудников заказчика.

Были люди, которые не хотели вести ретроспективы и Daily-митинги. Иногда члены команды забывали про культуру ведения доски. Но в итоге нам с командой удалось изменить ситуацию и выстроить такую систему, при которой каждый несет ответственность за продукт. Это сказалось на метриках и отношениях между командой и топ-менеджментом. За счет снижения техдолга и количества дефектов достигли высоких показателей Crash-Free пользователей — 99,8–99,9% на iOS и Android.

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