Как передать успешный MVP на разработку инхаус-команде

Разработку MVP часто отдают аутсорс-командам. Внешний подрядчик имеет больше ресурсов, чтобы быстро собрать работающий прототип приложения или сайта. А заказчик в это время может изучать рынок, продвигать будущий продукт и собирать собственную команду для его разработки. На этом этапе важна скорость запуска и тестирования гипотез, поэтому MVP создается максимально оперативно и дешево, без лишних трудозатрат на документацию, идеальную архитектуру, код и другие детали, ведь далеко не все идеи «выстреливают».

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

Технически процесс передачи MVP инхаус-команде не занимает много времени. Команда подрядчика передает заказчику доступ к используемым сервисам и репозиторий с библиотеками и кодом программ. При передаче проектов также принято отдавать заказчику документацию по проекту: техническое задание, описание настроек и инфраструктуры, логики работы системы, инструкции по работе с внешними сервисами, библиотеками и API. Но, поскольку при разработке MVP ключевым фактором является скорость, объем документации на таком проекте может быть существенно меньше. Чаще всего остаются лишь ключевые артефакты — список техдолга и описание основных частей проекта, которые будут активно дорабатываться (это могут быть как отдельные документы, так и подробные комментарии в коде).

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

Но прежде чем переходить к передаче артефактов, необходимо определиться с дальнейшей стратегией развития проекта и решить ряд организационных вопросов:

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

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

При передаче проекта время нужно не только заказчику, чтобы найти новую команду и подключить ее к проекту, но и подрядчику, чтобы найти сотрудникам новые задачи и параллельно участвовать в процессе передачи.

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

Найти новый проект аутсорс-команде можно в течение 1-2 месяцев, а вот на поиски и найм тимлида инхаус нужно запланировать не менее 3 месяцев, а вместе с погружением в проект — еще столько же. Итого, сообщить о передаче проекта можно за полгода. Это времени хватит и на поиски людей, и на проработку остальных организационных задач.

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

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

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

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

Важный момент: руководить командой совершенно точно должен штатный PM или тимлид, так что этого специалиста нужно найти в первую очередь.

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

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

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

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

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

Он более известен как Infrastructure as a Code (IaC). В тех случаях, когда требуется больше ресурсов — высокая скорость разработки, более высокие требования к устойчивости и работоспособности — IaC позволяет быстрее масштабировать ресурсы и сокращает риск ошибок, которые возникают при ручной настройке среды разработки. В дальнейшем команде разработки будет проще вносить изменения в работающее приложение, не отключая его — сервис останется доступным пользователям 24/7.

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

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

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

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

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

В основном команде подрядчика остаются незаконченные задачи по MVP, а также консультирование инхаус-команды.

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

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

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

Наша команда уже более пяти лет занимается реализацией проектов на Java и усилением команд по направлениям

• DevOps;
• Java разработка;
• Тестирование.

За время существования компании, мы принимали участие в работе над более чем 100 проектами различного объема и длительности.

Если перед вами стоят вызовы, для достижения которых вам может понадобится наша экспертиза, просто напишите нам,

• client@softwarecats.dev,
• https://t.me/alex_zarubin,
• или через любую форму на сайте.

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