Как бесшовно перевести IT-проект с аутсорса на инхаус. Чек-лист

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

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

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

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

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

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

Поэтому необходимо учесть два дополнительных аспекта:

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

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

При этом переход на инхаус-разработку несет в себе несомненные плюсы:

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

Жизнь интернет-магазина на разных этапах: какой должна быть команда и бюджет на развитие

Чек-лист: переводим проект на внутреннюю разработку

Основные этапы переноса — это подготовка документации по проекту, выполнение задач по договору, передача доступов и репозитория, передача артефактов работ и онбординг новой команды.

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

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

В рамках этой услуги подрядчик может предоставить следующие материалы:

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

Этап 2. Выполнение задач, предусмотренных договором и дополнительными соглашениями

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

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

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

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

Этап 3. Передача доступов и репозитория ответственному лицу, указанному в договоре

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

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

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

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

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

Один из ключевых инструментов — система CI/CD под управлением например, Jenkins. Она обеспечивает стабильность кодовой базы проекта, корректное выполнение автотестов и быструю сборку приложения в облаке. Это ускоряет процесс разработки и упрощает работу разработчиков.

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

Сюда могут быть включены:

• Проектные процессы, такие как flow разработки и бэклог.
• User Stories.
• Результаты исследований: конкурентный анализ, бенчмаркинг и другое.
• ТЗ.
• Прототипы и дизайн-макеты.
• UI-kit и дизайн-система.

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

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

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

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

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

Как правильно составить техническое задание на разработку интернет-магазина

Итого

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

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

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

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