Стоит ли развивать кросс-компетенции

    Всем привет! Меня зовут Леша. Я работаю системным аналитиком в Альфа-Банке, где занимаюсь развитием электронных каналов, в частности, новым интернет-банком для юридических лиц и индивидуальных предпринимателей.

    Кросс-функциональность в Scrum предполагает, что команда обладает всеми компетенциями, необходимыми для самостоятельной разработки продукта. Но должен ли каждый член команды фокусироваться строго на своей основной компетенции? Или стоит развивать кросс-компетенции, на которых специализируются коллеги?

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



    Развитие сотрудников в Банке включает три основных компонента – саморазвитие, тренинги и развитие на рабочем месте. Саморазвитие предполагает самостоятельное приобретение новых знаний и навыков за счет изучения релевантной литературы, прохождения видеокурсов, участия в митапах и конференциях. Тренинги позволяют в сжатые сроки получить новую информацию от тренера и применить ее на практике (на фото выпускная группа серии тренингов по js). Развитие на рабочем месте направлено на оттачивание навыков за счет решения реальных проектных задачек.

    Данная структура справедлива как в отношении основной компетенции сотрудника, так и для кросс-компетенций. Однако развитие последних является не требованием, а возможностью, предоставляемой Банком. И не каждый сотрудник видит потребность в развитии кросс-компетенций.

    Возникновение потребности


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

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

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

    Прирост производительности


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

    Для ответа на поставленный вопрос были проанализированы данные за 34 из 35 спринтов второго проекта (данные за один спринт не рассматривались, т.к. он был начат с нулем сторипойнтов). Производительность команды измерялась долей сожженных сторипойнтов на момент закрытия спринта. Расчеты показали, что средняя производительность команды за рассмотренный промежуток составила 45%.



    В 14 спринтах члены команды продемонстрировали кросс-компетенции. Средняя производительность в этих спринтах составила 53%. Значение показателя для спринтов, где кросс-компетенции продемонстрированы не были, оказалось на уровне 40%. Таким образом, был выявлен прирост средней производительности команды в результате применения кросс-компетенций.

    Планы на будущее


    Стоит ли развивать кросс-компетенции? Опыт реализации модуля почтовой корреспонденции в новом интернет-банке показывает, что стоит. Способность подхватывать задачки коллег позволила команде добиться 13% прироста средней производительности.

    Конечно, повышенный интерес к кросс-компетенциям может негативно сказаться на качестве работы за счет того, что задачу выполняет менее опытный в заданной области член команды. Поэтому каждому стоит фокусироваться в первую очередь на том, что получается лучше всего — на своей основной компетенции. Однако развитие кросс-компетенций могло бы стать приятным бонусом, который позволил бы сгладить просадку, а в некоторых случаях даже повысить производительность вашей команды. Поэтому интересуйтесь тем, что делают ваши коллеги. И, возможно, когда-нибудь эти знания вам действительно пригодятся.
    Альфа-Банк
    184,00
    Компания
    Поделиться публикацией

    Комментарии 6

      +4
      Такое ощущение, что вся статья писалась для попадания в поисковики по ключу «кросс-компетенции», такими темпами вы главу зеленого банка обгоните, он тоже любит говорить, что сотрудники должны быть универсальны :)
      Я работал в скрам-команде, нам тоже вещали про необходимость наработки кросс-компетенций и даже указывали планы развития с необходимостью изучения всякого разного. Вот только на мой взгляд, это все — перекладывание с больной головы на здоровую. При планировании спринта вы завышаете количество задач, которые вы можете выполнить и наблюдаете берндаун чарте пессиместичные картины, а потом затыкаете дыры планирования сотрудниками с помощью мантр о кросс-компетенциях.
      Стори поинты — просто аналог оценкам ресурсов в ч/д. Так если вы видите, что ваша оценка разъезжается с реальными возможностями команды, то зачем вы продолжаете эту порочную деятельность? Вы вылезете из сроков, сотрудники будут овертаймить, менеджеры будут нервничать и вот это все. Вы или ресурсов добавьте или укажите релизной команде, что они не умеют планировать спринты, а менеджер чересчур оптиместичен в ожиданиях. Уберете излишки задач и сторипоинты начнут расходоваться по тренду берндауна.
        +1
        Отсутствие аналитика или инженера по тестированию влекло за собой трудности при закрытии пользовательской истории, т.к. в соответствии с принятым DoD требовалось не только выкатить новую фичу в бой, но и покрыть ее документацией и автотестами.

        Отсутствие было запланированное? Если это не какой-то форс-мажор, то можно скорректировать DoD и исключить оттуда невыполнимые пункты. Либо не брать задачу вовсе.
          0
          В большинстве случаев отсутствие запланированное. Однако сейчас столкнулись с ситуацией, когда в команде нет тестировщика. Отсутствие стараемся компенсировать как собственными силами, так и за счет привлечения тестировщика другой команды.
            +1
            Сталкивался с вариантами «профессиональный тестировщик», «какой попало тестировщик» и «нет тестировщика». Первый вариант отрывается так сильно, что второй склонен считать аналогом третьего и все эти кросс-компетенции не спасают.
          +1
          Как насчёт посчитать статистическую значимость вашего улучшения? С такой небольшой выборкой и таким большим разбросом, думаю, вас ждёт разочарование.
            0
            Конечно стоит немного разбираться в разных технологиях, но лишь немного, т к сильно погружаясь в одну технологию или стек, неминуемо забываешь (или не обновляешь опыт и знания) по своим основным технологиям/стеку. Также важен баланс, когда ты суперузкий спец в одном, а когда нужно быть на достаточном уровне в нескольких технологиях. В любом случае для большинства задач большинство известных технологий справятся, правда конечно в разной реализации, но справятся при грамотном подходе

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое