11 октября 2023

ВРЕМЯ ПРОЧТЕНИЯ — 4 МИН

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

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

Нам в CleverPumpkin не раз приходилось передавать мобильные приложения инхаус-команде. Собрали советы и рекомендации по этому процессу, которые будут полезны и для студий разработчиков, и для заказчиков.
How to upload an app to the App Store and not get rejected
Из чего должен состоять процесс передачи проекта, чтобы все прошло гладко
Трансфер проекта включает несколько этапов и длится от одного месяца. Иногда он занимает значительно больше времени, если работа над приложением велась в течение нескольких лет и накопилось большое количество информации. Мы в CleverPumpkin выстраиваем этот процесс таким образом:

  1. Знакомство с проектом

  2. Передача базы знаний и документации

  3. Совместная работа

  4. Переход управления разработкой к инхаус-команде

  5. Консультирование

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

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

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

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

В процессе работы мы даем подробную обратную связь, формулируем задачи, следим за соблюдением стандартов разработки проекта. Если что-то идет не так, разработчики CleverPumpkin предлагают пути решения проблемы.

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

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

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

Процесс перехода может показаться длинным, но именно такой путь поможет качественно подхватить работу над проектом и гармонично развивать его.
Чек-лист по итогу передачи проекта
1
Передана база знаний, документация и доступы
  • Техническое задание
  • Описание проектирования, бизнес-требований, тест-кейсы
  • Рекомендации по тестированию, релизам, функциям
  • Отчеты о запуске автотестов
  • Таблица событий аналитики
  • Паспорт с доступами ко всем сервисам с данными по проекту
  • Исходный код приложения и документация по API
2
Создана дизайн-система
  • Отправлен UI-kit, в котором собраны иконки, шрифты и цвета
  • Переданы пользовательские сценарии
  • Отданы макеты экранов
3
Организована работа команды
  • Набрано нужное количество специалистов для развития проекта
  • Команда знает все о продукте
  • Распределены зоны ответственности
  • Налажены рабочие процессы
Команда CleverPumpkin всегда по-максимуму вовлечена в процесс передачи проекта, потому что нам небезразлично будущее приложения, в которое мы вложили много времени и сил. Мы стараемся в полной мере передать инхаус-разработчикам наш опыт и знания по продукту и выходим только тогда, когда убеждены в их эффективности. Так и мы, и заказчик будем уверены, что скорость и качество разработки не снизятся и проект сможет успешно расти.
Другие статьи по теме: