Как происходит передача it-проекта из аутсорса в инхаус-команду

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

Сложные цифровые продукты и высоконагруженные сервисы требуют непрерывной поддержки и развития. Поэтому, завершив разработку MVP, диджитал-компании предлагают разные форматы сотрудничества: 

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

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

Что учесть перед переходом на внутреннюю разработку

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

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

Также нужно учитывать ещё два момента:

1. Инхаус-команда может работать медленнее, чем IT-аутсорс, потому что старается распределять ресурсы равномерно. Диджитал-продакшны получают оплату за выполненные работы, поэтому развивают производственные процессы так, чтобы показывать результат быстро.

2. Поиск и найм в штат сотрудников — тоже долгий процесс. Чем выше грейд специалиста, тем тяжелее его найти. Кроме того, кто-то должен фильтровать отклики и оценивать кандидатов. Нужно нанимать рекрутера, который возьмёт поиск команды на себя, либо обращаться в HR-агентство.

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

Чек-лист: передаём проект внутренней команде

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

Этап 0. Помочь нанять сотрудников в штат

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

Этап 1. Подготовить документацию 

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

Что может подготовить подрядчик:

1. Документацию по общим настройкам, инфраструктуре, логике работы системы.
2. Документацию по бэкенду и фронтенду, описание API и интеграций.
3. Глоссарий по проекту, планы работ, гайды по запуску, тестированию и релизам.
4. Документацию по тестированию: тест-кейсы и отчёты о запуске автотестов.
5. Инструкции по работе с административной панелью.
6. Внешнюю документацию для пользователей, партнёров и надзорных органов. 

Этап 2. Завершить текущие задачи и гарантийные обязательства

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

Этап 3. Передать доступы и репозиторий

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

Какие доступы передают:

1. к серверу;
2. к административной панели;
3. к интеграционным сервисам;
4. в репозиторий;
5. к хостингу;
6. к управлению доменом;
7. другое.

Этап 4. Передать все отчуждаемые артефакты работ

Сюда входят: 

1. проектные процессы: флоу разработки и бэклог;
2. пользовательские истории; 
3. результаты конкурентного анализа и бенчмаркинга; 
4. технические задания; 
5. прототипы; 
6. дизайн-макеты; 
7. UI-kit и дизайн-система.

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

Хороший тон не просто передавать папку с артефактами, но и сделать файл-рубрикатор со ссылками и пояснениями, что внутри.

Этап 5. Провести онбординг новой команды

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

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

Итого

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

Чек-лист: что проверить после передачи проекта инхаус

1. Убедитесь, что вам предоставили всю документацию, которую вы запросили в договоре.
2. Проверьте, есть ли у вас доступы к серверу, админке, интеграционным сервисам, хостингу, управлению доменом и в репозиторий.
3. Убедитесь, что вам передали все артефакты, которые использовали при разработке проекта.

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

Написать нам.