Как увеличить техническую команду на 30% за 3 месяца: пошаговый пример из практики
Опубликовано: 2022-05-04В настоящее время трудно представить, что можно легко нанять команду из пяти-десяти штатных разработчиков с необходимым набором навыков. Ожесточенная борьба за таланты на рынке и выгодные предложения от конкурентов не делают его проще.
Почему? Ключевая проблема заключается в нехватке ИТ-специалистов, которая стала одним из быстрорастущих узких мест, с которыми сталкивается современный бизнес. Наем технических специалистов сейчас является настоящей проблемой. И тут нет ничего удивительного. За последние десять лет количество компаний B2B SaaS увеличилось в 50 раз и продолжает расти как снежный ком. Только в США насчитывается более 15 000 таких предприятий. Более того, такие гиганты, как Google и Amazon, продолжают отбирать вишенки на рынке труда в сфере технологий.
Кроме того, пандемия COVID-19 привела к безудержной цифровизации бизнеса. Таким образом, растущий рынок стартапов превратился в настоящую борьбу за найм и удержание лучших технических специалистов для работы в неИТ-компаниях и стартапах. В результате предложение кандидатам слишком высоких зарплат вызывает хаос на рынке.
Правда в том, что даже если вашему стартапу удалось привлечь внушительное финансирование, ваши кадровые проблемы далеки от решения.
Однако это не повод сдаваться. Мир стал удаленным. Ваши внутренние кадровые возможности больше не ограничивают вас. Более того, ваше местоположение также не является препятствием.
Здесь я поделюсь реальным случаем, когда наша компания Aspirity помогла масштабировать техническую команду в кратчайшие сроки и раскрыть опыт, который получили обе стороны.
Внутренний VS. Удаленный VS. Распределенные команды
В настоящее время появилось много новых подходов и моделей кадрового обеспечения, что делает доступ к глобальному кадровому резерву реальной перспективой для тех, кто ищет более гибкие и эффективные решения.
Давайте рассмотрим наиболее распространенные типы команд разработчиков с точки зрения их местоположения.
Внутренние команды: как все изменилось
Многие компании считают внутренние команды наиболее стабильным, управляемым и надежным решением. Вот наиболее распространенные аргументы в пользу внутренней модели:
- Прямой контроль над рабочим процессом.
- Возможность построить доверительную и прозрачную офисную среду.
- Общение лицом к лицу.
- Нет разницы в часовых поясах и языковых барьеров.
Однако во время пандемии менталитет людей изменился. Сегодня концентрацию всей командной работы в одном офисе можно считать устаревшей. Согласно исследованию Gartner, после вспышки COVID-19 82% работодателей позволяют своим сотрудникам некоторое время работать удаленно, а 47% руководителей компаний поддерживают полностью удаленную работу.
Из-за этих изменений минусы собственной разработки значительно перевешивают их преимущества. Имея гораздо более бедный кадровый резерв, вам будет сложно конкурировать с гигантами, которые нанимают только лучших местных специалистов. Таким образом, масштабирование вашей внутренней команды разработчиков и добавление необходимого опыта может оказаться слишком сложной задачей.
Удаленные команды: новая реальность
Удаленные решения — отличная альтернатива собственной разработке. Вы можете найти необходимые таланты с доступом к глобальному ИТ-рынку. Кроме того, вы можете выбрать удобный для вас часовой пояс и нанять нужных вам специалистов.
Потенциальный риск найма удаленных сотрудников заключается в том, что вам может быть сложно быстро интегрировать их в команду, которая уже работает над проектом. Кроме того, некоторым удаленным сотрудникам может потребоваться больше времени для адаптации, поскольку они не сразу почувствуют себя неотъемлемой частью вашей внутренней команды.
Распределенные команды: альтернативное решение
Итак, что может сделать бизнес, чтобы нанять квалифицированных удаленных специалистов и решить потенциальные проблемы, связанные с их адаптацией и вовлечением? Исходя из нашего опыта, создание распределенной команды — отличное решение.
Прежде всего, распределенная команда состоит из профессионалов, которые уже имеют взаимопонимание и могут эффективно взаимодействовать друг с другом. Они знают сильные и слабые стороны друг друга и могут выстроить процесс сотрудничества в кратчайшие сроки, не требуя от вас никаких усилий.
Более того, у таких команд наверняка есть отработанные и проверенные методы ведения баз данных, и у них не возникнет проблем с адаптацией новых сотрудников, если вам нужно быстро масштабироваться.
Также при найме распределенной команды следует проводить эффективную адаптацию. Очень важно донести основную идею вашего проекта и вызвать у новых участников страсть к вашему продукту.
Конечно, процесс адаптации займет некоторое время. Бизнес, переходящий на распределенную модель, должен учитывать разницу часовых поясов и культурные особенности. Впрочем, если вам нужно эффективное масштабирование, все эти факторы вряд ли станут препятствием. Для такой цели вы вряд ли найдете более ориентированный на результат вариант.
Сравнение цен
Стоимость разработки зависит от многих факторов. И значение имеет не только уровень квалификации задействованных в проекте разработчиков. Еще одним важным аспектом является местонахождение вашей команды разработчиков. В основном это зависит от экономических условий региона, средней заработной платы, налогов и многого другого.
Здесь мы сравним стоимость тех или иных услуг по разработке в разных частях мира. Это даст вам приблизительное представление о средних ставках инженеров-программистов, если вы решите передать разработку своего продукта в другую страну или нанять специалистов самостоятельно.
Учтите, что если вы нанимаете удаленных работников, вам придется столкнуться со многими подводными камнями, например, с налоговой системой в той или иной стране. Между тем, если вы обратитесь к модели распределенной команды, вендоры, скорее всего, справятся с этими проблемами без ваших усилий. Такие факторы существенно влияют на масштабирование и бюджет проекта.
Северная Америка | Восточная Европа | Южная Америка | |
Реагировать | $59,8 | $50,9 | 49,6 долл. США |
Реагировать на родной | $73,9 | $54,6 | 53,1 доллара США |
JavaScript | $78,6 | 49,3 доллара США | $51,0 |
Node.js | 63,5 доллара США | 47,5 долларов США | 50,3 доллара США |
В офисе или удаленно: наш опыт
Наша компания Aspirity накопила солидный опыт удаленной работы и применения модели распределенной команды. Во время пандемии наши сотрудники приспособились к новым реалиям работы из дома. Так что сейчас к работе в офисе возвращаются не более 10% из них. По нашему опыту, удаленная работа еще более продуктивна, поскольку устраняет офисный шум и другие отвлекающие факторы, позволяя сотрудникам полностью погрузиться в рабочий процесс.
Любопытно, что некоторые наши сотрудники решили начать работать удаленно и присоединиться к распределенным командам еще до начала пандемии. Осенью 2019 года к нам обратился стартап из Кремниевой долины с предложением присоединиться к их проекту. В то время они хотели создать инновационный продукт, но понимали, что это займет много времени и ресурсов, которых им не хватает. Таким образом, клиент искал от трех до пяти сотрудников одновременно, у которых был набор навыков, чтобы покрыть фронтальную часть, включая дизайн. И мы решили начать работать вместе.
Для нас также было новым опытом нести ответственность только за определенную часть проекта. В результате у нас установился формат работы, который мы теперь называем распределенной командой.
Обычно адаптация в таком проекте занимает несколько месяцев. Однако нашей команде удалось сделать это намного быстрее. Теперь я расскажу, чему мы научились, работая вместе в распределенной команде.
Поиск команды
Первый вопрос, с которым может столкнуться бизнес или стартап, — как найти распределенную команду, которая будет соответствовать их целям и ожиданиям. Вот несколько ключевых факторов, которые следует учитывать.
- Пул талантов. Чтобы создать исключительно инновационный продукт, вам, вероятно, потребуется доступ как минимум к 1-2% лучших специалистов по всему миру. Однако найти и удержать квалифицированных специалистов в США довольно сложно из-за нехватки ИТ-специалистов. Модель распределенной команды позволит вам получить доступ к ведущим специалистам в других регионах, таких как Юго-Восточная Азия, Восточная Европа и Южная Америка.
- Личные связи. Не пренебрегайте отзывами людей, которых вы знаете и которым доверяете. Хорошая репутация часто опережает лучшие команды, вне зависимости от их местонахождения.
- Культурное сходство. Крайне важно учитывать менталитет и ценности команды, которую вы нанимаете. Необходимо найти партнеров, которые смогут погрузиться в ваши бизнес-идеи и стать неотъемлемой частью вашего проекта. Это поможет вам наладить коммуникацию с командой, даже не замечая разницы между удаленными специалистами и вашими штатными сотрудниками.
- Влияние часового пояса. Для многих компаний разница в часовых поясах может показаться существенным недостатком при найме распределенной команды. Однако вы можете превратить это в преимущество. Например, при найме поставщика из Восточной Европы вы можете выполнять определенные процессы практически круглосуточно и без выходных. Главное, находите время для звонков и встреч, которое будет удобно всем.
Как проверить команду
После нахождения команды, которая кажется подходящей, пришло время проверить их надежность. Существует множество способов проверить, соответствует ли кандидат вашим потребностям. Наиболее распространены следующие:
- Ознакомьтесь с портфолио компании и кейсами.
- Читайте отзывы их клиентов.
- Обратите внимание на рейтинг репутации поставщиков на специализированных сайтах, таких как Clutch и GoodFirms.
Также лучше не полагаться на обещания кандидатов соответствовать самым высоким стандартам. Есть сотни продавцов, и каждый утверждает, что предлагает лучшие услуги.
Вот почему техническое интервью имеет решающее значение. Это поможет вам оценить технические возможности команды кандидатов, знания в конкретной области и актуальность экспертизы.
Более того, лучше не переоценивать выбор технического стека. Вместо этого отдайте предпочтение команде с отличными навыками в конкретной технологии, даже если это не та, которую вы рассматривали. Это намного лучше, чем нанимать так называемых подхалимов, которые всегда будут следовать вашим требованиям, независимо от того, насколько они обоснованы, вместо того, чтобы предлагать более эффективные решения.
Самое главное, убедитесь, что выбранный стек технологий ориентирован на будущее и имеет достаточно большое сообщество разработчиков.
Еще одним важным фактором является взаимодействие между бэкэнд- и фронтенд-командами. В нашем случае у клиента уже была своя команда бэкенда. Поэтому им нужно было убедиться, что специалисты по фронтенду понимают некоторые особенности бэкенда. Они искали специалистов, знающих такие основы, как работа с фальшивыми данными, API и т. д. Изучение таких основ на ходу может значительно снизить производительность и темпы разработки.
Стать совместной командой
Когда распределенная команда начинает работать вместе, ее членам требуется некоторое время, чтобы наладить совместный рабочий процесс. В нашем случае члены штатной команды клиента хотели, чтобы мы погрузились в суть проекта и основные идеи, прежде чем приступить к процессу разработки. Итак, изначально мы исследовали, как управлять проектом с учетом потребностей пользователей, как он должен быть спроектирован и какие графики требуются.
Для этого мы потратили месяц на анализ продуктов конкурентов. Мы изучили различные дашборды, чтобы понять, чего пользователь ожидает от похожих продуктов, искали и тестировали их, делали множество скриншотов. Наконец, мы собрали и систематизировали всю эту информацию, чтобы обращаться к ней в процессе проектирования.
В начале у членов нашей команды не было большого опыта в области проекта клиента. Предварительное исследование позволило нам получить необходимые рекомендации, на которые мы могли положиться при разработке продукта. Кроме того, процесс исследования помог нам глубже погрузиться в сам проект. И это был первый важный шаг.
Еще одним важным аспектом было управление проектами, которое помогло нам наладить эффективную коммуникацию между командами, запланировать встречи, организовать совместный рабочий процесс и избежать проблем в работе друг друга.
Вот несколько важных идей, полученных нашей распределенной командой, и методы, которые мы придумали.
- Коммуникация. Хотя мы начали с некоторых проблем и недоразумений, мы быстро достигли необходимых компромиссов и повысили нашу эффективность. Теперь наша команда использует несколько Slack-каналов и групповых чатов для мгновенных обсуждений и своевременной доставки важной информации. Наши проджект-менеджеры постоянно на связи, а наш техлид всегда знает, чем заменить работников во время праздников или любых непредвиденных обстоятельств. Это позволяет нам поддерживать непрерывный темп рабочего процесса.
- Встречи и звонки. Работа распределенной команды требует регулярных онлайн-сессий для обсуждения результатов, проверки результатов, составления планов и спринтов, обсуждения проблем и т. д. Поэтому у нас есть множество регулярных встреч для разных целей:
- Ежедневные встречи фронтенд-команды с владельцем продукта.
- Еженедельные встречи с лидером команды из другой страны.
- Ежедневные встречи членов нашей команды.
- Ретроспективные и технические ретроспективные встречи каждые две недели.
- Еженедельная техническая встреча для обсуждения нового технического плана.
- Регулярные встречи руководства.
- Обзоры спринтов каждые 2-3 дня.
Каждый звонок и встреча служат определенной цели, которая помогает команде оставаться на одной волне и понимать прогресс и проблемы друг друга. Однако многие вещи обсуждаются в групповых чатах и мессенджерах для экономии времени.
- Общее рабочее пространство. Вначале наша команда использовала два разных рабочих пространства Jira:
- Наш пользовательский интерфейс и рабочее пространство фронтенд-команды.
- Рабочее пространство нашего клиента для управления пользовательским интерфейсом, серверной частью, API и внешним интерфейсом.
При таком подходе QA на стороне клиента сообщил об ошибках пользовательского интерфейса, а наш QA сообщил об ошибках внешнего интерфейса. Позже мы перешли на единое рабочее пространство Jira, что значительно упростило процесс управления проектом.
Выводы
Предположим, вам необходимо быстро и эффективно масштабировать проект, не тратя время на поиск, найм и обучение всех необходимых штатных специалистов. В этом случае модель распределенной команды является одним из лучших вариантов. Это предоставит вам доступ к глобальному кадровому резерву и позволит нанимать опытных разработчиков с хорошо зарекомендовавшим себя опытом совместной работы.
При современных технологиях и подходах к управлению проектами построение и организация эффективного рабочего процесса — вполне достижимая цель. Использование мощных инструментов для коммуникации, совместной работы и документирования минимизирует риски и становится надежной основой для прозрачной и ориентированной на результат совместной работы.
Таким образом, все, что вам нужно сделать, это найти надежную команду с соответствующим опытом и сделать все возможное, чтобы передать им свою страсть к продукту, который вы собираетесь создать.
автор: Александр Ефремов (LinkedIn)