13 мифов о проектных командах при agile-трансформации в IT: проверка на практике

Мария Шах, выпускница Российской экономической школы 2020 года

В этой колонке я хотела бы поделиться опытом проведения agile-трансформации в IT-компании и проанализировать результаты, полученные в результате работы с проектными командами в качестве связующего звена между бизнес-аналитиками и разработчиками. Этот анализ стал основой для моей дипломной работы «Взаимосвязи между профилем, технической производительностью и финансовыми показателями IT-сервисов agile-команд» на программе «Мастер финансов» Российской экономической школы.

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

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

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

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

Миф 1: Включение в команду сотрудников на аутсорсе – плохая практика. Такие сотрудники бесполезны.

Спорный. Наличие в команде инженеров на аутсорсе положительно связано с соблюдением планов и пониманием целей компании. Оно также снижает количество ошибок. Однако при этом сокращается количество автоматизированных проверок сервисов/продуктов и процент успешных внедрений в тестовой среде.

Миф 2: Чем больше разработчиков в команде, тем лучше. В команде не нужны тестировщики.

Ложный. Чем больше разработчиков в команде, тем медленнее решаются задачи и тем сильнее становится непонимание целей компании. Большее количество разработчиков не влияет на количество автоматизированных проверок. Оно не приводит к значительному увеличению частоты внедрений и скорости создания сервисов/продуктов. В то же время наличие тестировщиков в команде положительно связано практически со всеми показателями операционной/технической эффективности.

Миф 3: Чем больше членов команды находится в одной локации, тем эффективнее работа всей команды.

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

Миф 4: Чем больше членов команды в Москве (в главном офис компании), тем эффективнее командная работа.

Ложный. Присутствие членов команды в Москве либо не влияет, либо несколько отрицательно влияет на скорость выполнения задач, процент успешных внедрений сервисов/продуктов и понимание целей компании.

Миф 5: Возрастающая сложность архитектуры сервисов/продуктов приводит к увеличению количества дефектов.

Ложный. Количество критических открытых дефектов не зависит от количества связанных сервисов/продуктов.

Миф 6: Чем меньше Lead Time (время с момента появления идеи до момента ее фактической реализации и появления на стороне пользователя), тем выше показатель EBIT.

Ложный. Быстрое внедрение и обновление сервисов/продуктов имеет небольшой отрицательный эффект на EBIT.

Миф 7: Чем больше участников в команде, тем быстрее будет завершено создание сервиса/продукта.

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

Миф 8: График работы не связан с эффективностью команды.

Ложный. График работы с 8:00 до 17:00 и с 9:00 до 18:00 не влияет на эффективность, а рабочий день с 10:00 до 19:00 отрицательно влияет почти на все показатели эффективности и рейтинг команды.

Миф 9: Чем более опытные инженеры в команде, тем лучше она работает.

Ложный. Наличие в команде очень опытных специалистов отрицательно сказывается практически на всех показателях эффективности, за исключением скорости выполнения задач.

Миф 10: Текучка кадров в команде снижает ее эффективность.

Ложный. Текучка кадров в команде отрицательно связана только с пониманием целей компании. В то же время планы соблюдаются лучше, и количество успешных инсталляций сервисов/продуктов увеличивается.

Миф 11: Чем больше дефектов, тем больше жалоб.

Верный. На каждый новый дефект появляются тысячи новых жалоб клиентов.

Миф 12: Чем больше жалоб, тем меньше клиентов.

Верный. С каждой новой жалобой количество клиентов сокращается на тысячи.

Миф 13: Команда будет успешной, если владельцем ее продукта будет IT-инженер.

Ложный. Команды, в которых владелец продукта не является IT-инженером, имеют более высокий рейтинг.

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

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