Вернуться

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

26.09.2023

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • к серверу;
  • к административной панели;
  • к интеграционным сервисам;
  • в репозиторий;
  • к хостингу;
  • к управлению доменом;
  • другое.

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

Сюда входят: 

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

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

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

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

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

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

Итого

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

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

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

 

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

Другие наши статьи

Давайте обсудим ваш проект

Никита Храмов
Аккаунт-менеджер
Никита Храмов

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

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

Звоните, пишите

Давайте обсудим ваш проект

Никита Храмов
Аккаунт-менеджер
Никита Храмов

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

Заполняя данную форму, вы принимаете условия Соглашения об использовании сайта, и соглашаетесь с Правилами обработки и использования персональных данных
Блог