Наймати фулстек-розробників: за чи проти

💡 Усі статті, обговорення, новини про HR — в одному місці. Приєднуйтесь до HR спільноти!

Усім привіт! Мене звати Микола Коваль, понад 14 років я займаюся розробкою, з них понад 5 у менеджменті, а останні 2 працюю в Liven — одному з бізнесів венчур-білдера SKELAR. Ми створюємо екосистему продуктів, яка допомагає користувачам покращувати своє ментальне благополуччя. Я приєднався до Liven першим інженером і закривав кілька процесів — від інфраструктури до бекенду та фронтенду. Але вже невдовзі виникла потреба формування команди. Сьогодні в бізнесі працюють понад 40 інженерів.

Усі ми бачили, як від початку повномасштабної війни в Україні IT-ринок адаптувався до нових умов — зросла потреба в гнучкості, спеціалістах, які зможуть закривати якомога більше процесів і при цьому вкладатися у менші бюджети. Останнім часом підвищився попит на найм фулстек-інженерів. Згідно з дослідженням DOU, популярність цієї сфери розробки зросла з 19% у 2023 році до 21,4% у 2024-му, а зараз на DOU відкрито майже 300 вакансій за запитом «Full Stack».

У 2023 році я й сам провів десятки інтервʼю на позицію фулстек-розробника для залучення в команди early-stage стартапів SKELAR. З одного боку, якщо ти тільки запускаєш бізнес і тобі потрібно оперативно створити MVP та пройти «долину смерті», то найняти єдиного спеціаліста, який водночас і пише клієнтський код, і відповідає за бекенд, видається вигідним варіантом. З іншого боку, про таке рішення варто подумати двічі: якщо одна людина займається всім — від створення користувацького інтерфейсу до роботи з базою даних — то це не лише виснажує спеціаліста, а й створює ризики для бізнесу, особливо в довгостроковій перспективі.

Фулстек чи профільний спеціаліст? Я часто замислювався, де проходить межа: коли інженер ще «фул», а коли вже Staff. І чи не простіше виростити сильного senior-фахівця до Staff, ніж шукати «універсального» працівника, який однаково добре пише і фронт, і бекенд, і ще й тримає інфраструктуру.

Разом із CTO Mate academy Вадимом Ільченком ми розглянули як сильні сторони, так і підводні камені найму фулстек-розробників. Тож далі — аргументи «проти» від мене та «за» від Вадима.

«Проти»: чому найм фулстек-розробника — це не «срібна куля»

Один спеціаліст — це погляд під одним кутом

На етапі побудови MVP в команду залучають фулстек-інженера не тільки тому, що цей фахівець може самостійно закрити всі процеси розробки. Ще одна пріоритетна причина — його не потрібно синхронізувати з іншими. А синхронізація — це найбільший bottleneck команди в процесі побудови чогось великого. Згадаємо ту ж історію про Вавилонську вежу: щойно люди втратили спільну мову та не могли домовитися й діяти спільно, будівництво зупинилося.

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

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

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

Тут спеціалісту доводиться вибирати, в який напрям зануритися. А щоб утримувати складну систему, необхідна експертиза відповідного рівня.

Проблема балансу між шириною та глибиною знань

Багато хто обирає фулстек-розробку саме тому, що їм цікаво одразу кілька напрямів — бекенд, фронтенд, DevOps. Це допомагає швидко закривати різні задачі й бачити ширшу картину. Але водночас такий підхід ускладнює накопичення глибокої експертизи в кожному з напрямів. У книзі про есенціалізм Ґреґ Маккеон наголошує на важливості вибору пріоритетів: якщо концентруватися на меншій кількості важливих речей, то можна досягти ґрунтовніших результатів. Такий самий принцип «10 000 годин»: майстерність формується роками цілеспрямованої роботи, а не «ривками» тривалістю кілька місяців.

Робочий приклад: потрібно розробити мобільний застосунок. Потрібен і фронтенд, і бекенд. Кого будемо шукати: двох фулстеків чи одного фронтенд- та одного бекенд-інженера? У такій ситуації я віддаю перевагу другому варіанту. Адже знайти фулстеків, які однаково добре почуваються в iOS, Android і ще й на бекенді, — завдання з зірочкою. Робити застосунок на React Native? Тоді аби фулстеку взятися за бекенд, ще й мобільної версії, йому потрібно чимало експертизи. Зазвичай це інженери з 7+ роками досвіду, які мають глибину в одній сфері та добре орієнтуються в суміжних технологіях. Це рівень, близький до Staff-інженера — подібних фахівців на ринку небагато і саме вони здатні закривати на собі комплексні проєкти.

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

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

Взаємодія з AI як маркер експертності

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

ШІ допомагає швидко розширити «горизонти знань»: за 15-20 хвилин можна розібратися в новій темі чи отримати кілька варіантів технічного рішення. Але також можна потрапити в когнітивну пастку. По-перше, AI може «галюцинувати». По-друге, він не створює експертної думки — лише пропонує напрями.

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

Інженер сьогодні — це не тільки той, хто пише код, а й оператор AI: він уміє правильно ставити завдання, критично інтерпретувати відповіді й інтегрувати їх у реальну інженерію.

Невизначеність очікувань

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

На власному досвіді я бачив: чим спеціаліст «горить», у тому й розвивається значно швидше. Наприклад, фулстек-спеціаліст приєднувався до команди з наміром писати бекенд, а на практиці мав здебільшого працювати на фронтенді або навпаки. Це викликає дискомфорт у самого спеціаліста та зниження продуктивності. На інтервʼю такі спеціалісти на запитання про мотивацію змінити роботу часто відповідають: «казали, що буде більше завдань із бекенду, а було 80% фронтових і мені не подобалося». Звісно, якщо інженер не отримує задоволення від завдань, він втрачає мотивацію. У результаті це знижує продуктивність і якість роботи.

А як за позицією фулстек-розробника оцінити, який напрям цікавить спеціаліста більше й у якому він має глибшу експертизу? Це створює серйозний виклик, адже на ринку немає чіткого розуміння: фулстек — це senior у бекенді/middle у фронтенді або ж навпаки. У такій ситуації дуже складно оцінити, наскільки ефективно людина буде виконувати задачі.

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

«За»: найм фулстека — вибір на користь швидких ітерацій і культури овнершипу

Вадим Ільченко CTO Mate academy

Я — Вадим Ільченко, CTO Mate academy. У розробці вже приблизно 8 років і починав із фронтенду. На початку кар’єри я глибоко прокачався саме в сфері анімацій, розумінні того, як це працює «під капотом», вивчив і «завіз» у компанію WebGL, що дозволило нам залучати більше клієнтів і вигравати нагороди на Awwwards. Паралельно цікавився бекендом, робив pet-проєкти та вивчав алгоритми.

У Mate academy я був першим штатним інженером. Одразу — фулстек. Мої перші (та й поточні) задачі були скоріше про «вміння швидко розбиратись у чомусь» і вирішувати проблеми бізнесу. Наприклад, перша задача була — пофіксити щось у бекенді на Ruby. Потім я мігрував сайт на Node.js і почав будувати платформу.

Коли з’явилася потреба наймати ще інженерів, ми з CEO Романом Апостолом одразу погодилися, що це будуть фулстеки. Ми — стартап, і нам важливо вкладатися в ріст, уміти швидко тестувати гіпотези, масштабувати те, що працює, і так само швидко відмовлятися від того, що не спрацьовує. У такому сетапі надзвичайно цінні інженери, які здатні закривати бізнес-завдання end-to-end.

Стратегія досі працює і я можу впевнено сказати, що для нас фулстек-розробники — дуже правильне рішення. Далі розпишу основні переваги, які спрацювали саме у нашому випадку. Спойлер: я не кажу, що фулстек — це «silver bullet», скоріше поділюся власним досвідом.

Менше часу на синхронізацію між розробниками

Як каже вище Микола, важливо, щоб усі були on the same page. У випадку, коли «фронтендер» і «бекендер» мають домовлятися, як працюватиме «кнопка на сайті», це займає багато часу та створює залежності. Згадайте жарт: «Скільки тобі треба часу на цю задачу? — Тиждень. А якщо додати ще одного розробника? — Два тижні».

Коли над цим працює одна людина, вона самостійно вирішує, як усе реалізувати, виходячи з наявного контексту та бізнес-потреб. Така людина оперує всім ланцюгом — від колонок і таблиць у базі даних до того, як ці дані потрапляють і відображаються на UI. Банально не треба йти до іншого спеціаліста й запитувати: «Як називатиметься це нове поле?»

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

End-to-end ownership і продуктове мислення

Наш інженер не лише пропонує рішення, а й несе повну відповідальність за його втілення — від ідеї до запуску в продакшені та збору аналітики. Мати оунершип над фічею чи частиною продукту, ставати «go-to person» з цієї частини, бачити, як юзери користуються нею в продакшені і розуміти кінцевий результат — все це дуже мотивує інженерів продовжувати працювати над продуктом. Це також напряму впливає на retention команди.

Наша культура і Job Ladder вимагають від розробників не лише коду, а й розуміння метрик та впливу на бізнес. Людина, яка має і технічний, і бізнес-контекст, здатна запропонувати прості рішення, що ефективно вирішують поставлену проблему.

Уніфікація технологій

JavaScript/Node.js стек постійно розвивається. Ми будуємо і фронтенд, і бекенд на TypeScript. Це дозволяє інженерам використовувати єдину технологію, що значно спрощує і прискорює розробку, а також полегшує knowledge sharing всередині команди. В контексті компанії один фулстек-розробник має доступ до даних, API та користувацьких флоу. В результаті фічі робляться швидше через відсутність оверхедів у комунікації та загальну обізнаність у всьому стеку.

Багато топових компаній, таких як Netflix, Airbnb, PayPal та інші, переходять на фулстек JavaScript-стек саме для того, щоб розробники мали ширше розуміння продукту. І це навіть не про витрати на найм, зарплату чи координацію роботи, а радше про швидкість і якість рішень, які ці люди можуть заделіверити, маючи повний контекст і глибоку обізнаність в продукті.

У мене є знайомі, які у своїх компаніях впроваджують Node.js стек саме заради можливості в майбутньому наймати «одного інженера», а не окремо бекендерів і фронтендерів. І це не маленькі компанії, де коду дуже багато. Але організації готові інвестувати, бо бачать у цьому користь.

Фулстек — це все ж T-shaped інженер

Я погоджуюся, що інженер із вузьким профілем може мати значно глибші знання, ніж умовний фулстек. Я сам це пройшов, коли заглибився у фронтенд-анімації аж до WebGL і рендерингу 3D-сцен із шейдерами — те, що більшість навіть фронтендерів у своїй кар’єрі не роблять.

Кожен інженер у Mate має певну глибину знань у певній області, частині продукту чи технології. Комусь подобається DevOps, і така людина покращує нашу інфраструктуру та CI/CD пайплайн (до речі, ми деплоємось щодня — про це у мене був виступ на DOU Architecture Day). Хтось занурюється в AI-напрям і впроваджує AI-фічі в платформу. Інша людина повністю відповідає за мобайл-напрямок, розвиває і покращує нашу мобільну апку. Хтось займається A/B тестами та інфраструктурою навколо них. Хтось свічнувся в дата-аналітику. І навіть тут, коли дата-аналітик розуміє, що потрібна нова колонка в базі чи новий івент у коді, він самостійно додасть це, запросивши код-рев’ю у інших команд.

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

Самарі

Питання найму має розпочинатися ще задовго до знайомства зі спеціалістом — воно розпочинається з питання «З яким завданням нам наразі треба впоратись?», «Яку ціль у бізнесі ми маємо?».

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

Головне — тверезо оцінюйте свій кейс та, наймаючи людей, в першу чергу звертайте увагу на те, наскільки їхній досвід релевантний вашим викликам.