Портал №1 по управлению цифровыми
и информационными технологиями

Шаг “Отложено” в потоке создания ценности

Рассмотрим простейший поток создания ценности:

На ваш взгляд, что в этом потоке не так? Подумайте, и когда будете готовы – листайте ниже.

 

 

 

 

 

 

 

 

 

 

Ответ бросается в глаза – один из шагов отличается от других. Опциональный шаг “Отложено” подразумевает, что задача, двигающаяся по потоку, может встать на паузу после этапа “В работе”, но до этапа “Проверка”. Причины этой паузы из схемы не ясны, но шаг “Отложено” даже визуально, из-за подписи “(опционально)”, уже выглядит инородным. Однако проблема не в инородности. Проблема в том, что на схеме изображён не поток создания ценности, а что-то иное: бизнес-процесс, workflow, схема состояний (статусов)… Но не поток.

Чтобы сделать картинку нагляднее, перерисуем её немного в другом виде:

Так стало более привычно, и больше нет претензии на поток.

Отчего же я так прицепился к этому слову – отложено? Что с ним не так?

С ним всё в порядке, если мы организуем работу какого-нибудь коллектива как процесс. Вполне легитимный шаг, вполне нормальная история: задачу взяли в работу, потрудились над ней, затем по какой-то причине трудиться дальше не можем, перевели в статус “Отложено”. Потом, через какое-то время, продолжим, а пока поработаем над другими задачами.

С ним всё очень не в порядке, если мы организуем работу такого же коллектива как поток. В этом случае этапа “Отложено” быть не может, и на то есть следующие основания.

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

Второе: теряется фокус на необходимости завершения того, что взяли в работу. Сколько времени задача может быть отложенной? Зачастую – неограниченное время. Команда даже придумает какое-то объяснение, задействуя мистические внешние силы, почему без такого шага никак не обойтись: смежники работают медленно, заказчик не предоставляет требуемую информацию, руководитель не принимает необходимое решение… Кто-то снаружи не даёт нам работать, при чём тут мы? Мы отложим, пока они не пошевелятся. Ожидание становится нормой. Mindset, простите за слово, иной. По процессу так можно, по потоку – нет. По потоку, после прохождения точки входа (точки принятия обязательств) команда должна поскорее исполнить взятые обязательства, а не откладывать их.

Третье: теряется предсказуемость. Как было описано выше, в статусе “Отложено” задача может провести неопределённое время. Равно как и понять по конкретной задаче – попадёт она в этот статус или нет – заранее невозможно, либо никто это не делает. Таким образом, на вопрос “когда примерно это будет сделано” не получается более-менее осмысленно ответить ни для отложенных задач, ни для всех остальных задач. А отсюда следующий шаг – к дедлайнам. Ведь если поток непредсказуем с точки зрения времени выдачи результата, то любой эффективный менеджер будет пытаться управлять через жёсткие сроки. А поток жёсткие сроки не очень любит, мягко говоря.

Четвёртое: теряется скорость. Цепочка рассуждений такова: отложенная задача занимает слот в потоке, который нельзя отдавать другим задачам. Таким образом, либо в потоке движется меньшее количество задач (что вряд ли возможно ввиду сохранения давления на входе), либо идея слотов будет заброшена. Нет слотов – нет WIP-лимитов. Нет WIP-лимитов – нет вытягивающей системы. Нет вытягивающей системы – нет потока. Нет потока – нет работы на высокой скорости.

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

Шестое: отложенная задача постепенно протухает, а у команды теряется контекст. С каждым днём нахождения в статусе “Отложено” задача становится всё менее актуальной, нужной. Результат постепенно теряет ценность (в этот момент любители бережливого производства громко скажут лозунг “Незавершёнка есть потери!”). Кроме того, с каждым днём тот, кто работал над отложенной задачей, всё меньше помнит что это за задача, кому и зачем нужна, как конкретно была сделана, почему отложена, что осталось сделать, и как потом починить то, что выйдет, наконец, из потока, потому что работать оно не обязано. Следствие такого подхода – попытка играть в управление дефектами. Ну то есть: категоризировать дефекты, ставить их в очередь, отличать критичные от некритичных, спорить до хрипоты про конкретные ситуации (является дефектом или нет?), терять время и деньги.

Просуммируем вышеизложенное. Наличие в потоке создания ценности такого шага, как “Отложено”, делает из потока процесс. В зависимости от контекста и поставленной задачи это не обязательно плохо, однако если хочется организовать именно поток – то очень плохо, потому что:

  1. даёт импульс к появлению таких дисфункций, как размытая ответственность, повышенные требования к контролю, управление через крайние сроки, управление дефектами;
  2. смещает фокус от создания ценности к выполнению работы (все всегда очень загружены, а результаты так себе);
  3. является более медленным по способу производства.

Понять есть ли такая проблема в вашем потоке очень просто – достаточно его картировать. Мы можем помочь с этим упражнением, делали его не раз в разных командах. Напишите нам на info@cleverics.ru и мы запланируем семинар для вашей команды.

Вопросы потокового управления мы обсуждаем на учебном курсе “DevOps Foundation“. Приходите.

PS. Вообще тема отличия потока создания ценности от бизнес-процесса немного более глубокая. Я рассмотрел лишь один аспект, но есть и ещё соображения.

PPS. Мы рассмотрели слово “отложено”. А каковы будут рассуждения для слова “заблокировано”? Оставим это домашним заданием.

 

«Kanban Flow Metrics: управление потоковым производством на основе данных»
Тренажёр про метрики на реальных примерах

Комментариев: 7

  • Сергей

    Олег, доброго.

    Если отнестись к “отложенной” задаче в потоке как “нереализованная глупость” – тоже ценность, или “отложенная по приоритету ценность – тоже ценность”, это может сказаться на том что наличие в потоке такого механизма как “Отложено” оценивается как “очень плохо”?

    • Сергей, добрый день. Если я правильно понял, Вы говорите про ситуацию “взяли задачу, поработали над ней, решили, что зря взяли, потому отложили”. Если так, то мне кажется более разумным такую задачу выбросить (в discard). Тогда всем будет понятно, что над ней работать больше не планируем. Задача не будет занимать ценный слот. Команда может провести анализ – как часто выбрасываем? Почему? Можно ли научиться брать в работу меньше глупостей? На конкретных примерах это упражнение может быть и несложным, и полезным.

      • Сергей

        Олег, спасибо за уточнение, но хотелось бы уточнить, ситуаций может быть много.
        Простое решение сразу “выбросить” – не всегда применимо.
        Выявлены новые обстоятельства оценка которых занимает время и выбрасывать сразу нельзя (анализ взаимосвязи либо сложен\долог, либо из-за приоритетности отложен на попозже).
        Ценность в любом случае создаётся (и в наборе опыта и разборе как брать меньше глупостей и в выпуске наиболее оптимального\безопасного продукта … в том числе все те вопросы которые Вы задали).
        Занятие “ценного слота” – не основная цель потока, что бы избавляться в нём (потоке) от “отложено”, несмотря на то что это действительно похоже на статус в процессе.
        Хотелось бы услышать ваше мнение с учётом описанных обстоятельств.

        • Сергей, по Вашему комментарию у меня есть такие соображения.

          Предположим, что специалист на определённом этапе потока приступил к очередной задаче, но выяснил, что завершить её не может. Например, задача оказалась слишком сложной, или зависит от других, или открылись новые, неизвестные ранее обстоятельства. Сразу выбрасывать в discard не хочется, но и держать её “в работе” вечно тоже как-то странно. В таком случае, на мой взгляд, нет ничего плохого, если специалист переключится на другую задачу, а к этой вернётся чуть позже. В конце концов, на этапах WIP-лимит не обязательно ставится из расчёта “одна задача на одного человека”, да и в целом – привязывать жёстко специалистов к этапам не всегда нужно и не всегда полезно. Главный вопрос – как надолго задача осталась без внимания? Если это небольшая часть от System Lead Time (ну или Cycle Time, не в названии дело – времени от входа до выхода из системы), то большой проблемы в ожидании нет, и отдельный статус “Отложено” не требуется. Если же такая задержка сравнима с System Lead Time, а то и превышает его – вот здесь уже начинаются неприятности, которые я описывал в заметке.

          Вторая мысль по Вашему комментарию – похоже, мы по-разному понимаем слово “ценность”. Для меня, если мы говорим про поток создания ценности, а не понятие “ценность” в общем смысле, то приобретение специалистами опыта не является ценностью. Поток выстраивается не для того, чтобы все исполнители учились, а чтобы предоставлять что-то ценное *клиенту*. Что не отрицает необходимости обучения персонала, разумеется.

          И ещё, я полностью с Вами согласен, что занятие слота не является целью потока. Поток не нужен, чтобы управлять слотами. Это слоты нужны, чтобы организовать поток. И если слоты не работают, то и с потоком может быть беда.

    • Если же речь про ситуацию “работаем над задачей, но тут прилетает более ценная, поэтому исходную задачу отложили”, то я являюсь противником переприоритизации. Нет такой необходимости – решать внутри потока про ценность задач и очередь. Это уже было решено на входе в поток. А если задачи небольшие и пролетают быстро, то и совсем не нужно переприоритизировать.

  • Александр Жилинский

    >Следствие такого подхода — попытка играть в управление дефектами.

    Все-таки управление дефектами это сформировашееся понимание у ряда activities, и не только itsm.

    А дополнить хотел, что даже в случае процессе – блокировка через “Ожидание” играет худшую роль freeze\hide. Не по конкретной задаче, а по чужим деятельностям вне процесса (участники незрелых процессов по дефолту считают, если вне то значит “не наше”, то и оптимизировать не стоит).

    • Саша, привет. Про смещение локуса согласен, ценное замечание.
      А вот про дефекты не очень понял.


Добавить комментарий для СергейОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM