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

Если руководитель ставит WIP-лимиты без аналитики, не объясняет команде и заказчикам, зачем нужны ограничения, всё может пойти наперекосяк. Сотрудники будут сидеть без дела или начнут брать задачи в обход менеджера. Я Андрей Сидоренко, сооснователь компании Neogenda, эксперт и тренер по Канбан методу. В статье расскажу, как грамотно ограничить количество задач и не навредить команде.

WIP-лимиты помогают команде фокусироваться на задачах и своевременно выявлять проблемы

WIP (work in progress) — это то, сколько задач у команды одновременно находится в работе. Если команда использует Канбан-доски, то WIP — это количество элементов на ее столбцах, дорожках, ячейках, людях и т.д.. WIP-лимит — это ограничение количества проектов или задач в системе для достижения какой-либо цели.

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

Ограничение входящих задач ускоряет процессы и прививает привычку выполнять одну задачу до конца и только потом браться за другую. А тимлид благодаря лимитам начинает лучше видеть проблемы и слабые места команды. WIP-лимиты ставят на что угодно: на сотрудников, типы задач, проблемные этапы работы и всю систему целиком. Вот несколько рабочих способов поставить WIP-лимиты.

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

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

Тестировщиков разгрузили, они больше не метаются от задачи к задаче. Теперь разработчики спрашивают, что им делать: они выполнили задачу, но отдавать на тестирование ее нельзя, потому что лимит. Для разработчиков можно сделать буферную колонку «Готово к тестированию». Постепенно система заполняется лимитами — команда подстраивается под объемы, которые могут вывезти тестировщики. 

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

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

Есть другой вариант — установить WIP-лимит меньше, чем количество сотрудников. Например, возьмем команду из 10 человек и поставим им лимит 8 задач. Теперь некоторым сотрудникам недостает задач, они спрашивают у тимлида, что им делать. Если тимлид не увеличивает лимит, люди начинают помогать друг другу, подхватывать части задач. Благодаря WIP-лимиту команда учится взаимодействовать и постепенно начинает работать быстрее.

На типы задач. Тимлиду нужно определить типы задач и понять, в каких пропорциях они взаимодействуют друг с другом. Например, разработчики выкатывают фичу (задача А), тестировщики ее тестируют (задача В) и находят баги, которые нужно пофиксить (задачи С). Тимлид делает вывод: задачи типа А порождают задачи типа С в пропорции один к пяти — и устанавливает соответствующий WIP-лимит на типы задач.

Когда не нужны WIP-лимиты

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

Если влезть в процесс и искусственно навязать слаженной команде лимиты, можно сломать систему. В этом случае есть два варианта эффективных решений: легализовать естественный лимит или оставить всё как есть.

Используйте метрики процесса, чтобы поставить WIP-лимиты

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

Чтобы понять, каким должен быть WIP-лимит, проанализируйте показатели процесса Для этого можно воспользоваться метриками и графиками:

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

• WiP, какое количество элементов находится на каждом из этапов на определенный период времени (обычно это дата). 

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

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

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

Объясняйте сотрудникам, для чего нужны WIP-лимиты

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

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

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

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

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

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

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

Попробуйте лимиты на симуляции. Можно, например, поиграть с командой во FeatureBan. Онлайн-игра познакомит сотрудников с принципами и практиками Канбан метода. 

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

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

Анализируйте сигналы от команды

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

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

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

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

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

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

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

Объясняйте заказчикам, для чего нужны ограничения

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

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

Например, прочитать книгу «Сначала скажите „нет‟. Секреты профессиональных переговорщиков». 

Не говорите о лимитах. Не стоит вставать в позу и говорить заказчикам: «Мы больше задач не возьмем, потому что у нас лимиты». Лучше показать им статистику команды и честно сказать: «Мы можем одновременно выполнять пятьдесят задач, а сто — не можем. Если вы нагрузите больше, время реализации предыдущих задач увеличится, а быстрее всё равно не будет». Простые аргументы отрезвляют.

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

Например, команда в неделю берет 10 задач поддержки, 6 задач фичи и 4 — техдолг. Всё вместе — 20 задач. Новую задачу по техдолгу они могут взять, когда завершат предыдущую задачу по техдолгу.

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

В этом случае ожно использовать револьверный механизм. 

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

Тимлид отводит каждому заказчику квоту в «барабане» и обслуживает их по очереди. Квоты нужно время от времени пересматривать, чтобы никто не ссорился.

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

Кратко: рассказываем, какие ошибки можно допустить при внедрении WIP-лимитов

Установить лимиты без аналитики и работы с Agile-метриками. Заниженный лимит задушит команду, а завышенный может спровоцировать завал брошенных задач. Нужно определиться, какие проблемы вы хотите вылечить лимитами, проанализировать скорость и пропускную способность команды и на основе данных поставить предварительный WIP-лимит. 

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

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

Не говорить заказчикам о лимитах. Заказчики могут воспротивиться ограничениям, конкурировать друг с другом и требовать взять еще задач. Если менеджер не настоит на своем, система сломается. Нужно объяснить заказчикам, что с лимитами команда будет работать быстрее.