Как найти программистов для разработки и перевести проект инхаус

Если у бренда есть сайт, это не значит, что теперь о вас все знают. 88% времени за смартфоном пользователи проводят в приложениях. Это означает, что даже крупным компаниям с торговыми площадками нужен трафик клиентов из приложений — по сравнению с сайтами конверсия в приложениях выше на 157%. Поэтому важно найти программистов, которые помогут вам создать приложение под задачи бизнеса. Так вы сможете охватить больше потенциальных клиентов и повысить продажи.
Для разработки приложения у бизнеса есть два варианта: использовать готовое «коробочное» решение или найти разработчиков и создать свой продукт с нуля. Первый путь поможет решить вопрос быстро и бюджетно. Собственная разработка поможет создать более современный продукт, который подстраивается под пользователя. В нём проще использовать персонализацию, внедрять современные механики и в целом выделять его среди однотипных приложений конкурентов.
Если высокая конкуренция и требовательные клиенты — это про ваш бизнес, самое время нанять программистов. Успех проекта зависит от опыта и навыков команды или отдельных специалистов. Ошибочный выбор приведёт к выходу «сырого» приложения с задержкой.
У нас более 13 лет опыта разработки приложений, их развития и поддержки. В статье расскажем, по каким признакам искать и нанимать программистов для быстрой реализации вашей идеи. А ещё покажем, как передать приложение после релиза инхаус-команде для дальнейшей поддержки плавно и бесшовно. Так, как будто разработчики вообще не менялись.
Где найти программистов: от фриланса к аутсорсу
Браться за задачу по созданию приложения правильно с выбора формата сотрудничества и поиска программистов. Рассмотрим три основных варианта: поиск фрилансеров, наём в штат и аутсорсинг команды. У каждого пути есть свои особенности, преимущества и недостатки.
Фрилансеры — недорого и для простых задач
Фрилансеры — это независимые специалисты (разработчики, дизайнеры, тестировщики и т. д.) работающие на проектной основе. Нанять программистов на фрилансе можно через специализированные платформы (Upwork, Freelancer, Toptal), на популярных карьерных порталах (hh.ru, LinkedIn) и по рекомендациям.
Преимущества работы с фрилансерами:
- Минимум бюрократии: договорённости заключаются быстро, без сложных процедур оформления, а все обсуждения ведутся напрямую с исполнителем.
- Гибкий график: с фрилансером можно договориться о работе раньше или позднее стандартных часов. Если он работает в другом часовом поясе, ему это может быть даже предпочтительнее.
- Скорость работы: фрилансеры заинтересованы в быстром завершении проектов, чтобы перейти к следующему.
- Экономичность: итоговая стоимость сотрудничества с фрилансерами часто ниже, чем у веб-студий или штатных сотрудников.
Недостатки:
- Риски: поскольку фрилансеры зачастую ведут несколько проектов одновременно, они могут нарушить сроки сдачи проекта или выйти из него, что приведёт к финансовым издержкам.
- Сложности поиска: найти квалифицированного и надёжного специалиста по рекомендациям или точно оценить навыки нового человека довольно трудно и требует вложений.
- Потребность в микроменеджменте: при работе с большим числом фрилансеров компании, скорее всего, потребуется отдельный менеджер для взаимодействия с ними.
При поиске разработчиков-фрилансеров важно не забыть о таких шагах, чтобы чтобы потом получить проект в срок:
- Изучите отзывы других заказчиков.
- Создавайте договор даже для проекта с небольшим бюджетом, в котором точно указаны дедлайны и условия сотрудничества.
- Убедитесь в наличии резервного плана на случай, если фрилансер откажется от работы без предупреждения.
Штатная команда — для больших компаний с длительными проектами
Собственная команда разработчиков подходит для долгосрочных проектов, требующих полного погружения. Такой подход также оправдан для крупных компаний с доходом от 1 млн долларов в год. Найти разработчиков можно через HeadHunter и аналогичные площадки, а также кадровые агентства.
Преимущества работы со штатной командой:
- Командный дух: работа внутри одного коллектива сплачивает с коллегами и мотивирует расти и развиваться вместе.
- Долгосрочные отношения: за время работы над проектами, сотрудник может раскрыть свои сильные стороны и освоить новые навыки. В следующих проектах он покажет ещё большую эффективность.
- Надёжность: сотрудник не может покинуть проект одним днём. Значит, ситуация, когда человек ушёл и некому подхватить работу, маловероятна.
Недостатки:
- Высокие затраты: зарплаты, страховки и отпуска требуют ежемесячной оплаты, даже если в данный момент у сотрудника нет задач.
- Сложности найма: поиск сотрудников и их адаптация к корпоративной культуре требуют времени и ресурсов HR-департамента.
Если вы решили нанимать программистов в штат, определите, какие специалисты нужны (разработчики, тестировщики, дизайнеры) и тщательно проработайте вопрос организации рабочего места (когда предполагается работа в офисе) и систему мотивации (бонусы, обучение, карьерный рост).
Аутсорс — когда нужно приложение под ключ
Ещё один способ найти разработчиков — сотрудничество с командой на аутсорсе. Такие студии и агентства берут на себя полный цикл работы: от проектирования до тестирования и технической поддержки.

Преимущества сотрудничества с аутсорс-командой:
- Прозрачность: все этапы работы, сроки и стоимость фиксируются в договоре.
- Многозадачность: в студии работают специалисты разных направлений, что позволяет закрывать все потребности проекта.
- Отсутствие микроменеджмента: за процесс отвечает проектный менеджер, который координирует работу команды. В то время как команда заказчика может сфокусироваться на основном направлении работы.
- Опыт: успешные студии могут представить портфолио прошлых проектов и обладают доказанным релевантным опытом.
Недостатки:
- Трудности коммуникации: если нанять программистов из удалённого региона, можно столкнуться со сложной коммуникацией из-за разницы во времени и культурных особенностей.
- Качество работы: не все команды оправдывают ожидания, поэтому важно тщательно анализировать кандидатов при отборе.
Как выбрать разработчиков для проекта
Выбор между фрилансерами, штатной командой и командой на аутсорсе зависит от специфики проекта, бюджета и долгосрочной стратегии. Если нужен быстрый и бюджетный результат — подойдут фрилансеры. Для долгосрочных проектов с постоянными доработками выгоднее нанять программистов в штат. Сотрудничество с аутсорс-командой подойдёт, когда требуется полный цикл разработки под ключ. Если вы выбрали последний вариант, вот на что стоит обратить внимание:
Изучите портфолио и отзывы на независимых платформах (Clutch, GoodFirms). Обратите внимание на проекты, сходные с вашим по тематике и сложности. Например, наши продукты из года в год оказываются финалистами и победителями номинаций авторитетных рейтингов, а Рейтинг Рунета присвоил нам первое место среди разработчиков приложений для крупного бизнеса.

Проверьте наличие опыта в релевантной сфере. Специализация команды — залог более глубокого понимания ваших потребностей. Все кейсы нашей команды с лидирующими игроками ритейла, фудтеха и банкинга изучайте на сайте.
Заключите договор с чётким описанием сроков, этапов и стоимости. Для большинства проектов это такие этапы: исследование, проектирование, разработка, тестирование и релиз приложения. Договор защитит от непредвиденных расходов и задержек, если студия нарушит договорённости.
При этом важно выбрать оптимальную модель сотрудничества:
- Time & Material подразумевает оплату только за проделанную работу, что делает эту модель гибкой. Подойдёт компаниям, которые активно развиваются, и понимают, что требования к проекту могут меняться в процессе разработки.
- Fixed Price — модель сотрудничества с точно определённым бюджетом и сроками до начала работ. Подойдёт для небольших проектов и ситуаций, когда изменения рыночных условий и других факторов слабо влияют на создаваемое приложение.
Обсудите коммуникацию и отчётность. Уточните, как часто вы будете получать обновления о ходе работы и как студия будет решать возникающие вопросы.
Выберите методологию разработки. В зависимости от специфики проекта и потребностей бизнеса, одному проекту подойдёт гибкий Agile-подход, а другому — точный линейный Waterfall. О преимуществах и недостатках главных 6 методологий рассказали в блоге.
Договоритесь, как команда будет предоставлять техническую поддержку после релиза. Или договоритесь о процессе передаче проекта для поддержки внутренним специалистам после релиза.
Как принимать готовое приложение после релиза
Поиск разработчиков позади, выбранная команда закончила с разработкой, а приложение вышло в цифровых сторах. Внешние специалисты могут продолжить поддерживать его уменьшенным составом или передать команде внутри компании. Мы в Surf предлагаем две модели развития проекта: переход проекта на поддержку или передача инхаус.
Проект на поддержке
Наша команда решает возникающие проблемы и анализирует текущее состояние продуктов, чтобы генерировать новые идеи. Эти идеи обсуждаются с продакт-менеджером на стороне клиента, и после согласования уходят в разработку.
В таком формате мы с 2015 года поддерживаем и улучшаем мобильное приложение Магнита, а с 2018 — приложение Банка ЗЕНИТ. В обоих кейсах предложенные нами механики и редизайн увеличили активность пользователей приложения в среднем на 20%.

Передача проекта команде инхаус
Поддерживать проект инхаус сложнее: для этого нужна техническая экспертиза либо готовность инвестировать значительные средства в её развитие. Такой вариант подходит продуктам, которые являются ядром вашей компании. Это не подойдёт для проектов на этапе тестирования.
Чтобы процесс передачи прошёл гладко, подумайте о нём ещё на этапе проектирования продукта. Для этого мы проводим CJM-воркшоп, где вместе с командой клиента строим карту пути пользователя, составляем таблицу функциональности будущего приложения, бэклог идей и инсайтов, роадмап его развития. Так легче передать проект: не придётся придумывать что-то с нуля, достаточно актуализировать уже готовые решения.
Как мы передаём проект инхаус: пошаговый план
Мы организуем передачу проекта инхаус в четыре этапа, чтобы клиент получил всю документацию и слаженную работу приложения.

Этап 1. Формирование инхаус-команды
Сначала мы помогаем с подбором кандидатов: согласовываем требования и подключаем тимлидов для проведения технических интервью. HR-специалистам заказчика нужно заниматься только поиском и первичным собеседованием. Мы выдвигаем требования и проводим собеседования как для себя — никаких поблажек.
Некоторые задачи лучше оставить студии. К примеру, любому проекту время от времени нужен UX/UI-дизайнер, чтобы добавлять новые экраны или вносить изменения в интерфейс. В небольшом продукте нагрузка на дизайнера будет низкой, поэтому выгоднее получать его услуги на стороне. Если речь идёт о масштабном банковском приложении — удобнее нанять дизайнера в команду.
В идеале на момент принятия решения о переходе инхаус нужны два специалиста:
- Продуктовый менеджер. Генерирует гипотезы, расставляет приоритеты, составляет планы на развитие.
- Технический директор. Отвечает за архитектуру, инструменты разработки, совместимость технологий.
Такие сотрудники есть в большинстве крупных компаний, но могут отсутствовать в стартапах. В таком случае мы тоже поможем найти их.
Этап 2. Погружение инхаус-команды в продукт
В начале второго этапа всем руководит наш тимлид, а развивают продукт наши разработчики. Постепенно вводим новых сотрудников в свою инфраструктуру: Jira, Confluence, мессенджеры, репозитории — как если бы они были сотрудниками Surf, которые работают на проекте. С этого начинается их погружение в продукт.
Команде не придётся тратить время на организационные моменты: изучение таск-менеджера, контроль дедлайнов, распределение обязанностей, подход к тестированию, процесс подготовки к публикации. Эти процессы уже налажены у нас в компании, и мы готовы делиться опытом.

Сотрудничество внешней и инхаус-команды необходимо, чтобы новая команда могла следовать стандартам проекта. Это помогает избежать ситуаций, когда темпы и эффективность разработки ухудшаются из-за разных взглядов на рабочие процессы.
Главная задача — сохранить при передаче качество продукта и запланированные сроки разработки.
На этом этапе мы следим за работой новых участников команды и даём им подробную оценку. Оцениваем количеством багов, контролируем время на решение задач, следим за соблюдением общих правил разработки проекта. Если новый член команды не соответствует требованиям проекта — дадим обратную связь и предложим подыскать замену.
В результате заказчик получает полностью укомплектованную инхаус-команду с налаженными процессами разработки. При необходимости количество специалистов будет наращиваться и по окончании этапа.
Этап 3. Передача управления разработкой
Для плавного перехода к самостоятельной разработке на стороне клиента наши тимлиды передают всю экспертизу в управлении и процессах. Они продолжают курировать проекты, формулируют задачи и контролируют их выполнение, параллельно обучают клиентского тимлида.
Вместо полного переноса нашей внутренней инфраструктуры, которая включает специфические инструменты для финансовой аналитики и внутренней коммуникации, мы делаем акцент на развёртывании ключевых элементов, критически важных для эффективности разработки, в первую очередь — CI/CD.
Главный элемент передачи — настройка и обучение работе с Jenkins, нашим CI/CD-комбайном. Это даёт стабильность кодовой базы, автоматизированное тестирование и быструю сборку приложений в облаке. В итоге это сокращает время вывода продукта на рынок.
Интеграция Jenkins с Jira автоматизирует управление задачами, исключая ручные обновления статусов и автоматически связывая задачи с версиями сборок. Когда ведущий разработчик клиента уверенно пользуется системой, мы передаём весь функционал управления. При этом предлагаем опциональную поддержку в виде аутсорсинга контроля качества, включая помощь в настройке автоматизированного тестирования.
Чек-лист: результаты приёмки проекта инхаус
Найти программиста, который всё сделает как надо — задача не из лёгких, но если подойти к процессу грамотно, получится собрать сильную команду и успешно запустить проект. Используйте сразу несколько каналов поиска, тщательно проверяйте кандидатов и обращайте внимание не только на их технические навыки, но и на умение работать в команде.
Успешная разработка — это не только код, но и прозрачное взаимодействие специалистов. Выбирайте программистов с учётом ваших задач и бизнес-целей, и тогда ваше приложение будет развиваться и приносить результат. Вот небольшой чек-лист, который поможет проверить, всё ли вы забрали от аутсорс-разработчиков.
Вы собрали инхаус-команду, когда:
- У вас есть тимлиды по каждому направлению/платформе и достаточное количество специалистов для развития продукта и тестирования.
- Наладили процессы разработки проекта.
- Передали команде исходный код проекта и документацию по API.
Вы сформировали дизайн-систему, если:
- Инхаус-команда получила UI-кит: набор основных сквозных компонентов, правила использования шрифтов и цветов.
- Проработали сценарии основных действий.
- Собрали макеты всех экранов.
База знаний по проекту готова, когда включает в себя:
- Техническое задание.
- Описание бизнес-требований.
- Бэклоги задач для планирования следующих спринтов.
- Паспорт с доступами к системам, которые используются в проекте.
Мы помогаем на каждом этапе разработки: формируем команду, погружаем в продукт, оцениваем качество работы и выходим из проекта только в том случае, когда вы можете продолжить разработку без потерь в качестве и скорости. Делаем приложения за 6 месяцев.