Во время разработки продукта в студии у заказчика появляется вопрос — как его развивать дальше: оставить в студии или продолжать со своей командой? Рассказываем о нашем опыте передачи проектов клиентам и помогаем определиться, ваш ли это вариант.
Наша студия Heads and Hands занимается разработкой мобильных экосистем, которые постоянно требуют поддержки и развития из-за появления в них новых партнеров и участников. Если внутри экосистемы что-то пойдет не так, это может сильно навредить бизнесу или способствовать его полному закрытию. Поэтому если заказчик решает развивать продукт самостоятельно, особенно важен момент его передачи из студии в команду заказчика. Все должно пройти так, будто команда и вовсе не менялась.
В статье делимся нашим опытом передачи проектов в инхаус-команду клиента и помогаем понять, подходит вам такой вариант развития событий или нет.
Этапы передачи проекта в инхаус
Уже на этапе разработки продукта мы вместе с клиентом планируем следующие шаги по развитию. Обычно это происходит в формате воркшопа, на котором мы делимся идеями развития и референсами по конкурентам, попутно собираем новые требования с клиента. Согласуем с клиентом видение того, как именно развивать продукт, и предлагаем несколько форматов дальнейшего развития.
Этап 1. Выбор формата развития продукта
Мы выделяем две основные модели развития: команда роста от студии и передача проекта в инхаус заказчику.
Выделяем команду роста на проект
Команда студии генерирует гипотезы по развитию на основе данных и предлагает их продакт-менеджеру со стороны клиента. После обсуждения и согласования гипотез с ним новые задачи уходят в разработку.
Такой гибкий подход позволяет подключать нужных специалистов по мере необходимости. Клиенту не нужно думать, чем занять команду, если нет задач для полной загрузки.
Про выделенную команду роста подробнее расскажем в отдельной статье, а здесь остановимся на втором варианте — передаче проекта клиенту в инхаус.
Передаем проект в инхаус
Такой вариант подойдет, если у компании-клиента есть сильная техническая и продуктовая экспертиза, продукт является ядром всего бизнеса, а бизнес готов инвестировать значительную часть бюджета в развитие продукта.
Мы передаем проект команде разработки заказчика в несколько этапов, чтобы сделать переход бесшовным. При необходимости помогаем в найме и формировании команды. Ниже в деталях рассмотрим, как организован этот процесс в Heads and Hands.
Результат этапа:
- Выбор модели развития продукта: с командой роста от студии или инхаус-командой.
Этап 2. Формирование инхаус-команды
В идеале, в момент принятия решения о передаче проекта в инхаус, в команде заказчика уже должны быть продакт-менеджер и технический директор. Первый отвечает за гипотезы, приоритеты задач, релизы и планы на развитие. Второй — за архитектуру, совместимость используемых технологий и сервисов, IT-инфраструктуру и набор инструментов разработки.
В крупных компаниях такие специалисты есть в 99% случаев. В стартапах и небольших компаниях продакт-менеджера и технического директора может не быть. В этом случае мы консультируем принимающих решение лиц по компетенциям данных специалистов, чтобы бизнес смог найти подходящих кандидатов.
Наша задача на этом этапе — помочь с подбором будущей инхаус-команды. Мы готовим требования к кандидатам, а HR-специалисты со стороны заказчиков занимаются поиском и первичным собеседованием. После того, как HR отберут подходящих специалистов, подключаем наших тимлидов и ведущих разработчиков проекта, для проведения технического интервью. Выбираем будущих тимлидов, разработчиков, тестировщиков как для себя — никаких поблажек и смягчений в требованиях.
На большой проект может потребоваться свой UX/UI-дизайнер, если в команде нет подходящего специалиста. Часто требуется внести небольшие изменения в интерфейс или сделать несколько дополнительных экранов — эти задачи можно оставить студии. В случае с супер-аппами или динамически развивающимися приложениями, в которых появляется множество новых разделов, зачастую удобнее нанять дизайнера во внутреннюю команду. При этом со студией стоит договориться о разработке дизайн-системы проекта.
Некоторым клиентам удобно, чтобы инхаус-команда работала в нашем офисе. Так новые сотрудники находятся в одной среде с разработчиками студии и могут обмениваться опытом и знаниями. В наших офисах есть зоны коворкинга, в которых инхаус-команда может работать вместе с нашей.
Результаты этапа:
- Сформированная инхаус-команда: тимлиды, разработчики, тестировщики.
Этап 3. Разработка смешанной командой
На этом этапе разработкой руководит тимлид студии, проектом занимаются разработчики студии, к ним постепенно подключается команда разработчиков и тестировщиков со стороны заказчика.
Основная цель — не затормозить сроки разработки, сохранить качество продукта и передать проекты, по которым дальше будет работать инхаус-команда.
Инхаус-команда может начать действовать в соответствии со своими представлениями об архитектуре и процессах разработки. Они могут не совпадать со стандартами, которые изначально разрабатывались для проекта. Так новая команда рискует проделать часть работы с нуля, замедлить темпы и эффективность разработки.
Совместная работа студии и инхаус-разработки позволяет избежать подобных ситуаций. Когда со стороны клиента появляется тимлид или разработчик, мы сразу погружаем его в процессы. Инхаус-команда не тратит время на рабочие моменты: как создавать задачи и подзадачи, в какой момент должен быть готов дизайн, кто проводит код ревью, как происходит тестирование, как готовятся новые версии к публикации. Все эти процессы уже отработаны студией, остается лишь передать опыт.
На этом же этапе даем заказчику обратную связь по тому, как справляются участники его команды. Смотрим, сколько багов совершает новый разработчик, сколько времени уходит на задачи и соответствует ли это предварительной оценке тимлида студии, как соблюдаются общие процессы разработки. Мы оцениваем разработчиков инхаус-команды также как своих. Если новый член команды не справляется — предлагаем найти замену.
Результаты этапа:
- Выстроенные процессы работы инхаус-команды.
- Постепенное наращивание объема инхаус-команды для соблюдения сроков и качества разработки.
- Обратная связь по испытательному сроку инхаус-разработчиков.
Этап 4. Трансфер управления разработкой
На этом этапе все еще остаются тимлиды студии: они декомпозируют задачи, отдают их в разработку, проверяют выполнение, контролируют качество кода, архитектуру и решения.
Тимлиды студии и заказчика работают вместе в течение одного-двух спринтов. Далее инициатива переходит на тимлидов заказчика, а тимлид студии остается в роли наблюдателя и постепенно выходит из процесса разработки.
Когда ведущий разработчик со стороны клиента полностью ориентируется в проекте, мы предлагаем два варианта развития событий:
- Полностью передаем задачи тимлидам и разработчикам заказчика и выходим из проекта.
Этот вариант работает, если в инхаус-команде хватает ресурсов для выполнения планов по разработке продуктов в установленные сроки.
- Передаем задачи тимлидам заказчика. Остается несколько разработчиков студии, которые дополняют инхаус-команду.
Если для соблюдения планов развития продукта у заказчика недостаточно собственных ресурсов, мы оставляем на проекте несколько своих сотрудников. Они продолжают работу с клиентом в формате time and material, то есть с платой за отработанные часы. В этот же момент клиент может заниматься поиском сотрудников, если планирует активное развитие продукта в долгосрочной перспективе. Если в дальнейшем потребуются небольшие доработки, то команда студии будет включаться в работу по мере необходимости.
Результаты этапа:
- Инхаус-тимлиды полностью погружены в проект: они знают все особенности архитектуры проекта и используемых компонентов, отлично ориентируются в функционале и особенностях реализации, а также могут ответить на любой вопрос по разработке.
- Проект полностью или частично передан команде заказчика.
- Сотрудники студии подключаются при необходимости.
Этап 5. Инхаус-разработка
Разработка полностью ведется командой клиента. Штатный тимлид студии при необходимости консультирует инхаус-команду. Через какое-то время, например, через месяц, мы можем провести аудит и ревью работы команды заказчика. Это позволит проконтролировать качество разработки и эффективность самостоятельной работы инхаус-команды.
Клиент может обратиться в студию, если скорость развития продукта необходимо повысить, а сил инхаус-команды не хватает. Разработчики студии знают проект, поэтому они быстро включатся в разработку на любом этапе.
Результаты этапа:
- Разработка управляется инхаус-тимлидом и ведется командой клиента.
- Проводим аудит работы инхаус-команды.
- Появляется возможность оперативно увеличить скорость разработки, подключив бывшую проектную команду из студии.
Результаты передачи проекта в инхаус
Набор, обучение, онбординг инхаус-команды происходит на стороне студии. В результате заказчик получает выстроенные процессы и сработанную команду, которая полностью погружена в проект и может заняться разработкой на полной мощности.
Создание собственной команды с нуля может стать длительным процессом: он займет от нескольких месяцев до года и даже дольше, особенно если в компании нет нужного уровня технической и продуктовой экспертизы. Мы советуем описанный выше вариант перехода, который позволит быстро запустить продукт и бесшовно передать его инхаус-команде.
Остались вопросы по вариантам развития вашего продукта? Напишите нам, поможем определиться!
