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

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

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

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

 

 

 

 

 

 

 

 

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

«DevOps: современный подход к организации работы ИТ»
Учебный курс про менеджмент, а не про технические практики

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

  • Сергей

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

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

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

      • Сергей

        Олег, спасибо за уточнение, но хотелось бы уточнить, ситуаций может быть много.

        Простое решение сразу «выбросить» — не всегда применимо.

        Выявлены новые обстоятельства оценка которых занимает время и выбрасывать сразу нельзя (анализ взаимосвязи либо сложен\долог, либо из-за приоритетности отложен на попозже).

        Ценность в любом случае создаётся (и в наборе опыта и разборе как брать меньше глупостей и в выпуске наиболее оптимального\безопасного продукта ... в том числе все те вопросы которые Вы задали).

        Занятие «ценного слота» — не основная цель потока, что бы избавляться в нём (потоке) от «отложено», несмотря на то что это действительно похоже на статус в процессе.

        Хотелось бы услышать ваше мнение с учётом описанных обстоятельств.

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

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

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

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

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

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

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

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

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

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

      А вот про дефекты не очень понял.


Добавить комментарий

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
    • 5 основных тенденций развития искусственного интеллекта и машинного обучения на 2022 год
      Вот несколько основных тенденций, к которым вашему бизнесу стоит начать готовиться. Искусственный интеллект и машинное обучение становятся доминирующей частью технологической
    • 6 тенденций в ИТ, за которыми нужно следить
      Чтобы выжить во время пандемии, организации обратились к ИТ, чтобы помочь справиться с последствиями - как негативными, так и позитивными. В некоторых отраслях, таких как телемедицина и видеоконференции, бизнес резко вырос, и ИТ-отделам таких компаний пришлось в спешке справляться с нагрузкой. В других, например, в сфере путешествий и развлечений, бизнес резко просел. Кроме того, возобновилось стремление к цифровой трансформации.
    • Восход Desktop-as-a-Service: что это такое и зачем вам это нужно?
      Широкое распространение облачных вычислений добавило в наш словарь множество сокращений, наиболее распространенными из которых являются SaaS, PaaS и IaaS. Действительно, наступила эра облачных решений, которые доставляют программное обеспечение, платформу и инфраструктуру потребителям и предприятиям по запросу и с оплатой по мере использования.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT