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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

  • Рубрики

  •  
  • Авторы

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

    • Открыта регистрация на вебинар «Какой SLM нам нужен?»
      22 апреля в 11:00 по московскому времени приглашаем вас на бесплатный вебинар «Какой SLM нам нужен?» Управление уровнем услуг — тема далеко не новая, но и …
    • Путешествие заказчика. Примеры. Часть 2
      Новый видеоролик продолжает серию, посвящённую концепции путешествия заказчика (customer journey), рассматриваемой на учебном курсе ITIL® 4 Specialist: Drive Stakeholder Value …
    • Поток создания ценности — поток создания чего?
      Прочитав замечательную статью моего коллеги «Все говорят: «Поток!». А ты построй поток» и возникшую после неё дискуссию, я подумала, что довольно часто сталкиваюсь с вопросом, а …
    • Service science в основе ITIL 4
      В редакцию портала поступил вопрос: Здравствуйте!  Роман Журавлёв в статье «Главное про ITIL 4» "...отнес к важным преимуществам то, что ITIL 4 опирается на такую …
    • Роль лидера в продуктовой команде
      Довольно много людей полагают, что ключ к развитию потенциала и расширению возможностей продуктовых команд — это вежливо дать понять их руководству, чтобы они перестали …
    • Канбан-метод будет принят в качестве национального стандарта РФ
      Федеральное агентство по техническому регулированию и метрологии Росстандарт совместно с инициативной группой признанных российских экспертов по Канбан-методу объявило о начале …
    • Коммуникации в гибридной команде
      Благодаря неумолимой поступи нашей новой нормальности всё явственнее проявляются контуры будущей организации труда. Всё очевиднее становится понимание, что работа будет …
    • DevDays Moscow пройдут 8-10 июня
      С 8 по 10 июня в Москве пройдёт конференция DevDays Moscow, посвященная разработке программного обеспечения. В программе конференции Актуальные доклады (40+ спикеров) 7 …
    • Мотивация разработчика В2В продукта
      Команда создания и развития продукта состоит из разных людей: разработчиков, аналитиков, QA, владельца продукта и, иногда, из иных участников. Основной костяк этой группы …
    • Инцидент – как много в этом слове…
      Вы когда-нибудь задумывались над смыслом этого слова? Что оно значит для вас? Готов поспорить, что ответ на это вопрос будет на 100% зависеть от контекста! Но этого мало. Вам надо …
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT