Как уменьшить влияние блокировщиков на сроки поставки с помощью кластеризации блокировщиков

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

Определите ваши блокировщики

Первый шаг к оценке препятствий, мешающих продвижению вашей работы, — это выявление ваших блокировщиков.

В тот момент, когда элемент работы блокируется, подумайте о причине этого и определите, что мешает работе.

Соберите все блокировщики и организуйте их в группы. Группы могут быть такими, как External Dependency (внешняя зависимость), Internal Dependency (внутренняя зависимость) или Expedite Request (ускорить запрос).

Создайте настраиваемое поле на вашей доске, например, Blocked Reason (причина блокировки), и добавьте в него группы, которые вы определили, в качестве вариантов. Теперь, когда новый элемент блокируется, вы можете связать его с любым из ваших блокировщиков. Вы также можете модифицировать настраиваемое поле, чтобы включить новые группы блокировщиков и поддерживать его в актуальном состоянии.

Зафиксируйте общее время блокировки

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

Наша Cycle Time Breakdown Chart (диаграмма разбивки времени цикла) автоматически собирает эту информацию, чтобы помочь вам определить блокировщик, который больше всего увеличивает ваше время доставки.

Определите коренные причины наиболее влиятельных блокировщиков

Какие возможные решения мы можем предложить для устранения этих препятствий? Очень эффективная техника, которую вы можете использовать, чтобы выяснить коренную причину проблем, — это подход 5 Why’s (5 почему). Вы задаёте вопрос «почему» несколько раз, и каждый ответ приводит вас к следующему вопросу в цепочке.

Например, Blocked reason: Unclear Requirements (причина блокировки: неясные требования). Почему требования предположительно неясны? Потому что не было предоставлено описание того, что должно быть доставлено. Почему это так? Потому что нет чётких требований к тому, как должна быть структурирована карта, прежде чем она будет добавлена в систему.

Управляйте дефектами так же, как и блокировщиками

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

Дефекты программного обеспечения часто являются основным препятствием на пути к раскрытию всего потенциала нашего решения на рынке. Дефекты обходятся дорого, особенно когда они попадают в производство. Проблемы, связанные с разработкой качественных программных решений, такие как постоянный рыночный спрос и нехватка времени, останутся. Стоимость дефектов, скорее всего, возрастёт, если мы не будем постоянно совершенствовать наши методы разработки.

Внедрение пределов WIP (Work In Progress)

Внедрение пределов WIP — это один из самых мощных подходов к сокращению времени доставки за счёт согласования спроса с возможностями и концентрации внимания на наиболее важной работе.

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

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

Принятие пределов WIP — это настоящий прорыв

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

Вы можете увидеть, как это работает на концептуальном уровне, взглянув на Little’s Law (закон Литтла). Уравнение закона Литтла связывает три основные метрики потока — время цикла, пропускную способность и объём работы в процессе, и способ, которым каждый компонент влияет на другие, является очевидным.

Проблема внедрения пределов WIP

Основная цель наличия пределов WIP — stop starting and start finishing (прекратить начало и начать завершение). Идея состоит в том, чтобы уменьшить спрос до уровня, соответствующего возможностям команды. Таким образом, команда будет работать только с таким количеством элементов, с которым она может справиться за один раз, что предотвратит искусственное старение текущей работы.

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

Переключение направления разговора

Умный способ подойти к ситуации, прежде чем вы даже начнёте говорить о внедрении пределов WIP, — это привести вашу команду к взаимному согласию относительно того, как они выбирают, какую работу взять на себя следующей. Для процесса разработки это может быть явная политика, которая выглядит так:

* После завершения работы вместо того, чтобы сразу же взять новый элемент из бэклога, сначала просмотрите карты на доске. Начните с самого правого столбца (того, который находится перед «Готово»), затем двигайтесь к началу рабочего процесса.
* Ищите элементы, которые никому не назначены, любые проблемы, которые необходимо исправить (даже если они не назначены вам), всё, что ждёт проверки кода или реализации обратной связи из проверки кода.
Новая работа должна быть начата только в том случае, если буквально ничего* не мешает продвижению текущих элементов работы в процессе.

Сосредоточьтесь на результатах

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

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

1. Какие методы предлагает статья для выявления и анализа блокировщиков, влияющих на сроки поставки?

В статье предлагается несколько методов для выявления и анализа блокировщиков:
* Определение блокировщиков: выявление всех элементов, которые блокируют работу, и организация их в группы (например, External Dependency, Internal Dependency, Expedite Request).
* Фиксация общего времени блокировки: подсчёт общего количества дней, в течение которых работа была заблокирована, и разделение этих данных по каждой из причин блокировки.
* Определение коренных причин наиболее влиятельных блокировщиков: использование подхода 5 Why’s (5 почему) для выявления коренных причин проблем.

2. Какие группы блокировщиков можно выделить при кластеризации?

При кластеризации блокировщиков можно выделить следующие группы:
* External Dependency (внешняя зависимость);
* Internal Dependency (внутренняя зависимость);
* Expedite Request (ускорить запрос).

3. Какие проблемы могут возникнуть при внедрении пределов WIP и как их можно решить?

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

4. Какие преимущества даёт внедрение пределов WIP?

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

5. Какие рекомендации даёт статья для эффективного управления блокировщиками и дефектами?

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

Источник