Почему работать в продуктовой команде — не всегда лучший вариант

Привет, это Холивеб и мы сдаем IT-команды в аренду. Если проще — занимаемся аутстаффингом IT-компетенций. Мало того, считаем, что это полезно и выгодно не только нам и клиентам, но и самим разработчикам. Наши прошлые заметки про то, как мы занимаемся торговлей «черным деревом» (зачеркнуто) аутстаффингом вызвали неиллюзорное подгорание — нас обвинили в эйджизме и несколько раз обозвали галерой.

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

Про возраст

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

Почему работать в продуктовой команде — не всегда лучший вариант

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

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

Про опыт

В разных странах практикуется такое явление, как Gap Year. То есть год после школы и перед следующим учебным заведением ты тратишь на то, чтобы «посмотреть свет». Бывшие школьники путешествуют, набираются опыта, размышляют о своем будущем.

Мы видим себя примерно тем же самым, только для уже опытных разработчиков. Ты поработал в паре продакшнов, но «осесть» пока не решаешься — мы зовем к себе. В формате аутстаффинга ты сможешь поработать на нескольких крупных проектах, лучше понять, как там всё устроено изнутри. Понять, что для тебя ок, а что вызывает желание свалить поскорее.

Ну и всё это на фоне роста основных скиллов.

Если говорить конкретнее, то у нас есть заказчики из финтеха, есть просто технологические компании, есть ecommerce с посещалкой в несколько миллионов. Сомнительных проектов у нас просто нет, мы не беремся за сайты Свидетелей Иеговы :)

Почему работать в продуктовой команде — не всегда лучший вариант

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

Я участвую в сложном финтех-проекте уже 8 месяцев. Доволен работой, в нашей команде много сильных специалистов и это отличная возможность узнать друг у друга что-то новое, делиться решениями и идеями. К сожалению, постановки задач не всегда содержат исчерпывающую информацию, поэтому приходится постоянно работать в связке с аналитиками и разработчиками — это «бутылочное горлышко» в процессах.

Михаил, QA-специалист Holyweb

Про стабильность

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

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

Понятно, что работу ты найдешь, и даже, возможно, с запросами «я сеньор, 2 года опыта, дайте 250К и личный вертолет». Хотя эйчарам лучше бы насторожиться.

Почему работать в продуктовой команде — не всегда лучший вариант
Почему работать в продуктовой команде — не всегда лучший вариант

Поэтому аутстафф-компания (по сути сервисная) от такого защищает. Отвалился один проект — перешли в другой.

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

Даниил, React-разработчик Holyweb

Про деньги

«Ага, вы продаете джунов как мидлов, платите им 30К, остальное в карман!» — примерно так часто пишут про аутстаффинг.

Сейчас зарплаты наших JS-разработчиков находятся чуть выше среднерыночной. Джунов у нас нет в принципе, мы не продаем их под видом мидлов и не навариваемся на разнице — как многие думают. Профиты у заказчика в этом случае другие: быстро получить укомплектованную команду людей под свои требования. Учитывая, что в противном случае ему придется перелопачивать тонну резюме и проводить десятки собеседований, заплатить больше, чтобы с этим было меньше проблем — вполне себе нормальный сценарий. А если вспомнить, какие вилки желаемых зарплат у разработчиков на hh.ru — то еще и выгодный.

Про комфорт разработчика

У нас галера, но такая, где каждому подложат подушечку под спину.

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

Почему работать в продуктовой команде — не всегда лучший вариант

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

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

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

Геннадий, PHP / Node.js разработчик Holyweb

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

Почему работать в продуктовой команде — не всегда лучший вариант

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

Итого — за 2,5 года не было таких случаев, когда бы разработчик хлопал дверью и уходил, потому что ему было некомфортно работать.

Про нелюбовь к релокейтам

Вопрос из самого начала: а зачем разработчику работать с вами, когда он может пойти сразу к «конечному» работодателю? Тут стоит сказать, что мы работаем только на удаленке. Разработчики — с нами, мы — с заказчиком. В то время как многие работодатели продолжают предлагать релокейт как обязательное требование: это их привычный формат работы. И это несмотря на то, что за весну-2020 все должны были привыкнуть к дистанционной работе.

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

Почему работать в продуктовой команде — не всегда лучший вариант

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

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

Про ООО «НДА»

Еще одно популярное сомнение звучит так: «у вас, наверное, всё под NDA, что я напишу в резюме?». На самом деле, это надуманная проблема — работодатели почти никогда не смотрят на названия проектов, в которых вы участвовали, им важна ваша роль в этих проектах и конкретные решенные задачи. Ну и наличие «Большой Важной Компании» в резюме сейчас не говорит примерно ни о чем: все работодатели понимают, что такие пылесосят резюме как угорелые и потом выплевывают обратно на рынок кадров откровенно слабых специалистов с перегретыми ожиданиями по зарплате и раздутым ЧСВ. Конечно, это не правило, но такое бывает часто.

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

Про софт скиллы

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

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

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

Почему работать в продуктовой команде — не всегда лучший вариант

Можно сказать, что у любого разработчика, который прошел через Холивеб, сильно прокачивается навык общения — как внутрикомандного, так и общения с техлидами и продакт-менеджерами (кстати, с эйчарами они не общаются вообще). Этот навык тоже хорошо пригождается потом.

Про то, как мы собеседуем клиентов

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

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

Более того, эти требования к клиенту могут меняться в зависимости от потребностей команды. Например, у нас был случай, когда разработчику Vue.js накидывали задачи по верстке. Это, конечно, было не тем, что он хотел делать — и он нам об этом рассказал. В итоге мы нашли компромисс с заказчиком и разработчик стал получать задачи по Vue.

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

Петр, React-разработчик Holyweb

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

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

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

Опыт работы такой же, как если бы я устраивался лично или через аутсорс. Отношение ко всем сотрудникам одинаковое. Из плюсов: получил полезный опыт в плане коммуникации с коллегами, поработал над крупным проектом, окончательно убедился в том, что вне размеров от компании, процесс работы может быть как в гаражном стартапе. Например, я удивился, что тут вообще не беспокоятся о том, сколько времени ты тратишь на задачу и не требуют жестких сроков. «Вот задача, делай». Из минусов: постановка задач, 40% времени тратишь на то, чтобы получить разъяснения, а тимлид в этом плане не очень помогает.

Дэнннис, React-разработчик Holyweb

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

Итого, что дает программисту работа аутстаффером:

  • Прокачка soft-skills: они учатся конструктивно взаимодействовать в горизонтальных командах, общаться с менеджерами, аналитиками, дизайнерами. Никто не отсиживается в песочнице, все сразу попадают в боевые условия, еще и на удаленку. После такого опыта переходы из проекта в проект проходят без боли.
  • Прокачка опыта в собеседованиях. У нас наработаны разные практики прохождения технических интервью, мы учим, как подавать себя. И реальные собеседования бывают раз в несколько месяцев.
  • Резюме. Разработчики получают опыт, который могут положить в свой CV и одновременно учатся правильно его оформлять.
  • Стабильный доход. Прозвучит странно, но это факт: люди, которые пришли к нам из стартапов и продуктов, сталкивались с задержкой зарплаты. Фактически, когда ты работаешь в продукте, ты разделяешь с бизнесом его риски. У нас много заказчиков из госсектора и крупных энтерпрайзов, так что платим мы вовремя и всегда.
  • Можно развиваться как горизонтально, так и вертикально. Кому-то нравится расширять стек или специалист просто находится в поиске лучшей специализации для себя, кому-то больше по душе копать вглубь. В аутстафф-компании можно развиваться так, как хочется.
  • Отношение к аутстафферу в команде проекта ровно то же, что и к «своим» разработчикам — это просто выяснено на нашем опыте.

Понимаем, что у вас все равно остались вопросы — так что пишите в комментариях или мне в Telegram. Чтобы не пропустить новые публикации, подписывайтесь на нашу группу в Facebook.

1414
41 комментарий

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

5

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

5

Комментарий недоступен

2

Не совсем понял. То есть в компании, где все друг друга знают, будут увольнять таким образом своих сотрудников? По-моему это нанесет слишком большой урон HR-бренду и бизнесу компании в целом, ведь он строится исключительно на специалистах. Это основной услуга/продукт. И это касается всех компаний, а не только тех, кто оказывает услуги аустаффа.

1

Отношение к аутстафферу в команде проекта ровно то же, что и к «своим» >разработчикам — это просто выяснено на нашем опыте.

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

3

Да, только кого-то мотивирует привязка к "успеху или провалу", а для кого-то важнее стабильная зп в рынке два раза в месяц, а не как вы пишете выше "Если заработаем на этом что нибудь, то никого в конце месяца не уволят") Хотя стартаперский дух и высокая вовлеченность - это прекрасно тоже. 

Вам не обидно, когда выросшие у вас разработчики уходят в другие компании? 

3