Outsourcing

За последние 30 лет ИТ-индустрия и подход к предоставлению ИТ-услуг изменились кардинально. Попробуем проследить основные этапы этой эволюции.

В хронологии будем опираться на западный как более релевантный.

1990-е: зарождение аутсорсинга

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

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

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

2000-е: появление управляемых сервисов

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

В то же время начали появляться хостинг-провайдеры, которые сдавали в аренду аппаратные мощности в дата-центрах (co-location). Обслуживание инфраструктуры провайдеры брали на себя.

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

Еще один маркер: появление прикладных корпоративных приложений в облаке SaaS. Первопроходцем стала компания Salesforce, разработчик CRM-платформы, которая существует и поныне. Здесь уже клиенты не задумывались о том, чтобы поддерживать инфраструктуру для функционирования корпоративного ПО этим занимался поставщик.

2010-е: становление MSP

Компании, которые раньше были ИТ-консультантами, стали предлагать, если буквально, управляемые ИТ-услуги (managed IT). Они набирали в команду специалистов разных квалификаций от системных администраторов до разработчиков, чтобы предоставлять полный набор услуг: настройку, администрирование и мониторинг ИТ-сервисов. Чем большим количеством сервисов управлял такой провайдер (Managed Service Provider MSP), тем он был успешнее.

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

2020: зрелость managed IT

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

Отметим главные особенности рынка managed IT.

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

• Инфраструктура и сервисы передаются в ведение MSP, который управляет и мониторит сервисы онлайн.

• Главная метрика для MSP не количество часов, которые отработал инженер, а должный уровень доступности сервиса, прописанный в SLA.

• Масштабирование вычислительных мощностей, которое раньше занимало недели и месяцы (с учетом закупки оборудования), теперь происходит за минуты.

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

• Капитальные затраты на ИТ сменились на операционные на ежемесячные платежи. Компаниям стало проще планировать ИТ-бюджет.

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

ИТ теперь затрагивают все бизнес-процессы: HR, закупки, финансы, продажи, обслуживание клиентов, информационную безопасность и так далее. Поддерживать эффективность этих процессов без помощи стороннего поставщика управляемых услуг всё сложнее.

Managed IT в России

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

Компаний, ИТ-сервисы которых застряли в 19902000-х, конечно, с каждым годом меньше. Российский рынок ИТ медленно, но верно движется в сторону managed services модели предоставления ИТ-услуг, которая, как нам кажется, наиболее адекватна реальности.

Всем привет.

Я team lead, сертифицированный коуч и начинающий психолог.

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

Я работал в двух продуктовых компаниях, одной outstaff (жил и работал в Абу Даби, по контракту с минской компанией) и двух outsource. В общей сложности был где-то на 15 проектах.

В этой статье хочу поделиться своим видением текущей ситуации на рынке.

• За время работы заметил следующие интересные феномены:

• В продуктовых компаниях люди чаще обсуждают что изменить в продукте (язык заплетается). В outsource компаниях в процессах

• В продуктовых компаниях меньше менеджмента

• В продуктовых компаниях реже взаимодействие с заказчиком (или целевой аудиторией)

Ни на одном проекте не встретил аналитику в outsource.

Здесь думаю следует пояснить, что такое outsource.

Аутсорсинг (своими словами) это такая сфера, в которой заказчик очень не хочет что-то делать и решает передать эту работу отдельной команде, за счёт чего последние и живут.

Если у кого-то есть вопросы или несогласие по поводу не хочет, идея ко мне пришла после прочтения статьи, с которой советую ознакомиться.

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

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

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

Причём всё это нужно трактовать не как объективные и осознанные недовольства заказчика, а как психологическую разгрузку. Что-то в стиле пожаловаться друзьям. Однако в случае outsource компании возможность пожаловаться является услугой, оказываемой такому заказчику.

Здесь ни в коем случае руководство outsource компании не должно обесценивать работу менеджеров или бизнес-аналитиков. Эти люди стоят на передовой. Их задача состоит в том, чтобы путём снижения сопротивления заказчика составить понятные и хорошо описанные требования для команды разработчика.

Таким специалистам необходимо иметь достаточно неплохие дипломатические навыки. И чётко разделять профессиональную и личную критику (вы делаете фигню и вы козёл).

Заказчик, каким бы он милым не казался, будет находиться в большом стрессе. И его логичным желанием будет слить своё напряжение в дипломата со стороны outsource.
Таким специалистом не должен быть разработчик (либо это должно быть отдельно прояснено с ним).

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

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

Наивысшим приоритетом для нас является удовлетворение потребностей
заказчика, благодаря регулярной и ранней поставке ценного программного
обеспечения

Очень важно понимать, что без качественной работы бизнес-аналитика (или любого другого дипломата) не удастся получить требования для регулярной поставки ПО.

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

Всё очень просто. Заказчик начинает использовать разработчика, как бизнес-аналитика. И сливать в него своё раздражение от задачи, которую ему так не хочется делать.

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

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

И здесь есть интересная ловушка.

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

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

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

Для упрощения воспользуемся метафорой семьи.

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

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

Поэтому разработчик находится в какой-то не совсем понятной ситуации. Как бы между двух родителей.

Здесь очень важно заметить про страх непринятия и обесценивания.

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

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

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

Получается при сильной фигуре заказчика, старшие разработчики могут открыто выражать своё недовольство как менеджерам, так и заказчикам. И уже отстаивать свой личный интерес.
Младшие же разработчики так делать не могут (чаще всего) в силу собственной идентичности в данной группе.

И здесь важно заметить, что если человек деградирует до невербального периода (до того, как научился говорить), то он просто не будет выражать своё недовольство, замкнётся и выгорит.

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

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

В такой ситуации для менеджеров наступает момент встречи с "ребёнком в подростковом периоде". Когда он ещё не самостоятельный (человек всё-таки на контракте). Но уже требует своего признания (уважение его договоров с заказчиком).

Данное признание очень помогает продвинуться всей компании, т.к у менеджеров убирается жёсткая необходимость ставить кого-то над таким разработчиком (бизнес-аналитика, менеджера).

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

И менеджерам ещё долго придётся вынашивать своё потомство, до появления следующей конфликтной ситуации.

Такой конфликт спор за признание родителя. Или "про процессы". Является наиболее частым в outsource компании именно из-за специфики работы.

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

От сюда и появляется первый феномен (из начала статьи).

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

А как следствие там будет скорее конфликт между детьми в коллективе в стиле папа, посмотри, как я могу (больше разговоров про непосредственно работу), чем про процесс. Никто не будет хотеть бороться за место отца, все будут бороться за его внимание друг с другом.

Как следствие разворачивается и второй пункт меньше менеджмента. Он практически не нужен. Всё прекрасно работает.

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

Про аналитику просто наблюдение. Ни с чем не смог связать.

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

С одной стороны так оно и есть - и статей вагон и проанализировать есть что. С другой, стороны есть специфика - и этапность ML разработки несколько отличается от стандартной и работа идет не только (и не столько) с кодом, сколько с данными.

Но давайте обо всем по шагам - в двух словах пробежимся по отличиям, а потом разберемся есть ли место аутсорсу в ML разработке и какое оно.

Вместо вступления пару слов про отличия

На самом деле основная специфика ML разработки заключается в в том, что здесь рулит не код, а данные. Есть конечно еще специфика, что алгоритмы ML мы не пишем, а только используем (обучаем), но это опять же во многом про данные. А данные у нас что? Правильно - данные это в первую очередь стратегический актив предприятия. И по большому счету ML - это ни что иное как процесс монетизации этого самого стратегического актива. А многие ли готовы отдать монетизацию своего актива на сторону?

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

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

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

Вариант 1 - когда ничего нет

Итак, с чего начинается ML в бизнесе, где его никогда не было? Бывает, что с картинки почти что в букваре, но чаще всего с гипотезы или идеи, которую кто-то подсказал. И в этот момент времени, по большому счету, без разницы кто докажет эту гипотезу - кто-то внутренний или внешний. Ведь речь пока идет только о том, чтобы доказать теорему, так что ничего не мешает привлечь варягов для доказательства. Оно даже будет быстрее и логичнее, главное не ошибиться с "варягами" (но подробнее о выборе подрядчика ниже).

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

Так что место номер раз для аутсорсинга - это первые шаги ML в конкретной компании. Проверка гипотезы или можно обобщить и сказать по-умному - стадия PoC (Proof of Concept). В этом сценарии разделение ответственности в работе над моделью может быть следующим (практически раскрашиваем CRISP-DM):

• Этап 0 - Идея или гипотеза. В идеальной картине мира она возникает у бизнеса. В утопичной - еще и с критериями успеха.

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

• Этап 2 - Обучение модели. Основная работа подрядчика. На самом деле это цикл работ по формированию признаков, обучению и тестированию модели. Итерации идут до тех пор пока целевая точность модели не будет достигнута.

• Этап 3 - бизнес тестирование модели и оценка результатов. Проводится совместно бизнес-заказчиком и подрядчиком. Если к этому моменту уже есть собственная экспертиза в ML, то оценка идет на троих.

• Этап 4 - адаптация и внедрение модели в продуктив. Вот на этом этапе ключевая развилка:

  • Либо к этому моменту появляется собственная ML экспертиза и тогда процесс в ее зоне ответственности

  • Либо модель поставляется как сервис и работоспособность обеспечивает подрядчик.

И в зависимости от выбранного пути определяется дальнейшая судьба аутсорса - если собственной экспертизы по ML не появилось и бизнес пошел по пути DSaaS (DataScience as a Service), то дальнейшее место аутсорса совершенно понятно. Скажу честно - на мой взгляд сценарий возможен только в случае если применение машинного обучения в компании ограничено и не имеет перспектив за пределами одного-двух кейсов. Ну а данные наверное данные в такой компании не слишком уж дорогой или не слишком стратегический актив.

Если экспертиза родилась, то для проверки следующих гипотез аутсорс уже не нужен - благо мониторинг моделей много сил не отнимает, поэтому между делом можно заняться развитием и расширением присутствия ML в процессе принятия решения. Хотя скажем честно - это верно только до определенного момента (уровня зрелости). В какой-то момент команду придется делить на саппорт и развитие, но это будет потом.

Вариант 2 - когда уже что-то есть

Поехали дальше. Если экспертиза по ML уже есть, то осталось ли место аутсорсу? Мой ответ - однозначно да. И место ему в сложных кейсах, когда все быстрые победы уже достигнуты, а все остальное требует серьезной экспертизы. Причем кейсы могут быть сложные не обязательно с точки зрения математики (хотя не без этого), сколько с точки зрения именно бизнеса. Кстати если кто считает, что внедрение ML модели в жизнь это просто - значит вам везло. Это ни разу не просто и к внедрению любой модели лучше относится как к отдельному проекту. Но подробнее об этом я лучше порассуждаю потом, благодарная тема. Так вот когда нужно создать новый бизнес-процесс, частью которого будет новая модель, или требуется модернизировать существующие процессы, чтобы модель была максимально эффективной, то зачастую проще и правильнее привлечь внешнего подрядчика, который сможет:

• Показать потенциальный эффект от комплексного подхода

• Поделиться примерами подобных внедрений и эффектов (в идеале организовать референс визит)

• Создать модель

• Разработать, описать и помочь внедрить целевой бизнес-процесс

• Поставить правильные метрики контроля и наладить мониторинг

• Оценить полученный эффект

Соответственно в части ML разделение зон ответственности будет примерно тем же самым, что и в первом случае. Но поскольку создание модели это далеко не самая сложная часть, то самое интересное и основное отличие - это бизнес-экспертиза и проектный подход.

И лирическое отступление

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

И на нем наглядно видно, что подрядчиков можно поделить условно на:

• Тех кто не представляет интереса - ни математики ни бизнеса, зачем такие нужны?

• Математики-Академики - полезны, для специфических задач

• Бизнес-консультанты - могут быть полезны, при условии, что с математикой вы их подстрахуете (или сделаете за них)

• ТОП-экспертиза - это, конечно, классно и универсально, но очень дорого.

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

• ТОП-чик это дорого. Окупит ли ожидаемый эффект привлечение компанию такого уровня?

• Недостающую часть экспертизы (бизнес или математическую) вам придется закрывать собой, выбирайте что у вас сильнее развито.

• Но не питайте иллюзий - недостающую бизнес-экспертизу для случая внедрения нового бизнес-процесса вы скорее всего не закроете. Иначе зачем вам помощники?

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

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

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

Выводы

В общем в сухом остатке, традиционно варианта три - два крайних и смешанный:

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

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

3. Смешанные сценарии, в частности:

   1. Для первых шагов с ML, когда работа подрядчика закроет почти полный цикл разработки

   2. В дальнейшем - PoC силами аутсорса, адаптация и поддержка успешных кейсов - своими силами

   3. По мере развития экспертизы - привлечение внешнего ресурса для проработки и внедрения сложных случаев