От функциональных «колодцев» к совместной работе функций: проектный офис, процессный офис и продуктовый подход

Продолжаем цикл статей о кросс-функциональной интеграции — способности компании работать как одно целое, а не как набор отделов, которые ведут собственные битвы.

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

Сегодня — о другом. Компании запускают проектные офисы, процессные подходы, продуктовые команды. А внутренние конфликты между подразделениями остаются. Почему? Потому что каждый из этих инструментов отвечает на свой вопрос: 

• проектный офис — как реализовать изменения и проекты?
• процессный офис — как обеспечить эффективность сквозных процессов?
• продуктовый подход — как создавать ценность для клиента?
• кросс-функциональная интеграция — как обеспечить совместную работу функций?

Разберём механизмы каждого инструмента, их эффекты, плюсы и минусы.

Проекты почти всегда выходят за рамки одной функциональной вертикали. Они требуют участия нескольких функций — значит, специалисты вынуждены договариваться, чтобы получить общий результат.
Сила проектного подхода — во временной надстройке поверх функциональных вертикалей. Представители разных функций оказываются связаны общей целью, сроками и взаимозависимостью задач. Результат одного становится условием для работы другого. Хорошо работающее подразделение уже не гарантирует успех проекта — нужно, чтобы работали все звенья. Так проектная работа заставляет организацию временно мыслить горизонтально.

PMO (проектный офис) усиливает этот эффект: создаёт единые правила, прозрачность зависимостей, механизмы приоритезации и координации.

Но есть оговорка. Проект заканчивается — временная надстройка исчезает, а с ней и наработанная интеграция. Проектный подход хорошо соединяет людей вокруг конкретного изменения, но не приучает организацию работать кросс-функционально каждый день.

1. Проект создаёт общую цель поверх целей функций

Ресурсы, которые в обычной организации существуют отдельно, на время проекта организуются в новую систему. Чёткое определение этому процессу дал Дж. Родни Тёрнер (британский исследователь управления проектами, редактор International Journal of Project Management ):

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

2. Проектная команда становится зависимой от результата других функций

Питер Друкер (отец современного менеджмента, автор «Эффективного руководителя») писал:

«Эффективность руководителя зависит от эффективности других людей».

Каждая функция может быть эффективна сама по себе: производство выполняет план, закупки оптимизируют затраты, HR вовремя набирает и обучает персонал, но проектный результат при этом не достигается годами.

Проект создаёт условия, чтобы увидеть: работа отдельного сотрудника — лишь одно из звеньев цепочки, а результат зависит от того, что происходит по всей длине цепочки. Руководитель проекта может идеально управлять сроками, но не в состоянии самостоятельно выполнить работу всех функциональных специалистов. Его результат зависит от способности разных людей действовать согласованно.

Джон Катценбах и Дуглас Смит (консультанты McKinsey, авторы «Мудрости команд») определяют команду так:

«Команда — это небольшая группа людей с взаимодополняющими навыками, объединённых общей целью, общими целями деятельности и единым подходом к работе и несущих взаимную ответственность за общий результат».

3. Проектный офис задаёт правила и формирует культуру работы над проектами

PMO превращает отдельные проекты в систему и управляет связями между людьми, функциями и инициативами. Он делает прозрачной критически важную информацию:

• какие проекты зависят друг от друга;
• какие подразделения участвуют в нескольких проектах одновременно;
• в каких точках возникают риски, задержки или конкуренция за ресурсы;
• какие компетенции востребованы;
• какие риски переходят из одного проекта в другой.

В зрелых организациях PMO делает больше, чем координирует: он ведёт мониторинг, задаёт методологии, помогает принимать решения и участвует в развитии компании.

Кейс: Ямал СПГ

Классический пример силы проектного подхода в России — Ямал СПГ. Проект объединял разработку месторождения, строительство завода по производству сжиженного природного газа, порта Сабетта, аэропорта, энергетической инфраструктуры, логистики и ледокольного флота.
Первая технологическая линия запущена в декабре 2017 года — в соответствии с бюджетом и графиком. Вторая — на шесть месяцев раньше графика. После запуска трёх линий совокупная проектная мощность достигла 16,5 млн тонн СПГ в год.

Кейс показывает силу проектного подхода в чистом виде: десятки функций и сотни участников собираются вокруг одной цели с жёсткими сроками, бюджетом и техническими требованиями.

Плюсы проектного подхода

• Быстро ломает функциональные барьеры;
• Даёт опыт совместной работы;
• Помогает решать разовые сложные задачи;
• Позволяет вести трансформации силами разных функций в едином проекте.

Минусы проектного подхода

• Интеграция живёт только внутри проекта — заканчивается вместе с ним;
• Классический эффект: «В проекте работали отлично, вернулись в операционку — снова воюем»;
• Внедрение проектного мышления требует времени и усилий.

Процессный офис работает не с отделами, а со сквозными потоками. Задача процессного офиса — связать процесс, владельца, показатель, проблему, изменение и измеримый результат.

Ключевую идею процессного управления сформулировал Майкл Хаммер (основоположник реинжиниринга бизнес-процессов, профессор MIT):

«Бизнес-процесс — это сквозная работа, создающая нечто ценное».

Он противопоставлял процесс отдельной операции или функции. Отдельная операция может быть выполнена идеально, но не создаст ценности, если она не встроена в работающий поток.

Хаммер приводил простой пример: клиенту не важно, что компания отдельно «распланировала доставку» или «распределила запасы». Клиенту важно, чтобы он получил заказ вовремя.

Кейс: EVRAZ Business System

Пример зрелого процессного управления в российской промышленности — EVRAZ Business System. Это единый подход группы, построенный на культуре непрерывных улучшений. По стратегическому отчёту за 2021 год, система охватывает почти все операции ЕВРАЗа. Её ключевые элементы — эффективное управление, развитие сотрудников, оптимизация процессов и амбициозные цели. Поиск улучшений компания встраивает в ежедневную работу сотрудников, а не выделяет в отдельные проекты.

Кейс показывает: процессный подход, как и проектный, нужно вписывать в общую систему работы. Он не только запускает непрерывные улучшения — сам процессный офис тоже пересматривается регулярно.

Плюсы процессного подхода

• Процессный офис эффективно устраняет потери на стыках;
• Становится видно, где теряется время, возникает ожидание или происходит дублирование функций;
• Даёт реальный эффект для операционной эффективности, если процессный офис берёт на себя лидерство в изменениях.

Минусы процессного подхода

• Часто процессный офис занимается не лидированием изменений, а только регламентами;
• Появляются карты процессов, схемы BPMN (Business Process Model and Notation), описание ролей - а реальное поведение сотрудников не меняется;
• В худшем случае схемы, правила и регламенты начинают противоречить друг другу и сбоить «на стыках».

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

1. Команда вокруг потока ценности

Мэтью Скелтон и Мануэль Пайс (авторы бестселлера «Team Topologies», эксперты по построению продуктовых команд) вводят понятие команды под поток ценности. Организация строится вокруг конкретного потока работы, а не по классическому разделению на технические функции.

2. Продуктовое трио

Марти Кэган (основатель Silicon Valley Product Group, автор бестселлеров «Inspired» и «Empowered») описывает самостоятельную продуктовую команду через модель продуктового трио.

Ядро продуктовой команды — три ключевых компетенции:

• продуктовый менеджер отвечает за ценность и жизнеспособность решения;
• дизайнер — за функциональность и привлекательность для пользователя;
• инженер — за техническую реализацию.

Интеграция происходит не потому, что три подразделения время от времени встречаются и что-то согласовывают, а потому что все три компетенции работают вместе с самого начала.

3. Ответственность за решения

Марти Каган и его коллеги из Silicon Valley Product Group противопоставляют две модели команд.

Feature teams (функциональные команды) — команды-исполнители. Им приносят готовое решение, они его реализуют. Классическая схема: руководство решило, что нужно построить, а команда фокусируется на том, как построить. В типичном сценарии маркетинг изучает рынок и формирует требования — например, к новому поколению умных устройств; ИТ разрабатывает продукт; тестировщики проверяют его на ошибки; и так далее по цепочке.

Product teams (продуктовые команды) устроены иначе. С самого старта разные специалисты вместе решают не только «как» сделать продукт, но и «что» нужно сделать. Интеграция между функциями встроена в процесс создания продукта, а не подключается на отдельных этапах.

4. Специальный фреймворк для гибких команд

Скелтон и Пайс предлагают фреймворк Team Topologies для повышения скорости и гибкости продуктовых команд.

Эксперты выделяют четыре типа команд:

• «потоковая» команда отвечает за конкретный продукт и способна создать его целиком «от и до»;
• «платформенная» команда создаёт внутренние инструменты и сервисы для других команд;
• «обучающая» команда проводит исследования, внедряет новые практики и обучает коллег,
• команда «сложной подсистемы» берёт на себя узкоспециализированные задачи, требующие уникальной экспертизы.

Фреймворк обеспечивает мини-экосистему нескольких продуктовых команд без лишних трений и согласований. Каждая команда отвечает за скорость и качество — от начала проекта и до его конца.

Кейс: СберЗдоровье

Компания перешла от сервисной модели к фича-командам — кросс-функциональным продуктовым командам, отвечающим за отдельные части продукта.

Результат: время регрессионного тестирования (повторной проверки уже существующих функций после изменений в продукте, чтобы убедиться, что новые фичи случайно ничего не сломали) сократилось с четырёх до 1-3 дней. Актуальность тестовых моделей (например, сценарий записи к врачу) выросла с 80% до 93%.

Кейс: ЦИАН

В ЦИАН более 20 автономных продуктовых команд. Команда в ЦИАН — это кросс-функциональная группа с высокой степенью автономии, которая отвечает за бизнес-результат, а не просто за выполнение задач.

Но автономность оборачивается минусами. Однажды две разные команды почти одновременно начали реализовывать похожую функциональность по обращению к данным Росреестра. Для решения проблемы дублирования ЦИАН внедрил архитектурный комитет и механизм ADR по фиксации архитектурных решений.

Плюсы продуктового подхода

• Все работают на один продукт — границы функций частично исчезают;
• Возникает сильный драйвер межфункциональной интеграции;
• Общие цели, бюджет, метрики и единая ответственность;
• Внутри компании появляется мини-компания, работающая на создание продукта.

Минусы продуктового подхода

• Чем сильнее интеграция внутри продукта, тем слабее она между продуктами;
• Компания приходит к идее «экосистемы» и получает ту же проблему дезинтеграции — только на уровне продуктовых команд.

Мы разобрали три подхода — проектный, процессный и продуктовый. У каждого есть сильные стороны. Но панацеи среди них нет: ни один сам по себе не убирает «функциональные колодцы» и потери на стыках функций до нуля.
Что бы вы не выбрали — один из трёх или их сочетание — стратегический фокус должен оставаться на самой кросс-функциональной интеграции.
Что это значит на практике — разберём в третьей, заключительной статье цикла.