Продукт vs аутсорс: як айтівцю змінити тип компанії і швидко адаптуватися
У 2024 році частка українських айтівців, які працюють у продуктових компаніях (45%), вперше перевищила частку тих, хто працює у сервісних (36%). DOU розпитав кількох спеціалістів про те, чому вони переходять у продуктові компанії з сервісних, які плюси і мінуси роботи з продуктом та як швидше пристосуватися до нової роботи.
Крім того, ми поставили кілька запитань представникам продуктових компаній, які наймають до себе айтівців в команду, зокрема про те, на які вони скіли звертають увагу.
«Коли бачиш, як твоє рішення покращує користувацький досвід, це дуже мотивує»
Дмитро Швець, iOS Software Engineer в Uklon, півтора року в продукті
В IT я вже сім з половиною років. Починав свій шлях в аутсорс-компанії. Тоді був «бум» на розробку мобільних застосунків, особливо своїх соціальних мереж різного домену. На ринку було чимало аутсорс-компаній з такими проєктами. Тому знайти роботу без комерційного досвіду не було особливо складно.
Потім я кілька разів змінював місце роботи, але протягом шести років залишався в аутсорсі.
Основну частину досвіду отримав під час співпраці з останньою компанією — Windmill Digital — перед переходом на продукт: пройшов там шлях від розробника рівня Middle до техліда. Мені подобалося зростати горизонтально, але в цьому був і негативний момент. Коли у тебе кілька проєктів, їх треба паралельно підтримувати й оперативно світчитися між цим «зоопарком» технологій.
Після початку повномасштабного вторгнення ринок перейшов у стадію стагнації, багато проєктів заморозили або взагалі закрили. Замовників бізнесу стало шукати складніше. Тому я, прагнучи стабільності, вирішив шукати продуктову компанію на внутрішньому ринку.
Знання мови програмування у мене було розвинуте «вглиб», тому я не поставав перед труднощами з технічного погляду. Та й особливих додаткових зусиль, щоб потрапити у продуктову компанію, докладати не довелося. У
Разючих відмінностей на старті чи особливих челенджів у перші місяці не побачив. Щоб адаптуватися до процесів і комунікації, достатньо було пройти випробувальний термін. Але швидше призвичаїтися до роботи у продукті мені допоміг Engineering Manager.
В аутсорсі було багато моментів, коли треба було, наприклад, налаштовувати залежності або виконувати суміжну/інфраструктурну роботу, пов’язану з основними завданнями. На це зазвичай йшло багато часу. Тобто, по суті, я відволікався від прямих обов’язків. Крім того, в аутсорсі нерідко мав комунікувати із замовниками, яким часом було складно донести бізнесово думку, переклавши з «технічної». На цьому тлі завжди виникали колізії. А от у продукті нічого подібного не трапляється, це суттєво економить час.
В аутсорсі я працював над проєктами, які замовляли клієнти, і часто це означало, що потрібно було адаптуватися до різних технологій і вимог, які постійно змінювалися. Це тягнуло за собою зміни термінів, накладало відбиток на саму розробку.
На противагу цьому сьогодні я маю змогу глибше зануритися в один продукт або кілька взаємопов’язаних продуктів, які є частиною бізнес-стратегії компанії. Тут я маю більше свободи в експериментах і впровадженні нових ідей.
Плюси роботи у продуктовій компанії:
- Глибоке занурення у продукт, зокрема — у технічному плані. Це допомагає краще розуміти його архітектуру, функціональність і потреби користувачів.
- Можливість впливати. Коли бачиш, як твоє рішення покращує продукт і користувацький досвід, це дуже мотивує.
- Довгострокова перспектива. Робота над тривалими проєктами і стратегічними цілями компанії дає змогу розвивати навички і накопичувати досвід в одній сфері.
Мінуси роботи у продуктовій компанії:
- Більше тиску. Високий рівень відповідальності за кінцевий результат продукту може бути стресовим.
- Залежність від внутрішніх процесів. Внутрішні процеси і рішення можуть уповільнювати розробку продукту.
- Ризики змін. Інколи виникають труднощі з адаптацією змін у стратегічних пріоритетах компанії, що може вплинути на напрямок розробки продукту.
«У продукті я відчуваю більше сили і сміливості запропонувати свою ідею»
Анастасія Сапелюк, Middle QA Engineer в EVO
Я світчерка і потрапила в IT частково стараннями чоловіка, частково — завдяки випадку долі. Чоловік завжди цікавився програмуванням і підбивав мене спробувати сили в цій сфері. Якось запропонував взяти участь у розіграші сертифіката на навчання в одній з IT-шкіл. Я виграла: суми якраз вистачало на курси QA, якими я і цікавилася. З перших занять я зрозуміла, що це моє.
Починала з роботи в аутсорсі, хоча не скажу, що це був свідомий вибір. Я старанно вчилася на курсах, тож моє резюме школа надіслала до однієї з компаній-партнерів. Я пройшла там співбесіду на Trainee і тоді не замислювалася про інші варіанти.
У своїй першій компанії — Vector Software — я виросла до Middle QA. Коли минуло кілька років, я зрозуміла, що аутсорс став для мене одноманітним. Іноді я відчувала, що не можу зробити більше, ніж хотіла б, бо ми впираємося у межі бюджету, бачення клієнта, часу та іншого (потрібне підкреслити, як то кажуть). Тому фактор того, що у вас є замовник, з яким сперечатися іноді дуже складно, мене зрештою і відштовхнув. Я почала відчувати сіру рутинність і все менше хотіла щось пропонувати чи вигадувати.
З іншого боку, мене захоплюють українські продукти, які допомагають розвивати внутрішній бізнес і, виходячи на світовий ринок, показують, що в Україні є багато крутих спеціалістів і бізнесів.
Втім на етапі пошуку такої компанії я стикнулася з нюансом. Нерідко потенційні роботодавці дивляться, чи є у кандидата досвід у продукті, і не готові навіть провести HR-інтерв’ю, якщо такого досвіду немає. Інші ж вимагають специфічний досвід роботи в домені, якого стосується продукт. На щастя, не всі такі категоричні й отримати роботу таки можливо — я тому приклад, адже влаштувалася в EVO.
У чому були найбільші зміни
У новій компанії викликом для мене стала потреба трохи змінити свій тип мислення — з аутсорсингового на продуктовий. Бо іноді в аутсорсі ти навіть не замислюєшся, чи застосунок, який ви робите, буде успішний, як його продають кінцевим користувачам, чи він взагалі їм потрібен. У тебе є завдання, яке потрібно виконати, і ти концентруєшся на ньому, геть не замислюючись над подальшою долею розробки.
Натомість у продуктовій компанії всі співробітники — це частинки великого механізму, робота яких важлива. І ти точно знаєш, що від твоєї праці залежатиме успіх продукту. Вражає, наскільки все пов’язано між собою, скільки людей працюють, щоб усе разом функціонувало чітко та злагоджено. Треба витратити чимало часу, аби осягнути всі нюанси роботи в такій компанії.
В аутсорсі ти — виконавець замовлення клієнта, грубо кажучи, робиш те, що він хоче, без зайвих питань. Знаю, що інколи бувають ситуації, коли клієнт пристає на ініціативи команди, коли його вдається переконати, що пропоноване рішення — саме те, що треба. Але я з таким, на жаль, не стикнулася.
У продукті я відчуваю більше сили і сміливості запропонувати ідею, яка може допомогти розвинути те, над чим ми працюємо. Можливо, у підсумку вона й не буде корисна, але тут панує така атмосфера, де це не сприймуть як критичну помилку. Це буде радше досвідом і перебудовою маршруту.
Швидше все зрозуміти й адаптуватися мені допомогла команда та гарно продумана комунікація в компанії. Був етап, під час якого я вивчала документи про роботу компанії, її культуру. Також нам проводили зустрічі для нових співробітників, де детально розповідали про всі ці механізми.
Я працюю у продукті з літа
«В аутсорсі кінцевим бенефіціаром нової фічі є клієнт, а у продукті — ти сам»
Максим Гайдук, Software Engineer у Grammarly
Нині пішов шостий рік як я працюю в IT. Свій шлях я почав з аутсорс-компанії. Спочатку пішов у NerdySoft, потім у SoftServe, де обіймав посаду інженера. Мені подобалася можливість працювати на різних проєктах, використовувати різні технології. Обов’язки були досить стандартні, робота часто була рутинна, але інколи я трошки більше проявляв ініціативи, аби щось зробити/покращити.
У період зростання ІТ-галузі була комфортна зарплата та стрімкий розвиток, оскільки все швидко рухалося і треба було встигати за всім. Однак нині не та ситуація, коли можна перебирати. Вибір проєктів зменшився, а ринок кандидатів, навпаки, збільшився.
Чому я врешті вирішив перейти у продукт? Я хотів більше бути там, де можна зробити конкретний імпакт. Крім того, у продукті я бачу можливість зростання: як професійного, так і фінансового. Ще це історія про стабільність. Про розвиток і заглиблення в ті технології, з якими раніше не стикався. Я завжди прагнув мати різноманітний досвід роботи, щоб стати універсальним інженером. Особисто я розширюю знання з PHP, Java, Scala, це точно знадобиться продукту.
Коли я шукав роботу, основним критерієм для вибору було те, чи я користуюся продуктами компанії, чи вони мені подобаються, чи є перспектива їхнього розвитку. Я проходив співбесіди в Google та Bolt, але процес з Grammarly просунувся відносно швидко, та й мені загалом імпонує культура компанії.
Коли прийшов у Grammarly, помітив певну різницю між наймом в аутсорс і в продукт. Останні зазвичай мають кілька етапів співбесід. У мене були такі етапи:
- первинна розмова з рекрутером;
- розв’язання двох задач з LeetCode (Computer Science, Algorithms and Data Structures);
- behavioral call з менеджером;
- live-coding;
- System Design;
- cultural fit.
Щоб отримати посаду, я додатково покращував знання в алгоритмах, структурах даних і проєктуванні систем.
Після того, як отримав офер, настав час онбордингу. І я помітив, що він досить різко переходить у безпосереднє виконання завдань. Обсяг інформації, який дають, великий, тому про все дізнаєшся вже в роботі. Загальний онбординг тривав два тижні. За цей час я мав виправити кілька багів, а потім перейшов до роботи над новою невеликою функціональністю і тепер працюю над середнім за складністю проєктом.
Не те щоб мені не подобався такий перехід до роботи. Зрештою він досить практичний і інженери можуть швидко почати контриб’ютити в загальну систему та отримувати знання вже в процесі. Але, думаю, мені було б комфортно мати
З усім тим на цьому етапі я отримав чітке розуміння про продукти компанії та їхній розвиток. Це допомогло швидше адаптуватися. Крім того, комунікація з командою та самостійний пошук інформації дали результат. Коли я кажу про пошук інформації, маю на увазі самостійність у виконанні завдань.
Я працюю у Grammarly з літа
Плюси роботи у продуктовій компанії:
- більший ownership над роботою, яку виконуєш;
- відчуття імпакту;
- велика кількість співбесід добре відбирає найкращих людей в команду;
- різноплановість роботи і стабільність;
- бенефіти (у мене це можливість онсайт-візитів, додаткові бюджети на особистий розвиток, покращення робочого місця, додаткові дейофи та сікліви).
У моїй компанії мінусів не бачу.
«У продукті ти не просто людський ресурс, який цінний тільки тоді, коли для тебе є проєкт»
Software Developer в AUTODOC
До того як почати працювати у великій аутсорс-компанії, я був частиною невеликої луцької команди, яка спочатку займалася аутсорсом, а потім стала і сама робити продукт. Тоді я взагалі не замислювався над типом компанії — просто працював.
Але коли компанія закрилася, переді мною постало завдання — знайти нову роботу. Я зареєструвався на Djinni, заповнив повністю LinkedIn-профіль, зробив резюме. Спочатку все йшло добре: писали рекрутери, я проходив інтерв’ю, технічну частину, але коли дійшли до перевірки англійської, сказали, що з таким рівнем я далеко не зайду. Тому я взяв паузу на два-три місяці й став активно вчити англійську, а разом з тим підтягував і технічну теорію.
Добре підготувавшись, став шукати саме велику й відому компанію, адже в невеликих локальних зарплати вдвічі нижчі. Пройшовши п’ять технічних співбесід, від двох компаній отримав офер і вибрав SoftServe. З моменту втрати роботи й до першого дня у SoftServe минуло чотири місяці.
Спочатку робота мені подобалося: геть інший організаційний рівень, бенефіти, яких не було у попередній компанії (100% оплачувана відпустка та лікарняні, нова техніка). Але одного дня клієнт вирішив замінювати послуги SoftServe на дешевші, від спеціалістів з Індії. Компанія не змогла знайти мені новий проєкт, і мене звільнили. Почався новий квест з пошуку роботи.
Цього разу все відбулося швидше — уже за місяць я перейшов в AUTODOC. І пропрацювавши тут дев’ять місяців, розумію, які є плюси у продуктовій компанії, хоча спеціально й не шукав саме такого формату.
З плюсів:
- вища зарплата;
- стабільність і прогнозованість (якщо продукт живий, тебе не звільнять за рік-два);
- можливість кар’єрного розвитку;
- розуміння, що ти потрібен компанії, оскільки ти — її працівник, а не просто людський ресурс, який цінний тільки тоді, коли для тебе є проєкт.
У SoftServe, звісно, було більше мерчу: його дарували і на свята, і на день компанії, і на день народження... Але я згоден на те, щоб отримувати більшу зарплату й не отримувати стільки мерчу [сміється].
Втім що стосується адаптації чи організаційних моментів безпосередньо в роботі, то великої різниці я не помітив і перед труднощами не поставав. Просто у SoftServe був Project Manager, з яким я обговорював підвищення зарплати, день, на який хочу взяти вихідний. А тут є Product Manager з трохи іншими функціями, тому організаційні моменти я вирішую з тимлідом.
Що кажуть менеджери продуктових компаній
Також DOU розпитав представників продуктових компаній, які наймають до себе розробників у команди. Вони розповіли, які вимоги є в їхніх компаніях і що має «підтягнути» айтівець, щоб перейти з аутсорсу в продукт за бажання.
Євген Генов Head of Engineering у Kyivstar.Tech
Наша компанія орієнтована на пошук спеціалістів рівня Middle та Senior, тому базовою вимогою є мати щонайменше три роки досвіду. Водночас інші критерії відбору не є специфічними та залежать від конкретної посади.
У продукті важливо, щоб кожен учасник розумів загальну стратегію та працював над спільною метою. Це не про індивідуальні досягнення, а про колективний результат, де цінність приносить синергія всієї команди. Ми не ставимо за мету переманювати окремих фахівців з аутсорсу, адже успіх у продуктовій компанії будується на роботі злагодженої команди, а не одного суперзіркового гравця.
Перехід з аутсорсингу до продуктового IT вимагає певних змін у підході до роботи, але це більше про адаптацію до нових умов і пріоритетів, а не про необхідність кардинально перевчатися. У продуктовій компанії ми приділяємо велику увагу якості продукту. Для когось швидкість виконання завдань може здаватися перевагою, але саме баланс між якістю та швидкістю стає ключовим чинником успішності. Тому для нас важливо, щоб команда орієнтувалася не лише на швидке досягнення результату, а й на те, щоб ці результати були якісні й допомагати довгий час розвивати продукт.
Чи є айтівці, які у продуктовій компанії не приживаються? Так, трапляються випадки, коли фахівці не знаходять себе у продукті, іноді це пов’язано з труднощами в роботі в команді. Як я вже казав: у продуктовій розробці важливо не тільки бути експертом у своїй сфері, а й вміти ефективно співпрацювати з іншими. Працювати наодинці над улюбленим проєктом — це одна річ, але робота в команді вимагає гнучкості, вміння домовлятися, обговорювати й разом ухвалювати рішення, що іноді стає викликом для спеціалістів.
Якщо ви прагнете потрапити до продуктової компанії, варто звернути увагу на кілька ключових аспектів. По-перше, проактивність — це одна з найважливіших рис. У продуктових командах важливо не просто виконувати поставлені завдання, а й бачити можливості для поліпшення продукту і пропонувати рішення. По-друге, системність. Робота потребує стратегічного підходу та вміння мислити на кілька кроків уперед. І, звичайно, продуктовий майндсет — це здатність думати з позиції користувача, розуміти його потреби та створювати рішення, які приносять максимальну цінність.
Денис Румянцев Deputy CTO Hily в appflame
У нас немає специфічних умов відбору для спеціалістів. Звісно, продуктовий досвід вітається через те, що загальний формат роботи у продукті та аутсорсі дещо відрізняється. Але на початку найму ми проводимо стандартний fit check, щоби дізнатися, чи підходить нам людина за цінностями та умовами роботи.
Наприклад, я завжди пояснюю кандидатам, що в продукті, на відміну від аутсорсу, не вийде часто переходити з технології до технології, бо всі core-технології визначені. Коли в аутсорсі заходить новий проєкт, в айтівців є можливість спробувати нові інструменти одразу в продакшені та здобувати новий досвід. У продукті такої розкоші немає, бо продукт той самий, а перехід на нову технологію — це завжди дуже зважене рішення: адаптація нової технології має бути вагомо обґрунтована та приносити бенефіти. Через цю відмінність багато кандидатів відпадають на перших етапах співбесіди.
Водночас інженерів рівня Middle+ дуже круто наймати з аутсорсу, тому що вони спробували багато різних технологій, здобули досвід у різних доменах, знають, що й де працює краще — іншими словами, набили руку. Але особисто мені ще не доводилося переманювати спеціалістів з аутсорсу. Найчастіше ми переманюємо інженерів з інших продуктових компаній, адже в них уже є необхідний пул компетенцій і розуміння специфіки продуктової розробки.
Я не можу сказати, що є айтівці, які не приживаються конкретно у продукті. Є айтівці, які загалом не приживаються в компанії. А продуктова вона чи сервісна — різниці немає.
Людині, яка хоче потрапити у продукт, потрібно розуміти, як працює продуктова розробка — її переваги та недоліки. Це гра в довгу. Інженери тут не отримують швидкого дофаміну через здачу проєкту, умовно, кожні шість місяців, бо в продукті немає «кінця», він триває постійно. Натомість ми отримуємо дофамін, коли бачимо в аналітиці, як фіча, яку робила та чи інша група людей, покращує метрики.
Айтівцям, які прагнуть працювати у продукті, потрібно розвивати продуктовий майндсет. Та, відверто кажучи, я слабо вірю, що можна навчитися цього, читаючи літературу або слухаючи доповіді. Проте його можна «тренувати»: аналізувати, як ті чи інші зміни впливають на досвід користувачів; аналізувати критичні для продукту метрики; пропонувати альтернативні рішення; співпрацювати з іншими департаментами тощо.
