Вы проделали большой путь и запустили приложение: нашли изучили рынок, составили задание, подготовили макеты, нашли команду разработки и проконтролировали процесс. Продукт готов и им уже пользуются клиенты. Время открывать шампанское? Не совсем. Уже совсем скоро ресурсы программистов могут понадобиться снова: чтобы разработать новые функции, исправить ошибки, повысить устойчивость системы.

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

Шаг 0. А нужна ли инхаус-команда?

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

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

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

Шаг 1. Начинайте не с разработчика

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

Шаг 2. Определите список ролей и подготовьте описание вакансии

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

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

Вот пример структуры описания роли, которую можно использовать:

• Название роли.
• Описание задач.
• Портрет человека, которого вы ищите.
• Формальные требования: какие нужны технологии и опыт.
• Описание проекта и команды.

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

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

Шаг 3. Выберите потенциальных членов команды 

Соберите отклики и отсейте тех, кто вам не подходит по профилю или опыту. С остальными проведите собеседование. Вот что стоит оценить в потенциальном кандидате:

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

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

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

Шаг 4. Организуйте тестовый день или испытательный срок

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

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

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

Шаг 5. Стройте процессы в команде

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

👉🏻 Система регулярного менеджмента. Например, можно работать спринтами. В начале каждого определять цель на ближайшее время, ставить и декомпозировать задачи. Проводить ежедневные статус-митинги. В конце спринта организовывать ретроспективу и демо: обсуждать, что сделали, что получилось, какие возникли проблемы. Давать регулярную обратную связь.

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

👉🏻 Организация технических процессов. Техническому лидеру команды стоит заняться тем, что разработка стала постоянным конвейером. Для этого должны появиться процессы тестирования, отдельные контуры для разработчиков, автоматизированные системы публикации обновлений.

Ещё у кода должна быть преемственность, чтобы новый член команды мог быстро в нём разобраться. Для этого может понадобиться документация, а также стандарты написания кода.

👉🏻 Синхронная работа разных команд. Со временем проект может разрастись и специалисты начнут работать обособленно: разработчики, дизайнеры и аналитики будут закрывать задачи отдельными командами. В этом случае нужно убедиться, что их работа удачно стыкуется. Например, дизайнеры обычно идут на 1–2 спринта впереди разработчиков, чтобы к тому моменту, когда задача попадает в работу, для неё уже были готовы макеты.

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

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

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

👉🏻 Сколько стоит приложение: разбираемся в смете проекта

👉🏻 Найти разработчиков: как выбрать формат работы с командой