«Ні. Це для технарів. Я гуманітарій». Знайомо?
Один ярлик, який колись з'явився через любов до мов, історії чи літератури, раптом починає визначати професії, на які ви навіть дозволяєте собі дивитися.
Але IT давно не складається лише з людей, які пишуть код. І навіть там, де технічні знання справді потрібні, «я цього поки не знаю» і «я не здатний цього зрозуміти» — зовсім не одне й те саме.
Тож питання варто поставити інакше. Не «Чи достатньо я технічна людина для IT?», а «Яка роль в IT відповідає тому, як я думаю, працюю і вирішую задачі?»
Спочатку розберімося: хто взагалі такий «гуманітарій»?
Зазвичай за цим словом ховається приблизно такий набір переконань:
- «Я не дружу з математикою».
- «Я ніколи не програмував».
- «У мене немає технічної освіти».
- «Мені легше працювати з людьми й текстами, ніж із формулами».
Але професія — це не шкільний поділ на тих, хто любив алгебру, і тих, хто писав хороші твори. У роботі значно важливіше інше:
- як ви структуруєте інформацію;
- чи можете розібратися в новій системі;
- як знаходите причину проблеми;
- чи вмієте ставити правильні запитання;
- як комунікуєте з іншими людьми;
- наскільки уважні до деталей;
- чи можете пояснити складне простими словами.
І тут виявляється цікава річ. Частина навичок, які люди звикли вважати «гуманітарними», в IT не заважають — вони потрібні.
IT — це не професія
Коли людина говорить «хочу працювати в IT», це приблизно як сказати «хочу працювати в медицині». Ким саме? Розробником? Аналітиком? Тестувальником? Project Manager? UX/UI Designer? Product Manager? Technical Writer?
Усі ці люди можуть працювати над одним продуктом, але їхні щоденні задачі та необхідні навички будуть абсолютно різними.
Тому якщо ви відкрили курс Python, нічого не зрозуміли й вирішили, що «IT не моє», — можливо, ви просто приміряли не ту професію.
Розглянемо кілька напрямів:
Business Analyst: якщо вам подобається розбиратися, «що насправді потрібно»
Уявіть, клієнт приходить до команди й говорить: «Нам потрібна система, яка автоматизує роботу менеджерів». Розробникам цього недостатньо. Що саме потрібно автоматизувати? Хто користуватиметься системою? Який процес існує зараз? Де він ламається? Які дані потрібні? Що має відбуватися після натискання кнопки?
Business Analyst перетворює «хочемо приблизно ось це» на вимоги, з якими вже може працювати команда. Тут потрібне розуміння технологій. Але не менше потрібні вміння слухати, ставити запитання, бачити логіку процесу, працювати з великим обсягом інформації та пояснювати одну й ту саму ідею бізнесу й технічній команді. Тому досвід у комунікаціях, освіті, маркетингу, менеджменті чи роботі з текстами може виявитися не «непрофільним минулим», а хорошою базою.
Project Manager: якщо вам природно перетворювати хаос на систему
Де ми зараз? Що блокує команду? Хто від кого залежить? Чому задача, яку планували завершити в середу, досі не готова? Що станеться з проєктом, якщо цей дедлайн зміститься?
Project Manager не зобов'язаний писати код замість розробника. Але він має достатньо розуміти процес розробки, щоб координувати людей, ризики, строки та пріоритети. Тут особливо цінуються системність, комунікація, відповідальність і здатність тримати в голові багато взаємопов'язаних процесів. Якщо ви та людина, яка в груповому проєкті несвідомо починає розподіляти задачі, збирати всіх докупи й запитувати «так, а який у нас план?» — варто придивитися до цього напряму.
QA: якщо ви помічаєте те, повз що проходять інші
Розробник бачить форму реєстрації й думає: «Працює». QA дивиться на ту саму форму й запитує: А що буде, якщо залишити поле порожнім? А якщо вставити 300 символів? А якщо натиснути кнопку двічі? А якщо користувач втратить інтернет посеред процесу? А якщо ввести неправильний формат даних?
Тестування — це значною мірою вміння шукати сценарії, про які інші не подумали. Так, QA теж працює з технічними інструментами, документацією, API, а в automation — і з кодом. Але на старті величезну роль відіграють уважність, логіка, допитливість і звичка запитувати: «А що станеться, якщо…?»
UX/UI: якщо вас цікавить не просто «красиво», а «зрозуміло»
Чому користувач не може знайти потрібну кнопку? Чому він кидає оформлення замовлення на третьому кроці? Як організувати інформацію так, щоб людині не доводилося думати, куди натискати далі?
UX/UI — це не просто вибір кольорів та красивих шрифтів. Це робота на перетині дизайну, поведінки людей, логіки продукту та бізнес-завдань. Тому здатність розуміти контекст, працювати зі смислами та дивитися на продукт очима іншої людини тут може бути серйозною перевагою.
А програмування? Гуманітаріям туди точно не можна?
Можна. Просто тут важливо не впадати в іншу крайність і не обіцяти, що програмування підійде абсолютно кожному.
Щоб стати розробником, доведеться вивчати алгоритми, структури даних, синтаксис мов, бази даних, архітектуру та багато іншого. На певних напрямах знадобиться і математика.
Програмування — це не постійне розв'язування складних рівнянь. Значна частина роботи розробника — зрозуміти проблему, розкласти її на менші частини, знайти закономірність і послідовно побудувати рішення.
Тому замість: «У мене гуманітарний склад розуму — чи зможу я?»
корисніше запитати: «Чи подобається мені сам процес вирішення таких задач настільки, щоб я був готовий цьому навчатися?» І це вже можна перевірити.
Але є нюанс: «нетехнічна професія» не означає «технології знати не потрібно»
Ось тут часто виникає інша крайність. Людина чує, що Project Manager або Business Analyst може не програмувати, і робить висновок: «Чудово. Значить, технічна частина мені взагалі не потрібна».
Не зовсім.
- Не обов'язково писати backend, щоб розуміти, що таке API.
- Не обов'язково бути DBA, щоб знати базові принципи роботи баз даних.
- Не потрібно самостійно деплоїти продукт, щоб розуміти, чим frontend відрізняється від backend і що приблизно відбувається між ідеєю та релізом.
Ваш рівень технічної глибини залежатиме від професії. Але працювати в технологічному середовищі й принципово не хотіти розбиратися в технологіях — погана стратегія.
Можливо, проблема взагалі не в тому, що ви гуманітарій
Іноді за фразою «я гуманітарій» стоїть зовсім інше: «Я боюся почуватися новачком».
У своїй нинішній професії ви вже знаєте терміни, правила й контекст. Можете підтримати професійну розмову. Розумієте, що робити, коли виникає проблема. А потім відкриваєте матеріал про IT й бачите: repository, endpoint, framework, pull request, sprint, deployment…
І раптом знову нічого не знаєте. Це неприємне відчуття. Але воно не означає, що у вас «не той мозок». Воно означає, що ви зайшли в нову професійну сферу. Кожен спеціаліст колись не знав, що таке API.
А як зрозуміти, який напрям мій?
Не починайте з питання «Де зараз найбільші зарплати?». Спочатку подивіться на тип задач, з якими вам доведеться працювати щодня.
Якщо вам подобається…
- розбирати потреби й структурувати інформацію → придивіться до Business Analysis;
- організовувати людей і процеси → Project Management;
- шукати помилки й перевіряти сценарії → QA;
- досліджувати поведінку людей і проєктувати взаємодію → UX/UI;
- будувати логіку та створювати рішення за допомогою коду → Development.
Але не обирайте професію лише за цим списком. Подивіться кілька реальних вакансій. Відкрийте програму навчання. Спробуйте базове практичне завдання. Подивіться, як насправді виглядає робота, а не тільки як вона описана в мотиваційному дописі.
Вам не потрібно одразу вирішувати, чим займатися наступні десять років. Спочатку достатньо зрозуміти: чи хочу я зробити наступний крок у цьому напрямі?
І ще одне: ваш попередній досвід не обнуляється
Світчери часто дивляться на перехід в IT так: «Мені 30. Я п'ять років працював у маркетингу. Тепер доведеться починати все спочатку».
Але ви не починаєте з нуля. Ви починаєте без досвіду в конкретній IT-ролі, але вже з професійним досвідом.
- Маркетолог може добре розуміти клієнта й бізнес-метрики.
- Викладач — пояснювати складне та структурувати інформацію.
- Журналіст — ставити питання, працювати з джерелами й швидко занурюватися в нову тему.
- Менеджер — координувати людей, строки та відповідальність.
- Фінансист — працювати з даними й бізнес-логікою.
Питання не в тому, як приховати своє «неправильне» минуле. Питання — яку частину цього досвіду можна перенести в нову професію і яких компетенцій до нього не вистачає.
Тож чи є гуманітарію місце в IT?
Якщо коротко — так.
Але не тому, що «IT підходить усім». І не тому, що можна знайти професію, де взагалі не доведеться мати справу з технічним. А тому, що поділ на гуманітаріїв і технарів занадто примітивний для сучасного ринку професій.
В IT потрібні люди, які пишуть код. І люди, які розуміють користувачів. Ті, хто аналізує вимоги. Ті, хто знаходить помилки. Ті, хто організовує процес. Ті, хто перетворює складну систему на зрозумілий продукт.
Тому головне питання не: «Я гуманітарій. Чи візьмуть мене в IT?»
А: «Що я вже вмію, яку роль хочу виконувати і чого мені потрібно навчитися, щоб до неї перейти?»
Ось із цього питання і варто починати світчинг.
Не вгадуйте професію — знайдіть свій напрям
Якщо ви хочете перейти в IT, але поки не розумієте, яка роль відповідає вашому досвіду, сильним сторонам і цілям, не обов'язково шукати відповідь самостійно методом проб і помилок.
На кар'єрній консультації SkillsUp ви можете разом з експертом розібрати свій досвід, визначити сильні сторони, оцінити можливі напрями переходу та сформувати реалістичний план наступних кроків.
Це можливість перейти від абстрактного «хочу в IT, але не знаю куди» до розуміння, яка професійна траєкторія може підійти саме вам. Можливо, ваш гуманітарний бекграунд — не причина відмовлятися від IT. А саме те, що допоможе знайти в ньому своє місце.