Вы можете посмотреть видео-версию статьи здесь:
Для быстрой проверки гипотез и адаптации под изменения на рынке нужны кросс-функциональные команды. Это основной строительный блок Аджайл-организации. Нагрузка на специализации внутри команды ложится неравномерно из-за непредсказуемости входящей работы и комплексности среды. Одно из решений—мультифункциональное развитие участников команды, которое снимает пиковые нагрузки, повышает продуктивность и гибкость. Разработчиков, которые кроме ключевой специализации со временем развивают вторичные навыки, часто называют T-шейп или мультифункциональными специалистами (Рис. 1).
(Рисунок 1: первичные и вторичные навыки)
Скрам-мастера и менеджмент, сталкиваясь с неудачами в мультифункциональном обучении, делают вывод, что люди не хотят учиться. Но забывают, что поведение людей—продукт системы. Люди с радостью учатся, когда организационный дизайн поддерживает их в этом. В статье рассматриваем принципы организационного дизайна, который способствует мультифункциональному развитию.
Поведение людей—продукт системы
В системном мышлении мы считаем, что поведение людей в организациях на 95% зависит от системы работы или организационного дизайна: структуры власти, процессов интеграции и координации, HR-политик, вознаграждений (Рис 2).
(Рисунок 2: система работы или организационный дизайн)
Поведение, которое повторяется три и более раз, является продуктом системы. “Нежелание учиться” проявляется на уровне поведения, и за ним стоят конкретные структурные элементы. Важно их вовремя обнаружить и заменить, чтобы поддержать людей в мультифункциональном обучении.
Матрица “убивает” стремление учиться
Пример распространенного организационного дизайна, который препятствует обучению —матричная структура. Создание Айджайл-организации на ее основе проблематично (Рис. 3). И вот почему.
Во-первых, из-за встроенного конфликта между функциями и проектами/продуктами.
(Рисунок 3: матричная структура)
У функциональных и продуктовых менеджеров конфликтующие цели и KPI. Например, достижение цели функционального менеджера “миграция на Кибернет” и “снижение инцидентов 2 категории до 2-х в месяц” негативно влияет на цель продуктового менеджера “улучшить конверсию на 15%”. И наоборот. Разработчик разрывается, на понимая, кому он должен быть более лояльным—функциональному руководителю или менеджеру проектов/Владельцу Продукта. Тут не до обучения.
Во-вторых, функциональные менеджеры оказывают влияние на зарплату и развитие компетенций разработчиков. Естественно, они заинтересованы в движениии подопечных по узким карьерным трекам.
Система грейдов выглядит так:
- Ba1, Ba2, Ba3…Ban для бизнес-анализа
- F1, F2, F3…Fn для функции фронт-разработки
Разработчики в матрице—узники функциональных колодцев. Не стоит удивляться, что люди не заинтересованы в мультифункциональном обучении. И сколько бы Скрам-мастер не возвращал команды к принципам Аджайл Манифеста, Руководству по Скраму, проводил обучающие игры и другие активности, это вряд ли что-то изменит. Организационная гравитация сильнее.
Матричная структура основан на принципах Тейлоризма:
- специализации,
- фокусе на выполнении отдельных задач и
- индивидуальной продуктивности.
Тейлоризм противоречит гибкости (Agility) и ее принципам:
- мультифункциональности,
- фокусе на ценности и
- командной продуктивности.
Разделяем продуктовый и линейный менеджмент
Давайте посмотрим на организационный дизайн, который органичен для Аджайл-организации и создает условия для развития мультифункциональности. Он следует принципу “Разделение продуктового и линейного менеджмента”, описанному в книге “Creating Agile Organizations”.
(Рисунок 4: разделение продуктового и линейного менеджмента)
Что значит разделение продуктового и линейного менеджмента:
- Работу командам дает только продуктовый менеджер. В Скраме он называется Владелец Продукта. У Владельца Продукта и команд общие продуктовые цели и KPI, как и у всех, кто входит в продуктовую группу.
- У разработчиков общий руководитель—кросс-функциональный менеджер. Он берет на себя административные задачи, вхож в кабинеты власти и устраняет организационные препятствия для команд и продуктового менеджера. Например… “соберите мне, пожалуйста, метрики, показывающие, что вас блокируют. Я зайду к зампреду и постараюсь убедить его, что риски надо включить в продуктовую группу”. Кросс-функциональный менеджер дает возможность учиться, не ограничиваясь узкой специализацией. Кросс-функциональным менеджером может быть формальный руководитель продуктовой группы. ВАЖНО: кросс-функциональный менеджер не дает командам работу, это ответственность продуктового менеджера.
- Когда у команд общий кросс-функциональный руководитель, они могут развиваться в смежных специальностях. Но у кого они учятся? Для этого нужны менторы/эксперты и сообщества. Эксперты находятся в командах. Ими могут быть бывшие руководители функций. В случае, если они не растеряли экспертизу. Сообщества—неформальные объединения, куда по желанию входят представители команд. Сообщества создаются вокруг доменных областей, технологий, функций и т.д. Сообщества и эксперты могут брать на себя ответственность за оценку профессиональных навыков, развитие компетенций, стандарты профессии. ВАЖНО: менторы/эксперты не являются руководителями и не дают работу командам. Следующий вопрос: кто берет ответственность за создание плана обучения и его контроль? Самоуправляемые Аджайл-команды. Отталкиваясь от дорожной карты и видения продукта, разработчики совместно создают план обучения и владеют им. Аджайл-коучи или Скрам-мастера помогают командам настроить регулярные циклы по созданию и пересмотру таких планов.
Design Structure Matrix (DSM) ниже подытоживает информацию, рассмотренную в этой секции.
Дополнительные практики
Разделив продуктовый и линейный менеджмент, мы создаем базовые условия для обучения. Этот процесс можно также усилить дополнительными практиками, например, создав зарплатную формулу, которая учитывает развитие в нескольких функциях одновременно. Можно добавить процесс 360 обратной связи в командах для корректировки поведения. А еще можно использовать практику slack time и работу в трех режимах: парное программирование, моб-программирование и сворминг. И подкреплять все это практикой звездных карт (матрица компетенций). Но все это заработает, если созданы базовые условия для обучения с помощью принципа отделения продуктового и линейного менеджмента.
Подводим итоги
Поведение людей в больших организациях—продукт системы и организационного дизайна. Отказ от мультифункционального развития мы часто принимаем за искреннее нежелание людей учиться. Но за этим поведением могут стоять вполне конкретные структурные элементы.
Отделив продуктовый менеджмент от линейного, мы создаем условия, при которых разработчики могут начать движение в сторону мультифункционального развития.
