wip limit что это
Kanban.club
Канбан обычно связывают с ожиданиями по повышению пропускной способности системы. Канбан содержит простой, но мощный инструмент — ограничение количества незавершенной работы или WIP (work in progress) лимиты. В этой статье разберемся, как они работают, на примере отдельной операции. Во второй части мы разберемся как этот механизм работает при наладке производственной цепочки
Эксперимент с многозадачностью
Наверняка вы обращали внимание, что попытка делать несколько задач одновременно скорее приводит к тому, что все задачи делаются и дольше и хуже. Насколько именно? Проведем небольшой эксперимент с друзьями. Попросим одного из них (назовем его разработчик) переписать имена всех остальных друзей (заказчиков), по одному имени на каждой отдельной карточке. Заказчики записывают время начала и окончания работы на своей карточке с именем (более подробно можно посмотреть здесь https://www.crisp.se/gratis-material-och-guider/multitasking-name-game).
Это упражнение проводим дважды. В первом случае (многозадачный режим), разработчик пишет по одной букве для каждого заказчика, и каждый раз переключается между заданиями. Во втором случае (последовательный режим), разработчик выполняет задачу от начала до конца не переключаясь.
Результаты видны на рисунке (синий — первый вариант, оранжевый — второй):
Результат 1. Время, необходимое на завершение одной задачи в «последовательном» варианте в несколько раз меньше, чем в «многозадачном» (обратите внимание на длину оранжевых и синих отрезков)
Этот эффект нашел свое отражение в законе Литтла, который связывает средние значения времени пребывания задачи в системе, число задач в ней и пропускной способности (см рисунок)
Втягивая в систему большее число задач, мы как бы «размазываем» её мощность на большее число элементов и тем самым увеличиваем время выполнения каждого из них.
Результат 2. Время выполнения всей работы в «многозадачном» режиме существенно больше, чем в «последовательном» (обратите внимание на разницу между вертикальными красной и зеленой линиями).
Типичный разброс значений 1.5-3 раза. Это приводит к тому, что как правило заказчик получивший свой продукт в «многозадачном» варианте раньше других все равно проигрывает самому последнему заказчику из «последовательного» сценария
О чем это говорит? В обоих сценариях был проделан один и тот же объем работы — написано одно и тоже количество одинаковых имен. Различия только в способе организации работы. Оказывается, вечная «проблема» менеджеров «мы не можем сделать эту задачу, если у нас не будет новых ресурсов» имеет еще одну неожиданную грань — управляя числом задач, принимаемых в работу (т. е. управляя WIP лимитом), можно добиваться увеличения (и уменьшения) пропускной способности системы в разы.
Стоимость переключения между задачами сама по себе не бесплатна. Для человека она обычно составляет 10-15% при добавлении каждой новой, одновременно выполняемой задачи. Попытка делать 5 задач одновременно скорее приведет не к пятикратному замедлению выполнения задач, а к работе системы практически «в холостую», когда большая часть мощности будет тратиться на переключение контекста, а не на реальную работу.
Оптимальный WIP для рабочей группы
Проецируя эти выводы на рабочую группу, можно ожидать, что существует такое оптимальное значение WIP лимита, которое обеспечивает её наилучшую производительность. Выше или ниже этого уровня, система будет или не нагруженной или перегруженной. Для выбора оптимального значения WIP нужно учитывать как зависит время выполнения задачи и пропускная способность системы от него
От нуля и до момента «насыщения» системы работой, её пропускная способность будет расти с увеличением числа задач. По мере наполнения системы этот рост прекратится, и скорее всего даже сменится снижением (помните еще про стоимость переключения контекста?). Время выполнения задачи наоборот, до этого момента, будет постоянной (помните шутку про то, что девять женщин не родят за 1 месяц ребенка?), а затем начнется увеличиваться в соответствии с законом Литтла и внутренними потерями на переключение контекста.
Таким образом, можно ожидать, что оптимальное значение WIP будет находится вблизи этой границы.
WIP-лимиты здорового человека и WIP-лимиты курильщика
Я и мои коллеги по работе для внутренних сотрудников компании, в которой я работаю, периодически готовим небольшие статьи, где разбираем различные кейсы по гибким подходам, включая и кейсы использования Канбан-метода для совершенствования и управления процессами. Такие статьи мы называем «Agile-shorts». И я подумал, «А почему бы не открывать свои статьи и для более широкой аудитории?» И, вот, сегодня я публикую первую свою статью из этой серии.
Сегодня я расскажу один из кейсов, почему проваливается использование такой практики как «Ограничение количества незавершенной работы» или WiP-лимиты. Оговорюсь, что это не единственная причина, но, на моей практике, очень распространенная. В будущих статьях, я, возможно, раскрою эту тему дополнительными интересными ситуациями.
Мало кто, работающий в ИТ-сфере, не слышал про гибкие подходы к созданию продуктов. Слова Agile, Kanban, Scrum уже крепко проникли в лексикон современных компаний. Кто-то их произносит с гордостью, кто-то с иронией, а кто-то сквозь зубы.
Последние, вероятно, на своем опыте столкнулись с неудачным использованием какого-то управленческого инструмента, и спроецировали свой негативный опыт на все будущие идеи.
Но эта заметка не для них. Эта заметка для вас, тех, кто понимает, что инструменты можно использовать по-разному, а на ошибках готов учиться.
Ограничиваем Пользовательские Истории, а работаем с Подзадачами
Часто, познакомившись с основами практик и методов, которые используются в Agile-культуре, у людей складывается впечатление, что, нажав Ctrl+C и Ctrl+V, они у себя получат ту же замечательную вещь, которую они увидели в учебном кейсе. На деле же оказывается, что «Ctrl+V» приходится, как в анекдоте, тщательно дорабатывать напильником.
Визуализируя работу команды, неофиты часто совмещают на одном уровне задачи, которые несут ценность для Заказчика, с задачами, которые имеют ценность только внутри процесса. Почему, спросите, совмещают? В основном, потому что привыкли работать в парадигме – «мне поставили задачу – я делаю задачу – я сделал задачу», в которой для выполнения не обязательно задумываться о ценности: «Ведь начальник уже об этом сам подумал, раз отдает задачу в работу».
В итоге, на одном уровне управления можно встретить такие задачи:
Провести нагрузочное тестирование – не самостоятельная задача, а нужна для прогресса какой-то другой
Заключить контракт с поставщиком ХХХ – не самостоятельная задача, а нужна для старта работ по другой задаче
Реализовать функционал голосового ввода – пользователь получит новый функционал для использования
Что же делать, спросите вы? Ответ в том, чтобы разделить разные уровни управления и понимать, какую проблему мы решаем.
Какие бывают уровни:
Работа на уровне исполнения задач одним человеком.
Для снятия перегруза с сотрудника используются персональные лимиты. В этом случае рассматриваются взгляд исполнителя – на задачи смотрят со стороны сотрудника, который выполняет работу.
Работа на уровне команды. Для нормирования работы команды, используются:
лимиты на систему/команду/сервис (Бэклог спринта – частный случай лимита на систему)
лимиты на тип задач (Квотирование)
лимиты на этап (работа с узкими горлами)
и другие, более экзотические типы ограничений
В этом случае нужно смотреть на задачи глазами Заказчика работ. Появляется такой объект как Customer recognizable item – задача, смотря на которую, Заказчик понимает, что это именно то, что он заказывал, и видит, что происходит с заказом.
Работа на уровне портфеля
Для эффективного распределения ресурсов для реализации портфеля инициатив, используются лимиты на объекты портфеля.
Например, лимиты на Эпики, чтобы сфокусироваться на завершении какого-то направления, а не распыляться на всё сразу. Хотя, конечно, это уже вопрос маркетинговой стратегии. Или на инициативы портфеля инициатив – чтобы сфокусироваться на скорости проверки гипотез и, в свою очередь, выбрать именно те, что даст нам конкурентное преимущество.
Резюмируя эту заметку, хочется подчеркнуть три вещи, которые помогут вам избежать ошибок и получить положительный опыт:
Попробуйте понять, для чего нужен инструмент, и в каком контексте он работает
Осознайте проблему, которую вы хотите решить применением инструмента
Если что-то не получается, допустите, что это не инструмент плох, а есть что-то, что вы не учли
И тогда, разочарование от того, что «мы потратили кучу времени, а оно не работает», вас обойдет стороной.
Как использовать Канбан для удобной работы не только менеджеров, но и программистов
Канбан — методология управления, которая используется примерно в 10 раз реже, чем Scrum, но от этого не становится менее интересной. В ее основе лежит представление процесса всей организации, как набора взаимосвязанных сервисов, которые в конечном итоге являются сервисом для конечного потребителя.
Канбан особенно легко внедряется начиная с топ-менеджмента и прекрасно комбинируется с теорией ограничений, изложенной в книге «Цель» Элияху Голдрата. Канбан выбирают для себя отделы техподдержки, системные администраторы, и даже менеджеры по персоналу и бухгалтеры, тесно работающие с IT.
Одной из основных отличительных черт являются принципы внедрения Канбана: «Начните с того, что имеете, визуализируйте процесс, договоритесь об эволюционном изменении процессов».
Заметьте, что речь идет не о том, чтобы громогласно объявить о внедрении Канбана, а лишь о том, чтобы эволюционно менять процессы в сторону улучшения. Наверное, вы подумали: «Звучит не страшно. Кто же от такого откажется?». И тем не менее, добиться заметных результатов с точки зрения бизнеса без серьезных изменений не выйдет.
Следом за невинной фразой «давайте договоримся об эволюционном изменении процессов» может поступить много разных предложений. И если внедряющий Канбан достаточно опытен, это все пройдет весьма аккуратно. Ниже описаны выгоды, ради которых стоит внедрять канбан, и практики, которые можно использовать для улучшения процессов.
Никто не научит программистов программировать быстрее с помощью этих методов, естественно. Но большую часть времени задачи скорее лежат в очереди или блокируются по тем или иным причинам, а иногда просто оказываются забытыми в гуще недоделанных дел. С наведением порядка в задачах канбан справиться вполне может.
Выгоды внедрения
В наше время, когда интерес к слову Agile, мягко говоря, перегрет, ее может и не предполагаться изначально. Но все-таки, даже если это было затеяно с целью выполнить поручения, из внедрения все еще можно извлечь пользу.
1) Канбан создан для того, чтобы увеличить прозрачность процессов внутри организации
Как часто происходит, что люди не понимают, как устроены процессы в той части компании, с которой им приходится взаимодействовать, но которая выполняет другую функцию? Например, как много маркетологи знают о работе программистов? А программисты о работе маркетологов?
Незнание устройства процессов другого подразделения часто вызывает иллюзии и пренебрежительно отношение к труду других, в таких условиях становится сложнее наладить контакт, и отделы могут даже превратиться во враждующие государства.
2) Канбан помогает бороться с «многозадачностью» в самых плохих ее проявлениях
Где-то на курсах учат «эффективных менеджеров», которые потом делают сами и советуют другим если задача не превышает 5 минут, отложить то, что ты делаешь прямо сейчас и сделать короткую задачу, чтобы навсегда избавиться от маленького балласта, а потом вернуться к основной, но самые догадливые заказчики начинают представлять каждую задачу как сверхмаленькую и требующую такого приоритетного подхода.
3) Канбан позволяет больше не заниматься оценкой сроков выполнения конкретной задачи
Вместо этого предполагается использовать статистические методы. Представьте себе, что вы измеряете диаметр сечения водопроводной трубы и скорость потока, а не занимаетесь предсказанием, как быстро конкретная капля(пусть даже помеченая синим красителем) пролетит через трубу из точки A в точку B.
Полезные инструменты, делающие Канбан эффективным
В отличие от Scrum, внедрение которого сопряжено с целым рядом ритуалов, внедрение Канбана происходит гораздо более плавно и незаметно. Однако оно также дает меньший экономический эффект в первое время, так как простая доска, какой бы красивой она не была, все еще не является внедренным Канбаном.
Канбан-доска
Канбан-Доска организации в целом и связанные с ней доски более низкого уровня для подразделений. Является важным аттрибутом, но ее наличие еще не гарантирует наличие гибкого мышления и наличия какой-либо методолоии в управлении организацией. Много внедрений в России заканчивается на этой стадии, впрочем также можно увидеть много внедрений скрама, из которых успели заработать только спринты.
Инструкция по внедрению:
1) Определите, через какие состояния реально проходит ваша типичная задача. Вариант «гнев, отчаяние, торг, депрессия, принятие», конечно, не принимается, но звучит поразительно часто.
Например, это могут быть такие столбики для общего IT-процесса(стратегический уровень):
В очереди | В работу | Анализ | Проектирование | Дизайн | Разработка | Тестирование | Выкладка
Или такие(для выделенного подразделения UX-дизайнеров):
В очереди | В работу | Макет | Прототип | Верстка | Передано в разработку
И вторая доска может быть расшифровкой слова «Дизайн» в первой доске, когда одна карточка на большой доске выглядит, как много мелких подзадач на дизайн в технической.
Физическое перемещение карточек по доске вместо электронного варианта дает определенное удовольствие, хотя и доставляет неудобства, особенно распределенным командам. Через 2-3 недели, когда вы поймете, какие именно состояния бывают у ваших работ на самом деле, можно перейти к электронному варианту.
Ограничение на количество работ в процессе. (WIP Limit)
Эта практика является важнейшей частью Канбана и без нее экономический эффект достижим с гораздо меньшей вероятностью. В практике автора внедрение лимита всегда происходит с серьезным сопротивлением, так как ограничение на задачи в каждом статусе воспринимается интуитивно как органичение прав и свобод трудящихся, что на самом деле конечно не так.
Как внедрить:
1) обсудите завалы недоделанных задач(если они есть) и примите решение с ними бороться;
2) введите ограничение на самый заваленный столбец и только на него;
3) как только мы начинаем уделять особенное внимание какой-то части процесса и ликвидируем «завал» в этом месте, то самым узким местом станет другой участок производства, найдите новое самое узкое место и поставьте ограничение и на этот столбик
(даже если для этого вам придется убедить смежное подразделение тоже обзавестись канбан-доской, почему нет);
4) последовательно внедрите и ужимайте ограничения по столбикам досок, связанных с нужным вам процессом, но не до такой степени, чтобы люди сидели без работы просто из-за введенного правила, небольшой целесообразный запас работ в любом статусе должен оставаться.
Инициатива по внедрению этой практики лучше всего принимается от самих исполнителей, ее почти невозможно внедрить «сверху», но она того стоит. Коучу достаточно легко подговорить ее использовать людей, показав ее преимущества на игре-симуляции Канбана.
SLA — Service level agreement, или соглашение об уровне сервиса
Несмотря на то, что название переводится как соглашение, на самом деле это элемент статистики, говорящий о том, как быстро в среднем раньше выполнялись задачи и позволяющий в связи с этим построить реалистичные ожидания.
Но, в отличие от статистики, этот уровень может включать небольшой запас при сообщении его внутренним или внешним заказчикам.
Внедрение
1) Подсчитайте статистическими методами, сколько времени в среднем проходит от постановки задачи в очередь заказчиком (внутренним или внешним). А также, в какой временной промежуток уложились наиболее быстрые 10% (назовем его X), и в какой уложились только 90% (назовем его Y). Подсчитайте также время Z для «долгостроев», сколько времени занимали самые длинные задачи.
2) Возьмите Х и прибавьте к нему Y, и вы получите реалистичные сроки выполнения 90% задач, даже если заказчики будут «набегать» со срочными поручениями, которые не могут ждать указанный срок и будут отодвигать ваши задачи. Скажем по секрету, что они наверняка приходят со срочными задачами и сейчас тоже в особом порядке. Автору известны случая «внутренней коррупции», где нарушение приоритетов стоило чашку кофе или шоколадку, некоторые рассказывают о реально заплаченных деньгах.
3) Договоритесь с заказчиком(не имеет значения, внутренним или внешним) о том, что в штатной ситуации задача обрабатывается за время X+Y, и лишь 10% задач могут выполняться крайне долго по тем или иным причинам вплоть до времени Z.
Классы сервисов
На самом деле мы немного схитрили, рассказав вам о классах сервисов на пару абзацев выше, но не назвав их. Это название звучит слишком сложно и местами пугающе, но сам подход является важнейшей частью внедрения Канбана для обеспечения гибкости в работе со внутренними и внешними заказчиками.
Как внедрить?
Обсудить эту возможность, написать официальное письмо и добавить разделение строк на доску, оно обычно называется Swimlines, и если в Jira с этим проблем не было в старой версии, то в Asana кажется без дополнительных скриптов это невозможно.
Роль Менеджера запросов(SRM)
В материалах по Канбану авторы изредка честно говорят, что эта роль нужна скорее для того, чтобы не увольнять Product Owner при переходе со скрама, но и в этой позиции (SRM) нет особенной нужды, если нет проблем с получением заданий от заказчика. Эта роль может быть полезна тем командам, которые страдают от отсутствия «единой точки входа» в продуктовых компаниях. Тогда этот человек может устанавливать формальные политики и разбираться с входящей очередью, но это точно не предполагается как работа на полную ставку. Как вариант, можно иметь одного реквест менеджера на несколько команд, и превратить в него бывшего менеджера проектов или руководителя группы разработки(в общем того, кто в новом процессе остался без лишней работы).
Роль Менеджера поставки(SDM)
Service delivery manager — гораздо более сильная роль, и в нее чаще всего ставят именно менеджера проектов, как того, кто нужен изначально, чтобы дела доводились до конца. При наличии деливери менеджера в большинстве случаев роль реквест менеджера практически не нужна, хотя формально они вместе обеспечивают двоевластие, реквест менеджер занимается теми задачами, которые еще не решили, нужно делать или нет, а деливери менеджер теми, которые уже точно нужно делать и доводить до конца.
Каденции. Различные встречи с изменяемой под процесс периодичностью
Таких встреч в канбане много, даже слишком много. Различные встречи от ежедневных до встреч планирования поставок и и планирования наполнения очереди(аналог планирования спринта в скраме).
Ежедневная «летучка» standup
На стендапах в отличие от скрама обсуждаются гораздо более приятные для исполнителей вопросы. Не нужно вспоминать мучительно, что же ты делал вчера, достаточно вместе со всеми посмотреть на доску и определить, что мешает каждой задаче справа налево перейти правее, и чему может помешать она
Operations Review
Как при работе не уйти в формализм и следование правилам в ущерб продукту?
В этом очень помогает проведение встречи Operations Review, отличающейся от аджайл-ретроспектив тем, что рассматривает процессы в организации в целом, чтобы не заниматься локальной оптимизацией на встречах ретроспектив каждой команды, так как в соответствии все с той же теорией ограничений локальная оптимизация скорее вредит эффективности организации, чем помогает ей.
Предсавьте себе инженеров техподдержки, которые без увеличения штата и других внешних признаков наличия проблемы все более и более эффективно и быстро отвечают нарастающему числу жалующихся пользователей, но поскольку им нужно отвечать быстро, не передают полученную информацию в команду разработки. Представить такое не сложно, такое происходит в техподдержках огромного числа российских и зарубежных компаний. Как бы эффективно, быстро, и красиво они не отвечали, если они не сигнализируют об источнике проблемы, то проблему сложнее обнаружить и исправить, а им будет все сложнее сравляться с нарастающей нагрузкой.
Планирование поставки
На этой встрече, которая не обязана происходить ровно раз в 2 недели, а происходит ровно тогда, когда есть какие-то проблемы с поставкой или неопределенность, например, в маркетинге, можно провести ревью того, что более готово к завершению и выбрать те задачи, которые являются более приоритетными на ближайшую поставку.
Наполнение бэклога
Честно говоря, особой необходимости в этой встрече у подопечных команд автора никогда не было, скорее была проблема в его переполненности из-за большого количества заказчиков, но тем не менее необходимость этой встречи легко понять тем, кто когда-либо делал продукт с нуля и помнит свежезаведенный например проект в Jira. На подобной встрече можно создать совместно наиболее приоритетные задачи в масштабах продукта или даже организации. С декомпозицией на технический уровень прекрасно справятся уже инженеры.
Метрики
Существует стандартный набор метрик продукта: выручка, прибыль, ARPPU(average rate per paying user), чуть более нелюбимая ARPU(average rate per user, которая учитывает выручку в пересчете на всех пользователей, а не только платящих) и другие. Эти метрики очень полезны для любого процесса в продуктовой компании, немного другие, но весьма схожие — для аутсорсной. Но это конечно касается стратегического уровня.
На уровне функциональных подразделений важно внедрить те метрики или их косвенные проекции, которые действительно направят процесс в нужное русло. И это не всегда среднее количество задач, выполняемых в день, или время, за которое задачи делаются в среднем. Хотя эти метрики по умолчанию предлагаются в канбане, процесс априори должен подстраиваться под нужды конкретного внутреннего и внешнего заказчика. Только так компания сможет стать набором взаимосвязанных сервисов друг для друга с целью оказания сервиса конечному клиенту.
Взаимодействие с управлением продуктом
Профессия менеджера продукта сродни работе стартапера, с той только разницей, что у менеджера продуктов есть только зарплата и, если повезет, процент от прибыли, а вот у стартапера зарплаты нет, но зато потенциальная прибыль принадлежит ему полностью(или в доле с партнерами).
Менеджеры продуктов существуют в компании для того, чтобы развивать отдельные продукты, заботиться о повышении их прибыльности и в принципе причинять добро своим клиентам, через решения реальных проблем реальных людей, а не реализации очередного набора задумок генерального директора, у которого к тому же может быть уже давно закончилась фантазия или никогда не было особого видения именно для этого направления.
Менеджеры продуктов являются владельцами бюджетов и формируют стратегию, включая виды сервисов, оказываемых клиенту и зарплатные бюджеты на реализацию задуманного. Менеджеры продуктов определяют ключевые метрики, которые должны достигнуть продукты. Подразделения могут быть в прямом подчинении у менеджера продуктов, а также возможна традиционная матричная структура, что гораздо хуже для управляемости и повышает нагрузку на коммуникации отдельных людей(руководителей отделов, пытающихся заниматься ручным управлением).
Менеджер продуктов может спроектировать нужный ему процесс и задать нужные ему метрики. Он может выборочно использовать скрам или канбан или даже fast waterfall на разных участках своего процесса, ведь в конечном итоге любая методология — лишь способ достижения цели.
Кросс-функциональные команды
Вы можете использовать кросс-функциональные команды в скраме. Вы можете даже использовать кроссфункциональную скрам-команду, как ячейку общей канбан-структуры организации.
Но не стоит прямо противопоставлять канбан скраму и спешить заменять одно другим. Канбан лучше всего подходит подразделениям-сервисам, а не кросс-функциональным «боевым» командам, каждая из которых может все от маркетинга до техподдержки.
В кросс-функциональных командах лучше не разделять работы по разным типам и не создавать противостояние в духе «эта задача еще не в моей колонке», в подразделениях же с одинаковой функцией сотрудников и большим количеством однотипных задач этот подход покажет себя хорошо с меньшими усилиями.
И снова про доску, которую многие по ошибке принимают за сам канбан
Как сделать так, чтобы программиста, тестировщика или любого другого инженера больше не дергал менеджер или любой представитель смежных подразделений с вопросом «когда будет готово?»
Достаточно научить людей читать доску и ставить задачи на доску. Ведь в представлении многих канбан = доска, хотя это на самом деле не так.
Обычно внутренние заказчики приходят в восторг, а если показать им команду в которой используются все вышеперечисленные методы, а некоторые из них даже внедряют канбан у себя в подразделении, если им нравится результат, не дожидаясь никаких требований сверху, что дает возможность запустить канбан в качестве вирусной методологии управления внутри средних по размерам организаций.
В практике автора даже был случай потери клиента, так как канбан «довнедрял» себя сам силами начавших его подробнее изучать специалистов, и генерального директора отстранили от ручного управления процессами, чем он при этом остался доволен.