Павло Вейник працює в 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 листопада.
Це партнерський матеріал. Інформацію для цього матеріалу надав партнер.
Редакція відповідає за відповідність стилістики редакційним стандартам.
Замовити матеріал про вас у форматі PR-статті ви можете тут.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: