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

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

Определение стратегии развития продукта

Мы предлагаем две модели развития проекта: переход проекта на поддержку или передача инхаус.

Проект на поддержке

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

Передача проекта инхаус

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

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

Мы организуем передачу проекта инхаус в четыре этапа, чтобы обеспечить бесшовность перехода.

Этап 1. Формирование инхаус-команды

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

Некоторые задачи лучше оставить студии. К примеру, любому проекту время от времени нужен UX/UI-дизайнер, чтобы добавлять новые экраны или вносить изменения в интерфейс. В небольшом продукте нагрузка на дизайнера будет низкой, поэтому выгоднее получать его услуги на стороне. А если речь идет об огромных проектах вроде мобильных приложений для банков, удобнее нанять в команду дизайнера.

В идеале на момент принятия решения о переходе инхаус нужны два специалиста:

1. Продакт-менеджер. Генерирует гипотезы, расставляет приоритеты, составляет планы на развитие.
2. Технический директор. Отвечает за архитектуру, инструменты разработки, совместимость технологий.

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

Этап 2. Погружение инхаус-команды в разработку продукта

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

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

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

Главная задача — сохранить при передаче качество продукта и запланированные сроки разработки. 

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

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

Этап 3. Передача управления разработкой

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

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

С точки зрения разработки, важнейшим инструментом является CI/CD-комбайн, в роли которого у нас выступает Jenkins. Благодаря нему мы можем быть уверены, что кодовая база проекта всегда стабильна, все написанные автотесты проходят корректно, все необходимые сборки быстро собираются в облаке без использования ресурсов локальной машины разработчика. Ключи, подписание сборки, необходимые конфигурации для поставки — все это один раз настраивается в Jenkins и значительно ускоряет time-to-market.

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

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

Чек-лист: результаты приемки проекта инхаус

Собрана инхаус-команда:

• Тимлиды по каждому направлению/платформе
• Необходимое для развития продукта количество разработчиков и специалистов по тестированию.
• Налажены процессы разработки проекта.
• Передан исходный код проекта и документация по API.

Сформирована дизайн-система:

• Передан UI-кит: набор основных сквозных компонентов, правила использования шрифтов и цветов
• Обозначены сценарии основных действий
• Собраны макеты всех экранов

База знаний по проекту:

• Техническое задание
• Описание бизнес-требований
• Бэклоги задач для планирования следующих спринтов
• Паспорт проекта с доступами к системам, которые используются в проекте

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