Как команда Kaiten использует Kaiten

Kaiten — российский таск-трекер, которым пользуются тысячи компаний среди которых Вкусвилл, Альфа-банк, Qiwi, Hochland, Mars, Сколково и другие. При этом над продуктом и его поддержкой работает совсем небольшая команда.

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

Решил поделиться своим опытом. Ведь кто может лучше рассказать об использовании инструмента, если не те, кто его создает и пользуется им каждый день?

Все начинается с базовых принципов

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

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

Поэтому наша команда разработки придерживается определенных принципов.

Фокусируемся не на дедлайнах, а на том, чтобы донести ценность пользователю за минимально возможное время

Общепринятая практика исполнения поручений фокусируется на сроках. Руководитель ставит задачу, уточняет, сколько времени она займет, и устанавливает дедлайн.

Чаще всего сроки являются дополнительной нагрузкой, и на самом деле не позволяют людям качественно выполнить работу, потому что:

• Люди неправильно оценивают работу из-за специфики самой оценки;
• Могут появиться более приоритетные задачи, тогда сроки теряют актуальность;
• Есть задачи, которые занимают меньше времени, чем сама оценка, поэтому разумнее опустить этот процесс.

Мы работаем иначе — наш процесс про то, как выбирать самое важное и очень быстро это доставлять клиенту.

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

Ограничиваем количество незавершенной работы

В нашем процессе налажена оптимальная пропускная способность. То есть люди в каждый момент времени сфокусированы на том, чтобы сделать именно то, что нужно, в минимально нужном объеме.

Разработчики не берут новые задачи, пока не доведут до конца те, что уже в работе, не перескакивают с задачи на задачу, не посещают бесполезные встречи, не стрессуют из-за огромного количества зависших задач.

Заранее готовимся к срочным задачам

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

Команда должна быть готова взять такие  задачи в работу.

В «Теории управления очередями» есть параметр «Загрузка ресурса». Смысл в том, что если все ресурсы загружены на 100%, то время ожидания в очереди бесконечно. Вот почему большинство компаний на рынке медленные, а мы очень быстрые.

Мы со страшной силой блюдем математику управления очередями:

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

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

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

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

Как мы планируем развитие продукта и ставим долгосрочные цели

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

Для верхнеуровневых планов у нас есть:

• roadmap составленный в модуле Кайтена User Story map;
• план значимых релизов, прописанный в документах Kaiten — это публичный документ, который могут посмотреть наши партнеры и клиенты;
• и пространство с крупными задачами «R&D High Level».

На пространстве «R&D High Level» расписаны крупные задачи в виде доски со статусами. Оно работает следующим образом:

• Есть большие идеи — они оформляются как отдельные карточки в колонке «Очередь», туда мы прикрепляем какую-то фактуру, анализ или разговоры с пользователями, которые легли в основу этих идей.
• Прежде чем эти крупные задачи попадают в разработку, они проходят несколько предварительных этапов Анализа. Эти этапы отображены на доске как колонка «Анализ» с несколькими подколонками: «В работе», «Конкурс», «Готово к разработке».
• Столбец «Конкурс» нужен, чтобы определять более приоритетные задачи, которые дальше мы возьмем в работу первыми. Только после всех подготовительных этапов задача попадает в колонку «Разработка». Дальше для этих крупных задач мы создаем детальные дочерние карточки на доске разработчиков.

Фильтрация задач — как мы понимаем, что брать в работу, с каким приоритетом, а что — выкинуть

Дальше, есть пространство Development — там ведется вся разработка и баг-фиксинг. Это пространство кардинально отличается наличием кучи подзадач. Здесь мы во всю используем канбан-метод.

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

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

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

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

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

Очередь «Ошибки»

Здесь фиксируются ошибки, которые регистрирует сама система в браузере или на серверах. Это техническая интеграция, которая делается через Webhooks в Kaiten.

Очередь «Пользовательский фидбек»

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

Она разбита на горизонтальные дорожки:

1. «К анализу»
   Сюда попадает весь пользовательский фидбэк, с которым пока вообще непонятно что делать. Здесь мы смотрим, насколько актуален этот запрос, единичный он или массовый, как он вяжется с верхнеуровневым планом развития продукта.
2. «Наиболее желаемое»
   Здесь находятся карточки, которые надо бы сделать, но мы еще не до конца в этом уверены. Проводим дополнительный анализ.
3. «Надо сделать»
   Здесь лежит то, что сделать нужно, но не срочно.
4. «Горячее»
   Это непосредственно та очередь, из которой нужно брать задачи в работу, если у команды есть capacity.

Техническая очередь

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

• либо они не так страшны сейчас;
• либо мы возьмем их в работу, потому что найдем способ сделать это быстро.

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

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

Главное здесь — держать очереди в чистоте.

Доска разработки — мы работаем быстро и эффективно, потому что следуем правилам

На этой доске есть 3 важных элемента:

1. Дорожки, по которым разбиваются задачи из разных очередей;
2. Правила, которые регламентируют систему приоритета очередей — кто когда из какой очереди берет новые задачи или присоединяется к уже существующим;
3. Лимиты, которые ограничивают возможность брать новые задачи, если старые еще не доведены до конца.

Доска разбита на этапы:

• Analyse;
• Code (В работе);
• Live (финальная стадия).

По горизонтали доска делится на Дорожки по типам задач. В каждую из этих дорожек отправляются задачи из конкретной очереди.

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

Отдельно стоит рассказать про правила. Они зафиксированы прямо в описании доски:

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

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

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

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

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

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

Следующие правила регулируют, из каких очередей и при каких условиях разработчик берет новые задачи в работу

Это как раз про приоритеты.

Сначала стоит брать задачи из очереди «Ошибки», затем из «Пользовательских запросов», затем из Верхнеуровневых задач, готовых к разработке и так далее.

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

У разработчика есть выбор, какую задачу ему сделать

Тут важный момент: у нас нет руководителя, который назначает задачи, а есть руководитель, который следит за очередями:

- Какую мне задачу делать?
- Выбери себе задачу из очереди «Пользовательские запросы».

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

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

Не просто довести задачу до «готово», а дать ценность пользователю

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

Чек-листы в карточках разбиты не по шагам, а по релизам

Мы не прописываем по задачам «Шаг 1», «Шаг 2» и тд. Потому что, как только начинаются следующие шаги, то оказывается, что задачу можно делать месяцами.

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

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

Это позволяет убирать весь мусор из головы и делать нужные вещи.

Финальная стадия работы над задачей состоит из трех этапов

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

Дальше есть 3 этапа:

«Анонс / База знаний» — по каждой новой функции сам разработчик пишет подробную инструкцию, как ей пользоваться. Это крайне важный этап процесса, потому что презентация своей работы позволяет кратно повышать ее качество. В процессе презентации мы сами пытаемся воспользоваться решением как пользователь и узнаем много нового о своем решении.

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

«Готово» — это когда задачи сделаны целиком. Здесь включена автоархивация. Выполненные карточки автоматически отправляются в архив и не нагружают пространство.

Выводы и советы начинающим пользователям

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

Вся работа команды строится внутри самого Кайтена. Но каким бы удобным ни был таск-трекер — это инструмент, а не волшебная таблетка.

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

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

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

Полезные кейсы:

• Как оптимизировать работу службы поддержки с помощью Kaiten. Опыт ProctorEdu
• Как генеральный директор технопарка «Сколково» контролирует работу сотни сотрудников за 15 минут в неделю. Кейс технопарка «Сколково»
• Не смогли оплатить Trello: как Kaiten спас строительную фирму от неразберихи из-за срочного переезда. Кейс «Белый журавль»
• Как упорядочить и автоматизировать работу бэк-офиса с помощью канбан-метода. Кейс «Академии Йоги»
• Искали замену Trello, а получили идеальный инструмент для scrum-подхода с agile-блоком в коробке. Кейс «Сантехники-Онлайн»