За год команда разработки Kaiten выросла в 3 раза, и привычные процессы перестали работать: доска переполнилась, потерялась прозрачность, а чтобы узнать, на каком этапе работа, приходится проваливаться в каждую карточку. 

Вместе с Юрой Юрковым, Delivery Manager Kaiten, расскажем, как мы прошли путь трансформации, какие решения сработали и как не потерять управление в момент масштабирования. Если вы в похожей ситуации — читайте статью и используйте наш опыт, чтобы быстрее навести порядок.

Как работала разработка в Kaiten 

Раньше была всего одна команда из 7 человек: CTO и full-stack разработчики. Задачи обсуждали на 15-минутных дейли, в чатах и в карточках на досках. 

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

Пространство команды делилось на несколько досок:

1 доска — Анализ. Сюда попадали все задачи команды: баги, фичи от продактов, идеи и гипотезы. СРО проводил квалификацию каждой задачи, определял срочность, проблему и ожидаемый результат. 

2 доска — Разработка. Если задача перемещалась на эту доску, значит,  ее можно брать в работу. На этом этапе всем понятно, какой результат ожидать, и какие шаги предпринимать для решения задачи. 

Колонки отражали основные этапы работы над задачей. Одна карточка — главная ценность. А все релизы отслеживались в чек-листах внутри карточки:

• Каждый пункт чек-листа — это конкретный релиз или часть работы.

• На каждый релиз назначали разработчика, который будет за это отвечать.

Такой подход удобно использовать, когда вся команда работает над одной крупной задачей: все в курсе, на каком этапе работа, при этом доска не засоряется мелкими карточками.

Как поняли, что пора меняться

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

На пространство добавили дорожки, соответствующие задачам конкретного сегмента. На доске образовалось 22 (!) дорожки, что привело к перегрузу системы. В них перемешались классы обслуживания, приоритеты, задачи разных продуктов, команд и направлений.

Отсюда вытекает вторая причина: доска перестала помогать. Стало непонятно, где именно и в каком статусе находится основная ценность, потому что релизы отражались внутри задачи в виде чек-листов. 

Например: один разработчик мог писать код, а другой все еще уточнял бизнес-требования. Оба — в одной карточке. Получается, что задача и в «Анализе», и в «Разработке». 

Из-за этого карточки на доске начали двигаться не только слева направо — как положено в потоке, — но и обратно. Сегодня задача ушла в «Готово», завтра вернулась в «В работе», а потом — снова вперед.

Такое поведение разрушает логику: теряется ощущение прогресса, искажаются метрики и накапливаются риски. Возникают недопонимания, дубли, конфликты по приоритетам.

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

Инструкция по изменениям: как перестроить процессы без боли и страданий 

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

Рассказываем, как перестраивали процессы и с чем столкнулись. 

Правило 1. Подстраивайтесь под глобальные изменения

Как говорили раньше, в Kaiten появились продуктовые сегменты, у которых были свои задачи для отдела разработки, что привело к перегрузу в пространстве. 

В системе должно быть просто ориентироваться: чем меньше лишнего на доске — тем выше фокус команды. Поэтому приняли решение: разделить команду по фокусу на группы по 5 человек и перенести карточки каждой на отдельные пространства.

У каждой группы появились свои задачи и статусы. Тимлиды проводят короткие дейли внутри команд из 5 человек. Теперь они не вызывают стресса у команды и не затягиваются. А дважды в неделю тимлиды проводят отдельные короткие встречи для синхронизации по общим вопросам и решения актуальных проблем. На этих встречах им помогают дашборды, которые показывают динамику по задачам и блокировкам. 

Правило 2. Учитывайте особенности продукта

Программное обеспечение Kaiten — это монолит. Значит, любое изменение в коде затрагивает всю систему: если нужно поправить 1 строчку кода, то деплоится весь Kaiten сразу. Из-за этого возникло противоречие: нужно было и разделить команды по фокусу, и сохранить взаимодействие на уровне всей разработки.

Здесь помогла удобная функция Kaiten, которая позволяет расположить одну и ту же доску в нескольких пространствах одновременно.

Как это работает: 

• Каждая команда работает в своем локальном пространстве;

• Доски с локальных пространств добавили на одно общее пространство. 

• Все изменения на доске локального пространства отражаются на доске в общем пространстве: перемещения карточек, ответственные, блокировки и так далее.

Не всем подходит один и тот же процесс: где-то задачи идут по классике — to do, In Progress, Done. А где-то нужна итеративная работа с исследованиями и быстрыми гипотезами. 

Благодаря тому, что одна доска может располагаться на разных пространствах, команды смогли настроить поток под себя, в тот же момент оставшись в едином процессе. 

Правило 3. Улучшайте то, что хорошо работает

Процессы, которые существовали в Kaiten до трансформации позволили создать и реализовать мощный и самодостаточный инструмент, который пользуется популярностью у клиентов. Со временем команда развивала доски, пространства и workflow, адаптируясь к новым задачам. Поэтому не пришлось строить новый процесс с нуля, достаточно было улучшить то, что уже хорошо работало. 

Доработали стадии неопределенности

Для работы над задачами стали использовать конус неопределенности (Cone of Uncertainty). Когда задача только попадает в бэклог, неопределенности много: непонятно, как делать задачу, из-за чего произошел баг, принесет ли решение результат или только усложнит систему. По мере продвижения задачи и поступления большего количества информации принимаются решения и многие неопределенности устраняются.

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

Юра спроектировал основную систему без использований таких слов, как, «Анализ» и «Разработка». Вместо этого ввел несколько основных стадий, которые не отражали этапы процесса, но говорили, как много мы знаем о задаче. Эти стадии:

1. Выявление ценности — ничего не знаем о задаче и должны вникнуть. Команда решает, а точно ли нужно делать то, что мы хотим. Если да, то как мы бы хотели, чтобы это было сделано.

Вопросы, на которые предстоит ответить:

• А есть ли там что-то, что следует делать?

• А точно ли это «баг»?

• А если стоит делать, то как?

• А не дорого ли решение?

2. Изучение ценности — команда погружается в суть того, что надо донести.

После «выявления ценности» задача попадает в бэклог с соответствующим классом поставки. А после — на «Изучение ценности».

Вопросы на этом этапе: 

• Если нашли ценность, то какова она? 

• Как ее стоить поставить? 

3. Реализация задачи — почти готова, скоро в релизе.

Доска, на которой задачи поставляются и закрываются — исправляют баги, реализуют функции и другое. 

Переход к новой системе оказался быстрым и безболезненным. В Kaiten легко менять процессы на ходу — добавлять дорожки и колонки, вводить WIP-лимиты или блокировки. Поэтому разделение досок по конусу неопределенности мы внедрили за один день. Изменения были резкими, но не революционными — мы просто перестроили существующую работу под новый принцип, а не изобретали процесс с нуля.

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

Ввели классы обслуживания

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

Это знакомо многим: вся команда тушит пожары, а стратегические задачи стоят на месте. У сотрудников растет стресс и появляется ощущение перегрузки, а руководитель теряет контроль над потоком.

Мы начали с главного — добавили контекст определения срочности задачи и вместе с этим разделили доски по дорожкам, соответствующим классу обслуживания. 

Классы обслуживания (поставки) — способ заранее определить, как реагировать на задачу, в зависимости от ее срочности и ценности для бизнеса.

Мы используем простую метафору движения:

• Срочные — как машина скорой помощи в пробке: пропустить в первую очередь.

• К дате — как такси в аэропорт: важно приехать вовремя.

• Обычные — можно ехать спокойно, плюс-минус час ничего не изменит.

• Несущественные — можем не двигаться, но в течение года лучше поехать.

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

Например: в отделе из трех сотрудников есть задача на автоматизацию процессов. Команда справляется и для них эта задача «Несущественная», поэтому вы ее не берут. Случается взрывной рост компании и через месяц +100 сотрудников в отделе и без автоматизации начинается хаос. Задача из «Нематериальной» превращается в «Срочную», так как работа отдела парализована. 

Вынесли релизы из чек-листов

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

Для релизов завели отдельную доску с классическим процессом: разработчики могут создавать сколько угодно карточек — все, что нужно, чтобы довести ценность до релиза. Это решило проблему параллельной работы. Теперь создать дочернюю карточку можно на любой стадии поставки ценности.

Например: если разработчику нужно что-то проверить на стадии выявления ценности или на стадии изучения, можно тут же создать карточку на отдельной доске и сделать релиз.  

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

Как понять, что изменения улучшают, а не усложняют

Чтобы убедиться, что процесс идет в правильном направлении, важно определить метрики и отслеживать их динамику. Это помогает вовремя скорректировать план, а не продолжать падать в пропасть хаоса и сорванных дедлайнов. 

Какие отчеты помогают делать выводы: 

• Накопительная диаграмма потока. Позволяет увидеть, сколько работы выполнено, задач осталось и темп выполнения проекта. А также отслеживать, на каком этапе карточки застревают.

Например, если посмотреть на график ниже, увидим, что данные резко спикировали вниз — значит часть задач из выполненных переместилась в новые.

• Спектральная диаграмма. С ее помощью можно отслеживать распределение времени и устанавливать реальные сроки в карточке.

Например, график ниже показывает, что с вероятностью 85% задача будет выполнена за 7,5 дней. А еще, что одна карточка была в работе дольше остальных — 21 день. Можем проверить, что останавливало работу и исключить тормозы для будущих задач. 

Пока рано делать выводы, но даже по первым срезам видно: динамика меняется в лучшую сторону. Мы уже разгрузили очередь багов от поддержки: раньше висело по 100+ задач, теперь в среднем — 30. Это в 3 раза меньше.

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

Что планируем делать дальше

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

«Важна система, которая способствует реализации бизнес-задач, в том числе и в перспективе: система способствует работе, росту и развитию команды. Такой процесс, который помогает, а не мешает. Он понятен, прозрачен, и им действительно пользуются», — говорит Юра, Delivery Manager. 

Мы задали вопросы Юре о том, каким он видит процесс дальше. Итак, блиц:

— Как отреагировала команда на изменения? 

Сопротивление было, но команда — золото.

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

— Каким будет процесс через 6 месяцев?

Простым. Понятным. Удобным. И — с накопленными данными.

Мы хотим, чтобы процесс не был чем-то внешним, «навязанным сверху», а стал средой, в которой команде комфортно работать. Где каждый знает, что происходит, и почему именно так.

— Что еще планируете внедрить?

На самом деле — не что, а зачем.

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

Вместо вывода

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

«Цель не в том, чтобы быть идеальными. Цель — делать удобную систему для команды и роста»/

Юра Юрков, лидер трансформации.

Именно с такой установкой получилось двигаться вперед — без давления, но с пониманием: все, что делаем, должно работать для людей. 

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