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

Все говорят: «Поток!». А ты построй поток

«А это была совсем не шляпа. Это был удав, который проглотил слона. Тогда я нарисовал удава изнутри, чтобы взрослым было понятнее.»
Антуан де Сент-Экзюпери, Маленький принц

Переход к продуктовым командам и организация работы по потоку – то, что происходит во многих компаниях, которым важна скорость поставки при создании/изменении цифровых продуктов. При этом необходимо произвести серьёзные изменения в разных областях функционирования компании.

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

Например, опыт проведения тренингов и игр на тему DevOps показывает, что понятие потока укладывается не всегда сразу. А иногда укладывается странным образом.

Казалось бы, всё просто. Поток – последовательность шагов, которая приводит к созданию ценности. И мы смело рисуем карту потока создания ценности (Value Stream Map) в виде набора «квадратиков со стрелочками». Как-то так:

Но что там, в квадратиках?

Как вам, например, следующий поток? Ничего не смущает?

Мне кажется, что здесь слишком большое количество этапов, которые обеспечивают создание ценности, относительно количества тех, на которых эта самая ценность создаётся. Считаю ли я, что эту «поддерживающую» деятельность нет нужды выполнять? Нет, не считаю. Боле того, допускаю, что в каких-то случаях нам понадобится подобная карта потока. Но то, на что я пытаюсь обратить внимание этой картинкой – это заметное смещение фокуса с ценности на что-то другое.

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

Copyright © 2017, The Open Group. All rights reserved.

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

 1.  «Поток», в котором шагами является любая деятельность. Так получается, когда мы просто перечисляем всё, что мы традиционно делаем в рамках решения анализируемых задач.

2.  Поток, в котором выделены шаги, на которых создаётся ценность.

В этом случае деятельность, которая обозначена как поддерживающая (например, мероприятия, направленные на обеспечение качества; решение вопросов, связанных с экономикой продукта; вопросы безопасности) «размазана» по всем этапам. Во всяком случае тот её объём, который должен выполняться в потоке.

Но здесь кто-то может возразить: «Позвольте! Этак вся продуктовая команда (на всех участках потока создания ценности) будет заниматься всеми аспектами продукта. Неужели имеется в виду именно такая ерунда?» Я бы ответил на этот вопрос положительно. Продуктовая команда отвечает за весь жизненный цикл продукта. За все его аспекты (а как иначе?). Следовательно, в предельном случае все участвуют во всех аспектах жизнедеятельности продукта. Понятно, что в реальной жизни у нас, несмотря на все эти модные T-shape, П-shape и Comb-shape профили специалистов, есть какая-то специализация. Есть уникальные знания и компетенции на каждом участке потока создания ценности. Но означает ли наличие специализации то, что, например, разработчик не отвечает за финансовую составляющую продукта (ведь он(а) просто пишет код)? По-моему, нет, если мы хотим, чтобы у нас была настоящая продуктовая команда.

Если эта мысль вызывает у вас дискомфорт, попробуйте другую. Означает ли специализация то, что, например разработчик не отвечает за качество продукта? Ведь он(а) «просто пишет код», а там, где-то дальше по потоку есть тестировщик(и) – там и будет обеспечено качество. Надеюсь, несуразность такого подхода в продуктовой команде проявляется более заметно.

И, если вовлечение все команды в реализацию «поддерживающей» деятельности не смущает, то, кажется, остаётся один вопрос. Как выделить этапы, которые относятся к «основному» потоку? На мой взгляд грубо можно сформулировать описание этой группы работы следующим образом. Это технические решения (архитектура, код), обеспечивающие удовлетворение как функциональных (FR), так и нефункциональных (операционных, NFR/OR) требований к продукту. Конечно, в рамках этой деятельности нужно будет согласовывать, общаться, принимать решения, и т.п. Поэтому вряд ли удастся с математической точностью определить, куда относить отдельно взятую операцию – к одному из шагов основного потока или к поддерживающей деятельности. Но, подозреваю, можно обойтись без этого.

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

«Flow Metrics: управление потоковым производством на основе данных»
Учебный курс про метрики на реальных примерах

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

  • Сергей Семикин

    А чем плохо, если в виде потока создания ценности будет описана вся деятельность?

    • «Всё» — это вообще всё? До какой степени детализации?

      Наверное, рисовать всё (а потом поддерживать в актуальном состоянии) слишком дорого. Да, и работать со слишком подробной картой слишком дорого – много времени на понимание, на анализ.

      А раз не всё, то нужно выбирать главное. Мы ведь для этого и строим модели (а VSM – это модель), чтобы получить упрощенное представление о реальности, но дающее понимание ключевых моментов.

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


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

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

  • Рубрики

  •  
  • Авторы

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

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT