Коли AI забирає рутину: чому майбутнє IT-команд — у Soft Skills

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

Цей матеріал виріс із двох точок. Перша — AI Impact Summit 2026, який нещодавно пройшов в Нью-Делі: ми з моєю бізнес-партнеркою Наталі Новгородською уважно в онлайні спостерігали за тим, як дискусія про AI переходить від питання «що автоматизується» до питання «що залишається людям». Друга — IT HR Forum 2026, де ми разом представили доповідь про резильєнтність IT-команд.

Вирішив від цього відштовхнутися й поділитися думками стосовно того, що зараз відбувається з HR-процесами в IT. Вважаю, що за останні 3-4 роки світ змінився кардинальніше, аніж за попередні 30 — AI вже пише тексти вакансій, аналізує CV, проводить первинні інтерв’ю тощо. І ось питання в тому, що залишається людям, коли алгоритм забирає роботу на себе? Тим більше — у світі, який переживає період кризи.

30% робочих годин будуть автоматизовані до 2030

Спочатку відзначимо звіт McKinsey від 2024 року, в якому прогнозується, що майже 30% робочих годин у світовій економіці до 2030 року будуть автоматизовані. Уточню, що мова не про зникнення професій, а про зміну структури всередині них. У багатьох ролях автоматизуються окремі задачі — аналіз, підготовка документів, обробка інформації; у результаті змінюється те, з яких саме тасок складається робота фахівця.

Цьому відгугується одне з ключових понять, яке звучало на AI Impact Summit — unbundling. Суть в тому, що AI все більше розкладає роботу на окремі завдання й забирає транзакційні частини на себе. А людям, відповідно, залишаються поведінка, сенси, взаємодія.

І якщо повертатися до HR-менеджменту, то є речі, які AI не може, я вважаю, замінити сьогодні:

  • Комунікацію з командою (AI її лише підсилює)
  • Людську поведінку, психологію

Людям залишаються саме Soft Skills, оскільки ми бачимо, що AI не змінює суть. Як наймали людей — так і наймають, як онбордили — так і онбордять, як працювали понад 80 тисяч фахівців у топ-50 IT-компаніях за даними DOU — так і працюють.

Змінися інструменти. Й тут мені подобається аналогія, що хірурги вже понад 100 років працюють зі скальпелем, а зараз можуть працювати із лазером — втім роль лікаря-хірурга нікуди не зникла.

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

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

5 елементів резильєнтності, які HR має будувати в IT-команді

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

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

Тут виокремлю 5 ознак, що визначають резильєнтність IT-команди:

  1. Психологічна безпека. Чи можна в команді сказати «я не знаю»? Поставити незручне питання, визнати помилку без ризику бути покараним? Якщо ні — команда функціонує в режимі самоцензури. Люди витрачають енергію на захист, а не на роботу.
  2. Емоційна зрілість лідера. У кризі команда майже не слухає, що конкретно каже лідер, вона зчитує, в якому він стані. Напружений, розгублений фаундер — нестабільна команда. Проте якщо лідер чесно каже: «Ситуація складна, є невизначеність, ми розберемося», то з’являється опора. Лідер у кризі стає емоційним регулятором.
  3. Адаптивні домовленості. Часто бачив, що втрачається ефективність не через зміни, а через застарілі правила. У кризу домовленості варто переглядати. Дайте відповіді команді на 3 питання: що залишається у вас стабільним, що можемо змінювати, як швидко переузгоджуємо рішення?
  4. Протоколи відновлення. Впевнений, що ви бачили ситуації, коли команди втрачають ресурс через втому. Питання, яке має ставити HR-менеджмент регулярно: що потрібно команді, щоб не вигоріти? Не завтра, а саме зараз? Відновлення — це також система, а не реакція, коли вже пізно. Думайте про це.
  5. Стратегічна ясність. Команда витримує тиск, коли розуміє сенс роботи. Куди ми усі разом рухаємося, чому це важливо, яка роль кожного? Якщо немає сенсу, то з’являється тривога, що поглинає продуктивність.

І якщо дивитися на глобальні поведінкові тренди через Google Trends, то ми бачимо динаміку, що резильєнтність зараз на піку:

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

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

Five Resilience-Check: практична модель

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

Декілька років тому ми з Наталі Новгородською для свого власного бізнесу розробили модель, яку назвали Five Resilience-Check, яка може стати вам у нагоді, щоб побудувати сильну резильєнтність.

Ця модель складається з 5 практик, такий собі Road map:

  • Крок № 1: check-up — діагностика стану команди. Проводимо оцінку команди через валідовані інструменти (скажімо, через тести CD-RISC / PSS-10) для розуміння рівня напруги й ранніх сигналів перевантаження. Це не психодіагностика.
  • Крок № 2: сheck-in — мобілізація ресурсу. Організовуємо короткі синхрони не лише про таски, а й про фокус, стан. Формуємо з цього щотижневу практику, додаємо на мітинги питання «ти як?», «чи ти в ресурсі»?
  • Крок № 3: check-communication — зменшення невизначеності. Це про відкриті домовленості, фідбек й побудову емпатії. Команда зможе витримувати вкрай складні ситуації, якщо буде розуміти, що відбувається. Зверніть на це увагу.
  • Крок № 4: сheck-recovery — відновлення ресурсного стану. На цьому етапі ми маємо провоговори з командою відпочинок, паузи й реалістичні дедлайни. Не «відпочиньте на вихідних», а побудувати план системного відновлення як частини операційки.
  • Крок № 5: сheck-adapt — навчання через зміни. Ось тут впроваджуємо Soft Skills Education — ретроспективи, роботу з помилками. Зауважу, що нейронні зв’язки формуються місяцями, тому якщо ви хочете, щоб у співробітника з’явилася певна навичка — будуйте стратегію.

Якщо подивитися на цю модель, то стає зрозуміло: жоден із цих кроків не про процеси чи інструменти, а про людей. Саме тому, мені здається, Soft Skills перестають бути «додатковою опцією» для IT-команд.

Soft skills як фундамент HR-архітектури

В IT ми звикли будувати архітектуру продуктів. Але значно рідше усвідомлено будуємо архітектуру навичок. Хочу саме навички, я вважаю, формують бізнес. Чому це так? Бо AI може автоматизувати процеси, але він не може вплинути на культуру або надихнути команду, яка перебуває у стані стресу.

Сьогодні дослідники виділяють понад 300 Soft Skills — від когнітивної гнучкості до етичного прийняття рішень. Це величезна екосистема, де роль HR-менеджера та фаундера змінюється:

  • Від адміністрування до проєктування: тепер не просто «наймаємо людей», ми проєктуємо поведінкові фреймворки під конкретні ролі.
  • Від навчання до розвитку резильєнтності: впроваджуємо інструменти оцінки (як-от Five Resilience-Check), щоб розуміти стан системи ще до того, як вона почне давати збої.
  • Від конкуренції з AI до синергії: інтегруємо алгоритми в операційку, щоб вивільнити час для того, що дійсно має значення — для людини.

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

Ось чому важливо розвивати Soft Skills.

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Дякую за коментар, але тут, як на мене, є змішування різних рівнів. Hard skills дійсно стають ще більш критичними — з цим важко сперечатись. Але приклади, які ви наводите як soft skills (написати лист, оформити документацію, описати зміни), насправді не є soft skills. Це інструментальні навички роботи з інформацією, і логічно, що саме їх AI зараз автоматизує найкраще. Через це і виникає відчуття, що «soft skills стають непотрібом», хоча по факту автоматизується інший рівень. Бо справжні soft skills — це не про тексти, а про те, як приймаються рішення, як люди домовляються в умовах конфлікту інтересів, як формується довіра і відповідальність у команді. Наприклад, коли команда обирає між швидким рішенням і правильним з точки зору архітектури — це не питання коду, це питання домовленостей і відповідальності. Коли бізнес тисне на строки, а розробка бачить ризики — AI може допомогти сформулювати аргументи, але не вирішує сам конфлікт. Коли проєкт починає «плисти», проблема зазвичай не в документації, а в тому, що команда по-різному бачить ситуацію і не синхронізована. Тому теза про «непотрібність soft skills» виглядає як наслідок некоректного визначення самих soft skills. Автоматизується операційний рівень, але системний рівень — взаємодія, мислення, прийняття рішень — стає ще більш критичним. І в цьому сенсі AI не замінює soft skills, а якраз підсвічує, де їх не вистачає. Я цю тему досить глибоко досліджував і в інших матеріалах, але тут хотів коротко показати саме різницю між операційним і системним рівнем.

Считаю, что мы тут все по большому счёту фигнёй занимаемся. Сама по себе концепция разработки программного обеспечения — устарела. AI сможет сразу генерировать конечный продукт напрямую, без необходимости разработки специализированного программного обеспечения. Любого, и в любых формах и размерах. Через несколько лет, когда процесс автоматизации в ключевых экономических видах деятельности завершится, и присутствие каких-то персонажей там будет излишним, необходимость в программном обеспечении в том виде, что есть сейчас — полностью отпадёт. Более того, даже не будет необходимости в операционных системах в том виде какие существуют на сегодняшний день. Все те плюшки и прибамбасы, что наворотили в Windows за последние 30 лет — не нужны. Это ещё не всё. Поскольку заниматься такой хернёй как написание специализированного программного обеспечения больше не нужно, то и продолжать тянуть весь легаси в архитектуре железа — тоже нет смысла. Что в x86-64, что уже в arm — одни сплошные костыли на костылях в несколько этажей, это всё можно переписать с нуля с учётом накопленного за последние 50 лет опыта, чем AI потом и займётся. Да и самого себя AI тоже будет переписывать.

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

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

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

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

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

Майбутнє IT команд — не в soft skills. Майбутнє — в менеджерах і HR, які на ретроспективі чи one-on-one уважно записують, а після — йдуть і вирішують озвучені проблеми.

Это если хотят и могут их решить. Очень часто one to one для галочки.

Дякую за коментар. Якраз те, що ви описали — це і є прояв soft skills, просто не в «класичному» розумінні.

Уважно вислухати на ретроспективі або one-on-one — це про активне слухання, емпатію та емоційний інтелект. Зафіксувати суть без викривлень — це про здатність працювати з інформацією без зайвих інтерпретацій, і це теж soft skill. Піти і реально вирішити проблему, а не просто «проговорити» — це про відповідальність, пріоритезацію і прийняття рішень. І найскладніше — з’єднати інтереси різних сторін і довести рішення до результату, а не залишити його на рівні обговорення.

Тобто мова не про «soft skills vs менеджери», а про те, що ефективні менеджери і HR якраз і діють через ці soft skills.

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

Тому питання не в тому, чи потрібні soft skills, а в тому, чи ми їх помічаємо в дії.

Цікаво, чи допоможе це перейти на 4-денний робочий тиждень більшості компаній, чи як завжди — зі зростанням продуктивності зросте «норма», а не зменшиться навантаження на людей. Бо люди працювали 40 годин на тиждень і 50 років тому (у 1970-х), але з тих пір завдяки різним інструментам продуктивність зросла в рази, але кількість робочих годин не зменшилася в рази.

Ой, та що ти таке дурне питаєш. Ясно, що будуть давати більше тасків, буде швидше вигорання.

Очікування виростуть. Навантаження ні. Просто ШІ за тебе роботу робить, ти лише чекаєш, перевіояєш, і коректуєш. Тобто прямої тупої роботи цілий день дизайнити і кодити якийсь клас чи дебажити тест, чи писати якусь документацію стало менше.

Просто ШІ за тебе роботу робить, ти лише чекаєш, перевіояєш, і коректуєш.

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

Дуже влучне питання — і, як на мене, відповідь тут якраз не лише в технологіях, а в управлінській логіці. Історично справді часто відбувається так: зі зростанням продуктивності зростає не вільний час, а норма очікувань. Компанії отримують можливість робити більше — і починають вимагати більше. Тому сам по собі AI не приведе автоматично до 4-денного робочого тижня. Це не технологічне, а управлінське і культурне рішення. Якщо збережеться логіка «можемо більше — значить треба більше», то навантаження не зменшиться, а просто зміниться форма роботи. Якщо ж компанії почнуть більше дивитися на результат, а не на кількість зайнятих годин, тоді такий сценарій справді можливий. І тут, до речі, знову проявляється роль soft skills — у вмінні визначати пріоритети, домовлятися про реалістичне навантаження, вибудовувати межі, приймати рішення не лише про те, що робити, а й про те, від чого варто відмовитися. Тобто технології можуть створити можливість для коротшого робочого тижня, але чи стане це реальністю — залежить уже не від AI, а від людей і управлінських підходів.

але він не може вплинути на культуру або надихнути команду, яка перебуває у стані стресу

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

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

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

І якщо повернутись до теми статті — культура, довіра, здатність працювати зі стресом, вирішувати конфлікти і будувати здорову взаємодію — це і є ті soft skills, які не тільки не зникають, а стають критичними. Бо без них будь-яка команда, навіть із мінімальною комунікацією, рано чи пізно впирається в ті самі проблеми.

Але причини токсичності нікуди не зникають: різні очікування, конфлікти інтересів, відсутність довіри, невизначеність ролей

Ні. Токсичність — це коли людина у команді — мудак.
Очікування, конфлікти, довіра — все це фікситься і самоналагоджується на ізі, якщо люди нормальні. Якщо ні — навіть якщо все налагоджено — буде токсичність.
Банально, достатньо кіслої морди або токсичного, але формально-корректного тону на міту, щоб у атмосфері з’явилася токсичність.

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