Оглавление

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

    Где найти разработчика — Обложка

    Если у бренда есть сайт, это не значит, что теперь о вас все знают. 88% времени за смартфоном пользователи проводят в приложениях. Это означает, что даже крупным компаниям с торговыми площадками нужен трафик клиентов из приложений — по сравнению с сайтами конверсия в приложениях выше на 157%. Поэтому важно найти программистов, которые помогут вам создать приложение под задачи бизнеса. Так вы сможете охватить больше потенциальных клиентов и повысить продажи.

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

    Если высокая конкуренция и требовательные клиенты — это про ваш бизнес, самое время нанять программистов. Успех проекта зависит от опыта и навыков команды или отдельных специалистов. Ошибочный выбор приведёт к выходу «сырого» приложения с задержкой.

    У нас более 13 лет опыта разработки приложений, их развития и поддержки. В статье расскажем, по каким признакам искать и нанимать программистов для быстрой реализации вашей идеи. А ещё покажем, как передать приложение после релиза инхаус-команде для дальнейшей поддержки плавно и бесшовно. Так, как будто разработчики вообще не менялись.

    Где найти программистов: от фриланса к аутсорсу

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

    Фрилансеры — недорого и для простых задач

    Фрилансеры — это независимые специалисты (разработчики, дизайнеры, тестировщики и т. д.) работающие на проектной основе. Нанять программистов на фрилансе можно через специализированные платформы (Upwork, Freelancer, Toptal), на популярных карьерных порталах (hh.ru, LinkedIn) и по рекомендациям.

    Преимущества работы с фрилансерами:

    • Минимум бюрократии: договорённости заключаются быстро, без сложных процедур оформления, а все обсуждения ведутся напрямую с исполнителем.
    • Гибкий график: с фрилансером можно договориться о работе раньше или позднее стандартных часов. Если он работает в другом часовом поясе, ему это может быть даже предпочтительнее.
    • Скорость работы: фрилансеры заинтересованы в быстром завершении проектов, чтобы перейти к следующему.
    • Экономичность: итоговая стоимость сотрудничества с фрилансерами часто ниже, чем у веб-студий или штатных сотрудников.

    Недостатки:

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

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

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

    Штатная команда — для больших компаний с длительными проектами

    Собственная команда разработчиков подходит для долгосрочных проектов, требующих полного погружения. Такой подход также оправдан для крупных компаний с доходом от 1 млн долларов в год. Найти разработчиков можно через HeadHunter и аналогичные площадки, а также кадровые агентства.

    Преимущества работы со штатной командой:

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

    Недостатки:

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

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

    Аутсорс — когда нужно приложение под ключ

    Ещё один способ найти разработчиков — сотрудничество с командой на аутсорсе. Такие студии и агентства берут на себя полный цикл работы: от проектирования до тестирования и технической поддержки.

    Преимущества сотрудничества с аутсорс-командой:

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

    Недостатки:

    • Трудности коммуникации: если нанять программистов из удалённого региона, можно столкнуться со сложной коммуникацией из-за разницы во времени и культурных особенностей.
    • Качество работы: не все команды оправдывают ожидания, поэтому важно тщательно анализировать кандидатов при отборе.
    Закажите разработку приложения под ключ
    Сэкономьте до 50% ресурсов благодаря кроссплатформенным технологиям.
    Узнать детали

    Как выбрать разработчиков для проекта

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

    Изучите портфолио и отзывы на независимых платформах (Clutch, GoodFirms). Обратите внимание на проекты, сходные с вашим по тематике и сложности. Например, наши продукты из года в год оказываются финалистами и победителями номинаций авторитетных рейтингов, а Рейтинг Рунета присвоил нам первое место среди разработчиков приложений для крупного бизнеса.

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

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

    При этом важно выбрать оптимальную модель сотрудничества:

    • Time & Material подразумевает оплату только за проделанную работу, что делает эту модель гибкой. Подойдёт компаниям, которые активно развиваются, и понимают, что требования к проекту могут меняться в процессе разработки.
    • Fixed Price — модель сотрудничества с точно определённым бюджетом и сроками до начала работ. Подойдёт для небольших проектов и ситуаций, когда изменения рыночных условий и других факторов слабо влияют на создаваемое приложение.

    Обсудите коммуникацию и отчётность. Уточните, как часто вы будете получать обновления о ходе работы и как студия будет решать возникающие вопросы.

    Выберите методологию разработки. В зависимости от специфики проекта и потребностей бизнеса, одному проекту подойдёт гибкий Agile-подход, а другому — точный линейный Waterfall. О преимуществах и недостатках главных 6 методологий рассказали в блоге.

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

    Как выбрать методологию разработки
    Сократить time-to-market и соблюсти все требования проекта.
    Узнать

    Как принимать готовое приложение после релиза

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

    Проект на поддержке

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

    В таком формате мы с 2015 года поддерживаем и улучшаем мобильное приложение Магнита, а с 2018 — приложение Банка ЗЕНИТ. В обоих кейсах предложенные нами механики и редизайн увеличили активность пользователей приложения в среднем на 20%.

    Передача проекта команде инхаус

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

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

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

    Как мы передаём проект инхаус: пошаговый план

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

    Этап 1. Формирование инхаус-команды

    Сначала мы помогаем с подбором кандидатов: согласовываем требования и подключаем тимлидов для проведения технических интервью. HR-специалистам заказчика нужно заниматься только поиском и первичным собеседованием. Мы выдвигаем требования и проводим собеседования как для себя — никаких поблажек.

    Некоторые задачи лучше оставить студии. К примеру, любому проекту время от времени нужен UX/UI-дизайнер, чтобы добавлять новые экраны или вносить изменения в интерфейс. В небольшом продукте нагрузка на дизайнера будет низкой, поэтому выгоднее получать его услуги на стороне. Если речь идёт о масштабном банковском приложении — удобнее нанять дизайнера в команду.

    В идеале на момент принятия решения о переходе инхаус нужны два специалиста:

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

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

    Этап 2. Погружение инхаус-команды в продукт

    В начале второго этапа всем руководит наш тимлид, а развивают продукт наши разработчики. Постепенно вводим новых сотрудников в свою инфраструктуру: Jira, Confluence, мессенджеры, репозитории — как если бы они были сотрудниками Surf, которые работают на проекте. С этого начинается их погружение в продукт.

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

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

    Главная задача — сохранить при передаче качество продукта и запланированные сроки разработки.

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

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

    Этап 3. Передача управления разработкой

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

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

    Главный элемент передачи — настройка и обучение работе с Jenkins, нашим CI/CD-комбайном. Это даёт стабильность кодовой базы, автоматизированное тестирование и быструю сборку приложений в облаке. В итоге это сокращает время вывода продукта на рынок.

    Интеграция Jenkins с Jira автоматизирует управление задачами, исключая ручные обновления статусов и автоматически связывая задачи с версиями сборок. Когда ведущий разработчик клиента уверенно пользуется системой, мы передаём весь функционал управления. При этом предлагаем опциональную поддержку в виде аутсорсинга контроля качества, включая помощь в настройке автоматизированного тестирования.

    Чек-лист: результаты приёмки проекта инхаус

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

    Успешная разработка — это не только код, но и прозрачное взаимодействие специалистов. Выбирайте программистов с учётом ваших задач и бизнес-целей, и тогда ваше приложение будет развиваться и приносить результат. Вот небольшой чек-лист, который поможет проверить, всё ли вы забрали от аутсорс-разработчиков.

    Вы собрали инхаус-команду, когда:

    • У вас есть тимлиды по каждому направлению/платформе и достаточное количество специалистов для развития продукта и тестирования.
    • Наладили процессы разработки проекта.
    • Передали команде исходный код проекта и документацию по API.

    Вы сформировали дизайн-систему, если:

    • Инхаус-команда получила UI-кит: набор основных сквозных компонентов, правила использования шрифтов и цветов.
    • Проработали сценарии основных действий.
    • Собрали макеты всех экранов.

    База знаний по проекту готова, когда включает в себя:

    • Техническое задание.
    • Описание бизнес-требований.
    • Бэклоги задач для планирования следующих спринтов.
    • Паспорт с доступами к системам, которые используются в проекте.

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