Різниця між роботою у продукті та аутсорсі з погляду розробника
Привіт! Мене звати Ярослав Мота, я Senior Software Engineer в N-iX. Дев’ять років працюю в українському ІТ: маю досвід роботи в продукті та аутсорсі.
У статті розповім про власний досвід і підрезюмую найважливіші плюси та мінуси роботи в українських ІТ-компаніях і на проєктах різного типу. Думаю, матеріал буде корисний тим, хто хоче змінити місце праці, але не знає, які переваги або недоліки очікувати від роботи в продуктовій чи аутсорс-компанії. А також тим, хто тільки стає на шлях ІТ.
Українська продуктова компанія
У продукті я отримав свій перший досвід роботи в ІТ. Дев’ять років тому, коли ще був студентом третього курсу, зрозумів: університет не дає мені бажаного практичного досвіду — і почав шукати вакансії на позицію трейні. Відтак знайшов варіант і пішов на співбесіду. Тепер розумію, що це була одна з найцікавіших співбесід. Оскільки практичного досвіду в мене не було, розмова базувалася на теоретичних знаннях, інтерв’юер давав цікаві алгоритмічні задачі та запитував, як би я розв’язував певну проблему. Наприклад, мене спитали про алгоритми обходу дерев. На псевдокоді їх треба було реалізувати та пояснити, для вирішення яких реальних проблем варто застосовувати.
За результатами співбесіди мене взяли у велику ІТ-компанію, що працювала над розробкою власного продукту, яким уже тоді користувалися організації в Україні. Моя команда удосконалювала його, щоб відповідати на потреби людей і залишатися № 1 у своїй ніші.
Плюси
Швидкість ухвалення рішень. Мій онбординг відбувся швидко, адже часу на «розкачку» не залишалося. Наприклад, не було зовнішніх замовників, які б давали доступи по кілька тижнів, як це трапляється в аутсорсі. На проєкті поряд зі мною сидів технічний директор, який розумів: що довше я буду готуватися до роботи, то довше вноситимуть у продукт потрібні зміни. Тож доволі швидко мене допустили до того, що мало прямий результат, — і це мотивувало.
Різноманітність завдань. Оскільки на продукті команда зазвичай невелика, то й завдання доводиться робити різноманітні: бекенд, фронтенд, інфраструктура та бази даних. Окремі ролі під такі таски відводять рідко. Так мені доводилося ще на позиції трейні заглиблюватися в те, як хоститься аплікація, як уникати проблем з перформансом на базі даних, як працює десктоп і веб.
Розуміння продукту та відчуття залученості. До нас в офіс запрошували кінцевих користувачів продукту. На такі зустрічі приходила залучена до розробки команда. Клієнти розповідали, як вони користуються продуктом, що можна поліпшити та якого функціоналу бракує. Ці зустрічі не допомагали моєму технічному розвитку, але схоже спілкування давало краще розуміння продукту та бізнес-завдань. Після обговорень ми збиралися з командою на брейншторм щодо нововведень. Кожен міг пропонувати свої ідеї та процес їхньої реалізації. Вже зараз я розумію, наскільки цей досвід став важливим і допоміг надалі не боятися висловлювати власне бачення, обстоювати думку і прислухатися до критики.
Дисципліна і відповідальність. Якщо ти недопрацьовуєш, це відразу відбивається на результаті всієї команди. Усі залучені в розвиток продукту фахівці сиділи в одному офісі: розробники разом з маркетологами, командою підтримки та керівництвом. Пам’ятаю, як колега, що працював уже пів року, почав робити менше на тлі інших та показував гірші результати, ніж раніше. Падіння мотивації сильно відчувалося. Те, що недопрацьовував колега, доводилося завершувати іншим. Ми обговорили те, що людина регулярно підводить команду, і в результаті він покинув компанію.
Мінуси
Відносно повільне технічне зростання. Я приєднався трейні в команду, де було два сеньйори, технічний директор і кілька мідлів. На проєкт зазвичай брали джуніорів, і була тенденція, що люди приходили на посади початківців, виростали до певного рівня та йшли. Оскільки проєкт був орієнтований на розв’язання бізнес-завдань, технології відставали від ринку. Міграція на нові відбувалася, але повільніше, ніж у продуктових компаніях, де драйвером є не лише бізнес, а й технічні аспекти (я брав участь у міграції з ASP. NET Web Forms, які тоді були застарілими). Завдання різноманітні, але часу зосередитися на чомусь одному переважно є мало.
Неможливість змінити проєкт у межах компанії. Якщо компанія зосереджена на розвитку лише одного продукту, то проєкт не вдасться змінити взагалі, на відміну від аутсорсингових фірм, де постійно з’являються нові можливості. Вважаю це негативним аспектом, адже від того, що працівники надто довго засиджуються на одному проєкті, не виграє ніхто. Спеціаліст поступово втрачає мотивацію, звикає до своїх завдань і припиняє активно розвиватися, а проєкту бракує свіжих ідей і підходів, позитивного та негативного досвіду, який уже мають фахівці в індустрії.
Проєкт не «з нуля». Рідко продуктові компанії на українському ринку починаються зі стартапу. Принаймні у Львові фірми, про які доводилося чути, переважно відкривали свої офіс на пізніх етапах розвитку. А тому немає шансу бути залученим на початку та отримати досвід «стартувати» розробку. На відміну від аутсорс-компаній, де в пайплайні трапляються проєкти «з нуля». Це важливо, адже найбільший розвиток ви здобуваєте, коли стартуєте проєкт, обираєте технології, архітектуру та підходи. Цей досвід не такий критичний для фахівців рівнів джуніор і мідл, але необхідний для сеньйорів.
Український аутсорс
Після продукту я працював у різних аутсорс-компаніях. Для себе умовно поділяю їх на аутсорс «зрілий» та «незрілий». Кажучи про критерій «зрілості», маю на увазі готовність компанії інвестувати в розвиток та збереження своїх фахівців, а також рівень проєктів, з якими вона працює.
«Незрілий» аутсорс
Після роботи на продукті я прийшов на проєкт у невелику фірму, клієнтами якої були також невеликі компанії. У команді було четверо людей, і працювали ми на клієнта, який надавав послуги консалтингу в страховій сфері. Їм не потрібна була постійна команда розробників у штаті, тому за рішенням звернулися до нас.
Плюси
Робота з найновішими технологіями. Ми могли обирати технології, з якими працювати. Адже головне — виконати завдання замовника. Тому віддавали перевагу тому, що було найцікавіше.
Постійна комунікація із замовником. Ми спілкувалися безпосередньо із клієнтом: брали участь в обговоренні завдань і допомагали ухвалювати рішення його продакт-оунеру. Для мене це була можливість розвивати софт скіли та знання англійської.
Візити клієнта та подорожі за кордон. Продакт-оунер приїздив до нас, щоб проводити сесії планування наступних фаз, узгоджувати технічні моменти та технологічний розвиток проєкту. Також тоді я поїхав у свій перший бізнес-тріп у Нідерланди. Я взяв участь у воркшопах, краще зрозумів бізнес замовників і мав змогу поспілкуватися з кінцевими користувачами продукту. В українських продуктових компаніях такі можливості трапляються набагато рідше, адже немає тісної взаємодії з клієнтами (або й узагалі сторонніх замовників), тому потреба у відрядженнях не є настільки важливою. Хоча, можливо, в посткоронавірусному світі бізнес-подорожі взагалі відійдуть в історію :)
Мінуси
Компанія не дуже вкладається у технічний розвиток фахівця. Через таку бізнес-модель (низька маржинальність, щоб конкурувати на ринку) невеликі компанії на розвиток своїх працівників виділяють малі бюджети. Наприклад, оскільки я виявив бажання здати сертифікацію, компанія покрила витрати на сам екзамен, але готувався я до нього самостійно і курси купував за власні гроші. У «зрілому» аутсорсі зазвичай є корпоративна передплата на освітні ресурси.
Економія на якості. Грошей у наших замовників зазвичай було небагато, тому ми, хоч і обирали технології, все ж економили на них (безкоштовні версії продуктів для розробки) та якості. Наприклад, залучали QA лише частково, частково тестували самі. У результаті перший реліз на продакшн не пройшов гладко, і ми всі вихідні виправляли дрібні баги.
Відсутність технічного ком’юніті. Люди з різних проєктів не обмінювалися досвідом. Компанія не приділяла увагу такому розвитку, тому що стек технологій переважно був різний.
Можливе звільнення у разі закриття проєкту. Я пішов з компанії сам. Потім дізнався, що, коли наш проєкт закрили, фахівця, який прийшов на моє місце, звільнили. Оскільки в таких компаніях нові замовники трапляються не так часто, як у «зрілих», утримувати бенч вони не можуть, та й проєктів з такими ж мовами програмування чи технологіями небагато.
Надмірна кількість узгоджень і жорсткі терміни. Перед початком розробки всього проєкту ми мали узгодити із замовниками тест-стратегію, високорівневу архітектуру та повний список сторонніх бібліотек і ліцензій. Згодом у процесі список бібліотек доводилося змінювати й додатково погоджувати всі ці зміни. Якби ми були частиною команди замовника, то довіра (і щоденний контроль) до нас була б вищою, все це узгоджувалося б легше під час розробки. Попри всі перемовини, які лише уповільнювали роботу, дата дедлайну не змінювалася, а тому це додавало стресу.
«Зрілий» аутсорс
Цікаво потрапити в аутсорс-компанію, яка працює зі світовими лідерами. Так сталося зі мною: я влаштувався на найбільший e-commerce проєкт у компанії N-iX.
Проєкт починався з досить рутинних як для Senior-фахівця завдань, але згодом став для мене особливим, адже вдалося його трансформувати. Коли представники клієнта зрозуміли, що ми показуємо гарні результати, стали поступово передавати нам усе більший скоуп робіт.
95% всіх технічних фахівців працювали з нашого боку, за замовником залишилися тільки стратегічні рішення щодо продукту. Мої завдання починалися з того, щоб вникнути в код і процеси, мігрувати їх на нові технології та оптимізувати. Далі я активно долучався до розробки архітектури. Ми з колегами мали щоденні обговорення з командою архітекторів від замовника, до наших ідей прислухалися — і це мотивувало.
Плюси
Робота з глобальними компаніями, офісів яких немає в Україні. Більшість клієнтів «зрілих» аутсорс-компаній — це клієнти з-за кордону. Все частіше глобальні лідери ринку звертаються до українських компаній, адже рівень знань наших програмістів часто вищий, ніж у спеціалістів з інших країн. Наприклад, наша компанія співпрацює з виробниками індустріальної та побутової техніки, якою, я переконаний, ви теж користуєтесь удома.
Інструменти та можливості для розвитку від компанії. «Зрілий» аутсорс зацікавлений у твоєму постійному розвитку. Серед можливостей — моделі компетенцій та поради щодо розвитку, менторство та семінари з обміну знаннями, юзер-групи всередині компанії та багато іншого.
Можливість змінювати проєкти. Ви можете отримати досвід у розробці різних типів рішень, у різних технологіях, індустріях без зміни компанії. Пропрацювавши на проєкті три з половиною роки, я збагнув, що втрачаю інтерес до завдань. Я поспілкувався з делівері-менеджером і зініціював свій перехід на новий проєкт, що якраз заходив у компанію.
Мінуси
Повільний процес ухвалення рішень. Ви сторонній вендор, і в більшості випадків знадобиться час, щоб налагодити роботу та ефективну комунікацію з клієнтом. Крім того, якщо в замовника є своя команда, то на запити його представників реагуватимуть швидше.
Підтримка legacy-коду. Коли ми починали, сет технологій був застарілим. Тому потрібно було підтримувати те, що вже роками використовували в компанії, та паралельно мігрувати на нові технології.
Рутинні завдання на старті проєкту. Потрібен час, щоб вам почали довіряти більше. Наш проєкт спершу налічував 5 людей і за кілька років виріс до 130. Замовники переклали на нас майже всю експертизу. А починалося все з того, що клієнти давали такі завдання, як рефакторинг, баг-фіксинг і мінімальні точкові поліпшення системи.
Переваги проєкту, на якому я працював
Близькість до замовника та можливість впливати на рішення. Коли замовник розвивав свій бізнес в одній з європейських країн, виникло завдання проводити транзакції не лише через банківську картку, а й через банківські перекази. Завдання нетривіальне, адже такі перекази були не моментальними, а оскільки продукт треба було давати якомога швидше, поставало питання нових воркфловів. Архітектори мали своє бачення, яке ламало архітектуру того, що вже було зроблено. Ми ж з колегою запропонували інший підхід, який теж вимагав багато зусиль, але не ламав наявну систему, а розширював її. Крім того, його можна було застосовувати для низки завдань, цікавих для моніторингу бізнесу.
Команда сеньйорів. Оскільки до нас приходили саме за експертизою, команда складалася з мідлів та сеньйорів. А коли працюєш у сильному колективі, твій розвиток відбувається набагато швидше.
Підвищення рівня англійської мови. Комунікація з фахівцями з боку клієнта завжди відбувається англійською, тому й у внутрішньому листуванні ми часто послуговуємося нею. Таким чином мій рівень англійської зріс від Intermediate Strong до Advanced.
Мої висновки
Підсумовуючи власний досвід, вважаю, що для спеціалістів рівнів джуніор і мідл найкращою буде аутсорсингова модель: і колеги близько, і розвиток швидкий. Сеньйорам буде цікавий продукт і «зрілий» аутсорс, де ти впливаєш на рішення, залучений у процеси, маєш змогу стартувати проєкти або працювати в глобальних компаніях. Мабуть, сеньйорів варто залучати і до «незрілого» аутсорсу, щоб виводити той на новий рівень. Aле через брак коштів нерідко туди потрапляють саме джуніори або мідли, від чого страждає і якість для замовника, і розвиток самих спеціалістів.
Хотілося б почути про ваш досвід і думки щодо роботи в ІТ-компаніях різного типу.
