Представьте: некая компания собирается внедрить Kubernetes. Внутри есть IT-отдел, но никто из штатных инженеров с этой технологией не сталкивался, поэтому руководитель отдает задачу на аутсорс. Команда аутсорсеров опытная, время есть. Что может пойти не так?
1. Потеря важных деталей
Прежде чем начать работу, любому подрядчику нужно осмотреться на местности. Какая у клиента задача? Какие технические решения используются? Почему именно такие? А что будет, если мы внедрим другое решение? Работа каких сервисов и команд изменится? Ответы на все эти вопросы важно получить до начала работы.
Проблема может возникнуть, если не все сотрудники заказчика, которые владеют нужной информацией, оповещены о приходе аутсорсной команды. К сожалению, такое случается, и заказчик утверждает техническое задание, в котором учтены не все важные детали.
К чему это приводит? В лучшем случае проблема всплывает во время презентации предварительных результатов работы.
— А вы учли, что мы позавчера новый сервис выкатили, который все меняет? — Впервые слышим об этом сервисе.
— Ну вот, надо учесть.
В худшем случае о проблеме становится известно уже на этапе сдачи работ. Инженеры заказчика пробуют внедрить, обнаруживают недостаток — и тут уже цензурно их реакцию не передать.
Совет. Если планируете работать с аутсорсной командой, оповестите всех заинтересованных участников внутри компании. Попросите предоставить нужные данные и задать любые вопросы, которые только могут возникнуть.
2. Замедление работы
Анализ и настройка инфраструктуры предполагает доступ ко всем серверам и программному обеспечению. Чтобы гарантировать заказчику, что доступы не попадут в руки мошенникам, исполнители подписывают NDA — соглашение о неразглашении, предусматривающее ответственность за любую утечку данных. Кроме того, все хранимые данные клиентов надежно шифруются, а вопросам безопасности уделяется важное внимание при работе инженеров с проектами.
Но бывают ситуации, когда заказчик не готов выдать исполнителю доступ к определенным сервисам или может дать только read only доступ. Значит ли это, что сотрудничество с исполнителем в таком случае невозможно? Нет, не значит. Исполнитель просто запрашивает нужную информацию у штатного сотрудника, у которого доступ есть.
Проблемы возникают, когда штатные сотрудники заказчика не предоставляют нужную информацию вовремя. Причин может быть много: некогда, замотался и забыл или «а это точно я должен делать?» Результат один — работа затягивается.
Совет. Выделите ответственного штатного сотрудника, обязанностью которого будет взаимодействие с аутсорсной командой. Лучше выбрать одного человека и убедиться, что у него будет достаточно времени на ответы исполнителям.
3. Конфликты
Когда предварительное исследование завершено и вся необходимая информация получена, команда исполнителей начинает работать. Взаимодействие идет через одного или нескольких штатных сотрудников, но в IT-отделе заказчика могут быть десятки человек, которых так или иначе коснутся изменения, внедряемые аутсорсером. И не все они могут быть с этими изменениями согласны.
Если перед началом работ руководители четко проговорили цели внедряемых решений, а после конкретизации технического задания показали его всем заинтересованным лицам и ответили на возникшие вопросы, то проблем быть не должно. Но что если нет? Тогда случаются неприятные разговоры в чатах.
— Ребята, мы закончили разворачивать новую архитектуру. Вот документация, пожалуйста, ознакомьтесь.
— Это что вообще такое?! Вас кто просил это делать?
— Ваш техлид Петр.
— ?!
Обычно дальше разговоров дело не идёт, но зачем портить друг другу настроение, если можно его не портить.
Совет. Четко проговаривайте цели внедряемых изменений для всей IT-команды. Показывайте план действий штатным сотрудникам до того, как внештатные начнут его воплощать. Настройте сотрудников на конструктивное взаимодействие.
4. Некачественное внедрение
Инфраструктура, на которой работает продукт или сервис, тесно связана с его архитектурой. Известный факт: нельзя просто так взять и внедрить Kubernetes. Если у вас был монолит, то прежде его придётся распилить на микросервисы.
Команда внештатных инженеров может подготовить Kubernetes-кластер, но распилить ваше приложение — нет.
Аналогично внештатные инженеры могут написать новый CI/CD пайплан, но они не могут заставить разработчиков им пользоваться. Поэтому чтобы результаты работы аутсорсной команды «прижились» внутри компании-заказчика, об этом нужно отдельно позаботиться.
Просто поговорить с сотрудниками будет недостаточно. В зависимости от ситуации могут потребоваться архитектурные и структурные изменения, которые обычно исходят от руководства.
Совет. Выделите время штатных сотрудников на обучение, а также на доработки, которые потребуются после окончания работ. Либо обсудите с подрядчиком возможность сопровождения проекта, пока команда не будет полностью готова с ним работать.
Как наладить работу штатных сотрудников с аутсорсерами
Как правило, избежать описанных выше проблем можно за счет простых действий.
- Согласовать внутри команды цели и задачи, с которыми вы обращаетесь к команде аутсорсеров. Оповестить всех заинтересованных лиц.
- Наладить обмен информацией между штатными и внештатными сотрудниками.
- Выделить время и ресурсы на приёмку и адаптацию внедрённых решений.
Если все это есть, то во взаимодействии не будет проблем. Конечно, если исполнитель действительно знает своё дело. Но иначе и быть не должно.
Статья основана на опыте компании Southbridge, которая более 14 лет поддерживает серверы и внедряет инфраструктурные проекты.
Партнерский материал
