Мария Шах, выпускница Российской экономической школы 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-инженером, имеют более высокий рейтинг.
Учет этих фактов может способствовать сокращению хаотичных действий при формировании проектных команд и выборе инструментов работы, а также выработке легко оптимизируемых процессов с вескими аргументами в отношении развития технической инфраструктуры, которой команды часто пренебрегают в погоне за краткосрочными выгодами.
Дальнейший анализ может стать основой для создания самообучающегося инструмента прогнозирования, который в режиме реального времени сможет сообщать командам, как повысить их эффективность.