Модели ИТ-аутсорсинга: Да, их несколько

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

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

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

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

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

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

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

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

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

В такой модели управление проектом остается на стороне поставщика услуг. Контактное лицо может быть не только Project Manager, но и Technical Lead, в зависимости от того, насколько технически грамотен клиент.

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

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

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

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

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

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

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

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

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

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

Более того, аутсорсинг и аутстаффинг в первую очередь направлены на обеспечение рентабельности, и здесь могут применяться различные варианты формирования цен. Давайте рассмотрим основные модели оплаты.

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

Фиксированное время и стоимость, гибкий объем (FFF: Fixed Price, Fixed Time, Flex Scope) В этом случае требуется прописать в контракте сроки и бюджет, но объем работ может быть изменен. Важно поддерживать общее качество продукта путем изменения объема, например, путем исключения менее приоритетных функций для соблюдения сроков и бюджета. На практике такой формат встречается редко.

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

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

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

При аутстаффинге выделенной команды или привлечении отдельных специалистов в основном используются модели оплаты Time & Materials (T&M) или Retainer. Различия между ними могут быть незначительными, поскольку даже в случае T&M в договоре обычно фиксируется минимальное количество часов, которые заказчик обязан оплатить.

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

На сегодняшний день нет проверенного подхода к привлечению квалифицированных разработчиков на краткосрочные проекты. Некоторые упоминают модель EaaS (Employee as a Service), но ее эффективность пока не подтверждена. Идея "облачного программиста" пока остается больше фантазией, чем реальностью.

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

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

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