Блог Scrum.ru

Продуктовые Титаники - как организации теряют гибкость

Эта статья входит цикл. посвященный книге Creating Agile Organizations, написанной Сезарио Рамосом и Ильей Павличенко.
Титаник затонул в ночь с 14 на 15 апреля 1912 года после столкновения с айсбергом. Лайнер шел почти на предельной скорости 42 км/ч. Высокая скорость в водах, занятых льдами, в то время являлась привычной практикой. Рассчитывали на то, что вперёдсмотрящие заметят препятствие и лайнер изменит курс. До принятия решения о смене курса прошло не более 52 секунд. Несмотря на это, Титанику не удалось избежать столкновения.
Рис. 1
: Марка с Титаником
Хотите верьте, хотите нет, но эта история снова актуальна в мире продуктовых компаний. В погоне за краткосрочными выгодами и быстрой производительностью организации жертвуют гибкостью в долгосрочной песпективе, как это сделал Титаник. Но не стоит волноваться! Мы можем извлечь уроки из истории и не допустить, чтобы нас постигла та же участь. Давайте рассмотрим, как компаниям не стать следующим Титаником, а вместо этого взять курс на долгосрочный успех.

Продуктовая фрагментация

В организациях можно наблюдать динамику, которую мы называем продуктовая фрагментация. Допустим, над продуктом работает одна или несколько команд. Тренды и запросы рынка меняются, поэтому нагрузка не ложится на области продукта равномерно. Как реагировать на внезапное изменение спроса, с которым не могут справиться команды? Быстрое решение - нанять разработчиков в область с нагрузкой. Проблема временно решена. Затем рынок снова меняется и под нагрузкой оказывается другая продуктовая область.
Рис. 2: Снижение адаптивности вместе с усилением специализации
Одновременно с наймом менеджмент усиливает специализацию команд, закрепляя за ними более узкие области продукта.
В то время, как самая ценная работа лежит в областях, испытывающих пиковые нагрузки, другие команды не приходят на помощь. Во-первых, потому что они не знают об этом. Они работают с локальными “Владельцами Продуктов” и не интересуются тем, что находится в соседних “Бэклогах”. Во-вторых, потому что они не могут. У них отсутствуют либо атрофировались знания о соседних доменных областях. Тем ни менее, они не простаивают. Они “эффективно и продуктивно” занимают себя менее важной работой, накачивая продукт излишней функциональностью, усложняя архитектуру и увеличивая стоимость владения продуктом.
Рис. 3: Низкая адаптивность на дает возможности снимать пиковые нагрузки
Цикл повторяется многократно. В итоге через годы перед нами сложный архитектурно и функционально продукт, который разрабатывают десятки, а то и сотни команд. Команды даже могут оставаться частично кросс-функциональными и доставлять самостоятельно фичи на рынок, но только из узкой продуктовой области, и, конечно, не самые важные с точки зрения всего продукта. С каждым циклом способность системы самостоятельно адаптироваться под изменения спроса снижается одновременно с усилением специализации.
Если вы знакомы с системным мышлением, эту же историю можно иллюстрировать с помощью системной диаграммы:
Рис. 4: Fixes That Backfire языком системных диаграмм
Это архетип Fixes That Backfire, в котором быстрое решение (балансирующая петля B1) помогает в краткосрочной перспективе. А негативные эффекты аккумулируются во времени, поэтому проблема возвращается с еще более сильной симптоматикой (усиливающая петля R2).
Так появляются продуктовые Титаники.

Почему умные люди делают это?

Почему умные люди предпринимают действия, снижающие организационную гибкость в долгосрочной перспективе? Большинство управленческих решений ориентированы на совершенствование отдельных частей. Этот подход обусловлен образованием. Большинство бизнес-школ преподают каждую из функций корпорации отдельно — производство, маркетинг, финансы, персонал и т. д. — и никогда не рассматривают или неадекватно изучают способы их взаимодействия. Менеджмент привык разделять целое на части и управлять ими по отдельности, потому что отталкивается от ложной ментальной модели:
Если эффективны части , то эффективно и целое
Так ли это? Представьте, что вы испытаете, если ваши органы (сердце, легкие, кровеносная система) начнут работать с максимально возможной продуктивностью. Например, сердце будет биться с частотой 250 ударов в минуту, а число дыхательных циклов, которое в норме не более 20, возрастет до 50?
Когда производительность частей системы улучшается по отдельности, производительность в целом может не улучшаться (и обычно не улучшается). Ни одна часть системы не может быть изменена без понимания ее влияния на целое и определения того, что это влияние полезно.
(Рассел Эйкофф)

Как избежать фрагментации и развить адаптивность

Допустим, вы хотите создать адаптивную продуктовую организацию, которая способна быстро реагировать на изменения спроса на рынке и работать над самым важным. Что делать? Давайте обратимся к системному мышлению. Чтобы оптимизировать целое мы должны пойти на снижение локальной эффективности отдельных частей согласно законам Акоффа о взаимозависимостях.
Другими словами, мы должны переподчинить цели команд большей цели - адаптивности!
А еще организационный дизайн должен соответствовать нескольким условиям:
  • Для команд должно быть прозрачным то, что является самым ценным с точки зрения всего продукта.
  • Команды должны справляться с пиковыми нагрузками, помогая друг другу.
Получается старый добрый масштабируемый Скрам. Мы видим команды, которые работают из общего Бэклога Продукта с общим Владельцем Продукта. Команды видят весь продукт целиком. Каждая команда может взять любой элемент Бэклога Продукта и доставить его на рынок.
Рис. 5: Адаптивность - любая команда может подхватить работу
В дополнение к этому, команды работают небольшими рабочими пакетами для ускорения поставки. Пиковые нагрузки сглаживаются благодаря подключения других команд. Если в разработке более 8-10 команд, то мы используем Скрам-паттерн Value Areas и разбиваем продукт на крупные части, снимая когнитивную нагрузку с команд и Владельца Продукта.

Да, но это не заработает у нас…

Бьюсь об заклад, вы думаете: «В теории это звучит здорово, но для моей команды это не сработает». Это нормально так думать, но вы и правы и неправы одновременно.
Вы правы в том, что ваша команда не сможет адаптироваться за одну ночь. Требуются время и усилия, чтобы восстановить навыки, которые могли быть утрачены из-за фрагментации продукта в течение месяцев и лет. Но не сдавайтесь! Подобно спортсменам, которые тренируют свое тело, чтобы поднимать тяжелые штанги или бегать марафоны, ваши команды могут научиться быть более гибкими при правильной подготовке и поддержке.
Не верите мне? Создайте для своей команды организационную структуру, которая будет способствовать ежедневной адаптации. Чем больше они работают над элементами из незнакомых областей, тем более гибкой со временем становится ваша продуктовая организация. Это похоже на наращивание мышечной массы — чем больше вы работаете над этим, тем сильнее вы становитесь.
При наличии терпения, настойчивости и правильных инструментов ваши команды смогут адаптироваться.
Надеюсь это было полезно. Желаю вам максимальной адаптивности! )))
Интересно узнать большое про гибкие организации? Добро пожаловать на наш сайт CreatingAgileOrganizations.com
Продукт Дизайн организации Системное мышление Илья