Перезагрузка процессов: как мы поменяли процессы в отделе разработки внутри Kaiten
Когда старые методы перестают работать, нужно создавать новые. Рассказываем, как масштабировали процессы вместе с ростом отдела
Отдел разработки Kaiten за год увеличился в 3 раза. Процессы с таким ростом не справились и перестали работать, как раньше — доска постоянно переполнялась, а у работы больше не было прозрачности.
Рассказываем о трансформации вместе с Юрой Юрковым, лидером трансформации в Kaiten. Покажем путь, который прошел отдел за время перенастройки процессов, рабочие решения для команды, и способы не терять управление даже в такой шторм.
Как было раньше: процессы в отделе до изменений
Не так давно в команде было 7 человек — full-stack разработчики и CTO. Им хватало дейли на 15 минут, переписок в чатах и карточках, чтобы эффективно справляться с нагрузкой и ничего не терять.
Разработчики пользовались одним пространством и всегда двигали карточки по стандартным колонкам от создания к закрытию.
Все процессы выстраивали вокруг потока — сначала брали и закрывали одну крупную задачу, потом начинали работу над следующей.
Изначально использовали 2 доски:
- Анализ. Доска бэклога — сюда приносили все задачи от продакт-менеджеров, любые баги и идеи для тестов. Затем СТО квалифицировал их, распределял очередность в зависимости от срочности выполнения, важности и объемов проблемы.
- Разработка. Все задачи на этой доске можно было брать в работу. Карточка проходила по колонкам — контрольным этапам работы с задачей, где каждый сотрудник знал, что делать для решения.
Все релизы собирали и выполняли в чек-листах внутри карточек:
- один пункт — завершенная часть работы или отдельный релиз;
- у каждого релиза — свой ответственный разработчик.
Этот подход удобен, если команда занимается одной большой и общей задачей. Тогда все в курсе, что и на каком этапе, а на доске не появляется лишних мелких карточек. Но потом все изменилось.
Как понять, что пришло время для перемен
Одной из главных причин стали перемены в структуре всей компании Kaiten. Стали появляться разные сегменты — каждому понадобилась своя продуктовая команда, тимлид и собственные задачи. Тимлиды должны были следить только за задачами своего направления.
Сначала решили просто добавить дорожки под задачи каждого сегмента, но так получили 22 (!) дорожки. Это перегружало систему и не добавляло удобства, потому что смешивались самые разные работы — классы обслуживания, приоритеты и задачи сразу для продуктов, направлений и команд.
В результате вместо прозрачных и удобных условий работы доска совсем перестала работать. Участники команды не понимали, что, где и в каком статусе находится, а еще не могли определить основную ценность — релизы были внутри карточек. Чтобы их увидеть, нужно было открыть каждую карточку.
Приведем пример. Пока один разработчик уже работал с кодом, другой — еще изучал бизнес-требования, и оба сотрудника находились в одной карточке. Так задача оказывалась сразу в двух колонках.
Вторая причина — сломался поток. Карточки стали прыгать между колонками как попало, а не по порядку. Задача уходила в колонку готовых, а на следующий день снова возвращалась «В работу» или на анализ.
Это разрушало логику и демотивировало команду — разработчики потеряли ощущение прогресса и стали копить риски, а в метриках вообще невозможно было разобраться. Стали появляться дубли, недопонимания и конфликты приоритетов.
Третья причина — дейли стали растягиваться на час из-за размеров команды. И этого времени все равно не хватало: участники команды не успевали поделиться сложностями и внести предложения. После таких встреч тимлиду приходилось проверять вручную порядок выполнения работы в каждой задаче и уточнять все у исполнителя.
Темп работы стал заметно снижаться, а сотрудники начали уставать от бесконечной работы без ощущения финала. Вместо дейли получились монотонные встречи, после которых работать никто не хотел работать.
Руководство по оптимизации: как провести изменения без стресса и негатива
Оставлять все процессы в том же состоянии было нельзя. С одной стороны работа вроде бы шла и карточки двигались. Но с другой — не было никакой прозрачности в процессах, а на доске было невозможно увидеть реальную картину. Кроме того, тимлиду приходилось заниматься микроменеджментом вместо реальных стратегических задач. Все это привело к решению полностью перестроить процессы. Рассказываем, как мы это сделали и с чем пришлось столкнуться по пути.
Правило 1. Адаптируйтесь к масштабным переменам
В первую очередь пространство перегрузило то, что на доску добавились продуктовые сегменты, а у них были свои планы на разработчиков.
Из-за большого количества участников и задач в системе стало сложно ориентироваться, а на доске стало много лишнего, это мешало фокусу команды.
Решили поделить команду на группы из 5 человек в зависимости от того, что для них в фокусе. Затем разнесли все карточки по пространствам групп:
Так на доске больше не было каши из десятков задач, группы смогли разделить задачи и присвоить актуальные статусы, а тимлиды — проводить короткие дейли без стресса для своих команд на 5 человек.
Также ввели короткие встречи 2 раза в неделю для синхронизации по общим вопросам и оперативного решения актуальных проблем. Проводить и отслеживать результаты встреч помогают дашборды, в которых отражается динамика по задачам и блокировкам.
Правило 2. Учитывайте специфику и нюансы продукта
ПО Kaiten монолитно, нельзя поменять даже одну строчку, чтобы не зацепить всю остальную систему. Поэтому нужно было разделить команды так, чтобы весь отдел разработки продолжал активное взаимодействие и каждый оставался в курсе работы коллег.
В Kaiten есть удобная функция, с помощью которой можно разместить одну доску сразу в разных пространствах.
В чем преимущества:
- у каждой команды есть свое локальное пространство для работы;
- все доски дублировали на общее пространство;
- все перемены на локальных досках отображаются в общем пространстве — так отдел видит движение задач, сроки, задержки, исполнителей и все остальное.
Еще одна сложность — не всем командам подходил одинаковый процесс. Одни команды двигалась по классическому пути с колонками to do, In Progress, Done. А другие работали итеративно, проверяли гипотезы и исследовали разные фичи.
Так как у каждой команды теперь были свои доски, они смогли настроить удобные для себя процессы, но при этом остаться в едином процессе.
Правило 3. Совершенствуйте то, что уже работает
Команды продолжили развивать свои доски и workflow, постепенно адаптируя их под новые задачи и процессы. Им не пришлось выстраивать процессы с самого нуля, они улучшали то, что уже работало. Но на этом команды не закончили улучшения.
Внедрили другой подход к задачам
Во время выполнения задач стали применять конус неопределенности (Cone of Uncertainty), где в начале работы сильно размыта оценка времени и ресурсов на выполнение, а ближе к финалу данные становятся четче.
Когда в бэклоге создают новую задачу, появляется много неопределенных моментов. Например, непонятно:
- как выполнять задачу;
- почему случился баг;
- поможет ли решение «починить» систему или только усложнит все.
По мере движения задачи через колонки поступает много информации для принятия решений, объемы неопределенности сильно сокращаются.
В командах сохранили деление досок по стадиям неопределенности, но убрали «линейный» процесс. Теперь решили взаимодействовать с размером неопределенности.
Юрий создал систему работы, в которой не было привычных стадий для анализирования и разработки. Теперь процесс состоял из стадий без этапов — в названии каждой колонки прописывалось, как много известно о задаче.
Как выглядели стадии:
- Выявление ценности. Подробностей по задаче пока нет, в нее нужно вникать и разбираться. Перед командой стоит ключевой вопрос: нужно ли это делать и, если нужно, то как?
Во время размышлений нужно ответить на несколько вопросов:
- стоит ли за это браться;
- действительно ли это проблема;
- если выполнять, то как;
- не окажется ли решение слишком дорогим.
- Изучение ценности. Команда подробно разбирает, что предстоит выполнить и донести до клиента.
Когда у сотрудников получится «выявить ценность», они переносят задачу в бэклог и устанавливают для нее класс поставки.
На этом этапе важно ответить уже на другие вопросы:
- какая у задачи ценность, если она есть;
- как именно стоит поставлять ценность.
- Реализация. Над задачей уже работает команда, она почти готова и скоро окажется в релизе.
На этом этапе задачи поставляют и закрывают — реализуют и расшаривают на клиентов функции, исправляют баги и решают сложности в использовании.
Командам удалось перейти к новому формату без проблем и поломок. Возможно, это потому что в Kaiten есть разные инструменты — например, можно добавить любое количество колонок и дорожек, ввести WIP-лимиты или блокировать некоторые задачи.
Изменения можно назвать резкими для команд, но перемены не вызвали «революцию» — нам нужно было только перенастроить под существующую работу отдела, а не разрабатывать инструменты с нуля.
Чтобы дальше развиваться, командам нужно было пересобрать процессы и желательно — без строгих привязок. Иначе переход мог затянуться из-за бесконечного документирования, лишнего обучения сотрудников и переделок проектирования.
Важно построить систему для развития команды, в которой можно реализовать текущие и будущие бизнес-задачи. Это должен быть удобный и прозрачный процесс, который будет помогать расти, а не мешать.
Юрий Юрков, Delivery Manager Kaiten
Ввели классы (категории) обслуживания
В начале у каждой группы были 2 дорожки — обычная для стандартных задач и отдельная для срочных. Чаще задачи попадали в «срочные», а дорожка для обычных задач оказывалась пустой. Разработчикам казалось, что несрочные и стандартные задачи — это не важно, поэтому они все сгружали в срочное.
Это создавало проблему — задачи некорректно распределялись, команда все время «тушила» какой-нибудь «пожар» и пыталась справиться с перегрузками. Стратегические задачи в это время простаивали, а руководитель не мог контролировать поток работы.
Эту проблему тоже решили — создали систему, которая помогала определить срочность выполнения задачи, На основе системы поделили доски по дорожкам. Также научились расставлять очередность задач в зависимости от их класса обслуживания — срочности и ценности для бизнеса.
Чтобы разделить задачи на потоки, использовали простую аналогию с движением:
- срочные — это «машины скорых» в пробке, их нужно пропустить без очереди и как можно скорее доставить в точку назначения;
- к дате — это «такси в аэропорт», где самое главное приехать вовремя (не позже установленного срока);
- обычные — можно двигаться в спокойном режиме, пара часов ничего не поменяют;
- несущественные — можно не двигать, если есть что-то более срочное, но в течение года лучше начать работу над задачей.
Классы обслуживания позволили управлять задачами так, чтобы не пропускать срочные и не тратить время в моменте на мелкие задачи. В то же время задача может передвинуться из неважных в срочные или «к дате».
Например, в отделе 3 сотрудника. Есть несущественная задача на автоматизацию, команда и без этого отлично справляется с работой. Внезапно отдел резко вырастает до 103 сотрудников и без автоматизации работа останавливается. Так задача из несущественной стала срочной.
Вытащили релизы в отдельные карточки
Команды поняли, что релизы в чек-листах хранить неудобно, поэтому стали создавать для них карточки. Основной единицей стала родительская карточка, в которой есть описание основной ценности. Все релизы, которые нужны для выполнения, стали дочерними задачами.
Для подготовки релизов создали отдельную доску, где разработчики могли создавать нужное количество карточек, чтобы довести ценность до релиза. Такой подход помог убрать дублирование задач, а дочерние задачи теперь можно было создавать вне зависимости от стадии процесса.
Например: если исполнитель решил проверить фичу еще на стадии определения ценности, он может создать отдельную карточку и сделать релиз на другой доске, родительская задача останется на месте.
Этот подход позволил снова сделать процессы прозрачными. Сразу видно, на каком этапе и какая работа, а карточки больше не двигались в неизвестном направлении. Тимлид снова мог по фасаду карточки определить ее готовность.
Чтобы внедрять обновления, нужно понять не «что» нужно, а «зачем». Основной фокус наших команд сейчас — доработать процессы во всех группах и разобраться, что нужно каждой в отдельности.
Юрий Юрков, Delivery Manager Kaiten
Как определить, что перемены делают лучше, а не хуже
Чтобы проверить, действительно ли процессы улучшаются, нужно следить за метриками в динамике. Так проще вовремя корректировать планы и менять направление движения.
Разберем несколько отчетов, которые помогают делать выводы:
- Накопительная диаграмма потока. Можно сразу понять, в каком темпе работает команда, сколько задач уже завершили и сколько осталось, а еще — где они останавливаются.
На графике ниже видно, что все линии резко опустились вниз — значит, некоторые завершенные задачи снова оказались в очереди к выполнению.
- Спектральная диаграмма. Отчет помогает правильно распределять время и ставить выполнимые сроки.
В графике ниже видно, что с вероятностью 85% команда выполняет карточку за 7,5 дней, но одна находится в работе уже 21 день. Можно изучить, что тормозит выполнение и постараться этого избежать для будущей работы над проектом.
Результаты трансформации отдела разработки Kaiten. Выводы делать пока рано, но можно отметить динамику улучшения.
Команда заметно уменьшила очередь багов — если раньше в колонке всегда было больше 100 задач, то теперь этот показатель не превышает 30, что в 3 раза меньше.
Процессы поменяли сразу в нескольких сегментах, уже подключили смежные отделы контента, аналитики и службы поддержки. Базовый подход сработал — стало можно донастраивать нужные инструменты и не бояться, что система развалится.
Идеальных процессов не существует, и цель трансформации процессов отдела была не в том, чтобы построить идеальную систему.
Планируем, что процесс работы останется удобным и понятным, а не навязанным руководством. Он должен быть комфортной для команд средой, где им понятно, что и как делать.
Юрий Юрков, Delivery Manager Kaiten
Вместо вывода
Часто глобальные перемены начинаются с мелочей — наведения порядка или создания новых пространств. Так проще понять, что и как нужно изменить, чтобы это работало на благо отдела.
Чтобы команды хорошо работали, нужно регулярно донастраивать или менять процессы. С ростом команд и задач мы начали трансформацию в отделе разработки Kaiten. У команды есть точка опоры для движения вперед, и они не планируют останавливаться. Ведь процессы меняются вместе с сотрудниками, изменениями на рынке или в основных продуктах,
