Тимлиду нужно наладить процессы в команде и повысить эффективность работы сотрудников. Один из способов это сделать — ограничить входящие задачи, то есть использовать WIP-лимиты. С их помощью сотрудники избавятся от завалов, начнут помогать друг другу, коллаборировать и работать быстрее.
Если руководитель ставит WIP-лимиты без аналитики, не объясняет команде и заказчикам, зачем нужны ограничения, всё может пойти наперекосяк. Сотрудники будут сидеть без дела или начнут брать задачи в обход менеджера. Я Андрей Сидоренко, сооснователь компании Neogenda, эксперт и тренер по Канбан методу. В статье расскажу, как грамотно ограничить количество задач и не навредить команде.
![](https://habrastorage.org/getpro/habr/upload_files/334/029/c16/334029c168b71475b10396c1a8bb3ffe.jpg)
WIP-лимиты помогают команде фокусироваться на задачах и своевременно выявлять проблемы
WIP (work in progress) — это то, сколько задач у команды одновременно находится в работе. Если команда использует Канбан-доски, то WIP — это количество элементов на ее столбцах, дорожках, ячейках, людях и т.д.. WIP-лимит — это ограничение количества проектов или задач в системе для достижения какой-либо цели.
Например, в процессе работы у сотрудников возникает соблазн бросить текущую задачу и взяться за что-то другое. Брошенных задач становится много, и у команды образуются завалы. Люди переключаются с одной задачи на другую, тратят лишнее время, теряют концентрацию и работают медленнее. Чтобы устранить эту проблему, нужны WIP-лимиты.
Ограничение входящих задач ускоряет процессы и прививает привычку выполнять одну задачу до конца и только потом браться за другую. А тимлид благодаря лимитам начинает лучше видеть проблемы и слабые места команды. WIP-лимиты ставят на что угодно: на сотрудников, типы задач, проблемные этапы работы и всю систему целиком. Вот несколько рабочих способов поставить WIP-лимиты.
На дорожки Канбан-доски. Если команда пользуется досками для визуализации задач в проекте, можно ограничить количество задач на отдельных дорожках. Например, на Канбан-доске спринта у нас четыре дорожки от бэклога до выполнения обязательства. В дорожке «В работе» должно быть максимум четыре карточки задач, а в дорожке «На проверке» — не больше пяти. Вот как это выглядит в интерфейсе.
![Пример Канбан-доски с лимитами в Kaiten. В колонке «В работе» лимит превышен на одну задачу, а в дорожку «На проверке» можно добавить еще одну карточку Пример Канбан-доски с лимитами в Kaiten. В колонке «В работе» лимит превышен на одну задачу, а в дорожку «На проверке» можно добавить еще одну карточку](https://habrastorage.org/getpro/habr/upload_files/d74/848/e26/d74848e2632daffc1e7ed13e5df0bb1b.png)
На проблемную часть системы. Тимлид видит, какую часть системы нужно оптимизировать, и устанавливает лимит на нее. Например, в команде этап тестирования — узкое место. Сколько бы ни разрабатывали разработчики и ни анализировали аналитики, тестировщики столько задач пропускать через себя не могут. Значит, нужно поставить здесь WIP-лимит.
Тестировщиков разгрузили, они больше не метаются от задачи к задаче. Теперь разработчики спрашивают, что им делать: они выполнили задачу, но отдавать на тестирование ее нельзя, потому что лимит. Для разработчиков можно сделать буферную колонку «Готово к тестированию». Постепенно система заполняется лимитами — команда подстраивается под объемы, которые могут вывезти тестировщики.
На вход в систему. В той же ситуации с тестированием тимлид может поставить WIP-лимиты сразу на вход в систему. Он смотрит, сколько задач влезает в тестировщиков, и формирует ограничения, исходя из их возможностей. В этом случае команда может даже не знать об ограничениях — тимлид просто не впускает в производство больше задач, чем нужно.
По количеству человек в команде. Если задач в системе будет столько же, сколько и сотрудников, каждый будет работать с одной задачей и не будет браться за новую работу, пока не закончит текущую.
Есть другой вариант — установить WIP-лимит меньше, чем количество сотрудников. Например, возьмем команду из 10 человек и поставим им лимит 8 задач. Теперь некоторым сотрудникам недостает задач, они спрашивают у тимлида, что им делать. Если тимлид не увеличивает лимит, люди начинают помогать друг другу, подхватывать части задач. Благодаря WIP-лимиту команда учится взаимодействовать и постепенно начинает работать быстрее.
На типы задач. Тимлиду нужно определить типы задач и понять, в каких пропорциях они взаимодействуют друг с другом. Например, разработчики выкатывают фичу (задача А), тестировщики ее тестируют (задача В) и находят баги, которые нужно пофиксить (задачи С). Тимлид делает вывод: задачи типа А порождают задачи типа С в пропорции один к пяти — и устанавливает соответствующий WIP-лимит на типы задач.
Когда не нужны WIP-лимиты
Бывает, что у команды есть естественный лимит. Все сотрудники знают, какой объем работы могут выполнить, завалов и брошенных задач нет. Тимлиду нужно сначала разобраться, есть ли в команде проблемы, которые нужно лечить WIP-лимитами. Если таких проблем нет — лимиты не нужны.
Если влезть в процесс и искусственно навязать слаженной команде лимиты, можно сломать систему. В этом случае есть два варианта эффективных решений: легализовать естественный лимит или оставить всё как есть.
Используйте метрики процесса, чтобы поставить WIP-лимиты
На этапе внедрения лимитов может быть непонятно, от чего отталкиваться. Если занизить лимит, у сотрудников будет недостаток задач, и они начнут брать работу в обход менеджера. Слишком высокий лимит грозит тем, что в системе появится свободное пространство: сотрудники будут набирать больше задач, чем могут сделать, — и образуется завал. Чтобы такого не было, нужно сначала разобраться, какие проблемы мы хотим вылечить лимитами.
Чтобы понять, каким должен быть WIP-лимит, проанализируйте показатели процесса Для этого можно воспользоваться метриками и графиками:
Throughput, график пропускной способности, покажет, какое количество элементов завершается в системе за определенный период времени.
WiP, какое количество элементов находится на каждом из этапов на определенный период времени (обычно это дата).
![Так выглядит диаграмма потока в Kaiten. На горизонтальной оси отмечены дни, на вертикальной — количество задач в день. Цветные области показывают, как меняется соотношение задач в течение работы над проектом. Так выглядит диаграмма потока в Kaiten. На горизонтальной оси отмечены дни, на вертикальной — количество задач в день. Цветные области показывают, как меняется соотношение задач в течение работы над проектом.](https://habrastorage.org/getpro/habr/upload_files/b81/e65/ff2/b81e65ff25b46d22ac0b19061c5b9e26.png)
Когда анализируете отчеты, нужно помнить, что реальная эффективность всегда ниже, чем показатели системы. Если диаграмма показывает, что команда работала над задачей десять часов, живых касаний там на два-три часа. Остальное время — это задержки, блокировки и решение вопросов с заказчиками. Если этого не учесть, можно завысить лимит, и он не будет работать.
Не стоит определять WIP-лимит по этапу с перепадами на диаграмме. Если одна из областей была сужена, значит, команда застопорилась на чем-то в этот момент. Расширение области потока может означать, что сотрудники набрали лишней работы.
Найдите в накопительной диаграмме период, когда поток был наиболее ровным, и поставьте лимит по этим данным. Только нужно проверить, не менялся ли контекст — может, кто-то из сотрудников ушел в отпуск или появилось больше срочных задач. Спустя время можно посмотреть, как команда работает с этими лимитами, и что-то изменить, увеличить или уменьшить ограничения задач.
Объясняйте сотрудникам, для чего нужны WIP-лимиты
Если установить лимит волевым решением и не объяснить, зачем это нужно, инструмент может не сработать. Сотрудники будут возражать, говорить, что ограничения не нужны и мешают делу. Худший сценарий, когда они будут тихо саботировать ограничения, умалчивать о проблемах и брать задачи в обход тимлида.
Чтобы ограничения принесли пользу, нужно показать команде, зачем это нужно и какие проблемы можно решить таким способом. Вот варианты, как безболезненно внедрить WIP-лимиты.
Не говорите о лимитах на этапе внедрения. Просто ограничьте поток входящих задач и распределяйте их соответственно лимиту. Со временем команда видит, что рабочий процесс изменился и нагрузка уменьшилась. К тому времени, как вы расскажете о лимитах, сотрудники поймут, что так работать легче и эффективнее.
Найдите нужный момент. Например, вы видите, что сотрудник каждый день на митинге говорит то же самое об одной задаче, — есть повод поинтересоваться, что происходит. Или замечаете, что команда перегружена и не справляется с работой. Можно сначала разобрать ситуацию с командой, выслушать их мнение и только потом предложить установить лимит.
Объясните на примерах. Не стоит говорить команде о «нарушении лимитов» как будто это распоряжение начальства. Лучше объяснить им ситуацию на языке цифр, аргументов и связей — показать, какие есть проблемы и как их можно решить.
Тимлид собирает команду, открывает доску, и они вместе смотрят задачи: над чем работаем, что в блокировке, до чего не успели добраться. Теперь он может сказать: «Смотрите, мы это не делаем, а от нас ждут. Давайте ограничим, чтобы нам не набежало новых задач. Я сам прослежу, чтобы не напихивали больше, чем мы можем сделать. Тогда вас не будут пушить и никто не скажет, что вы что-то не успеваете».
Если сотрудники волнуются, что просядет рабочий процесс, можно успокоить и сказать, что это эксперимент: «Не волнуйтесь, вся ответственность на мне, если не получится — сделаем иначе».
Попробуйте лимиты на симуляции. Можно, например, поиграть с командой во FeatureBan. Онлайн-игра познакомит сотрудников с принципами и практиками Канбан метода.
Вы соберете команду и выберете один из двух сценариев: «Команда маркетинга» или «Интернет-проект». После этого откроется Канбан-доска с визуализацией рабочего процесса. Сначала игроки будут выполнять задачи и свободно перемещать их по дорожкам. Во второй итерации на доске появятся WIP-лимиты, и команда сможет сделать выводы, как они влияют на процесс работы.
После каждой итерации ведущий проводит разбор: на что был похож рабочий процесс? Какие моменты кажутся знакомыми? Если продолжим работать так же, к чему придем в итоге? В процессе игры команда придет к выводам, что с WIP-лимитами можно работать быстрее и эффективнее.
![Экран онлайн-игры FeatureBan в Kaiten. Источник Экран онлайн-игры FeatureBan в Kaiten. Источник](https://habrastorage.org/getpro/habr/upload_files/d49/4ce/8de/d494ce8de7439b70663a6bc2a1904bd4.png)
Анализируйте сигналы от команды
WIP-лимиты сами по себе ничего не улучшат. Это прожектор, который помогает найти проблемы в работе команды. Когда после установки лимитов возникают сложности, это не повод всё отменить, а сигнал для внимательной работы с эффективностью команды.
Например, сотрудники говорят, что с лимитами у них мало задач и им непонятно, что делать. Или не получается закончить задачу и взять следующую. Тимлид может собрать несколько таких сигналов, проанализировать их и скорректировать ограничения, исходя из реальных потребностей сотрудников.
Сигналы от команды — главный инструмент тимлида в работе с лимитами. Вот как можно получать обратную связь от команды.
Не отменяйте лимиты. Ограничения входящих задач — не причина проблем, а инструмент, который подсвечивает их. Если испугаться и убрать лимиты при первых сигналах, потом будет тяжело вернуть их обратно. После негативного опыта сложно расположить команду и убедить сотрудников, что ограничения нужны.
Не меняйте лимит при первых сигналах. Если менять лимит по первому требованию команды, она не сможет поработать в новых условиях. Выводы о корректности лимита стоит делать спустя два-три спринта. Для этого нужно посмотреть на пять или десять задач, которые вышли из системы с другой скоростью и временем производства, проанализировать, как изменилась пропускная способность команды и среднее время цикла задач (Cycle time).
![Суммарный отчет в Kaiten показывает завершенные задачи за указанный период Суммарный отчет в Kaiten показывает завершенные задачи за указанный период](https://habrastorage.org/getpro/habr/upload_files/29a/495/514/29a4955146070aa9ff54fe847b98e351.png)
Если команда просит повысить лимит, тимлиду стоит спросить, зачем это нужно сделать. Потом он собирает количество таких сигналов за месяц и смотрит, какие выводы из этого следуют.
Обсуждайте сигналы с командой. Например, сотрудник перебирает задачи — откладывает недоделанную работу и берется за что-то другое. Почему он это делает? Он просто привык так работать или есть объективная причина блокировки задачи? Стоит задавать побольше вопросов и находить выход из ситуации вместе с командой.
Объясняйте заказчикам, для чего нужны ограничения
Бывает, что команда установила WIP-лимиты, но заказчиков это не устраивает — они не соглашаются с ограничениями и накидывают еще задач. В этом случае нужно объяснить заказчикам, почему лимиты выгодны и для них тоже.
Отдельная проблема — если заказчики не воспринимают тимлида как руководителя и занимают директивную позицию. Чтобы такого не происходило, нужно прокачивать навыки переговоров.
Например, прочитать книгу «Сначала скажите „нет‟. Секреты профессиональных переговорщиков».
Не говорите о лимитах. Не стоит вставать в позу и говорить заказчикам: «Мы больше задач не возьмем, потому что у нас лимиты». Лучше показать им статистику команды и честно сказать: «Мы можем одновременно выполнять пятьдесят задач, а сто — не можем. Если вы нагрузите больше, время реализации предыдущих задач увеличится, а быстрее всё равно не будет». Простые аргументы отрезвляют.
Расскажите о типизации задач. Если у заказчиков разные по объему задачи, нужно объяснить им, чем они отличаются. Важно, чтобы все участники рабочего процесса одинаково понимали каждый тип задачи и знали пропускную способность команды. Тимлид должен объяснить, что удобнее дать команде две-три важные задачи, чем отгрузить десять и ждать, когда они выполнятся в произвольном порядке.
Например, команда в неделю берет 10 задач поддержки, 6 задач фичи и 4 — техдолг. Всё вместе — 20 задач. Новую задачу по техдолгу они могут взять, когда завершат предыдущую задачу по техдолгу.
Помогите договориться. Иногда заказчики перетягивают одеяло и конкурируют друг с другом. В этом случае тимлиду можно обозначить, сколько задач он готов взять от каждого. Это поможет им договориться друг с другом и расставить приоритеты.
В этом случае ожно использовать револьверный механизм.
Команда — это револьвер, задачи — выстрелы, а то, как они поступают в систему, — барабан с шестью слотами.
Тимлид отводит каждому заказчику квоту в «барабане» и обслуживает их по очереди. Квоты нужно время от времени пересматривать, чтобы никто не ссорился.
В слабых руках «револьвер» может поломаться. Например, кто-то говорит, что это не новая задача, а недоделанная старая. Если тимлид не возражает, «пуля» не вылетает из «барабана». Другие начинают делать так же, «барабан» вращается медленнее или совсем останавливается.
Кратко: рассказываем, какие ошибки можно допустить при внедрении WIP-лимитов
Установить лимиты без аналитики и работы с Agile-метриками. Заниженный лимит задушит команду, а завышенный может спровоцировать завал брошенных задач. Нужно определиться, какие проблемы вы хотите вылечить лимитами, проанализировать скорость и пропускную способность команды и на основе данных поставить предварительный WIP-лимит.
Не объяснять команде, в чем смысл лимитов. В ответ на директивное поведение сотрудники будут протестовать, саботировать нововведения или брать задачи в обход. Важно наглядно показать людям, почему с лимитами работать удобнее, — тогда они примут подход и будут давать ценную обратную связь.
Не анализировать обратную связь от команды. Команда будет подавать сигналы — говорить, что работы мало или что-то не получается. Если испугаться и всё отменить, будет только хуже. Нужно собрать данные и сигналы и вместе с командой порассуждать, что можно улучшить.
Не говорить заказчикам о лимитах. Заказчики могут воспротивиться ограничениям, конкурировать друг с другом и требовать взять еще задач. Если менеджер не настоит на своем, система сломается. Нужно объяснить заказчикам, что с лимитами команда будет работать быстрее.
ruomserg
Меня всегда восхищают вот эти эксперименты из серии: "В команде 10 человек, поставим WIP=8, пусть учатся взаимодействовать". Мало у команды естественных проблем и ограничений, которые надо преодолеть - так мы им еще одно вкрутим... При этом, команда - это очень дорогой и хорошо настроенный инструмент. Вспоминается анекдот про суровых сибирских мужиков и дорогую японскую пилу - там тоже любили экспериментировать пока не сломали...
Так вот - работать это должно с точностью до наоборот. Определив что у нас в процессе есть какое-то ограничение (например, тестировщик) - мы подчиняем остальную систему этому ограничению (по-Голдратту). Внимание! Мы сначала организуем работу команды по-новому, а для контроля и визуализации (!) этого нового способа работы уже ставим WIP.
Ключевая беда наших управленцев (и тех, кто их учит) - это непонимание разницы между tools/controls и instruments. Точнее в смешении "инструментов" (руск) и instruments (англ). Слово почти одно и то же, но значения - существенно разные. Западный менеджер знает что он может смотреть на instruments, но управляет не показателями а процессом. Российский его коллега убежден что его задача - обеспечить правильные instruments, а процесс как-нибудь сам организуется лишь бы услаждать взор менеджера правильными значениями показателей. Естественно, в реальности это ведет к тому, что писаная и неписаная рабочая культуры расходятся все дальше и дальше - и менеджер через какое-то время сам не знает чем управляет... :-(
AndyJack Автор
Соглашусь. В целом беда начинающих (и не очень) менеджеров в том, что они отталкиваются от инструмента, а не от решаемой проблемы. Я достаточно давно на рынке и работаю с разработкой, менеджерами, топами, чтобы всякого повидать и могу сказать, что до этой мысли надо просто дойти самостоятельно.
Кому-то нужен rocketscience и его не устраивает объяснение механики, ему пофиг на теорию ограничений Голдратта, кому-то надо просто сказать инструкцию: "возьми вот это, сделай так и не спрашивай", а кто-то работает в среде, где срабатывает эксперимент. Я сам лично был во всех стадиях и переосмыслял эти вещи, сам видел менеджеров в этих стадиях и до сих пор вижу. Если погуглите какие-то видео со мной, то увидите мою позицию относительно того, какие мысли я вгружаю в менеджмент в своей работе, через публичные мероприятия.
В статье я пишу не об одном единственном варианте: "поставьте лимит по количеству людей", в статье я специально пишу, что есть ситуации, в которых лимит не нужен, если это, с ваших слов: "команда - это очень дорогой и хорошо настроенный инструмент." - я бы с такой пылинки сдувал и кофе приносил бы. Так же, я набрасываю разные варианты того, как это можно сделать. В статье я отвечаю на просто вопрос: "как их внедрить и какие бывают ошибки". Тонкой красной линией я говорю о том, что это не надо делать бездумно. Ну и, конечно, хочу сказать, что на основании своего опыта, я не могу утверждать, как это должно работать во всех ситуациях. В каких-то командах, от установки лимита приходило понимание, что взаимодействовать - это хорошо, что это снимает перегруз, где-то меня прям просили их поставить, где-то я не мог внедрить лимиты ни под каким соусом, хотя они были нужны и я аргументировал, показывал проблемы, графики и т.д., меня просто игнорили, а где-то это работало и мы приходили к ним эволюционно. Ну и, конечно, были ситуации с экспериментами "на шару", которые были, как успешные, так и нет. Поэтому я описал точно рабочие варианты.
ruomserg
Ну тогда у нас примерно одинаковые мысли. Единственное - я бы опасался в русском сегменте интернета выражать мысли типа "WIP усиливают...", "WIP влияют..." (не обязательно WIP - можно ставить любой другой показатель). Потому что в большОм количестве случаев это будет воспринято буквально. На самом деле, и усиливают и влияют на команду договоренности, а WIP (и все остальное) - это средства визуализации и контроля за этими договоренностями. И да, среди достаточно опытных и адекватных менеджеров это самое "договориться об изменении процесса" подразумевается и может даже не проговариваться (примерно как опытный водитель говорит "положил стрелку спидометра на 90" не упоминая о том, что тому предшествовал анализ обстановки и нажатие на педаль газа). Но сколько тех адекватных ?... А остальные пойдут расшибать себе лоб путем установки WIP и ожиданием что команда как-нибудь справится и с этим навязанным ограничением. То есть натурально заставлять спидометр показывать 90 вне зависимости от текущей скорости движения (потому что "...так в интернете писали, и им помогло"). :-(