Особенности управления эффективностью ИT-команд в условиях цифровой трансформации в 2025 году

Рассмотрим, как это влияет на эффективность ИТ-команд, выгорание сотрудников, какие потери несут компании и какие новые надстройки ИТ-команды внедряют для повышения эффективности к уже распространенным гибким Scrum и Kanban методологиям.

Цифровая трансформация и новые вызовы для ИТ-команд

По данным исследования Центра коммуникаций и цифровых решений Школы управления СКОЛКОВО 2024 -2025 г. сотрудники теряют до сорока часов рабочего времени в месяц на избыточные и неэффективные рабочие коммуникации и встречи. Это так же относится и к ИТ-инженерам, аналитикам и QA-инженерам. Однако у ИТ-команд есть общая особенность операционных процессов - в подавляющем большинстве среди них популярны гибкие Agile методологии управления рабочими процессами такие как Scrum и Kanban. Scrum подразумевает, что команды будут оценивать, заранее прорабатывать решения и брать в работу ограниченный список задач на короткий период - спринт, который чаще всего длится одну или две недели. Такая методология встречается в технологических компаниях, в которых есть большие и устоявшиеся ИТ-решения. Таким образом в компаниях естественным образом распределилось, что ИТ-команды, работающие по методологии Scrum разрабатывают уже протестированные решения в текущей инфраструктуре, предусматривая и тестируя все возможные сценарии и не используя быстрых, но высокорискованных инструментов для реализации поставленных задач. С другой стороны, по методологии Kanban работают ИТ-команды в стартапах или с молодыми и быстрорастущими продуктами в дивизионах крупных и средних компаний, в условиях, когда главный показатель - скорость выпуска в продакшн новых функций, модулей и опций чтобы протестировать их, замерить показатели и принять решение о масштабировании. Методология Kanban подразумевает потоковую систему работы с задачами, когда есть постоянно пополняемый список задач, из которых разработчики берут их в работу от самой приоритетной и далее по списку.

Таким образом бизнес-процессы выглядят так, что лидеры компаний и департаментов могут гибко управлять бэклогами команд, приносить свежие идеи для реализации и менять направление развития технологичных продуктов. Однако в ситуации 2024 и 2025 годов мы видим как каждый квартал выходят значительные обновления в ИИ системах, происходят прорывы в автоматизации процессов: еще в 2023 году мы наблюдали за презентациями возможностей ИИ-агентов, которые будут интегрироваться в существующие системы и брать на себя выполнение различных функций и уже сегодня мы наблюдаем появление сотен стартапов и технологичных ИТ-решений, которые созданы и растут командой из одного или нескольких человек и десятками автономных, автоматизированных ИИ-агентов, которые полностью забрали на себя функции сопровождения, саппорта или управления различными ИТ-системами. В недавнем интервью Павел Дуров, CEO и основатель Telegram озвучил, что в его команде одного из крупнейших мессенджеров мира работает всего около сорока человек и при этом благодаря системам автоматизации осуществляется круглосуточная поддержка более ста тысяч серверов.

Потери эффективности и экономические последствия

В таких условиях лидеры компаний и департаментов технологичных организаций с наличием ИТ-платформ и систем ежемесячно получают массу информации о новых возможностях ИИ-автоматизации, ИИ-инструментах и вынуждены как можно быстрее внедрять это в свои бизнес-процессы через постановки задач лидерам ИТ-команд, направлений и отделов для поддержания конкурентоспособности и удержания позиций на рынке. С учетом того, что на рынке преобладает функциональная и дивизиональная структуры компаний, в которых предусмотрены одна вертикаль руководства, все чаще так же встречается и матричная структура, где есть горизонтали и вертикали управления. Такие системы позволяют быть более гибкими, однако они подразумевают двойное подчинение команд, например, так лидер команды ИТ-разработчиков будет в подчинении как техническому лидеру, так и руководителю по вертикали. Тоже самое с web-дизайнерами и QA-инженерами. Поэтому проблематика потери до сорока часов рабочего времени, которую показали в исследованиях СКОЛКОВО, в 2025 году значительно выше именно для ИТ-команд. По данным Росстат в 2024 году средняя заработная плата в ИТ-секторе 163 000 рублей в регионах России и 249 000 рублей в Москве, таким образом при минимальной оценке потерь в 25% рабочего времени каждой ИТ-команды, состоящей из восьми человек, компания в регионах Р.Ф. теряет до 3,9 млн. р. в год, а в Москве до 5,9 млн. р. в год только за фонде оплаты труда. Сюда прибавляется недополученная прибыль из-за просроченных релизов новых разработанных функций и ИТ-продуктов, а также потери, связанные с повышенной текучестью ИТ-инженеров из-за выгорания. На сегодняшний день нет качественного и статистически значимого исследования, точно показывающего эту цифру потерь, однако ниже я поделюсь зафиксированными наблюдениями, проведенными в шестнадцати ИТ-командах EdTech и FinTech компаний и выделю четыре, регулярно и массово повторяющихся, появившихся в 2024-2025 годах бизнес-процесса, из-за которых растут годовые потери и падает эффективность. Опишу какие методологии и надстройки команды внедряют для их нивелирования дополнительно к Scrum и Kanban. А главное, как эти методологии влияют на их результаты и сколько денег экономят компаниям.

Наблюдения и выявленные проблемы в ИТ-командах

Метрикоориентированные организации измеряют эффективность ИТ-команд с помощью шести ключевых показателей:

1) Скорость выпущенных функций в релиз - показатель того, насколько уровень квалификации ИТ-сотрудников, подходит под текущие цели и задачи;

2) Процент реализации плана задач за период (спринт, месяц, квартал, год) - показатель уровня управляемости и предсказуемости в достижении целей и задач;

3) Утилизация времени разработчиков - показатель уровня организованности бизнес-процессов команды и бизнес-процессов коммуникации с другими командами;

4) eNPS (Employee Net Promoter Score) - показатель уровня удовлетворенности сотрудников своими текущими ролями, функционалом и заработной платой;

5) Уровень текучести сотрудников - показатель эффективности менеджмента в ИТ-команде;

6) Количество ошибок или «багов» в ИТ-сервисах - показатель качества осуществляемой разработки и тестирования ИТ-функций, решений и систем.

Первая зафиксированная у большинства наблюдаемых ИТ-команд регулярная проблема, которая значительно снижает эффективность работы - выполнение только продуктовых задач с наиболее быстрым путем реализации чтобы быстро сделать релиз и тестирование. Это влечет за собой накопление быстрых и не системных решений в крупных и давно работающих ИТ-платформах, в которых не предусмотрены и не проработаны все пользовательские сценарии. Через несколько месяцев у ИТ-команд накапливается количество поломок или «багов», которые приводят к массовым жалобам со стороны пользователей или рискам поломок и полному отключению массовых ИТ-продуктов как на несколько часов, так и на несколько суток. Эта проблема очень коварна тем, что ее не обнаруживают в течение нескольких месяцев и она имеет накопительный эффект - когда количество небольших малозаметных ошибок или непроработанных сценариев копится из месяца в месяц. В это же время лидеры команд и департаментов гонятся за реализацией новых функций и каждый последующий спринт команд наполняется исключительно новыми продуктовыми задачами, нацеленными на улучшение уже существующих функций или добавление новых. Таким образом через 6-10 месяцев посреди рабочих спринтов система дает критические сбои или пользователи засыпают техническую поддержку письмами об ошибках при попытках воспользоваться функциями ИТ-продукта в разных сценариях (например, на другом языке, с другого устройства или в другом пользовательском пути). В условиях полной загрузки рабочих спринтов ИТ-инженеры вынуждены останавливать работу, изучать и экстренно работать над решениями все чаще появляющихся поломок и ошибок. Этот тренд имеет нарастающий эффект и на второй год работы ИТ-команды значительно ухудшает попадание в запланированные сроки реализации крупных проектов компании, а также отрицательно влияет на мотивацию сотрудников.

Методологические решения: надстройки к Scrum и Kanban

По наблюдениям и замерам эффективности, есть две успешно внедренные надстройки к Scrum и Kanban методологиям, которые успешно решают эту проблему.

Первая значительная надстройка — это разделение ролей внутри ИТ-команд. В классических Agile методиках выделяются только три роли - Product Owner, Scrum Master, Development Team. В командах же с наилучшими показателями эффективности четко обозначены, распределены между сотрудниками и функционируют следующие роли:

1) IT Project manager - основной источник бизнес-требований. Общается с заказчиками, приоритизирует бизнес-задачи, доносит обратную связь по результатам работы команды от заказчиков (продуктовых менеджеров или любых других коллег, которые приносят задачи в команду). Имеет собственные ключевые показатели эффективности по количеству реализованных проектов командой разработки за отчетный период (обычно месяц или квартал). Отвечает за формирование и соблюдение рабочих процессов и организационную работу, за консультации бизнесовых команд, предварительную аналитику и проектирование/делегирование проектирования для крупных проектов.

Читайте также

Готов ли российский бизнес к эре цифровых сотрудников? Обзор рынка ИИ-агентов

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

2) Tech Lead - разработчик и руководитель, ответственный за стратегию развития архитектуры системы, за проектирование технических проектов, их декомпозицию и внесение задач в технический бэклог. Формирование и приоритизацию технических бэклогов; работоспособность сервисов в продакшене. Развитие команды и каждого участника с точки зрения «твердых навыков».

3) Lead Backup - специалист, замещающий лида и принимающий часть его обязанностей с целью погрузиться в роль лидера ИТ-разработчиков.

4) Lead QA - руководитель по тестированию, который отвечает за приоритизацию бэклога багов, межкомандное взаимодействие, менторинг и поддержку других QA (инженеров по тестированию), а также их бизнес-процессов.

5) Manual QA - специалист по тестированию, который отвечает за проверку работоспособности разработанных задач, выполнение критериев успеха задач и их качества, а также разбирает обращения из службы поддержки, инициирует создание баг-тикетов (задач по исправлению или предотвращению появления ошибок) и при необходимости эскалирует их.

6) Automation QA - специалист по тестированию или разработчик, который отвечает за разработку сценариев для проведения автоматического тестирования системы.

7) Developer - разработчик. Отвечает за оценивание задач, создание технического решения, реализацию и первичное тестирование задачи, а также за релиз и мониторинг реализованных задач в продакшене.

8) On-Duty Developer - разработчик, ответственный за проверку систем мониторинга и оповещений об ошибках системы, выполнение быстрых исправлений ошибок и заведение задач по исправлению или предотвращению технических ошибок, которые вредят системе, но с которыми пользователи могут не сталкиваться.

Вторая надстройка, которая внедрена и при замерах эффективности успешно работает у ряда команд в течение трех лет - разделение «бэклогов» или списков созданных задач, над которыми будет работать команда ИТ-инженеров после приоритезации со стороны бизнес-заказчиков. В традиционных методологиях Scrum и Kanban предусмотрен один продуктовый список задач, который пополняется различными бизнес-заказчиками и затем приоритезируются Scrum-мастером, и из которого задачи поступают в работу ИТ-инженерам после их оценки и подготовки технических решений. В наблюдаемых командах с повышенной производительностью наблюдается разделение таких списков задач и ответственных за управление ими. Однако самое важное отличие - в каждый рабочий «спринт» обязательно фиксируется время или объем «сторипоинтов» для задач из каждого бэклога. Вот как обозначены и работают данные списки задач:

1) Продуктовый бэклог задач

Список задач, в который добавляются задачи от различных бизнес-заказчиков - лидеры департаментов, Руководители продуктов и проектов.

2) Бэклог «багов»

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

- специалист по тестированию нашел ошибку и создал задачу по ее решению;

- руководители других команд сообщают об ошибках.

3) Технический бэклог задач

Читайте также

Алексей Никитин: «Бизнесу не нужен ИИ в BI — ему нужны решения без задержек»

Если ваш головной офис находится в Китае, зарубежное BI-решение вполне может быть корпоративным стандартом. Но когда управленческий контур здесь, данные «живут» в России, и отвечать за них тоже приходится здесь, выбор управленческого ИТ-инструмента быстро переходит в стратегическую плоскость. Алексей Никитин, генеральный директор Visiology, ответил на вопросы редакции о развитии российского BI, сопоставлении российских технологий с зарубежными, работе с большими данными и глубоком внедрении искусственного интеллекта в процессы принятия управленческих решений.

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

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

Новые форматы рабочих встреч и планирования

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

Планирование продуктового списка задач

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

Участники: вся команда, кроме QA-инженеров;

Цели встречи:

- Оценить созданные и описанные бизнес-заказчиками задачи, которые заранее были приоритизированы IT Project manager;

- Выявить не готовые к разработке user story «пользовательские сценарии» и подсветить их IT Project manager чтобы у него было время собрать информацию до следующего планирования спринта;

- Уменьшить список задач без оценки в продуктовом бэклоге.

Планирование списка задач по исправлению ошибок (далее - багов)

Близкая по смыслу с планированием продуктового бэклога встреча, на которой QA-инженеры и по одному представителю Backend и Frontend направлений разработчиков приоритизируют и дают оценку задачам в бэклоге багов. В отличие от продуктовых и технических задач, баги чаще всего являются неожиданным поведением системы и не требуют каких-либо серьёзных переделок и доработок (либо требуют для начала просто исследования), поэтому объективность оценки не очень важна и на встрече не присутствуют все разработчики, только по одному представителю направлений Backend и Frontend. Пока текущий бэклог багов не разобран, встреча проходит раз в неделю и длится не больше часа. Рано или поздно бэклог будет разобран и встречаться так же часто и долго не будет необходимости: встреча будет происходить по запросу.

Участники: все QA-инженеры команды, один бэкенд-разработчик, один фронтенд-разработчик.

Цель встречи: дать оценки и приоритизировать баги.

Планирование технического списка задач

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

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

Участники: все ИТ-разработчики команды.

Читайте также

Офисные пакеты: изучаем редакторы от Google, Яндекс и Р7 офис

Онлайн-офис больше не экзотика, но насколько он действительно готов заменить привычные «тяжелые» решения? IT-World сравнил новые браузерные редакторы Яндекса с Р7 Офис и Документами Google — по функционалу, скорости, совместной работе и реальной пригодности для повседневных задач. Выясняем, где минимализм и ИИ помогают работать, а где без «взрослого» офиса все еще не обойтись.

Цель встречи: дать оценки и приоритизировать бэклог технических задач.

Результаты внедрения и эффект для компаний

По проведенным наблюдениям, замеру эффективности и моему опыту управления ИТ-командами в роли ИТ-Project manager Lead, две вышеуказанные методологические надстройки (разделение ролей и разделение бэклогов задач) снижает количество неожиданных поломок системы и ошибок, с которыми сталкиваются пользователи на ≈25 процентных пунктов, а выполнение запланированных проектов в течение года при этом достигает точности в 90%. Так же при замерах зафиксировано, что текучесть разработчиков в таких командах ниже на ≈50 процентных пунктов по сравнению с остальными ИТ-командами, работающими по классическим методологиям Agile в аналогичных компаниях.

Прогноз и развитие в 2026 году

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

Источники:

1. Исследование Центра коммуникаций и цифровых решений Школы управления СКОЛКОВО

2. Интервью Павла Дурова Лексу Фридману в октябре 2025 года

3. Росстат, средние заработные платы по отраслям в 2024 году