Системная оптимизация: прокачиваем компетенции Команды

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

Узкие специалисты — неоптимизированная система

Представим, что есть Команда Разработки, в которой работают Вася, Петя и Коля. Вася — специалист по зелёной технологии, Петя — по синей, Коля — жёлтой. Друг другу они помогать не могут. Тем не менее Команда Разработки является кросс-функциональной, вроде всё хорошо.

Команда Разработки получает от Владельца Продукта задачи, каждая из которых требует применения трёх технологий: зелёной, синей и жёлтой. В Спринт Команда взяла три таких задачи, вот промежуточный результат:

Системная оптимизация: прокачиваем компетенции Команды

Что произошло за три дня? Вася и Петя продолжают работать над первой задачей, потому что в ней большой кусок работы по зелёной и синей технологиям. Коля же успел завершить часть своей работы в первой и второй задачах, и перешёл к третьей. Что он будет делать дальше? Скорее всего вытянет менее приоритетную задачу из Бэклога Продукта и займётся ею.

Системная оптимизация: прокачиваем компетенции Команды

Итог Спринта — большое количество незавершённой работы в прогрессе (WIP), готова только одна бизнес-задача.

Много Скрам-команд работают так, и количество завершённых бизнес-задач в Спринте определяется тем членом Команды (ресурсом), на которого пришлась пиковая нагрузка в Спринте. В нашем примере это был Пётр.

Обратите внимание на то, что в приведённом примере все разработчики работали, как им казалось, эффективно, максимально используя свои компетенции. Но если посмотреть на систему целиком, то большая часть усилий была потрачена впустую.

Расширение компетенций позволяет решать задачи быстрее

Представим, парни прокачались и матрица компетенций стала выглядеть так:

Системная оптимизация: прокачиваем компетенции Команды

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

Системная оптимизация: прокачиваем компетенции Команды

Итог Спринта — готовы две бизнес-задачи, нагрузка распределена более равномерно между членами Команды.

Важно, что мы не добавляли в Команду новые «ресурсы», что увеличивает стоимость Команды и количество линий коммуникации, а стали лишь более эффективно использовать существующие. Отсюда вывод: оптимизация системы в разработке инновационных продуктов тесно связана с необходимостью в обучении. Развитие новых компетенций — непрерывная активность в Скраме.

Нас вынуждают не учиться

Мы выросли в парадигме классического менеджмента, который предполагает, что люди должны максимально эксплуатировать свою текущую экспертизу. Просто откройте любой сервис по поиску работы и вы найдёте массу объявлений: Senior Java Developer, Middle .NET Developer и так далее.

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

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

Как сделать так, чтобы люди учились

Чтобы Команда Разработки обучалась и становилась гибче, ей нужно создать необходимые условия для обучения, изменить систему. Как сказал Крэйг Ларман, культура следует за структурой. Система большой организации ломает нас, мы перестаём активно учиться и осваивать новые навыки. Вывод: необходимо изменить структуру, чтобы активировать желание людей вновь обретать знания.

Помогает обучению Препятствует обучению
Продуктовая парадигма, фокус на долгосрочных целях Проектная парадигма, фокус на краткосрочных целях
Команда сидит вместе в одном помещении Распределённые команды
Команда выделена на 100% и работает только над Продуктом Участники Команды работают над несколькими проектами одновременно
Команда работает вместе, как минимум, год, а желательно два-три года Пул ресурсов, после окончания проекта люди распределяются по новым проектам
Меряем системную продуктивность (ROI, PnL, Cycle Time) Меряем индивидуальную продуктивность (количество закрытых задач, человеко-часы), что стимулирует людей эксплуатировать текущую экспертизу
Команда Разработки лояльна Владельцу Продукта и выделена под Продукт Команда Разработки остаётся в «матрице» и имеет функциональных менеджеров
Разработчики получают повышение зарплаты, если расширяют свои компетенции (T-Shaped люди) Разработчики получают повышение в зарплате, если растут узко в одной специальности
Кросс-функциональные и кросс-компонентные команды Компонентные команды

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

Во-первых, приготовьтесь к игре в долгую. Вам понадобится много терпения. Я начинаю с того, что обращаю внимание Команды на то, что узкая специализация делает их менее гибкими.

Во-вторых, мы часто пользуемся инструментом Звёздная Карта, с помощью которого отслеживаем изменения в матрице компетенций сотрудников.

В-третьих, почти все команды, с которыми я работаю, рано или поздно начинают использовать Канбан, который великолепно работает со Скрамом. Канбан ограничивает количество незавершённой работы внутри Спринта и стимулирует сотрудников помогать друг другу.

Ключевые мысли статьи

  • Обращайте внимание на системную оптимизацию.
  • При создании инновационных сложных продуктов работа вариативна, и Команде необходимо постоянно обучаться.
  • Обучение — непрерывная активность в Скраме.
  • Есть ряд факторов, препятствующих обучению и стимулирующих его.

 

Автор статьи

Меня зовут Илья Павличенко, и я — Аджайл Коуч в компании Unusual-Concepts. Также я сертифицированный Скрам тренер в Scrum.org Я ни минуты не работаю, потому что занимаюсь любимым делом. Скрам — мое хобби и моя жизнь. Хотите больше узнать о том, как стать эффективным Скрам-мастером и Владельцем Продукта? Приходите на мои Professional Scrum Master (PSM) и Professional Scrum Product Owner (PSPO) тренинги.

Scrum ON!



Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *