Что такое wip лимит
Как снова привести работу в движение с помощью лимитов незавершенной работы
Лимиты незавершенной работы нужны совсем не для того, чтобы препятствовать работе. Как раз наоборот.
Просмотр тем
Что такое лимиты незавершенной работы?
Лимиты незавершенной работы (WIP) применяются в процессе agile-разработки, чтобы ограничить максимальное количество задач на каждом этапе рабочего процесса. Лимитируя объем незавершенной работы, вы можете обнаружить слабые места в рабочем процессе команды. Благодаря этому вы без труда выявите проблемы в потоке поставки продукта до того, как ситуация усложнится.
Почему лимиты незавершенной работы так важны?
Надеюсь, что теперь вам захотелось узнать подробнее.
Ограничения WIP повышают производительность команд и уменьшают количество «почти выполненных» задач, заставляя команды сосредоточивать усилия на меньших объемах работы. По сути, ограничения WIP вырабатывают у команды привычку выполнять работу до конца. Что еще важнее, они проливают свет на препятствия и проблемные места. Когда имеется некий индикатор, который однозначно указывает на проблемные места, команда может дружно штурмовать задачи, препятствующие дальнейшему продвижению работы, чтобы разобраться в них, выполнить и разрешить проблемы. После устранения препятствий работа в команде снова приходит в движение. Благодаря этому клиенты быстрее получают новые порции ценных изменений. Этим и важны ограничения WIP в процессе Agile-разработки.
В процессе разработки может появиться желание приостановить работу над текущей задачей и взяться за что-то другое. Когда открыты сразу две задачи, приходится переключать контекст или передавать работу коллегам. Переключение внимания с одной задачи на другую не проходит даром: на это тратится время и снижается концентрация. Практически во всех случаях лучше выполнить одну задачу до конца, чем взяться за новую работу и не завершить ее. Иными словами, ограничения незавершенной работы не дают нам тормозить собственный процесс.
Наконец, ограничения WIP помогают выявить случаи, в которых простой или перегруженность приобрели уже хронический характер. В результате команда может увидеть слабые места во всем процессе, а не только в отдельных областях работы.
Если команда раньше никогда не использовала лимиты незавершенной работы, они могут показаться неудобными. Поднимите вопрос о лимитах WIP в первых нескольких итерациях. Научитесь понимать, когда и почему команда достигает лимита незавершенной работы. На первых порах не поддавайтесь соблазну самовольно менять эти лимиты. Если лимит достигается на постоянной основе, значит, установлен слишком строгий лимит WIP или вы обнаружили слабое место в рабочем процессе команды.
Использование лимитов незавершенной работы в agile-командах
Теперь, когда вы осознали ценность лимитов WIP, можно перейти к сути дела.
При развертывании нового рабочего процесса обсудите всей командой, какое ограничение WIP нужно установить для каждого статуса. Прежде чем устанавливать ограничения, рекомендуем понаблюдать за несколькими спринтами и определить, сколько рабочих задач в среднем находится в каждом статусе. Ниже приведен пример Agile-доски с ограничениями WIP, которую использует обычная команда разработчиков ПО.
В примере выше для столбца Code review (Проверка кода) установлено ограничение незавершенной работы. Это ограничение превышено, поэтому фон столбца окрашен в красный цвет.
Поскольку задачи, перемещенные в столбец Done (Завершено), не требуют дополнительных действий, для него ограничение WIP не устанавливается. На доске выше статус Ready for dev (Готово к разработке) получают пользовательские истории, которые были тщательно проверены владельцем продукта и командой. Когда команда разработчиков приступает к выполнению рабочих задач, она переносит задачи из столбца Ready for dev в столбец In progress (В работе). Важно, чтобы в статусе Ready for dev всегда находилось достаточно задач. Так участники команды разработчиков будут задействованы максимально эффективно. При этом на этапе Ready for dev не должно быть слишком много историй, чтобы владелец продукта не ушел далеко вперед в тот момент, когда появятся новые требования, и чтобы программу было проще адаптировать к изменениям.
В статусе In progress находятся задачи, над которыми идет активная работа. Здесь ограничения WIP нужны, чтобы никто не сидел без работы и чтобы никто не занимался несколькими задачами одновременно. На доске, показанной выше, для задач в статусе In progress установлено ограничение в 4 задачи, и в этом статусе в настоящий момент находятся 3 задачи. Значит, команда может взяться за дополнительную задачу. В некоторых командах целесообразно выбирать такое ограничение незавершенной работы, которое было бы меньше числа участников команды. Это поможет подготовиться к внедрению надлежащих Agile-методик. Когда разработчик заканчивает работу над задачей и видит, что команда уже достигла ограничения WIP, он понимает, что пора выполнить несколько проверок кода или присоединиться к другому разработчику, чтобы заняться парным программированием.
В статусе Code review находятся истории, для которых код уже полностью написан, однако его требуется проверить, прежде чем выполнять слияние с базой кода. Своевременные проверки кода — лучшее средство для обеспечения высокого качества, ускорения вывода инноваций на рынок, упрощения слияний (открытых веток становится меньше) и обмена знаниями между участниками команды разработчиков. Приступать к работе на этой стадии следует как можно скорее по нескольким причинам.
Благодаря ограничениям незавершенной работы непроверенный код не будет накапливаться бесконечно.
Обратите внимание: на Agile-доске выше у команды скопилось слишком много задач по проверке кода, поэтому столбец окрашен в красный цвет.
4 цели для agile-команд, использующих лимиты незавершенной работы
Как и все новое, ограничения незавершенной работы могут поначалу показаться неудобными. В среднесрочной перспективе команда должна найти идеальный баланс, а в краткосрочной такое неудобство окажется даже на руку. Благодаря этому команда сможет увидеть слабые места в рабочем процессе. Поработав с ограничениями WIP в течение нескольких недель, можно будет при необходимости скорректировать их. Не поддавайтесь соблазну увеличить ограничение WIP просто потому, что команда постоянно его достигает. Не упустите возможность повысить производительность. Лучше всего делать это с помощью обучения команды и развития новых наборов навыков у каждого участника или через повышение эффективности в каком-то аспекте процесса разработки.
Цель 1. Научиться делить работу на отдельные задачи примерно равного объема. Разбивая на части требования и пользовательские истории, важно следить, чтобы на выполнение отдельной задачи уходило не более 16 часов. В итоге команда будет увереннее подходить к оценке сложности работы, и проблемных мест станет меньше. Ничто так не замедляет работу команды и не приближает ее к ограничениям WIP, как большая задача, препятствующая работе конвейера.
Если ограничения незавершенной работы выбраны командой правильно, время цикла для задачи снижается. Время цикла — это время, необходимое для выполнения задачи. Подробнее см. на нашей странице, посвященной показателям Agile.
Цель 2. Подбирать ограничения WIP в соответствии с навыками команды. В примере выше предполагается, что участники команды имеют схожий набор навыков. Если в команде есть специалисты, их участие может повлиять на ограничения незавершенной работы. Создайте отдельный статус для работы специалиста. Если в этом статусе будут возникать проблемы, используйте это как возможность пополнить набор умений участников команды навыками специалиста и повысить производительность всей команды.
Цель 3. Сократить простои. Если у какого-либо участника команды появилось свободное время, посоветуйте ему помочь коллегам на других этапах работы. Общая продуктивность команды повысится, а заодно и сотрудник чему-нибудь научится!
Цель 4. Сохранить здоровую культуру разработки. Ограничения незавершенной работы нужны не для того, чтобы разработчики спешили, опасаясь перегрузки на каком-либо этапе. Они нужны, чтобы поддержать устоявшиеся практики Agile-разработки, которые обеспечивают неизменное качество продукта и исправность базы кода.
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-лимит. Конспект подкаста Kanban Talks
Разбираем, что такое WIP-лимит, как определить его размер, кто его устанавливает и для каких элементов
Алекс Цыбульник
Всем привет! Сегодня мы с вами обсудим одну из практик Канбан-метода — это WIP-лимиты или ограничение количества выполняемой в данный момент работы.
Об авторе подкаста Kanban Talks
Алексей Цыбульник — акредитованный Канбан-коуч Kanban University (KCP), автор и ведущий подкаста Kanban Talks.
Гость подкаста — Алексей Пименов, аккредитованный тренер Kanban University, первый российский специалист уровня Accredited Kanban Consultant, преподаватель, тренер и консультант по Kanban Method.
Что такое WIP-лимит?
WIP (work in progress) — сколько задач находится в работе, сколько рабочих элементов находится в производственной системе. Например, у вас есть какая-то команда, и они реализуют какие-то запросы клиентов. WIP — это сколько этих запросов сейчас находится в работе.
WIP-лимит — это практика, когда мы ограничиваем количество проектов или задач в производственной системе.
И здесь есть ряд вещей, с которыми люди путаются.
WIP ≠ WIP-лимит. WIP — это сколько всего рабочих элементов находится в системе. WIP-лимит — ограничение числа рабочих элементов в системе для достижения определенной цели.
WIP-лимиты не должны быть маленькими. Его размер зависит от ваших целей. Например, ваша цель — сократить время производства. Не факт, что для ее достижения вам надо сделать этот лимит как можно более маленьким. Но само наличие лимита — это уже хорошо.
Не существует универсальной формулы расчёта WIP-лимита. Нельзя взять и скопировать WIP-лимиты из одного подразделения в другое, и чтобы всё заработало. Они находятся эмпирическим путём на основании анализа потока и подбираются под некоторую оптимизационную цель.
Для колонки «Пишем» установлен WIP-лимит в 4 карточки. В Кайтене можно установить WIP-лимит для колонки, дорожки или ячейки
Какую выгоду получает организация и сотрудники от использования WIP-лимитов?
Предсказуемость. Первое, что мы получаем, это мы убираем некоторую рандомность времени производства по рабочим элементам. У нас появляется нечто, что можно назвать предсказуемостью системы. Работая с WIP-лимитом, мы можем эту предсказуемость повысить, либо понизить в зависимости от того, что нам нужно.
Защита от выгорания на персональном либо командном уровне. С лимитами у вас появляется некоторое время, когда вы можете отдохнуть, порефлексировать над рабочим процессом и качеством работы, и т.п. В общем, работать без цейтнота и перегрузки.
Попробуйте Kaiten бесплатно и улучшите свою продуктивность
Как определить WIP-лимит на уровне команды?
На уровне команды или отдела я рекомендую действовать следующим образом. Попробуйте посчитать, сколько работы находится у команды сегодня, вчера, позавчера и т.п. Нарисуйте график, и вы увидите, что этот график скачет: когда-то у нас работы больше, когда-то у нас работы меньше. Но, например, за последний год объём работы не превышал какого-то порога.
Если проанализировать, почему объём работы не превышал какого-то значения, то вы найдёте 3 причины:
Если рассмотреть с этой точки зрения, то WIP-лимит у вас уже есть. Это какое-то внутреннее чувство, то, что называют gut feelling. Дальше встает вопрос о легализации этого лимита, чтобы где-то была записана эта цифра. Если сделать так, то не будет больно ни заказчикам, ни вам.
Как понять, что можно уменьшить WIP-лимит?
Проводить собрания и на них просматривать задачи в работе. В первую очередь смотрим те, которые ближе к закрытию, потом остальные. Если в ходе такого просмотра вы понимаете, что в системе находятся рабочие элементы, которые давно не трогали, то значит есть превышение количества работы в системе, WIP-лимит можно легко понизить.
Если я хочу посмотреть максимальный WIP-лимит по команде, какой отчет мне нужен в таск-трекере?
CFD (cumulative flow diagram) или накопительная диаграмма потока. То есть у вас должны быть обозначены этапы, где команда начинает работу, и где заканчивает. Накопительная диаграмма потока, его высота в штуках задач будет показывать, сколько у нас незавершённой работы сейчас находится в системе.
Пример накопительной диаграммы потока в Кайтене
Кто принимает решение по увеличению или уменьшению лимитов в end to end системе?
Зависит от ситуации. Вот у нас есть некоторый end to end процесс. И стоит задаться вопросом, кто отвечает за то, чтобы задача, попавшая в end to end процесс, получилась с предсказуемым результатом и в рамках бюджета заказчика?
Может получиться так, что поднимет руку продакт-менеджер, руководитель департамента или кто-то ещё. Вот тогда этот человек будет ответственен за оптимизацию производственного процесса и изменение WIP-лимита.
Может быть ситуация, когда никто руку не поднял. Тогда нужно найти сотрудника в компании или нанять нового, дать ему формальную власть над участниками этого end to end процесса. И он будет отвечать за изменение WIP-лимита и за результат. В Канбане это роль service delivery manager, читайте про нее в предыдущем выпуске конспектов.
А может быть ещё альтернативная история, когда есть групповая ответственность. Например, в Скраме за то, что будет сделано, отвечает вся скрам-команда. В этом случае роль service delivery manager выполняет группа людей, и они должны будут принять решение по изменению WIP-лимитов.
Как использовать WIP-лимиты в проектном управлении?
Декомпозировать проект на элементарные требования, которые должны быть сделаны. Эти требования должны быть по некоторому производственному процессу, который требует в начале детального анализа, по требованию реализации, интеграции, тестирования и т.п.
За декомпозицию и оптимизацию процесса, в том числе и за назначение WIP-лимитов, будет отвечать проджект-менеджер. По сути в этом производственном процессе он выполняет роль service delivery manager.
Для каких элементов следует использовать WIP-лимиты?
Давайте попробуем поразмыслить, возьмём 3 сущности: epic, story и task.
Если мы начнём ставить WIP-лимиты на task, мы получим производственную систему, в которой мы будем предсказуемо завершать task разного вида с разными классами обслуживания.
Если мы начнём вводить WIP-лимиты на story, то это будет полезно, потому что мы получаем предсказуемый клиентский сервис. То есть мы можем давать достоверные прогнозы для заказчика, когда будет сделано то, что ему нужно.
Если мы введём WIP-лимит на epic, то точно также мы получим предсказуемость по стратегическим проектам.
С чего начинать внедрение WIP-лимитов?
— Если есть культура вовлечения, поддержки и ответственности, то сформировать коллективный совещательный орган, который будет анализировать данные и принимать решения по установке WIP-лимитов.
— Если культуры нет, то установить эти лимиты на основании своего управленческого решения.
Что делать, если WIP-лимиты нарушаются?
Если какой-то руководитель установил WIP-лимит, и вы тайком от него нарушаете это правило, то это сигнал, что при установке лимита что-то не учли, кто-то не был услышан. Нужно разбираться.
Если вы лимиты нарушаете прям в открытую и на регулярной основе, то грош цена вашим договоренностям и решениям. Это не очень хорошая история. Проще отменить эту практику и работать без нее.
Я меняю лимиты на уровне команд в момент, когда кто-то из команды уходит в длительный отпуск или на больничный. Так можно?
Я бы лимиты не привязывал к численности команды. У вас есть статистика, которая собирается по завершённым рабочим элементам за достаточно длительный промежуток времени. Она уже учитывает, что у вас постоянно кто-то болеет или в отпуске, учитывает ваш годовой процент замены людей. Любое изменение лимитов может нарушить эту статистику и вы по ней уже не сможете адекватно делать прогнозы.
Кроме того, если вы будете менять лимиты на ежедневной основе, то вы даже не ощутите эффекта от того, что они у вас есть.
Как с помощью WIP лимитов Kanban повысить эффективность работы отдела рекрутинга
Бытует мнение, что Kanban — это очень сложный метод. Действительно, в нем значительно больше различных нюансов, чем в том же Scrum. Но в этом и заключается его ценность — более обширная сфера применения и возможность влияния на большее количество аспектов управленческой работы, чем у его более популярного “конкурента”.
Тем не менее, пугающая многих сложность, на мой взгляд, сильно преувеличена. Все зависит от языка описания. Этой статьей я начинаю серию публикаций, в которых подробно разберу каждый из инструментов Kanban. По возможности максимально простым языком и на примерах не из мира IT.
Заранее оговорюсь: я — консультант, управленец и специалист в Kanban. Все кейсы для статей буду брать из опыта своих клиентов. Поэтому не готов буду спорить о профильных аспектах обсуждаемых процессов. Что клиент у себя построил, с тем и работаем 🙂
Сегодня на примере отдела рекрутинга поговорим о необходимости ограничивать объем одновременно выполняемой работы (Work in progress limits). Одном из основных условий внедрения Kanban.
Как чаще всего выглядят стадии найма персонала в компании среднего размера?
От “бизнеса” поступают заявки на закрытие различных вакансий. По мере возникновения они сыпятся в общий Беклог работы отдела рекрутинга. Далее, в зависимости от профиля позиции и правил компании, в различной последовательности могут проходить этапы поиска и отбора резюме, проверки кандидатов службой безопасности, первичного интервью, ряда профильных интервью со специалистами компании и финальное общение с руководителем.
Последовательность этапов для нас сейчас не столь важна. В каждой компании есть свои нюансы. Для нас важно понять как именно организован сам процесс работы над заявкой и что влияет на его эффективность.
Обычно все начинается с того, что наш рекрутер (назовем ее Леной) берет в работу заявки из общего списка отдела. Берет сама или их назначает руководитель, сейчас тоже не принципиально. Вопрос в том, какое количество заявок находится в работе у Лены одновременно?
Допустим, наша Лена — очень ответственный сотрудник. Она знает, что в текущий момент от разных департаментов поступило 10 заявок, каждая из которых является срочной и важной для бизнеса. Чтобы принести максимальную пользу компании, Лена принимает решение работать над всеми ними одновременно (М-многозадачность). Она расставляет приоритеты и начинает поиск резюме.
И тут возникает первый вопрос — совпадают ли расставленные Леной приоритеты с приоритетами компании?
И даже если эти приоритеты расставил ее руководитель, который осведомлен о них значительно лучше, у Лены, как у любого живого человека, могут быть позиции, которые ей нравятся больше остальных, и те, что меньше. Те, в которых она — спец, и те, в которых она “плавает”.
Поэтому, даже если приоритеты расставлены правильно, неосознанно Лена качественнее и быстрее обработает своих “фаворитов”, а остальные имеют большие шансы “зависнуть”.
Особенно такие “зависания” вероятны, если список задач Лены постоянно пополняется новыми “приоритетными” заявками от разного рода руководителей, которые она ответственно обрабатывает. При этом считая, что приносит максимально возможную пользу для компании.
Но так ли это на самом деле?
Есть ли в вашей компании явные правила приоритизации задач отдела рекрутинга? Или же, как обычно принято на постсоветском пространстве, приоритеты устанавливаются громкостью голоса и наличием “звезд на погонах”? Есть ли полная уверенность в том, что месяцами не закрывающиеся позиции уборщицы или грузчика, менее важны для бизнеса, чем найм маркетолога или финансиста? Как часто подобные вопросы обсуждаются в кругу руководителей смежных подразделений?
Устанавливая лимиты на каждую из стадий процесса, Канбан, для начала, помогает сделать текущую ситуацию более прозрачной, а затем начать ею лучше управлять.
Так, допустим, на стадию поиска резюме мы поставим ограничение в 3 заявки. Это означает, что наша Лена не может работать над более чем 3 вакансиями одновременно. Таким образом, приоритеты в ее работе становятся для всех более видимыми. И новую позицию в работу Лена может взять только в случае передачи на следующий этап одной из трех, уже находящихся в работе.
Это приводит к тому, что в отделе начинают накапливаться заявки из разных департаментов. Что порождает споры о том, какую заявку брать следующей? Достаточно ли у нас рекрутеров? Достаточно ли у них квалификации для закрытия всех возможных вакансий? Или нужно ввести разделение по специализациям между рекрутерами? Или, возможно, что-то тормозит работу Лены на последующих стадиях?
Узнать о блокерах на следующих стадиях мы можем, опять же, только в случае установки ограничений на объем выполняемой ими работы. Они не обязательно должны быть равны лимиту предыдущей стадии (хотя можно начать и с этого). Но должны быть обязательно. Иначе заявки будут уходить как в бездонную бочку. Люди будут работать, а с какой скоростью они эту работу выполняют и согласно каким приоритетам снова будет не ясно.
Допустим, следующим этапом после нахождения резюме у нас будет его проверка службой безопасности. Одна из самых длительных стадий процесса найма в большинстве компаний.
Если наша Лена действительно очень быстро находит нужные резюме и заваливает СБ кандидатами на проверку, то с введением WIP лимитов она будет часто простаивать в ожидании результатов. И это породит массу неудобных, но очень полезных для нас вопросов: чем занять Лену? может ли она помочь кому-то на следующих стадиях? не слишком ли длительны наши процессы проверки кандидатов? достаточно ли у нас ресурса СБ? возможно ли провести доп обучение для рекрутеров, чтобы они могли самостоятельно отсеивать часть кандидатов без помощи специалистов службы безопасности? и т.д…
Таким образом, шаг за шагом мы можем выявлять все больше изъянов нашей системы и находить для них соответствующие решения.
Но самое главное, установка WIP лимитов дает возможность начать замерять время прохождения заявки через всю нашу процедуру найма и управлять скоростью ее закрытия за счет уменьшения или увеличения WIP лимитов на разных стадиях.
Также подобные замеры могут дать нам дополнительный инструментарий для косвенного влияния на весь процесс. У нас появляются оцифрованные аргументы, чтобы объяснить руководителям, как задержки на их стадиях влияют на скорость закрытия вакансий по всей компании.
Так, на моей памяти, СЕО одной достаточно крупной организации, одним росчерком пера сократил время закрытия вакансий по всей компании на 30%, после того как узнал, что 40% времени кандидаты ждут собеседований и финальных решений от сотрудников первой линии его подчинения. Без этих цифр руководитель отдела рекрутинга пыталась достучаться с этой проблемой до ТОПов больше года!
Но если все так “ровно и гладко”, то почему, спросите вы, этим инструментарием пользуется так мало компаний?
Из-за страха простоев и тех неудобных разговоров, которые порождают вопросы, приведенные выше.
В нашей культуре не принято “выносить сор из избы”. Нам проще закрыть глаза на неэффективность того или иного процесса, чем вызвать на неприятный разговор коллегу из соседнего отдела. Мы надеемся, что они сами поймут и обязательно исправятся, а это происходит крайне редко.
Я привел в статье множество вопросов. Но не дал ни одного ответа. Я сделал это умышленно, поскольку ответы зависят от реалий каждой конкретной ситуации.
Канбан — это не панацея и не волшебный метод решения проблем. Но при желании с его помощью можно сделать более явными основные изъяны любого процесса и начать планомерно их исправлять.
Об остальных инструментах в следующих статьях. Подписывайтесь на обновления!