О WIP-лимитах замолвите слово

В этой статье я хочу разобраться почему же проваливается использование такой практики как “Ограничение количества незавершенной работы” или как их называют еще wip-лимиты. В данной статье я буду разбирать эту проблему на примере самой распространенной причине провала.

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

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

Данная статья предназначена тем, кто понимает, что инструменты можно применять по-разному, а на ошибках можно и нужно учиться.

Итак. Поехали. Самая распространенная проблема провала внедрения Kanban и по совместительству использования WiP-лимитов в других гибких методологиях.

Работаем с подзадачами, а не пользовательскими историями

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

Визуализируя работу команды, неофиты часто совмещают на одном уровне задачи, которые несут ценность для Заказчика, с задачами, которые имеют ценность только внутри процесса. Почему совмещают? В основном потому, что не могут изменить въевшуюся парадигму “мне поставили задачу – я делаю задачу – я сделал задачу”, которая не требует задумываться о ценности выполняемой работы, ведь “Начальник же подумал, раз поставил задачу”.

В итоге на одном управленческом уровне мы получаем:

• “Сделать MVP продукта” – задача имеет ценность для Заказчика, так как пользователь получит то, что сможет использовать.
• “Провести нагрузочное тестирование” – не является самостоятельной задачей, а нужна для прогресса другой.
• “Заключить контракт с поставщиком АБВ” – тоже не может быть самостоятельной задачей.
• “Реализовать функционал голосового ввода” – задача необходимая чтобы пользователь мог использовать продукт.

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

Рассмотрим ситуацию на конкретном примере. Приходит менеджер и говорит, что задача “Реализовать функционал голосового ввода” имеет более высокий приоритет чем “Проведение нагрузочного тестирования”, поэтому бросаем вторую и берем в работу первую. По-началу все вроде бы идет складно пока не оказывается, что реализовать функционал голосового ввода не получается без проведения нагрузочного тестирования. Задача блокируется и ждет когда же мы закончим проводить нагрузочное тестирование. Но не тут-то было. Лимит-то заполнен! Как гласит теория – чтобы взять задачу в работу, надо завершить предыдущую. Текущая задача бросается, внимание переключается на другую, и как итог заказчик не получает никакого результата. Заказчик недоволен, время на реализацию уходит больше, менеджмент тоже недоволен, так как стало хуже чем было. Итог – практика плохая, инструмент – отстой.

А что же делать-то? Ну во-первых – разделить уровни управления и понимать какой уровень управления какие проблемы решает.

Какие есть уровни управления:

• Задача требует для реализации работ одного сотрудника:
  • для снятия перегрузки вводятся персональные лимиты. В этом случае учитывается мнение исполнителя – так как задачи предстоит выполнять конкретному сотруднику.
• Задача требует выполнения на командном уровне:
  • лимиты на систему/команду/сервис (Бэклог спринта)
  • лимиты на тип задач (Квотирование)
  • лимиты на этап (Работа с узкими горлышками)
  • более редкие типы ограничений возникающие в частных случаях в зависимости от проектов и их специфики.

При этом на задачи необходимо смотреть глазами Заказчика. Для этого вводится такое понятие как Customer recognizable item – объект глядя на который Заказчик понимает, что именно он заказывал и может понять что же происходит с его заказом.

• Работы на уровне портфеля
  • Для эффективного распределения ресурсов при реализации портфеля инициатив, используются лимиты на объекты портфеля

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

Как итог, хочу выделить три основные вещи, которые помогут вам получить положительный опыт от внедрения WiP-лимитов:

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

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

При написании статьи использовался материал WIP-лимиты здорового человека и WIP-лимиты курильщика Дениса Бартоломе.