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

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

Четыре принципа, на которых мы строим процессы

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

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

Принцип 1. Польза для клиента главнее дедлайнов

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

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

• Если появится срочная задача, придется пересмотреть сроки по другим.

• Сотрудник не всегда может правильно оценить, сколько времени уйдет на работу.

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

Принцип 2. Завершить текущую задачу важнее, чем начать новую

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

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

Принцип 3. Всегда оставлять время на что-то срочное

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

• На входе сортируем задачи по типам и сразу распределяем их по очередям. Если копить всё в одной колонке, в ней будет хаос.

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

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

Принцип 4. Учитывать опыт клиентов, чтобы улучшать продукт

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

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

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

Продуктовая разработка подразумевает верхнеуровневое планирование и техническую декомпозицию задач. Мы в Kaiten используем такой набор инструментов: 

• Roadmap для визуализации стратегического плана компании, где указаны основные направления развития, вехи и сроки. 

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

• Пространство R&D High Level для крупных задач — интеграции с новыми сервисами, новых отчетов, диаграмм и так далее.

Мы организовали R&D High Level так, чтобы было удобно смотреть статусы крупных задач. Для этого сделали четыре колонки — «Очередь», «Анализ», «Разработка» и «Готово».

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

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

После того как подготовка закончится, крупная задача передвигается в «Разработку». На доске разработчиков мы создаем детальную дочернюю карточку.

Фильтруем задачи, чтобы не делать лишнюю работу

Разработку и исправление багов фиксируем в пространстве Development. Тут мы используем Канбан-метод — так проще контролировать работу, когда у каждой задачи появляются подзадачи. 

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

• ошибки;

• пользовательский фидбек;

• техническая очередь.

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

Очереди «Пользовательский фидбек» и «Техническая очередь» разделены на дорожки по приоритетам.

Ниже — о том, как устроена каждая очередь.

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

Система регистрирует ошибки из браузера или серверов через Webhooks в Kaiten, а затем автоматически добавляет их в эту очередь. 

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

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

Чтобы распределить приоритеты, мы создали четыре горизонтальные дорожки: 

1. Дорожка «К анализу». Это фидбек, который еще рано пускать в разработку, потому что надо получше изучить. Например, выяснить актуальность и массовость запроса, совпадает ли они с тем, как мы планируем развивать продукт.

2. Дорожка «Наиболее желаемое». Это возможные задачи, для которых нужен более подробный анализ. После него мы либо берем карточку в работу, либо откладываем.

3. Дорожка «Надо сделать». Сюда попадают несрочные задачи.

4. Дорожка «Горячее». Из этой очереди команда берет задачи в первую очередь.

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

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

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

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

Используем лимиты, чтобы фокусироваться на важном 

После того как команда берется за задачу, карточка последовательно проходит три этапа: Analyse, Code (в работе) и Live (финальная стадия).

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

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

• Когда можно брать новые задачи?

• В каком порядке и из каких очередей можно брать карточки?

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

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

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

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

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

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

Не просто доводим задачу до статуса «Готово», а даем пользу клиенту

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

Дальше — подробнее о каждой детали.

В карточках с чек-листами не шаги, а релизы

В каждой карточке есть чек-листы, где прописано, что конкретно надо сделать в рамках этой задачи. Каждый пункт этого перечня — это функция или улучшение, которое получит пользователь. Например, вместо «Шаг 1» мы напишем «Серый пункт меню с замком в плюсе, в замке — „Функция отключения на уровне настроек компании‟». Мы используем такой вариант, потому что так легче держать фокус на пользе для клиента. Ведь пока мы работаем над большой задачей, он получает новые функции.

У финальной стадии работы три этапа 

Готовые задачи попадают в колонку Live, которая состоит из трех подколонок: «Анонс / База знаний», «Долг» и «Готово». Это разделение нужно, потому что, даже если клиенты уже пользуются какой-то функцией, мы продолжаем над ней работать.

До окончательного «Готово» карточка проходит еще два этапа:

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

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

Выводы: как командой не утонуть в потоке задач

У Kaiten небольшая команда разработчиков. Чтобы быстро обновлять продукт и приносить пользу конечному потребителю, мы не тратим время на ежедневные созвоны и лишнюю работу. Вместо этого мы используем принципы, которые помогают фокусироваться на важном: 

• Строим процесс вокруг пользы для конечного клиента, а не вокруг дедлайнов. 

• Сначала завершаем текущие задачи, а потом беремся за новые.

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

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

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

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