Решаемые проблемы: как внедрить Kanban и не поседеть
Руководитель проектов Agima Екатерина Чернышева рассказывает, какие блокеры возникают в команде, если рабочие процессы не настроены.
Привет! Я Катя, руководитель проектов в AGIMA. В 2020 году меня подключили к работе с небольшой командой, которая разрабатывала мобильное приложение для крупного онлайн-магазина одежды. Проект сразу показался мне сложным и интересным одновременно.
С одной стороны, заказчик сразу сказал, что планирует создать гибридную команду — такую, в которой на равных трудятся наши ребята и сотрудники заказчика. Задачей было настроить процессы, в том числе для той части команды, для которых я была подрядчиком.
С другой стороны, на проекте был неконтролируемый поток задач, не было приоритетов. Задачи валились откуда угодно, оценивалось не всё и не всегда, не было плана релиза и т.д. Поэтому накопились технический долг и дефекты, а бизнес-задачи не выпускались в продакшен по несколько месяцев.
В этой статье разберу эти проблемы и расскажу, как мы исправляли ситуацию.
Почему было сложно
Когда я пришла на проект, команда только завершила выпуск MVP и перешла на новую модель работы. Ребята пытались внедрить Scrum, но все процессы работали хаотично и зависели от случайных решений. Например, фича могла попасть в текущий спринт, без удаления других задач. Это влияло на сроки и качество работы. Не было культуры ведения доски, не велся учет нагрузки команды, технический долг и количество дефектов росли.
Но мне повезло. Заказчик знал о проблемах и был готов их решать. Для помощи команде и выстраивания единого процесса работы был привлечен методолог. Нашей общей с ним задачей было внедрить Канбан и перестроить процессы таким образом, чтобы всей команде было комфортно. Но внедрять все практики приходилось в уже существующем коллективе, который привык работать без системы.
К тому моменту уже накопилось много блокеров, которые определяли поведение коллектива и заказчика. Новый формат работы никому не давался легко, поэтому всё нужно было обосновать, доказать, проиллюстрировать. Со временем, когда команда начала расти, делать это стало проще — все новички не знали, как было до, и работали по установленным правилам.
И в первую очередь мы выявили три большие взаимосвязанные проблемы. Вместе с методологом и командой мы начали их решать.
Проблема №1: задачи долго выпускались в прод
Изначально на проекте один спринт мог длиться полтора-два месяца. Цикл жизни одной задачи был слишком долгим. Это существенно влияло на все процессы, а в итоге и на качество продукта. Связано это было с тем, что у команды не было четкого понимания критичности и важности дефектов и задач. На тот момент действовало правило «Все баги критичные, все задачи срочные».
Это было неправильно. У нас копился технический долг, в бэклоге была неразбериха. Разработчики пытались делать всё и сразу. При такой системе прогнозировать результат и сроки сложно или почти невозможно.
Как решили
Первым делом мы настроили версионность. С этого момента объем спринта определялся на планировании. Мы заранее решали, какие фичи разработаем и какие дефекты поправим. При этом исходили из объема задач — в спринт не могло попасть больше, чем мы можем сделать. Мы четко следили за культурой ведения доски в Jira. Установили WIP-лимиты: 2 задачи в разработке, 1 в ревью, 1 в тестировании на исполнителя. Лучше вносить изменения в продукт постепенно, но регулярно, чем в большом количестве, но без системы со сдвигом поставок и неопределенным составом релиза.
Каждая задача теперь должна была пройти все этапы, чтобы мы могли контролировать нагрузку, находить узкие места и своевременно перераспределять функции. Например, если мы понимали, что узкое место — тестирование, то кто-то из разработчиков подключался к нему.
Еще более важной целью было убедить в этом бизнес-заказчика. Много сил и времени ушло, чтобы объяснить, почему нельзя переполнять спринт новыми функциями. Убеждали на срезах, совещаниях, созвонах. По их итогам готовили митинг-репорты — ключевой элемент коммуникации. После каждого совещания все участники получали письмо с подробным описанием принятых решений. Если в дальнейшем возникали вопросы или конфликты, нам было на что сослаться. Задачи на планировании мы выбирали вместе с бизнес-заказчиком. При планировании спринта внедрили систему эпиков. Вывели ее на отдельную Канбан-доску с приоритезацией по положению в колонке. Это помогало нам не тормозить важные бизнес-процессы, при этом следить и за качеством продукта, и за процессом. Перед этим мы определили, что в каждый спринт берем не более 20% задач, связанных с техническим долгом и дефектами. Остальное — бизнес-задачи.
Еще сделали таблицу наполненности спринтов и закрепили ее в общем пространстве Confluence. В ней мы помечали, когда задача поступила и когда будет реализована (то есть планируемая дата релиза).
Мы отказались от идеи, что исполнитель должен дорабатывать свои задачи. Например, разработчик занят на 40-часовой задаче, а на доработку попала его предыдущая. Очевидно, что в этом спринте разработчик приступить к задаче на доработку не успеет. Поэтому мы передаем ее другому исполнителю по методу вытягивания — кто освободился, тот и берет первую по приоритетности задачу в списке. Это уменьшило время на разработку в масштабах спринта и увеличило вовлеченность команды в проект. Каждый исполнитель знал о каждой задаче.
Инструменты: Канбан-доски в Jira, система эпиков, митинг-репорты, встречи по планированию, WIP-лимиты, таблица наполненности спринтов в Confluence, взаимозаменяемость специалистов, процентное соотношение задач в спринте, теги версионности.
Что в итоге
Всё это сделало работу более прозрачной и четкой. Длина спринта сократилась до 2,5 недель, а эффективность выросла. Мы начали быстрее разбирать бэклог и технический долг, а метрики по проекту улучшились.
Проблема №2: команда выгорала
Работать в постоянном цейтноте — большой стресс для коллектива. Одной из моих задач было удержать людей и подобрать новых разработчиков для усиления команды. Поэтому пришлось быстро разобраться, как сделать работу комфортной для всех и поднять командный дух. И снова помогла систематизация процесса. Поскольку спринты стали короче, а объем выполняемой работы понятнее, частично эту проблему удалось решить. Но этого было мало — внутри распределенной гибридной команды было особо важно создать доверительные отношения.
Как решили
Мы сделали ретроспективы обязательными. На этих встречах мы подробно разбирали каждый спринт, обсуждали проблемы и искали решения. Раньше ретроспективы проводились по остаточному принципу — «если будет время». Но времени никогда не было. Нам удалось убедить коллектив, включая клиента, что ретроспектива — это важно. Причем не только для команды, но и для продукта — разбор позволяет не повторять ошибки и расти как команда.
Ретроспективу проводили в Miro. Каждый раз ее вел новый член команды. Мы хотели, чтобы люди имели больше влияния на процесс и глубже погружались в проект и в команду. Эту практику мы быстро распространили и на дейли. Когда каждый человек знает задачи другого, он ответственнее относится к своим — это мотивирует. Основная идея: каждый участвует в процессе, погружается в задачи и видит проект целиком.
Распределение ответственности внутри команды стало одним из принципов нашей работы. Мысль о том, что все в равной степени отвечают за итоговый продукт, сделало процесс более цельным. Заодно это помогло сократить количество узких мест. Объясню на примере: теперь каждый член команд мог в меру возможностей и умений взять на себя обязанности другого. Взаимозаменяемость сделала процесс более продуктивным. А заодно каждый человек увидел свои зоны роста.
Я сделала обязательной обратную связь от коллег. Раз в 2–3 недели проводила опросы, чтобы понять, как люди себя чувствуют в коллективе. Это были созвоны, анкеты в Google-формах. Иногда общалась с нашими руководителями и тимлидами, с руководителями от заказчика. Цель была одна — понимать потребности команды и создавать комфортную атмосферу.
Инструменты: ретроспективы в Miro, опросы в Google-формах, встречи One-on-one, взаимозаменяемость в команде, дейли и ретро с разными ведущими.
Что в итоге
Удалось стабилизировать команду, ребята начали мыслить позитивно. Мы уменьшили стресс за счет изменения в процессах — теперь нет цейтнота и переработок. В итоге команда увеличилась почти втрое. На старте нас было 5–7 человек, а сейчас — более 15.
Проблема №3: на команду всё время давили
На выгорание коллектива влияло и отношение бизнес-заказчика — проблемы нередко решались через конфликты. Общение было напряженным, скованным. Всем не хватало взаимопонимания. Было важно это взаимопонимание найти.
Как решили
После того как наладили версионность и объяснили всем принципы пополнения спринта, стало проще. Но чтобы проблема полностью ушла и отношения наладились, мы ввели правило «трех ног». Раз в месяц-два мы встречались с руководителем компании-заказчика и моим руководством на срезах. Мы вместе обсуждали, что сейчас хорошо, а что плохо. Все получали полезную обратную связь.
В процессе выяснили, что главная проблема — сложно прогнозируемые сроки выполнения задач. Это вызывало у топ-менеджеров тревогу и желание поторопить команду, которая и так не успевала разобраться с техдолгом и дефектами. Вместо этого приходилось делать новые фичи, которые попали в спринт вне планирования.
Чтобы этого избежать, мы начали проводить с руководителями заказчика встречи по пополнению бэклога. Изначально проводили их раз в спринт, но этого оказалось мало. Поэтому сейчас они проходят в начале каждой недели. На этих встречах мы используем покер планирования — методику оценки задач. Теперь проще достигать договоренностей по объему работы, которую мы берем в спринт.
Дейли тоже проходят с участием бизнес-заказчиков. Нам было важно донести и до команды, и до топ-менеджеров, что дейли — это срез для понимания статуса задач и их сроков, а не для выяснения отношений. Все проблемы, которые хочется обсудить, мы либо выносим на отдельную встречу, либо обсуждаем в конце дейли со всеми заинтересованными.
Инструменты: правило «трех ног», встречи по пополнению бэклога с участием бизнес-заказчика, покер планирования, дейли.
Что в итоге
Все эти меры сняли градус напряжения. Команде стало комфортнее, а заказчику спокойнее. Отношения удалось не только стабилизировать, но и сильно улучшить. Сейчас с тем же заказчиком мы планируем новые проекты. Это хороший маркер — значит, всё было не зря. К тому же в команде снизилась текучка. А сформированная система помогает специалистам развиваться.
К чему пришли
Моя личная цель состояла в том, чтобы не просто выстроить процессы, а сделать их удобными для всех. Все изменения, которые описаны в статье, проходили не без сопротивления со стороны команды. Особенно это чувствовалось, когда она стала полноценной гибридной и пришлось организовывать работу одновременно у моих коллег из AGIMA и у сотрудников заказчика.
Были люди, которые не хотели вести ретроспективы и Daily-митинги. Иногда члены команды забывали про культуру ведения доски. Но в итоге нам с командой удалось изменить ситуацию и выстроить такую систему, при которой каждый несет ответственность за продукт. Это сказалось на метриках и отношениях между командой и топ-менеджментом. За счет снижения техдолга и количества дефектов достигли высоких показателей Crash-Free пользователей — 99,8–99,9% на iOS и Android.
На старте в коллективе было 5 человек, а сейчас нас уже более 15. Спринт, который изначально мог растянуться на полтора месяца, теперь длится 2,5 недели. Любая спорная ситуация решается внятным и конструктивным разговором. Но главное — новые фичи доходят до пользователей намного быстрее.
Команда выгорала, вы им обязательные ретроспективы сделали, а в отпуск вы команду не хотели бы отпустить??
Отпуск не изменит ужасные бизнес процессы, а автор молодчина
а после отпуска возвращаться в те же условия, такое себе
Отпуск спасти может на 2-3 месяца, потом по новой. И главное, что многие компании даже не хотят принимать факт того, что вообще существует выгорание. Это типа как? Ну сходи в дей офф и приходи обратно.
Слушал тут зарубежных ребят (не помню, кто именно был, найду, пришлю ссылку), так они говорили, что сейчас все больше и больше психоэмоционального расстройства зафиксировано у людей моложе 30. И это даже не про нас шла речь (в советстком-то союзе никто не болел и сексом не занимались), а вообще про мир.
Спасибо за комментарий.
Да, действительно на практике сталкиваемся с подобным типом компаний и успешно прорабатываем с ними кейсы по выгоранию сотрудников.
Будем очень благодарны за приложенную ссылку.
Комментарий недоступен
От Идеи до реализации, спасибо за комментарий.
Описанное увеличение команды является следствием выстроенных процессов, хорошей и доверительной коммуникации с клиентом.
Мы выявили оптимальную релизную схему — 2, 5 недели. Это позволило нам:
— Устранить давление от клиента «Ну когда вы уже выпустите релиз?»
— Планировать с учетом возможностей команды;
— Прогнозировать развитие продукта.
Конечно, объем выпускаемых фич изменился в большую сторону, а техдолг и количество дефектов уменьшились.
Комментарий недоступен
А количество инкремента может быть разное
Спасибо за статью
Хм, а почему от Scrum отказались? Он лучше подходит к описанному. Agile Kanban для выполнения долгосрочных работы, где много сопересечений есть, а тут у вас итеративность (в тексте читается легко).
По поводу команды - обновлять надо. Как бы ни звучало это дико, но при наличии таких проблем, надо либо объяснять, что мы так НЕ работаем, либо менять. Тем более, что это в самом начале проекта, а не в середине или конце.
Сергей, спасибо за комментарий.
Если вы подразумеваете итеративность как релизные циклы, то это никак не противоречит внедрению Канбан практик на проекте.
В этой статье мы старались описать, что мы пришли к непрерывному потоку создания ценности и отошли от управления продуктом итеративно для создания комфортной работы команды, улучшения и ускорения процесса поставки ценности и уменьшения выгорания людей на проекте.
Плюс внедрения Канбан практик в том, что их можно и нужно внедрять постепенно, погружая команду и включая их в процесс изменений. Это позволяет не отказываться от текущей команды и создать комфортный климат в коллективе. А увольнение — это всегда дорого и больно, тем более в гибридной команде. =)
Интересная статья, но что-то команду мне все еще жалко. Столько нового им внедряли, словно подопытные кролики.
Чего жалеть то. Есть проблемы. Их нашли и нашли инструменты решения.
Рабочие процессы существа растущие и меняющиеся, особенно в гибкой разработке.
Антон, полностью согласны с вашим мнением.
Понимаю вас, сама с этим сталкивалась, но потраченные нервы и часы того стоили!
Посоветуйте хорошие книжки по менеджменту, а то уж больно хорошие у вас результаты
Ольга, спасибо за комментарий.
Наши рекомендации от автора статьи:
- Канбан краткое руководство. Авторы Дэвид Дж. Андерсон и Энди Кармайкл.
- Канбан – альтернативный путь в Agile. Автор Дэвид Дж. Андерсон
Комментарий недоступен
Из статьи тоже самое почерпнул. Только цифры по затратам скорее всего ни х3, а х2, за счёт того что рутины задачи на джунов повесили +проджект это ни сеньоры, по зп примерно +-мидлы
Комментарий недоступен
Тут уже глубже высчитывать гадание на кофейной гуще. Математику мы с вами примерно одинаково считаем...
Комментарий недоступен
Ну кому как...
Расскажите, пожалуйста:
- В чем оценивали задачи стори поинты, часы\дни?
- Дейли проходили в формате скрама: что сделал вчера? чем буду заниматься сегодня? какие проблемы? или больше в формате: что нам нужно сделать чтобы достичь результата? какие задачи блокируют движение к нему?
- Определяли ли цель спринта?
Стори поинты не измеряются в абсолютных оценках. Оценка в sp— это совокупное значение объёма, рисков и сложности реализации.
При расчёте velocity команды условно можно перевести sp в абсолютные единицы, но в любом случае это будет примерно и условно
Спасибо, так же понимаю Стори поинты. Интересно в чём ребята оценивали работу и действительно ли у них sp не в формате 1sp = день
Надеюсь нет, иначе какой смысл
Николай, спасибо за комментарий.
- Оценка происходила в часах по Фибоначчи, что является комфортным для клиента и команды. Условная максимальная единица декомпозированной задачи — 40 часов. Старались прийти к максимальным единицам — 8 и 21 час.
- Дейли проходили в формате «что нам нужно сделать, чтобы достичь результата?» и «какие задачи блокируют движение к нему?» + план работы на сегодня, чтобы синхронизироваться в команде.
- SRM-менеджер разбивал задачи эпиков по приоритетности на доске и вместе с командой мы определяли цель и планы релизных схем.
Автор, а зачем в приложении крупного онлайн-магазина одежды запись пациент на приём к врачу? 🤔
Евгений, спасибо за комментарий.
Это пример доски с не настроенными процессами.
Была ли у вас такая проблема, что на групповых созвонах большинство не включает видео? Т.е. чувствуется желание изолироваться.
Кто как это решал?
Ребята, нужно выкопать яму для гроба, сделаете?
— Конечно! Сначало мы внедрили... :