Знаете ли вы компании, которые используют Аджайл-практики и внедрили Скрам, но так и не получили ощутимых результатов после нескольких лет трансформации? Чаще всего дело в том, что цели оптимизации адаптивность и скорость противоречат организационному дизайну компании, который поддерживает другие цели. В этой статье мы научимся находить несоответствия между целями оптимизации и текущей структурой.
POSIWID (“Purpose Of The System Is What It Does”)
Специалист по системам и управлению Стаффорд Беер разработал важную и популярную эвристику системного мышления, известную под аббревиатурой POSIWID: «Purpose Of the System Is What It Does». Другими словами, цель оптимизации определяет результаты системы. Беер считал POSIWID лучшей отправной точкой для понимания любой системы. Мы должны сосредоточиться на фактических результатах, а не на желаемых. Почему? Системы показывают в точности те результаты, которые определены ее целью оптимизации и поддерживающей цель структурой.
Когда люди понимают, как цель системы и ее структура определяют результаты, они могут взять на себя ответственность за изменению структуры.
Давайте приведем примеры, где ЗАЯВЛЯЕМАЯ и ФАКТИЧЕСКИЕ цели систем не совпадают.
Обратите внимание на формулировки в последней колонке. Вместо того, чтобы говорить о “плохо спроектированной системе” или “побочных эффектах”, мы считаем, что текущая система уже сейчас блестяще справляется с достижением плохих результатов.
Каждая система идеально разработана для достижения результатов, которые она получает. (Дон Бервик)
Хороший пример, когда поставленная цель не работает — Copy-Paste масштабирование. Это самый распространенный способ использования Скрама в больших организациях по всему миру.
Когда Скрам ошибочно воспринимается как “командный” фреймворк, то за каждой командой закрепляется локальный “Владелец Продукта”, а команды формируются вокруг функций, компонентов и внутренних бизнес-процессов.
Такая структура порождает зависимости и длинные релизные циклы. Кроме того, команды работают не над самой важной функциональностью из-за наличия многочисленных Бэклогов Продукта. Copy-Paste масштабирование имеет мало общего с заявленными оптимизационными целями. Чаще всего фактические цели оптимизации: сохранение статуса-кво и структур власти, индивидуальная эффективность, создание видимости изменений для того, чтобы отрапортовать руководству о том, что “трансформация завершена”. Поэтому фактическая цель, определенная с помощью POSIWID, может звучать так:
продуктовая организация блестяще справляется со своей целью занять людей работой, обеспечить длинные циклы и создать видимость изменений
Итак, можно до посинения доказывать, что целью системы является [XYZ], но если это не подтверждается результатами и поведением системы, то это ЗАЯВЛЕННАЯ цель, а не ФАКТИЧЕСКАЯ. Давайте дальше разбираться в том, как привести к соответствию цели оптимизации и организационный дизайн.
Топ-менеджмент определяет цели оптимизации
Когда ЗАЯВЛЕННАЯ и ФАКТИЧЕСКАЯ цели оптимизации не совпадают, то люди разочаровываются и демонстрируют негативное отношение к изменениям, потому что видят несоответствие ожиданий и реальности. Чтобы убрать несоответствие нам нужна поддержка топ-менеджмента.
Топ-менеджмент определяет цели оптимизации и организационный дизайн.
Мы начинаем каждую Аджайл-трансформацию с определение целей оптимизации и проектирования структуры продуктовой группы: организационного дизайна, процессов, наград, HR-практик и т.д. После определения целей принимаемые управленческие решения перестают быть “плохими” или “хорошими”. Они либо поддерживают заявленные цели оптимизации, либо нет.
Выравниваем цели оптимизации и структуру
Приведем пример одного из наших клиентов, с которым мы пошли в Аджайл-трансформацию. В качестве базового процесса был выбран Скрам. Менеджмент так определил оптимизационные цели в порядке важности:
- Работа над самым ценным (1).
- Скорость (2).
- Адаптивность (3).
Работа над самым ценным означает, что в любой момент времени команды занимаются самой важной проблемой пользователей продукта с точки зрения всей продуктовой группы. Под скоростью понимается время цикла от запроса клиента или идеи до поставки (Lead Time). Адаптивность — способность команд изменять направление разработки продукта при смене приоритетов.
Выбранные цели оптимизации совпадают с тем, что часто называется Аджилити (Agility). Если вспомним Аджайл Манифест, то упоминание этих целей можно отыскать среди двенадцати принципов:
Нашим главным приоритетом является удовлетворение клиента через раннюю и непрерывную доставку ценногопрограммного обеспечения (Аджайл Манифест).
Для достижения этих оптимизационных целей мы спроектировали структуру из следующих элементов.
Ниже вы найдете детальное описание всех структурных элементов.
Один Бэклог Продукта и один Владелец Продукта.
Только такой дизайн максимально поддерживает работу множества команд над самым ценным. Этот важнейший элемент структуры имеет определенные последствия. Команды должны быть готовы к работе в незнакомых для них ранее областях продукта и постоянному обучению и развитию компетенций.
В краткосрочной перспективе это неизбежно ведет к снижению индивидуальной эффективности. Это не “хорошо” и не “плохо”, потому что, индивидуальная эффективность не являлась оптимизационной целью, она вторична. В начале трансформации мы тщательно проговариваем этот пункт с командами и спонсорами изменений, предупреждая их о будущем снижении индивидуальной эффективности. Очень часто для того, чтобы оптимизировать целое, мы жертвуем производительностью его отдельных элементов.
Фиче-команды и общая кодовая база.
Работа в общем Бэклоге Продукта затрагивает много архитектурных компонентов и функций. Чтобы оптимизировать скорость (Lead Time), команды становятся автономными: кросс-функциональными и кросс-компонентными. Это подразумевает общее владение кодовой базой.
Области ценности размером 2-3 команды.
Область ценности представляет собой часть продукта, которая закрывает потребность клиента, но не самостоятельна в отрыве от остальной части продукта. Каждая команда обычно принадлежит лишь к одной области ценности. Как размер области ценности соотносится с целями оптимизации? При ее увеличении может потребоваться освоение командой дополнительных компонентов и функций, а также новые доменные знания. Широкие области требований поддерживают максимальную адаптивность, потому что команды могут работать с разными типами фич, но негативно сказываются на скорости. И наоборот, чрезмерно узкие области требований и фиче-команды обеспечивают самую высокую скорость поставки, но низкую адаптивность и неспособность работать над самым ценным в общем Бэклоге Продукта. Так как наш клиент поставил скорость выше адаптивности, то мы выбрали узкие области требований, в каждой из которых находится по 2-3 команды.
Как бы выглядела структура в случае, если бы менеджмент обозначил работу над самым ценным и адаптивность самыми важными целями оптимизации? Вероятнее всего, мы бы предложили широкие области ценностей и фреймворк LeSS.
Непрерывная интеграция и автотесты.
Фиче-команды не имеют зависимостей, но имеют конфликты на уровне кода. Почему? При переходе от компонентного организационного дизайна к фиче-командам, кодовая база становится общей и команды работают во многих компонентах одновременно.
Отсутствие высоких стандартов качества может привести быстрой деградации кодовой базы. Поэтому переход к фиче-командам ВСЕГДА идет параллельно с работой над инженерными практиками. Мы стремимся к интеграции работы всех команд как минимум раз в день, чтобы обнаруживать конфликты в коде и быстро их разрешать. А для этого команды должны иметь существенное покрытие кода автотестами и доверять им.
Работа в парном и моб-программировании, частый swarming.
Работа в перечисленных стилях значительно снижает WIP и время цикла (Lead Time), а также имеет ряд других преимуществ. Вот они: непрерывное ревью кода и обучение, отсутствие передач и связанных с ними потерь информации, отсутствие блокирующих вопросов, максимальный фокус команды и т.д.
HR-практики для мульти-функционального обучения.
Кросс-функциональные и кросс-компонентные команды становятся гибкими и могут снимать пиковые нагрузки, если в них работают мульти-функциональные специалисты, которые помогают друг другу. Помним, что “мульти-обучение” является одной из основ Скрама и упоминается в знаменитой “The New New Product Development Game”. Поэтому HR-практики должны измениться, чтобы поддерживать развитие разработчиков в смежных специальностях.
Адаптивное планирование с представителем бизнеса.
Есть паттерн, который мы замечаем во многих организациях. Давление менеджмента на разработку вызывает автоматическое снижение качества. Давление возникает из-за контрактных обязательств, внутренним коммитментов и фиксации объема работ. Мы называем это контрактной игрой между бизнесом и разработкой. Чтобы команды вкладывались в качество, необходимо адаптивное планирование с Владельцем Продукта представителем бизнеса. При адаптивном планировании команды прогнозируют объем работы исходя из того, что они по факту могут сделать, а не спущенных сверху ожиданий. Команды работают над самой ценной функциональностью в общем Бэклоге Продукта с той скоростью, с которой они могут разрабатывать продукт, соблюдая стандарты качества (Definition of Done). Задача Владельца Продукта — понимая реальную пропускную способность команд, упорядочивать Бэклог Продукта для извлечения максимальной ценности.
Поведение меняется, но только со временем
В предыдущей секции мы привели пример, когда цели оптимизации соответствуют структуре. Тем не менее, после проектирования и изменения структуры проходит некоторое время, прежде чем поведение людей в системе коренным образом меняется.
Культура следует за структурой (Крэйг Ларман)
Все дело в привычках. Если на протяжении длительного времени структура поощрял индивидуальную эффективность, то переход к системной оптимизации (один Бэклог Продукта, фиче-команды) и новым инженерным практикам (непрерывная интеграция, общее владение кодом, автотесты) будет не быстрым. Для редизайна система необходима поддержка менеджмента, терпение и коучинг на трех уровнях: организационном, командном и инженерном. Также важно подключать команды к процессу изменений с самого начала, создавая вместе с ними новые структурные элементы. Ведь автономность и чувство владения изменениями крайне важно для мотивации человека.
Основные мысли статьи:
- Любая продуктовая организация показывает результаты, которые определяются ее целью оптимизации и организационным дизайном.
- Для понимания системы мы должны сосредоточиться на фактических результатах, а не на желаемых.
- Мы начинаем Аджайл-трансформацию с определение целей оптимизации и проектирования структуры. Топ-менеджмент определяет цели оптимизации.
- После проектирования и изменения организационного дизайна проходит некоторое время, прежде чем поведение людей в системе меняется.
- Для редизайна системы необходима поддержка менеджмента, терпение и коучинг на трех уровнях: организационном, командном и инженерном.
