7 правил для работы с IT-командой на аутсорсинге
на главную спецпроекта
7 правил для работы с IT-командой на аутсорсинге

Между хаосом и гиперконтролем: грамотно привлекаем айтишников на аутсорс.

Андрей Саломатин, ИТ-эксперт, советник председателя правления Бланк Банка, ранее вице-президент и CTO Ренессанс Банка, рассказывает как эффективно построить работу IT-департамента с использованием аутсорсинга без гиперконтроля или полного хаоса в процессах.

Рынок IT-аутсорсинга в России растёт очень быстро: по данным опросов, за 2022 год около трети российских компаний стали прибегать к нему чаще, а в 2024-м около 25% планируют выделить на него больше средств. Пока что на аутсорсинг передают лишь 10% IT-услуг, но эти показатели будут увеличиваться.

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

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

Правило № 1: привлекать не более 40% от штата

Общих правил соотношения штата и аутсорсинга индустрия не сформулировала: каждый сам определяет пропорции. Если говорить про постоянные команды разработки и поддержки, то идеальной я бы назвал пропорцию 60–70% на 30–40% в пользу штата, а управленческая команда должна на 100% состоять из штатных сотрудников. Только так вы сможете контролировать ключевые процессы внедрения и развития систем и технологий в компании, гибко управлять ресурсами, перераспределяя их между направлениями и масштабируя в случае необходимости. Иначе, попав в зависимость от аутсорса, возрастает риск потери контроля над командой и расходами.

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

Правило № 2: переманивать аутсорсеров в штат — не лучшая идея

Кажется, что лучший способ изменить расклад сил в свою пользу — переманить классных специалистов в свою команду. Но в России рынок IT по-прежнему является рынком работника: из-за дефицита кадров зарплаты IT-специалистов в прошлом году выросли на 15–20%. Это значит, что компаниям всё сложнее конкурировать в битве за высококвалифицированных сотрудников, предлагая им всё бОльший доход. Такое могут себе позволить лишь корпорации с безграничными бюджетами, остальные рискуют сделать свои ИТ-команды ещё дороже.

«Когда в 2022 году мы запускали программу перевода сотрудников в штат Ренессанс банка, компания выделила бюджет на 80 человек. Это позволило бы переманить по 5–10 специалистов от каждого подрядчика. Но люди отказывались, даже когда мы предлагали +10–15% к их текущей зарплате».

Андрей Саломатин, ИТ-эксперт, советник председателя правления Бланк Банка

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

Правило № 3: уметь работать в условиях неопределённости

Аутсорсинг используют там, где не хватает собственных ресурсов и экспертизы. Это значит, что вы не можете на 100% предсказать, как будет развиваться проект и с какими сложностями вы столкнётесь.

Любой новый продукт, сервис или функция всегда связаны с непредсказуемостью. Измениться может всё: бюджет, условия на рынке или законодательство, которое накладывает ограничения на ваш бизнес. Будьте к этому готовы и заранее подумайте, как вы будете реагировать на изменения, не пытаясь предусмотреть всё в рамках договоров, ТЗ и допсоглашений. Для этого можно, к примеру, перейти на итерактивный подход и разбить проект на короткие этапы, в финале каждого собирая обратную связь и выстраивая план действий на основе актуальных изменений. Либо же заранее определить, какие составляющие проекта неприкосновенны, например, бюджет, а какие можно «флексить»: сроки, размер команды и элементы системы или готового продукта. Лучшая стратегия тут — плотное сотрудничество и постоянный контакт с подрядчиком. Это позволит вовремя находить win-win решения.

«Когда Ренессанс менял MDM-систему, на этапе тестирования вступили в силу изменения в закон об обработке персональных данных. А уже на этапе запуска мы поняли, что замена системы будет очень сложной и опасной, поэтому нужно разработать отдельную процедуру отката изменений, на случай, если что-то пойдёт не так. Всё это потребовало больших объёмов дополнительных работ, как от аутсорсеров, так и от сотрудников банка. И эти работы было сложно предусмотреть в самом начале».

Андрей Саломатин, ИТ-эксперт, советник председателя правления Бланк Банка

Правило № 4: наметить точки контроля

«Неопределённость» не означает, что можно закрыть глаза на управление проектом и хаос в процессах. Важно предусмотреть целый ряд контрольных точек и мероприятий на каждом из основных этапов:

  • согласование архитектуры;
  • согласование технических заданий;
  • промежуточные демо-версии;
  • ревью кода;
  • тестирования силами внутренней команды — функциональное и нагрузочное.

Это позволит вам контролировать ход разработки и избежать неприятных сюрпризов в финале.

«В Ренессансе, в рамках проекта по замене системы, которая отвечала за управление продуктовым рядом в торговых точках, взаимодействие с вендором было изначально без жёсткого контроля. При этом вендор форсировал разработку до того, как была согласована вся документация. В итоге во время приёмки первого этапа оказалось, что решение не отвечает требованиям, а переделки займут более года (в 2 раза больше первоначальных сроков) и потребуют в 1,5 раза больше средств. Поэтому проект оказалось проще перезапустить уже с другим вендором и на другой технологической платформе.

И наоборот, когда заменяли платёжный шлюз IBM на новый, контроль был плотным на каждом этапе. Это позволило в самом начале выявить и совместно устранить целый ряд проблем архитектурного характера и внедрить проект с задержкой всего на месяц и превышением бюджета на 10%. И это при участии более 50 человек со стороны вендора».

Андрей Саломатин, ИТ-эксперт, советник председателя правления Бланк Банка

Правило № 5: интегрировать процессы

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

Правило № 6: формировать команды правильно

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

«Когда в Ренессансе мы внедряли собственную систему брокерского обслуживания, для мобильного банка собрали сводные IT-команды, где от каждого вендора было по 1–2 человека. Они получились плохо управляемыми и слабо мотивированными: было много ошибок, сроки постоянно срывались, а вся ответственность лежала на руководителе проекта. Выходом стало как раз формирование команд, в каждой из которых были люди из одной аутсорс-компании».

Андрей Саломатин, ИТ-эксперт, советник председателя правления Бланк Банка

Правило № 7: запуск продукта — ещё не конец

После завершения проекта команда аутсорсера должна будет некоторое время поддерживать новый продукт — как минимум пока ваши сотрудники не смогут развивать его самостоятельно. Обычно это занимает от трёх месяцев до полугода в зависимости от сложности и масштабов проекта.

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

«В одной из компаний, где я работал, приоритеты в развитии бизнеса менялись примерно раз в 6–9 месяцев. В результате потребности и ресурсы тоже менялись, например, на одном из направлений было от 8 до 3 команд. Если бы это были полностью штатные сотрудники, мы бы столкнулись с колоссальными репутационными и финансовыми потерями от таких сокращений. Но за счёт аутсорсинга отделались „малой кровью“, а „лишних“ штатных сотрудников перевели на другие направления».

Андрей Саломатин, ИТ-эксперт, советник председателя правления Бланк Банка

Аутсорсинг на постоянной основе может быть выгоден ещё и потому, что для IT-компаний действуют налоговые льготы, тогда как расширение штата слишком затратно и создаёт дополнительную нагрузку на HR-специалистов.

Соблюдайте баланс

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

«Аутсорс — это плата за скорость развития и гибкость вашего бизнеса. Он полезен там, где изменения нужны быстро, а доля неопределённости очень высока».

Андрей Саломатин, ИТ-эксперт, советник председателя правления Бланк Банка