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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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