Павло Вейник працює в IT вже понад 20 років, 15 з них навчає розробників. Щоправда, останні чотири роки бере айтівців лише просунутого рівня та в межах курсів, де викладає.
У партнерському тексті IT-архітектор Павло Вейник розбирає найпоширеніші проблеми, з якими стикаються розробники, та розповідає, як будувати комунікації з колегами, щоб кар’єра йшла вгору.
Павло Вейник – досвідчений СТО, ex-Architect Miro та EPAM. Він також засновник Hard & Soft Skills – екосистеми навчання, у якій досвідчених IT-фахівців навчають hard і soft skills, щоб підготувати до рівня techlead та вище.
Цікава деталь: перед кожним новим потоком Павло Вейник особисто зустрічається з тими, хто бажає навчатися в нього й іноді… відмовляє їх.
Павло Вейник:
«Я маю систему трьох не. Не продавати заради продажу. Курс – це шлях зростання, він повинен підходити потенційному студенту, тому й зустрічаюся окремо з кожним, слухаю його “робочу історію”. НЕ переконувати і навіть відмовляти, якщо бачу, що людина поки що не готова вкладати час і зусилля. Або не розуміє необхідність не тільки hard, але і soft skills. Для кар’єрного зростання потрібно розвиватися комплексно, а це означає як системні знання, так і вміння подати себе та завоювати повагу колег. Насправді дорогу здолає не той, хто йде, а той, хто розуміє, куди йти. А з експертом просто простіше налаштувати компас».
У цьому матеріалі Павло знайомить з одним з кейсів, який він розбирав на одному із занять курсу “Технічний Лідер”. Він наводить як приклад проблему, а потім коментує її
Записатися на курс Hard & Soft Skills
Дано: Олександр – молодий розробник у великому технологічному банку. Начебто важливий кар’єрний етап для хлопця з амбіціями, але незабаром після пропозиції він налаштований піти: є враження, що лід і менеджери роблять із класного проєкту класичну «галеру»
Олександр: «Кажуть, що я маю вриватися у прод, і кидають на чергування»
«Працюю в цьому банку майже чотири місяці та зіткнувся із проблемою – великим навантаженням. Зрозуміло, є основний бізнес-беклог, ним займається кожен. Але ще система чергувань, вона також усіх стосується: приблизно раз на місяць чи тиждень стежиш за продуктом, фіксуєш баги, працюєш з тикетами Service Desk.
Це складно, тому що компанія велика, а я в ній нещодавно. Тому мене ставлять ще частіше. Кажуть, що я маю вриватися у продукт, і кидають на чергування підтримкою в основної зміни. Пушать, щоб “занурювався швидше і глибше”. Це стрес: кожен баг мені в новинку, плюс я постійно відриваюся від основних завдань».
Коментар Павла:
«Хороша і правильна стратегія. І у проєкт поринаєш, і комунікацію налаштовуєш, і ростеш, адже все чіпаєш своїми руками. Я з рішенням твого ліда погоджуюсь, бо воно допомагає швидше розібратися, що робить команда. Суть системи не в коді. Вона в тому, що крутиться на продакшен-серверах. І якщо людина орієнтується в тому, що крутиться, це точно дозволяє їй краще писати код. Крім того, для компанії правильно, коли кожен член команди розуміє проблему і може принаймні прикинути рішення.
Це один з етапів зростання для сеньйорів, особливо тих, які прийшли з аутсорсу і не бачили самого продакшена. Лізти у прод і в реальному часі дивитися моніторинг з логами. Ага, щось прилетіло на сервак, стільки запитів за секунду в такий час – а ось тут ми розгорнули нашу фічу, і її час такий. Є різниця, звідки вона та інше.
Зрозуміло, що тобі складно: нова система, проєкт великий. Але це зона твого активного та гарячого зростання. А стрес можна зменшувати. По-перше, просто розуміючи та приймаючи користь того, що відбувається. По-друге, не соромлячись просити поради. Це нормально».
Олександр: «Наприкінці майже кожного спринту є овертайм – проджект-менеджери завжди пушать взяти на себе більше»
«Про чергування перестану хвилюватись. Але є й інші дзвіночки з навантаженням, через які думаю піти. Наприкінці майже кожного спринту є овертайм – проджект-менеджери завжди пушать взяти на себе більше. Ну коли ми вже зовсім під зав’язку, лід може їм сказати своє стоп-слово. Але потім кожен спринт те саме: “Хлопці, а можете ще ось це взяти? Ну давайте, га?” А ще чергування, багато інших активностей. Я хочу піти, але ще й хвилююся, як рекрутери відреагують на мої чотири місяці роботи і що казати в такій ситуації. Не розповідати ж про начальника-самодура».
Коментар Павла:
«А це вже справді нездорова ситуація. У всіх компаніях, де я був технічним директором, завжди вибудовували систему, де розробники самі оцінювали завдання і брали у спринт. З урахуванням обумовлених ризиків і розстановкою високої та низької пріоритетності.
І архітектор, і менеджер у такій системі мають золоте правило – уточнювати з розробником, як він оцінює терміни. Не з позиції “а чого так довго”, звісно. Якщо відбувається “оцінює він, роблю я”, як взагалі можна відповідати за вчасний результат?
Завжди відповідай щодо термінів спокійно та конструктивно. І дивися на реакцію. Якщо у відповідь чуєш: “Два дні даю, і мене не хвилює!”, це вже жорсткий червоний прапор. Значить, менеджер тебе втоптує, а не допомагає працювати. Якщо відповідь буде в рамках дипломатії: “Я зрозумів, ти новенький, нумо подумаємо, що робити із цим”, то є шанс навести мости.
Багато залежить від формату, який заведений у компанії: тут або кулак, або пошук рішення. Project manager знає, що, як команда щось не зробить, під пресом опиниться він. Нагорі в нього запитають, чому інший менеджер вибив зі своїх людей роботу, а в нього не вийшло. І зроблять висновок, що він просто не вміє працювати з командою. Система “пушити й тиснути” завжди будується зверху. І це нормальна причина, щоб піти. Стрес – нормальна причина щось міняти.
Але взагалі три-чотири місяці, будь-який термін до пів року роботи в одному місці та потім звільнення – це мінус. Одного разу я мав історію, коли я два місяці попрацював і пішов. То я взагалі цей досвід у резюме не вказував. Може, й тобі так варто вчинити? Вміння подати себе – це також важливе та сильне знання. Я чую твоє хвилювання і розумію, що курс тобі підійде, не буду відмовляти».
Павло Вейник:
«Часто стикаюся з тим, що досвідченим інженерам вистачає знань, але не вистачає вмінь і навичок, як влитися в нову команду та чітко доносити свою позицію. Це проблема не лише Олександра.
Колись давно я зрозумів, що не можна стати техлідом чи архітектором, набираючи додаткові фреймворки у стек або додаючи нові домени в резюме. Технічний лідер – це спосіб мислення. Саме через це майже п’ять років тому я створив ком’юніті Hard & Soft Skills, де досвідчених інженерів підтримують такі самі, будь то експерти-викладачі чи спільнота випускників.
Найприємніше у викладанні досвідченим інженерам – бачити, як дорослі люди усвідомлюють, що перейшли на інший рівень абстракції в мисленні, інакше почали дивитися на проблеми та їхні наслідки, бачать систему цілком».
Цей кейс розбирали на вебінарі в межах Technical Leadership – восьмого набору затребуваного курсу Hard & Soft Skills, на якому інженери просунутого рівня доводять свої hard і soft skills до ідеалу. Шанс записатися на курс через попередню співбесіду ще є – переходьте в офіційний Telegram-канал. Старт навчання – 28 листопада.
Резиденти Дія.City сплатили до бюджету понад 8 млрд грн податків в І кварталі 2025 року.…
У Китаї закликають офісних працівників не працювати надто багато — держава сподівається, що вільний час…
Експерти звертають увагу на тривожну тенденцію: люди все частіше використовують ChatGPT, щоб визначити місцезнаходження, зображене…
Компанія JetBrains випустила нову версію мультимовного середовища розробки IntelliJ IDEA 2025.1. Оновлена IDE отримала численні…
Платформа обміну миттєвими повідомленнями Discord впроваджує функцію перевірки віку за допомогою сканування обличчя. Зараз вона…
Wikipedia намагається захистити себе від тисяч різноманітних ботів-скрейперів, які сканують дані цієї платформи для навчання…