Довольно часто в общении с представителями разных организаций на тему продуктового подхода приходиться уточнять само понятие «продуктовый подход». Ведь это словосочетание не патентованное. Не существует единственной «правильной» книжки, где даётся единственно верное определение этого понятия. Поэтому оно бывает нагружено разными смыслами. Некоторые из них неразрывно связаны с понятием «трансформация». Та самая, которая цифровая (и которая не сводится к повсеместному внедрению цифровых технологий – более того, широкое распространение использование цифровых технологий не является сутью цифровой трансформации [если есть задача разобраться в этом, добро пожаловать на курс «Трансформация ИТ в традиционных компаниях»]).
Попробуем разобраться и выстроить некоторую структуру.

Можно продуктовый подход без потока? – Да.

Что означает «продуктовый подход»? То, что для организации становится важным (и может быть даже становится во главу угла) понятие продукт. Нечто, что наша организация создаёт, предоставляет, развивает, поддерживает и т.п. Понятие «организация» здесь используется в его архитектурном определении, например, как оно дано в ITIL®4 (а не в смысле «компания», «предприятие»). Т.е. в качестве примера организации мы можем рассматривать предприятие, или ИТ-подразделение.
Что значит «становится важным»? Это означает, что, например, организацию интересуют доходы и расходы в разрезе продукта(ов). Это не означает, что мы перестаём считать деньги в разрезе проектов, функциональных подразделений. Это означает сдвиг приоритетов. Например, нас в меньшей степени волнует прибыльность конкретного проекта, в рамках которого, например, продукт был создан и внедрён. Нас больше интересует совокупная стоимость и прибыльность продукта в конкретных важных для нас точках жизненного цикла продукта. Экономика всех остальных элементов (проектов, подразделений), разумеется, небезынтересна, но вторична.
Если мы строим советующие организационные механизмы для решения этой задачи, то это и есть реализация продуктового подхода.

Трансформация?

Какие здесь потребуются изменения? Наряду с линейными менеджерами, менеджерами процессов, менеджерами проектов, появляются продуктовые роли: менеджеры, владельцы (product owners). Скорее всего поменяется структура отчётности и, возможно, подчинённости. Возможно, будут произведены изменения организационно структуры. Например, чтобы объединить какие-то подразделения в более крупную структуру, работа которой ориентирована на продукт. Например, продуктовый департамент.
На рисунках 1–3 показан условный пример такого преобразования (все совпадения случайны).

Рис.1	Рис.2	Рис.3

• Рис.1 Исходная организационная структура
• Рис.2 Определены те сотрудники, которые вовлечены в работу в работу над двумя разными продуктами («красным» и «синим»). Для простоты рассматриваем частный случай, когда подмножество этих сотрудников не пересекается.
• Рис.3 Насколько это было возможно изменили структуру, создав «красный» и «синий» департаменты, перераспределив ресурсы (как уж получилось). То, насколько нужно будет и получится преобразовать организационную структуру зависит от многих факторов. В частности, от того, как мы определим границы продуктов. Ведь можно просто сказать, что то, на что работает то или иное подразделение и есть продукт (на самом деле, во многих случаях это не так). И тогда оргструктуру можно вообще не менять (вряд ли).

Насколько это серьёзное изменение для организации, и будет ли здесь «трансформация» подходящим словом, зависит от масштаба изменений. В некоторых случай компании ограничиваются переименованием PM-ов в PM-ов (т.е. проектных менеджеров [project manager] в продуктовых менеджеров [product manager], или, скорее, во владельцев продуктов [product owner, PO]). Является ли это трансформацией, судите сами.

Может ли здесь быть полезным то, что многие (неверно) отождествляют с гибкими подходами (aka Agile)? Например, Scrum? Да, вполне. В каком-то объёме. Но какие-то неведомые волшебные команды, выделенные на 100% на работу в продукте, специалисты, объединённые тесными эмоциональными связями (что это вообще такое?), WIP-лимиты и вообще многое из того, о чём будут вещать Agile-коучи, здесь скорее всего будет восприниматься как какая-то магия. Как что-то, что имеет слабое отношение к реальности.

Поток

Нужен ли здесь поток? Разумеется, для того, чтобы обеспечить эффективную, управляемую работу различных частей организации во благо продукта(ов), нужна какая-то конструкция, которая объединяет всё и всех. Такой конструкцией является «поток создания ценности» (value stream) – последовательность этапов, которая описывает решение задачи от и до (сквозной процесс, если угодно).

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

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

Более того, многие организации, использующие инструмент «карта потока создании ценности» (value stream map), получают заметные преимущества, включая понимание того, как всё работает в целом, того, где возникают узкие места. Но говорить о том, что движение задач по организованной таким образом производственной системе представляет из себя быстрый поток (flow), в большинстве случае не приходится.

Можно продуктовый подход без потока? – Нет!

Там, где требования к скорости решении задач высоки, нам потребуется построить быстрый поток. Именно такая организация работы даёт бизнесу существенные преимущества. Именная эта претензия к ИТ («вы работает медленно!») со стороны бизнеса звучит в компаниях, где уровень зрелости ИТ довольно высокий, и претензии к доступности возникают редко. И, думаю, именно такая реализация продуктового подхода и успешные кейсы в этой области привели к повышенному интересу к продуктовому подходу и цифровой трансформации. Поскольку всё большему количеству организаций требуется иметь возможность решать задачи существенно быстрее.

В чём здесь основное отличие от того, что мы рассмотрели в предыдущем разделе? И нельзя ли просто разогнать поток в той конструкции, что мы уже обсудили? До какой-то степени можно повышать скорость и в предыдущей модели. Но этот рост довольно серьёзно ограничен. Для того, чтобы повысить скорость существенно, нужно менять (почти) всё. То есть как раз здесь не обойтись без серьёзной трансформации.
Часть изменений с позиции классической, традиционной организации работы могут казаться контринтуитивными. И потому восприниматься как магия. Всего один пример.

Поток

Организация быстрого потока требует среди прочего управления входом в поток. Производственная система, которая обеспечивает обработку задач входящих поток – это какая-то конфигурация наших ресурсов. В простейшем случае – это продуктовая команда (со всеми необходимыми средствами автоматизации). Это может быть и более крупная совокупность людей и/или подразделений (например, часть оргструктуры, которая есть ничто иное как небольшая группа специалистов, отмеченная на картинке выше цветом). Задачи, которые поступают на вход этой производственной системы, образуют очередь (бэклог). Кажется очевидным, что нам нужно организовать работу так, чтобы бороться за уменьшение размера бэклога. На самом деле нет. Это не является основной целью.

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

Сложности с равномерностью потока обусловлены многими факторами. Это и вариативность в работе самой производственной системы. В частности, в работе каждого конкретного сотрудника. И вариативность задач. По размеру, несмотря на все наши усилия по грамотной декомпозиции (что тоже отдельный навык). И по структуре временных и трудозатрат на решение задач одного размера на разных участках производственной системы. Плюс вариативность с точки зрения сроков решения одинаковых в вышеописанных параметрах задач – вполне возможно, что на очередную подобную предыдущим задачу потребуется больше времени (возможно, только на конкретном участке).

Поэтому, во-первых, производственная система должна быть саморегулируемой. Здравствуй, система вытягивающего типа с WIP-лимитами (ограничения на количество задач, находящихся в обработке в каждый момент времени). Дополнительно, для того чтобы минимизировать неравномерность потока, вызванную различными отклонениями в работе производственной системы или вариативностью задач, было бы здорово иметь возможность быстрого перераспределения ресурсов внутри производственной системы. Здравствуйте, T-shape профили компетенций сотрудников и те самые тесные эмоциональные связи между специалистами, работающими в одном потоке. Таким образом мы не просто ограничиваем вход в систему. Все описываемые механизмы должны работать в комплексе.

По моему опыту обсуждения данной темы с коллегами из разных организаций могу сказать, что большинство знакомо с теорией ограничений Голдрата. Знает основные концепции, пришедшие из бережливого производства (Lean): вытягивающая производственная система, WIP-лимиты. Но все эти элементы не складываются в общую картину. И получается, что человек рассуждает так: «Нет, всё, конечно, понятно. Но мы же не можем… <дальше можно подставить: «не брать в работу задачи, которые нужно решать бизнесу», «допустить простой сотрудников (ведь чем выше утилизация каждого участка, тем выше эффективность системы», «не определять дедлайны для всех задач», и т.д.>!» Именно здесь и требуется трансформация. Причём на уровне всей организации, включая бизнес. А для того, чтобы этакое радикальное изменение подходов к организации работы не было прыжком слепой веры, нужно хорошо разобраться с ключевыми компонентами этой картины, понять их взаимосвязь. Ну, и, да, потребуется сдвиг парадигмы.

Чтобы разобраться с тем, какие ключевые элементы составляют эту магию трансформацию, приходите на курс «Трансформация ИТ в традиционных компаниях»]). Ближайший будет скоро, 17–19 июля. Обсудим, поспорим. Абсолютно все детали этой большой темы за три дня разобрать, конечно, невозможно. Но построение чёткой структуры из того, что является самым главным, и как это самое главное работает, гарантируем. Как и сдвиг парадигмы 😊

PS

В таблице ниже показано соотношение описываемых в заметке состояний организации в разрезе обсуждаемых характеристик.

* Концепция потока создания ценности (value stream) может быть полезна и здесь. Но то, как будут протекать задачи в этом потоке (flow) чаще всего не имеет отношения к равномерности и высокой скорости.

Если расположить указанные в таблице состояния на шкале «потоковости», где чем правее точка на шкале, тем более быстрый поток решения задач удалось построить

На самом деле на этой шкале больше точек, соответствующих тем или иным состояниям организации, чем нарисовано. Ради интереса можете попробовать найти на этой шкале место организации, в которой много взаимосвязанных продуктов, сложная оргструктура и большая численность персонала. Там будут свои тонкости организации быстрого потока. Все принципиальные моменты остаются без изменения. Но есть нюансы. Если будет интересно, можем обсудить в следующих заметках.

ТРЕНАЖЁР

Kanban Flow Metrics: управление потоковым производством на основе данных

Тренажёр про метрики на реальных примерах