Оглавление

    Как мы бесшовно передаем проекты в инхаус-команду

    Мы в 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-кит: набор основных сквозных компонентов, правила использования шрифтов и цветов
    • Обозначены сценарии основных действий
    • Собраны макеты всех экранов

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

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

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