Менеджмент цифрового продукта. От идеи до идеала

Если в компании полностью отсутствует гибкая культура, то ее называют горизонтально интегрированной (рис. 3.23). В такой компании подразделения объединены вокруг функций. Например, юридический департамент, финансовый, проектный офис, департамент информационной безопасности, департамент информационных технологий и т. д. Каждый из них работает по принципу конвейера и имеет свой норматив прохождения артефактов, как правило, документов. Например, много лет назад в одном банке норматив времени на рассмотрение документов юристами составлял две недели, при этом не было точной уверенности, что после этого не придется отправлять документ на повторное рассмотрение. Функциональные департаменты не заинтересованы в бизнес-результате, а следовательно, сотрудники не хотят рисковать ради него репутацией. Люди скорее склонны творчески выявлять риски, чем их творчески устранять. В результате на каждом этаже происходит значительная задержка. Трансформация идеи в ценность для клиента может происходить так долго, что теряется актуальность, и выпущенный продукт на старте уже нуждается в значительной доработке. Стоит ли говорить, что доработка тоже может потерять актуальность, пройдя через этажи. Горизонтально интегрированные организации очень негибки к внезапным изменениям.

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

Один из самых лучших способов запустить Agile в горизонтально интегрированной компании – это выбрать отдельно взятый департамент (часто это департамент IT) или создать отдельную компанию с новыми процессами, что нередко называется «инновационной лабораторией» или «технологической компанией». В экспериментальном режиме создается частично вертикальная компания (рис. 3.24).

Сотрудники из разных функциональных подразделений объединяются в кросс-функциональные команды, способные ритмично увеличивать поток ценности для конечных клиентов.

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

Рис. 3.24. Частично-вертикальная компания

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

Например, бизнес-блок «Розничный бизнес» имеет в составе несколько трайбов – депозиты, кредиты и инвестиции. В трайбе депозитов есть команда, которая отвечает за раздел депозитов в мобильном банке.

Рис. 3.25. Вертикально интегрированная компания

Однако гибкие подходы не всегда просто перенести с уровня одной или нескольких команд на уровень всего продукта, портфеля или предприятия.

Для этого требуется масштабирование гибких подходов, которое представляет собой специальный набор методов и практик, направленных на расширение и координацию гибкости в организации.

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

3.3.6. Понятие и цели масштабирования гибких подходов