Рассмотрим простейший поток создания ценности:
На ваш взгляд, что в этом потоке не так? Подумайте, и когда будете готовы – листайте ниже.
Ответ бросается в глаза – один из шагов отличается от других. Опциональный шаг “Отложено” подразумевает, что задача, двигающаяся по потоку, может встать на паузу после этапа “В работе”, но до этапа “Проверка”. Причины этой паузы из схемы не ясны, но шаг “Отложено” даже визуально, из-за подписи “(опционально)”, уже выглядит инородным. Однако проблема не в инородности. Проблема в том, что на схеме изображён не поток создания ценности, а что-то иное: бизнес-процесс, workflow, схема состояний (статусов)… Но не поток.
Чтобы сделать картинку нагляднее, перерисуем её немного в другом виде:
Так стало более привычно, и больше нет претензии на поток.
Отчего же я так прицепился к этому слову – отложено? Что с ним не так?
С ним всё в порядке, если мы организуем работу какого-нибудь коллектива как процесс. Вполне легитимный шаг, вполне нормальная история: задачу взяли в работу, потрудились над ней, затем по какой-то причине трудиться дальше не можем, перевели в статус “Отложено”. Потом, через какое-то время, продолжим, а пока поработаем над другими задачами.
С ним всё очень не в порядке, если мы организуем работу такого же коллектива как поток. В этом случае этапа “Отложено” быть не может, и на то есть следующие основания.
Первое и главное: на этом шаге не создаётся ценность. К задаче, над которой мы работаем, не добавляется ничего, что подвигает эту задачу ближе к конечному результату. Что, повторюсь, допустимо для процесса, но совсем не хорошо для потока.
Второе: теряется фокус на необходимости завершения того, что взяли в работу. Сколько времени задача может быть отложенной? Зачастую – неограниченное время. Команда даже придумает какое-то объяснение, задействуя мистические внешние силы, почему без такого шага никак не обойтись: смежники работают медленно, заказчик не предоставляет требуемую информацию, руководитель не принимает необходимое решение… Кто-то снаружи не даёт нам работать, при чём тут мы? Мы отложим, пока они не пошевелятся. Ожидание становится нормой. Mindset, простите за слово, иной. По процессу так можно, по потоку – нет. По потоку, после прохождения точки входа (точки принятия обязательств) команда должна поскорее исполнить взятые обязательства, а не откладывать их.
Третье: теряется предсказуемость. Как было описано выше, в статусе “Отложено” задача может провести неопределённое время. Равно как и понять по конкретной задаче – попадёт она в этот статус или нет – заранее невозможно, либо никто это не делает. Таким образом, на вопрос “когда примерно это будет сделано” не получается более-менее осмысленно ответить ни для отложенных задач, ни для всех остальных задач. А отсюда следующий шаг – к дедлайнам. Ведь если поток непредсказуем с точки зрения времени выдачи результата, то любой эффективный менеджер будет пытаться управлять через жёсткие сроки. А поток жёсткие сроки не очень любит, мягко говоря.
Четвёртое: теряется скорость. Цепочка рассуждений такова: отложенная задача занимает слот в потоке, который нельзя отдавать другим задачам. Таким образом, либо в потоке движется меньшее количество задач (что вряд ли возможно ввиду сохранения давления на входе), либо идея слотов будет заброшена. Нет слотов – нет WIP-лимитов. Нет WIP-лимитов – нет вытягивающей системы. Нет вытягивающей системы – нет потока. Нет потока – нет работы на высокой скорости.
Пятое: отложенная задача мешает другим задачам. Находясь в потоке (пройдя через вход, но не пройдя через выход), отложенная задача создаёт неравномерность течения. Неравномерность – один из самых неприятных видов потерь: неосязаемый, но сильно влияющий. Влияющий на всё, что проходит через поток, на все задачи. В первую очередь замедляющий их все.
Шестое: отложенная задача постепенно протухает, а у команды теряется контекст. С каждым днём нахождения в статусе “Отложено” задача становится всё менее актуальной, нужной. Результат постепенно теряет ценность (в этот момент любители бережливого производства громко скажут лозунг “Незавершёнка есть потери!”). Кроме того, с каждым днём тот, кто работал над отложенной задачей, всё меньше помнит что это за задача, кому и зачем нужна, как конкретно была сделана, почему отложена, что осталось сделать, и как потом починить то, что выйдет, наконец, из потока, потому что работать оно не обязано. Следствие такого подхода – попытка играть в управление дефектами. Ну то есть: категоризировать дефекты, ставить их в очередь, отличать критичные от некритичных, спорить до хрипоты про конкретные ситуации (является дефектом или нет?), терять время и деньги.
Просуммируем вышеизложенное. Наличие в потоке создания ценности такого шага, как “Отложено”, делает из потока процесс. В зависимости от контекста и поставленной задачи это не обязательно плохо, однако если хочется организовать именно поток – то очень плохо, потому что:
- даёт импульс к появлению таких дисфункций, как размытая ответственность, повышенные требования к контролю, управление через крайние сроки, управление дефектами;
- смещает фокус от создания ценности к выполнению работы (все всегда очень загружены, а результаты так себе);
- является более медленным по способу производства.
Понять есть ли такая проблема в вашем потоке очень просто – достаточно его картировать. Мы можем помочь с этим упражнением, делали его не раз в разных командах. Напишите нам на info@cleverics.ru и мы запланируем семинар для вашей команды.
Вопросы потокового управления мы обсуждаем на учебном курсе “DevOps Foundation“. Приходите.
PS. Вообще тема отличия потока создания ценности от бизнес-процесса немного более глубокая. Я рассмотрел лишь один аспект, но есть и ещё соображения.
PPS. Мы рассмотрели слово “отложено”. А каковы будут рассуждения для слова “заблокировано”? Оставим это домашним заданием.
Олег, доброго.
Если отнестись к “отложенной” задаче в потоке как “нереализованная глупость” – тоже ценность, или “отложенная по приоритету ценность – тоже ценность”, это может сказаться на том что наличие в потоке такого механизма как “Отложено” оценивается как “очень плохо”?