Несколько лет назад для решения срочных или комплексных ИТ-задач компании привлекали сторонних подрядчиков. Проектный аутсорсинг с четким разделением ролей «держателя» и «исполнителя» заказа стар как мир. Не так давно на российском рынке появилась новая модель сотрудничества — выделенные центры разработки или DDC. Когда заказчик выступает в роли и «держателя», и «исполнителя» заказа вместе с подрядчиком. Ответственность за конечный результат распределяется в равной мере. По сути, это та же услуга аутсорсинга, но реализуется через иную модель сотрудничества и на долгосрочной основе. Что по факту делает подрядчик? Анализирует запрос клиента, формирует необходимую команду по численности, компетенциям и опыту, организует ее работу на базе своего филиала, обеспечивая всей необходимой инфраструктурой. В полном сотрудничестве с внутренней командой выделенный центр погружается в проект и ничем больше не занимается. Разбираемся с особенностями формата вместе с Олегов Вылегжаниным.

Центр разработки = центр компетенций

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

Можно ли условно назвать DDC аналогом тренингового центра для развития профессионализма штатных сотрудников?

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

Долго = win+win

Такое партнерство имеет смысл выстраивать на долгосрочной основе, чтобы получить все его преимущества и для подрядчика, и для заказчика:

• Быстрая отладка процессов
• Сокращение числа ошибок и, соответственно, переделок
• Сокращение затрат
• Предсказуемость и надежность результатов
• Высвобождение времени и внимания (ИТ-директор может спокойно заниматься стратегией, а не «тушением пожаров»)
• Стабильный финансовый поток

Всем ли подходит такое партнерство?

«DDC встраивается в существующие процессы заказчика, поэтому важно, чтобы оба партнера обладали зрелой процессинговой структурой управления. Выделенный центр — это не про набор программистов, а про выстраивание процессов. Это как подключаемый модуль, который не замещает мощности заказчика, но усиливает. Второй важный момент — стратегическое видение. Как продукт\проект будет развиваться в ближайшие 3-5 лет, какие фазы, объем требуемых ресурсов, прогнозы и так далее.

Встречал искаженное представление, что DDC — это „коробка с кнопкой“: включил — работает; выключил — не работает. Выделенный центр — живой организм со своими внутренними процессами. И если простой длится, к примеру, больше 2-х недель, то может начаться отток кадров. Это ответственность и поставщика, и заказчика. Заказчик со своей стороны должен понимать, что вне зависимости от загрузки, оплата ведется. Поставщик же управляет кадрами. Например, в диалоге с заказчиком решают, что пауза будет использована для развития профессиональных компетенций сотрудников — тренинги, деловые игры и так далее. Все решаемо, важен диалог».

Инструменты управления

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

Исполнитель берет на контроль:

• Мониторинг эффективности и качества работы сотрудников по согласованным метрикам;
• Решения технических и организационных проблем;
• Взаимодействие с клиентом по планированию деятельности выделенного центра разработки;
• Проведение мотивационных мероприятий и обучение сотрудников выделенного центра.

Чем управляет заказчик?

«Сама модель взаимодействия предусматривает, что управление выделенной командой остается как функция у подрядчика. Заказчик же оставляет за собой управление на уровне постановки задач и разработки метрик оценки качества. Это очень важный момент, чтобы заказчик мог адекватно формулировать задачи проекта. Какие задачи и как решаем — это уровень управления заказчика. Под это мы выстраиваем соответствующие процессы и подбираем компетенции».

Когда DDC, а когда аутсорсинг ресурсов?

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

Какой ключевой аргумент в пользу DDC?

«Средний срок формирования выделенного центра примерно 6 месяцев с момента принятия решения до вывода на 1 проектную мощность. Поэтому если заказчик хочет решить задачу за 2-3 месяца, то, конечно, усиление команды внешними ресурсами или аутсорсинг. Здесь важно понимать суть услуги DDC — это не программисты, а процессы. И когда стоят системные, стратегические задачи, тогда имеет смысл подключать такой внешний модуль.

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

Какие есть риски?

Словосочетанию «зависимость от разработчика» пора занять достойное место в учебниках по психологии, в разделе аддикции. Так ли страшен, как малюют? На самом деле, это вопрос базовой мотивации и договоренностей. Под базовой мотивацией имеется в виду то, что обе стороны заинтересованы «сделать хорошо». Изначально в основу партнерства ложится задача, сформулированная от результата: мы хотим получить Х, поэтому сделаем все, что от нас зависит, а что не зависит — учтем и просчитаем. Это первое.

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

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

Хорошо, а чем рискует поставщик? Деньгами и репутацией. Команда и инфраструктура находятся на балансе подрядчика, и ему важно, чтобы выделенные разработчики не простаивали и были загружены не на 10%, а на 100%. Но и этот риск снимается на этапе проработки договора, куда стоит включить максимально возможный список сценариев: принцип ценообразования на долгосрочный период, бонусы за превышение плановых показателей, штрафы за невыполнение плановых показателей, допустимая норма сверхурочной нагрузки, норма оплаты сверхурочной загрузки, условия сокращения численности команды, условия расширения численности команды...

Чем рискует подрядчик?

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

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

Также контролируема история с неожиданными прекращениями сотрудничества. Выделенный центр формируется в среднем 6 месяцев. То есть не получится собрать команду по щелчку пальцев, и так же ее разобрать. И это тоже прописывается в договоре».

Защита и конфиденциальность информации

Повсеместная цифровизация приводит к тому, что внимание к вопросам кибербезопасности становится восходящим трендом. В случае с выделенным центром разработки вопрос защищенности данных, know-how рассматривается с особой тщательностью. Ведь такой формат сотрудничества предполагает максимальную открытость и уязвимость заказчика.

Какие существуют специальные меры по обеспечению безопасности в DDC?

«Мы используем понятие „секьюрный контур“. Это замкнутая система со ступенчатой авторизацией, разграничением прав, которую контролирует заказчик. Можно подключать аппаратный уровень защиты: создать выделенный сервер, использовать в качестве рабочих ПК и ноутбуки с минимальным количеством портов. На организационном уровне можно ввести протоколы и контроль действий во время работы, передвижений, установить видеонаблюдение. Если нужно, мы готовы развернуть DDC на территории заказчика. Все зависит его требований, мы готовы со своей стороны обеспечить сколь угодно высокую степень защиты».

Что будет «завтра»?

Американский рынок еще 20 лет назад был построен именно на модели DDC. А для российского рынка она относительна нова. Основной стимул для развития выделенных центров разработок и центров компетенций в регионах — это высокая стоимость и дефицит высококвалифицированных ресурсов в Москве и Санкт-Петербурге, где сконцентрирован основной бизнес.

Какие вы видите драйверы спроса, и чего ждать в ближайшие несколько лет?

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

Мы перешли уже к той стадии развития рынка, экономики, когда речь идет не о 20-30% профитах от выбора того или иного решения, а о 3-5%. Именно эти цифры становится достаточным аргументом, чтобы рассматривать альтернативы.

Многое в этой оценке зависит от уровня заработной платы, который очень неравномерный по регионам. И если считать только по параметру стоимости человек\часа, то дешевле брать в штат. Но это слишком узкий взгляд на DDC, который не позволяет учитывать долговременных выгод. Контракты длятся в среднем от 5 до 15 лет, это дает возможность поставщику существенно снижать цену на свои услуги. Например, подрядчик может создать 2 или 3 выделенных центра для разных клиентов на балансе одного юрлица, сократив, тем самым, операционные расходы. Это выгодная для бизнеса модель, доказанная мировой практикой».

PDS

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

«Года 3-4 назад на российском рынке начала появляться информация и кейсы зарубежных коллег по модели PDS, product development service. Это следующая ступень развития DDC, когда заказчик осознанно передает поставщику\разработчику функцию решений по продукту. Меняется и финансовая модель. Оплата ведется от маржи, потому что, по сути, разработчик создает и поддерживает готовый бизнес для заказчика, а не предоставляет сервис. Пока в российской практике нет реальных примеров, но, полагаю, они появятся в ближайшем будущем».