Иногда компании разрабатывают Продукт десятками и сотнями людей без добавления новых ролей, событий или процессов Скрама. Они так могут, потому что оптимизировали организационный дизайн компании.
У организации тоже есть дизайн, как у грузовика или болида «Формулы-1». Большой грузовик спроектирован для того, чтобы перевозить груз из пункта А в пункт Б. Ради такой эффективности приходится мириться с долгим обслуживанием. Например, для замены шин нужны пара человек, подъёмное оборудование и несколько часов.
Дизайн болида «Формулы-1» оптимизирован для скорости и гибкости. Гоночная машина не рассчитана на то, чтобы работать долго, — только одну гонку. Но во время пит-стопа 20 человек работают вместе и меняют шины быстро. У всех людей конкретные задачи, и большую часть времени они ждут, пока другие выполнят свою работу. Благодаря такому дизайну шины меняют в разы быстрее, чем на грузовике, — мировой рекорд составил 1,92 секунды.
Если вы хотите заменить шины большого грузовика за 1,92 секунды, команда из пит-стопа «Формулы-1» не поможет. У вас просто будут новые роли, инструменты и процессы. Дизайн большого грузовика не оптимизирован для скорости, и вам придётся заново его проектировать.
Иерархия — типичный организационный дизайн. Она оптимизирована под многие вещи, но не для скорости и гибкости. Джон Коттер выделяет и другую проблему иерархии:
Проблема в том, что на философском и практическом уровне иерархия со своими управленческими процессами противоположна переменам. Она стремится уничтожить аномалии, стандартизировать процессы, решить краткосрочные задачи и добиться быстрой работы при текущем режиме.
Некоторые оптимизационные цели иерархии подразумевают использование контроля и ресурсов или попросту «время, проведённое сидя в кресле».
Иерархия выстраивает такой дизайн организаций, при котором они становятся группами одной функции. Работу групп по ключевым показателям тоже оценивают менеджеры одной функции.
Например, существуют группы, которые специализируются только на заключении контрактов или выставлении счётов. Другие группы специализируются на технологиях типа Java, .NET, Oracle. Есть группы со специализацией на тестировании, архитектуре, безопасности и проектном менеджменте.
В иерархии нет ничего плохого, если оптимизационные цели соответствуют задачам. Но если вы хотите стать гибким, цели нужны другие:
Иерархия для этих целей не подходит.
Организации, которые стремятся совместить Аджайл и иерархию, зачастую пытаются представить новые роли, процессы и инструменты, но в итоге следуют Аджайлу только формально. Дают новые имена старым вещам, и ничего не получается. Это всё равно что пытаться заставить команду из пит-стопа «Формулы-1» заменить шины на большом грузовике за 1,92 секунды.
Поэтому не спрашивайте, как масштабировать Скрам и приспособить его к иерархии.
Чтобы стать Аджайл, вам нужно оптимизировать организационный дизайн под правильные задачи. Зачастую это реорганизация в широком смысле слова.
Проектируйте организацию вокруг Продукта так, чтобы она была оптимизирована для постоянного внедрения потребительских функций. Не нужно оптимизировать компанию для использования ресурсов или «времени, проведённого сидя в кресле».
Найдите Владельца Продукта с предпринимательским менталитетом, который понимает рынок, и дайте ему полномочия вести жизненный цикл Продукта.
Создайте Скрам-команды, которые могут разрабатывать сквозные клиентские функции, и поставьте их в основу организации.
Организуйте свои команды, чтобы они работали над Продуктом и добивались интегрированного прироста в каждой итерации, а у вас было чёткое понимание процесса.
Начните работать с кросс-функциональными менеджерами, которые будут трудиться в кросс-функциональной организации, и не поощряйте оптимизацию под одну функцию.
Внедрите систему Человеческих Операций, в которой ценится командная работа и есть стремление к правильным навыкам.
Будучи одним из авторов ScrumPlop, я настоятельно рекомендую прочесть о шаблонных последовательностях, изучить публикации LeSS и Руководство по Нексусу — из них вы узнаете о построении аджайловых организаций ещё больше.
Представим, что Продукт завалился из-за недостаточного тестирования. Менеджер обычной компании первым делом создаст детальный процесс и закрепит за ним ответственного или целый департамент. Но тогда ответственности лишится Команда. Мы верим, что излишнюю сложность в структурах и процессах надо убирать, извлекая большее из меньшего: отказываться от подготовительных и стабилизационных Спринтов, выделенных команд анализа требований, архитекторов и очередей из задач для каждой команды.В LeSS команды кросс-функциональные. Они разбираются в бизнес-домене, дизайне и архитектуре, делят между собой общую кодовую базу для всех компонентов, сами анализируют требования заказчиков и конечных пользователей. В итоге они доставляют полноценную функциональность, а не внутренние компоненты или данные. Условия для наращивания кросс-функциональных навыков создают Скрам-мастера и менеджеры. А ещё есть мы — быстрорастущее комьюнити практиков и коучей LeSS. Мы призываем вас превратить машинообразные бездушные организации в организации со смыслом, где людям будет приятно работать. Не ожидайте, что этот процесс будет безболезненным. Но если вы возьмёте курс на гибкость, то упростите организацию, адаптируете её к быстро меняющимся условиям и реализуете скрытый потенциал.