Особенности работы на аутсорс и продуктовую компанию. На примере EPAM, Softeq, Yandex и Glovo

Мне довелось поработать в двух американских аутсорс компаниях — EPAM Systems и Softeq, и в двух продуктовых — Yandex и Glovo. Разбираю, в чём основная разница работы на продуктовую компанию и аутсорс, из моего опыта — состав команд, KPI, ценности, проекты, карьерный рост и зарплаты.

12 комментариев

Кто рассказывает: Алексей Невский, Lead Software Engineer и AWS Certified Architect в испанском технологическом стартапе Glovo.


Разница в командах 

Продукт. Размер команды: максимум 8-11 человек:

  • Product Manager;
  • Engineering Manager;
  • Backend Developer — 3-4 позиции; 
  • Android Developer — 0-2; 
  • iOS Developer — 0-2; 
  • Frontend Developer — 0-1;

Как правило, продуктовые команды маленькие и сфокусированы на определенном своём скоупе функциональности большой системы.

Из менеджеров только 2 человека: 

  • Product Manager — отвечает за то, что вы будете делать дальше, описывает фичи и принимает решение касательно функциональных требований;
  • Engineering Manager — отвечает за контроль прогресса по реализации намеченных Product Manager’ом, планов, убеждается что все «on track».

Аутсорс. Размер команды: 5-30+ человек:

  • Sales Manager;
  • Project Manager;
  • Delivery Manager;
  • Scrum Master;
  • Business Analytic — 1-2 позиции;
  • Solution Architect — 0-1;
  • Backend Engineer — 2-8; 
  • Android Engineer — 0-2; 
  • iOS Engineer — 0-2; 
  • Frontend Engineer — 0-1;
  • Firmware Engineer — 0-1;
  • QA Engineer — 1-4;
  • Dev-Ops Engineer — 1-3.

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

Количество разработчиков также не ограничено маленьким количеством, потому что нужно иметь возможность реализовать любой скоуп работы, тут все зависит от размера проекта, может быть как 2-3 разработчика, так и 10-20. И даже (редко) больше.

Разница в ролях и процессах

В продуктовой компании команды компактны, автономны, обладают большей свободой локальных решений, отвечают за продуктовую функциональность от и до, включая самих разработчиков, выполняют более широкий спектр обязанностей (например, в Glovo, на основе еженедельных ротаций каждый из членов команды независимо от должности проводит Daily Meetings, Planning, Retro), а также сами себе бизнес-аналитики, архитекторы и тестировщики. 

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

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

Ежедневная рутина. Как выглядят спринты в продукте и аутсорсе

Сейчас почти все компании следуют двум методологиям организации разработки: Scrum либо Kanban.

Но в большой продуктовой компании, например Glovo, вы скорее всего встретите гибридное чудо: все как бы Agile, но по факту Waterfall, который наполовину Kanban, а на другую половину мимикрирует под Scrum. 

С одной стороны соблюдены некоторые формальности: у вас есть Sprint, у вас есть Backlog, Retro, Planning, Estimations Session, Story Points и Team Velocity. Но главный Planning будет на год вперед. Дальше — разбивка на два полугодия (H1/H2), а потом каждая половина разбивается еще, и получаются кварталы Q1-Q4.

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

В аутсорс компаниях, где я работал (EPAM Systems и Softeq), процесс более формальный. Есть отдельные Project Manager, Delivery Manager, Scrum Master и Business Analytic, а разработчики фокусируются с большего только на технической части и планировании на спринт или два вперед. Для остального есть другие люди.

Какие у компаний ценности и позиционирование

Если вы откроете сайт и социальные сети Glovo, для которой важно соответствовать европейским ценностям, то вы легко увидите что она сфокусирована на следующем:

Product:

  • Press opinion;
  • Social Media Outlook;
  • Investment Attractiveness; 
  • Users Satisfaction;
  • Design;
  • Diversity;
  • Green.

Такие крупные аутсорс гиганты как EPAM Systems сфокусированы больше на Enterprise clients:

Outsource:

  • Well-known customers;
  • Client opinion;
  • Engineering Solutions offering;
  • Business Solutions offering;
  • Help for Startups.

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


Продуктовые фокусируются на внутреннем продукте и KPI, аутсорс — на клиенте, технологиях и расходах проекта.


Работая в EPAM Systems на проектах Adidas, Coca-Cola, Whirlpool я конечно же был очень горд за принадлежность к этим брендам и разработку современных решений для них с использованием самых последних технологий. Работая в Yandex, ощущал себя вообще рок-звездой, потому что основные конкуренты — топовые компании, такие как Microsoft, Google, Apple и другие.

Особенности разработки

В аутсорсе tech stack диктует клиент, вся инфраструктура на его стороне, как и сопутствующие системы, будь то Jira, Confluence, Jenkins или Git. Надо быть готовым к множеству дополнительных аккаунтов тут и там, репортингу времени во внешней и внутренних системах, ожидание пермишенов неделями, быть готовым к жестким ограничениям. Любой релиз новой версии системы четко спланирован и заранее согласован. 

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

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

KPI — от чего у всех подгорает и на чем все сфокусированы

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

Например, снижение contact rate на 10% в течении квартала или двух разработки. И проекты вы будете планировать на основе этих метрик, чтобы двигать их в лучшую сторону. Вы будете волноваться только об улучшении ключевых метрик части продукта, за которую ответственна ваша команда. Ни архитектура, ни инфраструктура всей системы в целом, ни общий perfomance системы — нет, для вас это все blackbox, а 1-5% функциональности, за которую ответственна именно ваша команда — ваше всё. И не дай бог вам нужно поправить функционал, за который ответственны 2-3 других команды — даже небольшие правки и процесс их согласования может затянуться на недели и даже месяц.

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

Проекты и возможности роста   

В продукте — один большой проект. Ваша команда ответственна лишь за небольшую его часть. Поэтому критически важно выбрать хороший продукт = компанию, потому что это то, с чем вы будете иметь дело 100% вашего времени. Почитайте про компанию, изучите отзывы пользователей, попользуйтесь продуктом сами. Нравится — идите работать в эту компанию. Если у вас есть сомнения — подумайте 3 раза прежде, чем соглашаться, так как иначе вам придется искать новую работу снова (если вы конечно не хотите каждый день есть стекло).


Чтобы продвигаться по службе вперед в продукте, вы должны показать «импакт» вашей работы — как она критически важна для приложения, над которым вы работаете, на сколько % вы его улучшили, столько тем самым $ миллионов денег вы сэкономили. Без этого «отчета ваших достижений» — никуда.


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

Зарплата и бенефиты

Для примера рассмотрим Senior Engineer должность на рынке США, Европы и СНГ.

Пакет компенсаций в продуктовых MAANG компаниях в Калифорнии состоит из следующих пунктов: 

  • 180k базовой зарплаты;
  • 125k опцион на акции;
  •  50-75k начальный бонус за подписание контракта;
  • +20% годовой бонус за хороший перформанс.

Что составит $400-450k в 1-й год, и далее около $320-350k каждый год.

Если вы работаете в аутсорсе и находитесь на территории США, то вам доступно:

  • 120-180k базовой зарплаты;
  • +10% годовой бонус за хороший перформанс.

Если вы работаете в аутсорсе и находитесь на территории СНГ:

  • 22-50k базовой зарплаты .

Если работаете в аутсорсе и находитесь на территории Европы:

  • 48-60k базовой зарплаты;
  • 4-5k начальный бонус за подписание контракта.

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

  • 52-65k базовой зарплаты;
  • 5-7k опцион на акции;
  • 5-10k начальный бонус за подписание контракта.

Все цифры в брутто, до вычета налога, который +/- составляет:

  • 10-13% в СНГ;
  • 32-35% в США;
  • 35-45% в Европе.

Легко увидеть, что по пакету компенсаций США далеко впереди, далее СНГ, и только потом Европа. Заранее просчитайте вашу чистую зарплату! Не забывайте про налоги и аренду жилья. Разница до и после крайне существенна.

Пакет бенефитов как правило очень похож и сильно зависит от самой компании. В компаниях СНГ он точно не хуже европейского.

Касательно продуктовой компании и аутсорса скорее всего наибольшее отличие будет в технике: аутсорс будет предлагать стандартный Windows Laptop, продукт скорее всего будет предлагать свежие модели Apple MacBook.

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

Что я выбираю для себя?

Мне довелось поработать в двух американских аутсорс компаниях — EPAM Systems и Softeq, и в двух продуктовых — Yandex и Glovo. Каждая из них по-своему хороша. Так что для меня это 50/50. 

Сейчас я отвечаю за улучшения KPI и миграцию в микросервисы в Glovo, а если завтра очередной большой клиент может захотеть разработать или переписать с нуля новую систему, то почему нет?

Как вы видите, везде есть свои за/против. Вряд ли вы найдете «серебряную пулю», которая решит все ваши проблемы.


Составьте список из плюсов и минусов для вас, определите что вам важно (на основе персональных увлечений и семейных обстоятельств) и сделайте правильный выбор :) 


Дорогу осилит идущий. Главное — не останавливайтесь.

А где вы бы хотели работать? Пишите ваше мнение в комментариях! 

Вы тоже можете начать вести свой блог на dev.by — вот инструкция. Или присылайте темы, идеи и вопросы на blog@dev.by

Мнение авторов блогов может не совпадать с мнением редакции. 

Что ещё почитать?


Читать на dev.by