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

Антон Деменев -

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

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

Что входит в процесс передачи проекта

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

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

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

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

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

Как организовать передачу проекта от подрядчика заказчику

1. Заранее уведомить об этом аутсорс-команду, договориться об условиях ее выхода из проекта

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

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

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

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

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

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

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

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

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

3. Провести онбординг и погрузить инхаус-команду в планы развития проекта

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

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

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

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

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

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

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

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

5. Запланировать развитие проекта, внедрить DevOps-практики 

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

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

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

6. Выстроить процесс параллельной работы над проектом инхаус и аутсорс команд 

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

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

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

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

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