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

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

Клиент занимался подбором, поиском и передачей проекта не один, а при помощи стороннего менеджера. Процесс длился порядка 4 месяцев и был разбит на несколько этапов.Такая длительность передачи была связана с объемом проекта, а также с тем, что у нас не было жесткого дедлайна.

Этап 1 – Знакомство и погружение

Погружение в проект, над которым мы работали более 7 лет – задача со звездочкой. Этап занял порядка 3-4 недель и начался с общего созвона команд. Мы познакомились, определили последующие шаги взаимодействия, зафиксировали зоны ответственности.

Также команде клиента требовалось с нуля настроить всю инфраструктуру на своей стороне: начиная от постановки задач в Jira, заканчивая настройкой CI/CD. Мы помогали разбираться в нюансах и отвечали на вопросы.

Этап 2 – Совместная работа

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

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

Этап 3 – Рефакторинг

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

Этот этап был последним для нас с точки зрения написания кода, но не последним во всем процессе.

Этап 4 - Консультирование

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

Документация

Мы передали следующую документацию:

Вся она хранилась на Google Drive, к которому клиенту был предоставлен доступ.

Список инструментов

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

Дизайн

Мы использовали Figma, которую клиент скопировал к себе и выдал нам доступ на редактирование до конца передачи проекта. То есть мы вели работы уже в пространстве заказчика. Этот вариант оказался удобнее, чем передавать права нашего документа.

Код

Мы передавали коды платформ iOS и Android, автотесты и backend. Изначально мы предоставили команде доступ к нашему репозиторию, а после завершения всех работ они скопировали себе актуальный репозиторий. Это самый простой вариант передачи.

Оплаты и счета

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

Техдолг

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

Учетные записи

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

Важные обстоятельства

Здесь мы хотим отметить моменты, которые периодически волновали нас и на которые стоит обратить внимание при приемке проекта и формировании команды.

Организация работы новой команды

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

Периодически мы замечали, что в команде клиента многие работали как будто сами по себе, и проекту это явно не на пользу. Чтобы сработаться, нужно время, и его стоит закладывать в план работ. А еще – понимать, что первые пару месяцев новая команда будет менее эффективной, чем старая.

Подбор менеджера

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

Фидбэк по команде

Больше всего при передаче проекта работали и контактировали с новой командой именно мы, а не сам клиент. Иногда нас смущали некоторые моменты коммуникаций или формата работы – и эту обратную связь мы периодически эскалировали до клиента. На наш взгляд, информация о том, как ведет себя команда «в бою», важна и может помочь в дальнейшем.

Синхронизация

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

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

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

Автор Юлия Ларионова

Редактор Елена Майорова