Різниця між роботою у продукті та аутсорсі з погляду розробника

Привіт! Мене звати Ярослав Мота, я Senior Software Engineer в N-iX. Дев’ять років працюю в українському ІТ: маю досвід роботи в продукті та аутсорсі.

У статті розповім про власний досвід і підрезюмую найважливіші плюси та мінуси роботи в українських ІТ-компаніях і на проєктах різного типу. Думаю, матеріал буде корисний тим, хто хоче змінити місце праці, але не знає, які переваги або недоліки очікувати від роботи в продуктовій чи аутсорс-компанії. А також тим, хто тільки стає на шлях ІТ.

Українська продуктова компанія

У продукті я отримав свій перший досвід роботи в ІТ. Дев’ять років тому, коли ще був студентом третього курсу, зрозумів: університет не дає мені бажаного практичного досвіду — і почав шукати вакансії на позицію трейні. Відтак знайшов варіант і пішов на співбесіду. Тепер розумію, що це була одна з найцікавіших співбесід. Оскільки практичного досвіду в мене не було, розмова базувалася на теоретичних знаннях, інтерв’юер давав цікаві алгоритмічні задачі та запитував, як би я розв’язував певну проблему. Наприклад, мене спитали про алгоритми обходу дерев. На псевдокоді їх треба було реалізувати та пояснити, для вирішення яких реальних проблем варто застосовувати.

За результатами співбесіди мене взяли у велику ІТ-компанію, що працювала над розробкою власного продукту, яким уже тоді користувалися організації в Україні. Моя команда удосконалювала його, щоб відповідати на потреби людей і залишатися № 1 у своїй ніші.

Плюси

Швидкість ухвалення рішень. Мій онбординг відбувся швидко, адже часу на «розкачку» не залишалося. Наприклад, не було зовнішніх замовників, які б давали доступи по кілька тижнів, як це трапляється в аутсорсі. На проєкті поряд зі мною сидів технічний директор, який розумів: що довше я буду готуватися до роботи, то довше вноситимуть у продукт потрібні зміни. Тож доволі швидко мене допустили до того, що мало прямий результат, — і це мотивувало.

Різноманітність завдань. Оскільки на продукті команда зазвичай невелика, то й завдання доводиться робити різноманітні: бекенд, фронтенд, інфраструктура та бази даних. Окремі ролі під такі таски відводять рідко. Так мені доводилося ще на позиції трейні заглиблюватися в те, як хоститься аплікація, як уникати проблем з перформансом на базі даних, як працює десктоп і веб.

Розуміння продукту та відчуття залученості. До нас в офіс запрошували кінцевих користувачів продукту. На такі зустрічі приходила залучена до розробки команда. Клієнти розповідали, як вони користуються продуктом, що можна поліпшити та якого функціоналу бракує. Ці зустрічі не допомагали моєму технічному розвитку, але схоже спілкування давало краще розуміння продукту та бізнес-завдань. Після обговорень ми збиралися з командою на брейншторм щодо нововведень. Кожен міг пропонувати свої ідеї та процес їхньої реалізації. Вже зараз я розумію, наскільки цей досвід став важливим і допоміг надалі не боятися висловлювати власне бачення, обстоювати думку і прислухатися до критики.

Дисципліна і відповідальність. Якщо ти недопрацьовуєш, це відразу відбивається на результаті всієї команди. Усі залучені в розвиток продукту фахівці сиділи в одному офісі: розробники разом з маркетологами, командою підтримки та керівництвом. Пам’ятаю, як колега, що працював уже пів року, почав робити менше на тлі інших та показував гірші результати, ніж раніше. Падіння мотивації сильно відчувалося. Те, що недопрацьовував колега, доводилося завершувати іншим. Ми обговорили те, що людина регулярно підводить команду, і в результаті він покинув компанію.

Мінуси

Відносно повільне технічне зростання. Я приєднався трейні в команду, де було два сеньйори, технічний директор і кілька мідлів. На проєкт зазвичай брали джуніорів, і була тенденція, що люди приходили на посади початківців, виростали до певного рівня та йшли. Оскільки проєкт був орієнтований на розв’язання бізнес-завдань, технології відставали від ринку. Міграція на нові відбувалася, але повільніше, ніж у продуктових компаніях, де драйвером є не лише бізнес, а й технічні аспекти (я брав участь у міграції з ASP. NET Web Forms, які тоді були застарілими). Завдання різноманітні, але часу зосередитися на чомусь одному переважно є мало.

Неможливість змінити проєкт у межах компанії. Якщо компанія зосереджена на розвитку лише одного продукту, то проєкт не вдасться змінити взагалі, на відміну від аутсорсингових фірм, де постійно з’являються нові можливості. Вважаю це негативним аспектом, адже від того, що працівники надто довго засиджуються на одному проєкті, не виграє ніхто. Спеціаліст поступово втрачає мотивацію, звикає до своїх завдань і припиняє активно розвиватися, а проєкту бракує свіжих ідей і підходів, позитивного та негативного досвіду, який уже мають фахівці в індустрії.

Проєкт не «з нуля». Рідко продуктові компанії на українському ринку починаються зі стартапу. Принаймні у Львові фірми, про які доводилося чути, переважно відкривали свої офіс на пізніх етапах розвитку. А тому немає шансу бути залученим на початку та отримати досвід «стартувати» розробку. На відміну від аутсорс-компаній, де в пайплайні трапляються проєкти «з нуля». Це важливо, адже найбільший розвиток ви здобуваєте, коли стартуєте проєкт, обираєте технології, архітектуру та підходи. Цей досвід не такий критичний для фахівців рівнів джуніор і мідл, але необхідний для сеньйорів.

Український аутсорс

Після продукту я працював у різних аутсорс-компаніях. Для себе умовно поділяю їх на аутсорс «зрілий» та «незрілий». Кажучи про критерій «зрілості», маю на увазі готовність компанії інвестувати в розвиток та збереження своїх фахівців, а також рівень проєктів, з якими вона працює.

«Незрілий» аутсорс

Після роботи на продукті я прийшов на проєкт у невелику фірму, клієнтами якої були також невеликі компанії. У команді було четверо людей, і працювали ми на клієнта, який надавав послуги консалтингу в страховій сфері. Їм не потрібна була постійна команда розробників у штаті, тому за рішенням звернулися до нас.

Плюси

Робота з найновішими технологіями. Ми могли обирати технології, з якими працювати. Адже головне — виконати завдання замовника. Тому віддавали перевагу тому, що було найцікавіше.

Постійна комунікація із замовником. Ми спілкувалися безпосередньо із клієнтом: брали участь в обговоренні завдань і допомагали ухвалювати рішення його продакт-оунеру. Для мене це була можливість розвивати софт скіли та знання англійської.

Візити клієнта та подорожі за кордон. Продакт-оунер приїздив до нас, щоб проводити сесії планування наступних фаз, узгоджувати технічні моменти та технологічний розвиток проєкту. Також тоді я поїхав у свій перший бізнес-тріп у Нідерланди. Я взяв участь у воркшопах, краще зрозумів бізнес замовників і мав змогу поспілкуватися з кінцевими користувачами продукту. В українських продуктових компаніях такі можливості трапляються набагато рідше, адже немає тісної взаємодії з клієнтами (або й узагалі сторонніх замовників), тому потреба у відрядженнях не є настільки важливою. Хоча, можливо, в посткоронавірусному світі бізнес-подорожі взагалі відійдуть в історію :)

Мінуси

Компанія не дуже вкладається у технічний розвиток фахівця. Через таку бізнес-модель (низька маржинальність, щоб конкурувати на ринку) невеликі компанії на розвиток своїх працівників виділяють малі бюджети. Наприклад, оскільки я виявив бажання здати сертифікацію, компанія покрила витрати на сам екзамен, але готувався я до нього самостійно і курси купував за власні гроші. У «зрілому» аутсорсі зазвичай є корпоративна передплата на освітні ресурси.

Економія на якості. Грошей у наших замовників зазвичай було небагато, тому ми, хоч і обирали технології, все ж економили на них (безкоштовні версії продуктів для розробки) та якості. Наприклад, залучали QA лише частково, частково тестували самі. У результаті перший реліз на продакшн не пройшов гладко, і ми всі вихідні виправляли дрібні баги.

Відсутність технічного ком’юніті. Люди з різних проєктів не обмінювалися досвідом. Компанія не приділяла увагу такому розвитку, тому що стек технологій переважно був різний.

Можливе звільнення у разі закриття проєкту. Я пішов з компанії сам. Потім дізнався, що, коли наш проєкт закрили, фахівця, який прийшов на моє місце, звільнили. Оскільки в таких компаніях нові замовники трапляються не так часто, як у «зрілих», утримувати бенч вони не можуть, та й проєктів з такими ж мовами програмування чи технологіями небагато.

Надмірна кількість узгоджень і жорсткі терміни. Перед початком розробки всього проєкту ми мали узгодити із замовниками тест-стратегію, високорівневу архітектуру та повний список сторонніх бібліотек і ліцензій. Згодом у процесі список бібліотек доводилося змінювати й додатково погоджувати всі ці зміни. Якби ми були частиною команди замовника, то довіра (і щоденний контроль) до нас була б вищою, все це узгоджувалося б легше під час розробки. Попри всі перемовини, які лише уповільнювали роботу, дата дедлайну не змінювалася, а тому це додавало стресу.

«Зрілий» аутсорс

Цікаво потрапити в аутсорс-компанію, яка працює зі світовими лідерами. Так сталося зі мною: я влаштувався на найбільший e-commerce проєкт у компанії N-iX.

Проєкт починався з досить рутинних як для Senior-фахівця завдань, але згодом став для мене особливим, адже вдалося його трансформувати. Коли представники клієнта зрозуміли, що ми показуємо гарні результати, стали поступово передавати нам усе більший скоуп робіт.

95% всіх технічних фахівців працювали з нашого боку, за замовником залишилися тільки стратегічні рішення щодо продукту. Мої завдання починалися з того, щоб вникнути в код і процеси, мігрувати їх на нові технології та оптимізувати. Далі я активно долучався до розробки архітектури. Ми з колегами мали щоденні обговорення з командою архітекторів від замовника, до наших ідей прислухалися — і це мотивувало.

Плюси

Робота з глобальними компаніями, офісів яких немає в Україні. Більшість клієнтів «зрілих» аутсорс-компаній — це клієнти з-за кордону. Все частіше глобальні лідери ринку звертаються до українських компаній, адже рівень знань наших програмістів часто вищий, ніж у спеціалістів з інших країн. Наприклад, наша компанія співпрацює з виробниками індустріальної та побутової техніки, якою, я переконаний, ви теж користуєтесь удома.

Інструменти та можливості для розвитку від компанії. «Зрілий» аутсорс зацікавлений у твоєму постійному розвитку. Серед можливостей — моделі компетенцій та поради щодо розвитку, менторство та семінари з обміну знаннями, юзер-групи всередині компанії та багато іншого.

Можливість змінювати проєкти. Ви можете отримати досвід у розробці різних типів рішень, у різних технологіях, індустріях без зміни компанії. Пропрацювавши на проєкті три з половиною роки, я збагнув, що втрачаю інтерес до завдань. Я поспілкувався з делівері-менеджером і зініціював свій перехід на новий проєкт, що якраз заходив у компанію.

Мінуси

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

Підтримка legacy-коду. Коли ми починали, сет технологій був застарілим. Тому потрібно було підтримувати те, що вже роками використовували в компанії, та паралельно мігрувати на нові технології.

Рутинні завдання на старті проєкту. Потрібен час, щоб вам почали довіряти більше. Наш проєкт спершу налічував 5 людей і за кілька років виріс до 130. Замовники переклали на нас майже всю експертизу. А починалося все з того, що клієнти давали такі завдання, як рефакторинг, баг-фіксинг і мінімальні точкові поліпшення системи.

Переваги проєкту, на якому я працював

Близькість до замовника та можливість впливати на рішення. Коли замовник розвивав свій бізнес в одній з європейських країн, виникло завдання проводити транзакції не лише через банківську картку, а й через банківські перекази. Завдання нетривіальне, адже такі перекази були не моментальними, а оскільки продукт треба було давати якомога швидше, поставало питання нових воркфловів. Архітектори мали своє бачення, яке ламало архітектуру того, що вже було зроблено. Ми ж з колегою запропонували інший підхід, який теж вимагав багато зусиль, але не ламав наявну систему, а розширював її. Крім того, його можна було застосовувати для низки завдань, цікавих для моніторингу бізнесу.

Команда сеньйорів. Оскільки до нас приходили саме за експертизою, команда складалася з мідлів та сеньйорів. А коли працюєш у сильному колективі, твій розвиток відбувається набагато швидше.

Підвищення рівня англійської мови. Комунікація з фахівцями з боку клієнта завжди відбувається англійською, тому й у внутрішньому листуванні ми часто послуговуємося нею. Таким чином мій рівень англійської зріс від Intermediate Strong до Advanced.

Мої висновки

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

Хотілося б почути про ваш досвід і думки щодо роботи в ІТ-компаніях різного типу.

LinkedIn

21 комментарий

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

Работал в аутсорсе, формошлёпных веб-студиях, стартапе и продуктовой компании. Каждая по-своему прекрасна и, имея определённый уровень, мне было в кайф в каждой из них работать.

На данный момент мне больше нравится работать в продуктовой компании. И продуктовую буду искать, если вдруг надо будет менять место работы.

Кому де більше імпонує працювати, враховуючи попередній досвід? в аутсорсі чи в продуктовій компанії?

Кому де більше імпонує працювати, враховуючи попередній досвід? в аутсорсі чи в продуктовій компанії?

Даже не знаю:
Есть аутсорс конторы которые во время карантина переводят свои безликие ресурсы на удаленку.
А есть продуктовые конторы, которые настолько заботятся о своих сотрудниках, что

Некоторые отказались выходить на работу в офис из-за риска своему здоровью:
— А твоё решение по людям, которые не входят в группу хроников или пожилых людей?
— Мы их уволили.
— Уволили? Немедленно?
— Да!

Спасибо, что поделился своим опытом! Для тех, кто рассматривает компанию N-iX это точно будет полезным материалом.

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

А так, например совсем не представлен «зрелый», выражаясь терминологией автора, продукт.
Исходя из размера и возраста компании, работу в условном N-iX нужно сравнивать с работой в условном Slack, а работу в условном Epam — с работой в условном LinkedIn.

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

Если супер упрощённо, то в основе канонических бизнес моделей лежат такие цели:
— Стартап: time to market, rapid growth, disruption. Отсюда следует постоянный кранч, гонка за хайповыми технологиями, компромиссное качество. Зато высокая динамика абсолютно во всем: начиная от принятия решений, заканчивая финансовым и карьерным ростом и его же падением.

— Продукт: sales/subscriptions.
Отсюда следует гонка за фичами (так называемые фича-фабрики). Пользователь — бог, а точнее аналитика — бог. Ты делаешь то, что диктуют цифры в аналитике для повышения sales/subscriptions. Зато там, где критический для пользователя функционал — качество будет топовым и инженерные практики образцовыми. Быть в core team популярного продукта — это одна из лучших позиций для зрелого инженера.

— Аутсорсинг: продажа человеко-часов.
Deliverables — это закрытые таски в джире, репорт в тайм-трекере и демо для клиента. Отсюда следует минимальная вовлечённость инженеров в сам продукт, хотя это нередко навязывается клиентом и менеджментом. Инженерные практики больше зависят от проекта, чем от самого аутсорсера, но из-за специфической бизнес модели аутсорсинга, качеством чаще жертвуют, особенно когда клиент уже «на крючке», а бесконечный багофикс и переделки — это прибыль, а не убыток. Зато инженерам нередко можно с минимальным риском для репутации (все под NDA) учиться и экспериментировать за счёт клиента. Например, переписать монолит на микросервисы просто ради практики. Это одна из лучших позиций для начинающего инженера.

по зп — немає різниці, зате у продуктах більше сношають мозг через те, що часу на розкачку немає. В аутсорсі є плюс — що всі «непопулярні» рішення ти можеш скинути на замовника. В продуктах — відгрібаєш сам. В аутсорсі іноді зустрічається реальна погодинна оплата і оплата овертаймів, в продуктах — часто гола ставка, макс дадуть вихідний якщо у вихідні працював. Це пов’язано з різною структурою оплати зі сторони замовника. Всі інші плюси і мінуси у статті — можна зустріти як в аутсорсі, так і в продуктах.

очень сильно влияет на это размер компании как продуктовой так и аутсорс

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

Не побачив в списку найважливішого при виборі роботи: характерної культури в компанії. Таке враження, що українське IT повністю ігнорує цей аспект роботи, хоча він насправді має чи не найбільше значення як при наймі працівників, так і визначає вектор роботи на компанію.
Будь яка з компаній в розрізі маже і має різну культуру праці, робочого спілкування і відповідальності.
Вся оця різниця в технологіях і розвитку зводиться до визначення слова «зроблено» в контексті роботи. Кожна з цих компаній вкладає своє значення і від цього ростуть ноги у всіх відмінностях.

характерної культури в компанії.

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

Ось якраз в цьому вся соль: не важливо чи займається ваша компанія чи якого вона розміру, а культура компанії — це той розріз, по якому (молодому) спеціалісту найкраще вибирати компанію для професійного розвитку.

а культура компанії — це той розріз

Вопрос в том как определить этот срез? Как оценить культуру компании?

Glassdoor, linkedin, оце-наше-айті, ресурсів купа. Так само поговорити про культуру компанії на співбесіді чи поточними/колишніми робітниками 🕵️‍♀️

Мне кажется компании делятся на 2 вида по культуре:
1. Культурные платят 1 числа следующего месяца
2. Без-культурные тянут до 15-20 числа.

3. 25 числа текущего месяца

на «ті самі 5к» можна й раз на два місяці отримувати котлету в 10к, тому не дуже критично))
хіба якщо щомісячні виплати по кредитах/іпотеках, тоді так

Самые первые плюсы — это больше для стартапа характерно (ну или стартапа внутри большой организации с определенной свободой действий)

Когда людей много, то и в продукте

Розуміння продукту та відчуття залученості.

страдает

Когда людей много, то и в продукте

Розуміння продукту та відчуття залученості.
страдает

Ужас даже в том что и в маленькой команде (менее 10 человек с учтом продукт овнеров) может так же страдать, потому что вовлеченность заканчивается на тимлиде, а разработчики просто «закрывают таски в джире». Это такой стиль управления.

Это срам, а не стиль управления

Як і зазвичай автор просто описав свій особистий, не дуже прямо скажемо, універсальний досвід :).

Блаааттт! Опять и снова?

Дев’ять років працюю в українському ІТ
що для спеціалістів рівнів джуніор і мідл найкращою

Не знаю, может когда автор наберется опыта, то не будет привязывать «тип бизнеса компании» к условиям работы и возможностям.

Но в общем важно понимать:
На данный момент (и последние где-то 5-10 лет) тип компании не влияет на условия работы и возможности для развития. Интересные задачи могут быть как в большом аутсорсе, так и в продукте и в мелких студиях. Микроменеджмент и овертаймы могут быть так же во всех компаниях.

Важно понимать что конкретно вам может дать конкретная позиция (даже не компания) в конкретный момент времени. Условия могут отличаться от проекта к проекту (отдела к отделу).

Крутая статья, спасибо! Очень четко по полочкам все разложили :)

Подписаться на комментарии