Вхід і реєстрація
Різне · 1 серпня, 16:41 2660
DOU Community

Чи маєте ви досвід онбордингу нової людини на своє місце?

Нещодавно ми поспілкувалися з айтівцями про звільнення і те, чи стараються спеціалісти йти з роботи екологічно. Один з респондентів розповів про свій досвід:

«При звільненні я завжди закінчую всі активні проєкти або масштабні задачі. Не говорю зайвого [...]. Готую документації для наступника. За потреби ходжу на співбесіди шукати собі наступника».

Розкажіть, чи онбордили ви нову людину на своє місце під час професу звільнення? Чи це все ж задача ліда?

Теми: звільнення, менеджмент, онбординг
👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
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
Sergii Voloshyn Product Manager в DOU.ua 15.08.2024 08:49

У Derek Sivers є пост (чи розділ книжки «Anything You Want») під назвою Naïve quitting на схожу тему:
sive.rs/nq

Відповісти
Підтримати
Alex Tcy 05.08.2024 20:41

Ось якраз в процесі ))
А як ви здогадалися?

Відповісти
Підтримати
Vladyslav Homeniuk Front-end developer в Цифровий вік 05.08.2024 17:58

З попереднього місця роботи я пішов знайшовши собі заміну. Коли я почав вивчати нову технологію з якою хотів працювати в майбутньому я почав адвокувати пошук 2го тех спеціаліста в команду. Він і справді був необхідний хоч і не критично, після його появи я підготував документацію і інструкції на випадок якщо буду змушений неочікувано покинути проєкт. На щастя мені надійшла пропозиція по роботі з лайтовими умовами. Я мав ще декілька місяців на те що б звільнитись. Тож я попередив керівництво про своє звільнення за 1.5 місяці. І спокійно змінив місце роботи коли прийшов час )
Всім раджу відкрито говорити роботодавцю якщо плануєте звільнення. Вас запам’ятають хорошим працівником, можливо це колись вам знадобиться )

Відповісти
Підтримати
Вавилен Татарский 04.08.2024 14:53

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

Відповісти
Підтримати
Vic Programmer 04.08.2024 12:04

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

Відповісти
Підтримати
Eduard Voloshyn IT Business and System Analyst в Sprinterra 02.08.2024 20:51

мої принципи які склалися просто самі собою —> dou.ua/...​rums/topic/36551/#2354499

Відповісти
Підтримати
Просто Анон 02.08.2024 14:22

Якщо норм розходимся, останні тижні з малою загрузкою, то можна і онбордити.

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

Відповісти
Підтримати
Просто Анон 02.08.2024 14:14
«При звільненні я завжди закінчую всі активні проєкти або масштабні задачі.

Байки)

До тебе приходять, кажуть «ти звільнений, нотіс період по контракту 1 місяць)».
І що, за 3 тижні реально закінчити *всі* активні проекти і *мастштабні* завдання? (бо ще тиждень на всяку передачу проекту, документацію і т.п.).

Відповісти
Підтримати
Olena Sharovar Node.js/JS в Waverley 02.08.2024 15:05

Залежить на який позиціі людина була, чи є хтось ще хто закінчить ті таски, буває що й просто виключають доступ без попередження (американці)

Відповісти
Підтримати
Просто Анон
amigo 04.08.2024 12:15
всі

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

Відповісти
Підтримати
Просто Анон
Просто Анон 04.08.2024 12:49

Для мене ось це

ти зариваєш таски, що мав зробити в цьому спринті.

і ось це звучать як різні речі

"При звільненні я завжди закінчую всі активні проєкти або масштабні задачі.
Відповісти
Підтримати
amigo
Vic Programmer 04.08.2024 16:18

Буває, дуже часто при чому — що в начальство попадають люди які гадки не мають про існування Bus factor. Частіше усього тому — що вони дуже вправні торговці, бізнесмени. Чудово знаються на торгівлі інтригах психології обману і т.д. При цьому керівники команд з виробництва з таких людей як правило нікчемні, просто нема відповідної кваліфікації як з виробництва так і з керування персоналом. Типовий приклад — Стів Балмер. Власне так само стосується тих ситуація коли з виробничої спеціальності людина потрапляє в необхідність — або керувати, або торгувати — а то і перше і друге одночасно. Там часто справді суттєві неприємності типу касового розриву виникають, чи розвалюються команди втрачається експертиза до нуля та провалються усі строки та трапляються over budget через over enginering зокрема, чи нульових навичок з маркетингу.
Для FAANG та інших наслідки скорочень одним днем вже були дуже погані, за останній рік усі компанії по проходили через масштабні збої та інші проблеми. З останніх — збій в ядрі Windows з діленням нуль dou.ua/forums/topic/49627. Як бренд роботодавця вони і взагалі усі крім Apple впали в дно-денне. Там працювати більше вже не для кого не мрія і підозрюю в середині вже конкретний гадюшник зі зміями, як у фільмі Margin Call www.youtube.com/watch?v=wSdpMbvA6_Q Там по ходу фільму виявляється, що і торговців в результаті замінити не так вже і просто. А Еріка змушені повернути вже відділком безпеки (тобто бандитами). В реальності фільм на основі інвестиційного банку Lehman Brothers. Тобто капіталізм він такий, який би крутий і розкручений бренд в усіх сенсах не був, хоч йому і 200 років, він може бути втрачений за дуже короткий проміжок часу.
Безумовно оці усі скорочення це так звана «стадна поведінка», і безумовно американський уряд який ніби з партії Франкліна Рузвельта, що активно саме з цим боровся ще 100 років тому — усе профукав. Бо щось по типу «Марк узяв усю відповідальність на себе» це ні про що. Марк та інші за великим рахунком ніяк не відповіли за прорахунки, доки. Але в довгу це матиме свої наслідки 100%. В індустрії завжди є фактор двох чуваків з гаража, чи кімнати в університетській общазі. І якийм би крутим не був бренд голубого гігінту, він виявиться лише картковою будівлею створеною маркетингом, який переможе інший : Hi I Mac and I a PC, Think different тощо.

Відповісти
Підтримати
amigo
Beaver Green 02.08.2024 13:57

Поділюся історією, яка багато чому мене навчила, і яку я дуже часто розповідав, коли приходив на новий проєкт.
Якось наша галера підписала одну з 10 ТОР ІТ компаній (не хочу писати назву — але здогадатися не важко). Отже в Харкові зібрали «зіркову» команду .Net синьорів — і ця команда почала працювати як аутстаф — розширення команди клієнта. Продукт це одна з найбільших і найвідоміших ентерпрайз-систем. Відповідно це просто велетенський монстр з десятками різних репозиторіїв, десятками різних команд у різних країнах, білдом який збирається 12+ годин і віртуальними машинами на яких він розгортається.
На жаль с самого початку відношення до нашої команди вендорів з боку FTE (Full Time Employee) було приблизно як до прибиральниць в офісі. «Тобто найняли якихось папуасів нам у допомогу. Але нам тут допомога не потрібна — хіба що якусь мавпячу роботу їм дамо.» Отже ніякого онбордінгу для нас просто не було! Менеджери по своїх каналах намагалися випросити посилання на якусь документацію, а девелоперам дали доступ до сорсів — дивиться і розбирайтеся самі. На щастя код написаний не погано, а як мінімум з підтримкою статичних аналізаторів. Методи на 100500 рядків чи десяток вкладених іf білд просто пропустить. Але при цьому головна фішка FTE девелоперів — це кастомізація. Наприклад не можна просто відкрити солюшин в VS і почати працювати — для цього треба запустити спеціальний CMD файл, який спочатку усе налаштує — а потім запустить VS. Якщо використовується якась бібліотека чи фреймвок — то обов’язково загорнута у свою обгортку і зі своїми налаштуваннями. Про фронтент і казати лячно: там власний коктейль з купи нод модулів, а десь глибоко закопаний вусмерть кастомізований реакт.
Ми навіть жартували що це «job scurity»: треба робити так, аби без тебе ніхто не розібрався — інакше тебе легко замінять. Отже навіть налаштувати робочі енвайроменти, збілдити і запустити ми змогли десь на другомі місяці роботи на проєкті.
За декілька років, звичайно, ми в усьому розібралися, зуміли показати що ми можемо робити не гірше (а іноді і краще) за FTE, отримали таку довіру від менеджера з боку клієнта що коли йшла мова про розширення його команди — він обрав додати 5 вендорів з Харкова замість 2х FTE яких йому пропонували (я так розумію приблизно за ту ж ціну). Отже усе було чудово, усі були задоволені, команда вже почала непогано розумітися не тільки у коді і алгоритмах, а і у бізнес — фічах таких як логістика, робочій графік, забезпечення матеріалами і т.і.
Але прийшов 2021 рік (коли війська Парашки «проводили навчання» біля кордонів). Не знаю які там аналітики сидять у клієнта, але вони на верхньому рівні дали сигнал що працювати з вендорами з України — занадто ризиковано. І менеджера з боку клієнта поставили перед фактом що нас у нього забирають — а замість дадуть якихось інших вендорів з Індії.
На той час наша команда вже була авторами чималої частини коду і володіла знаннями декількох важливих фіч, які ми імплементували. Отже стало питання передати знання. На це відводився цілком останній місяць нашої співпраці — але справа в тому, що наступний вендор ще не сформував команду — і нам нікого було онбордити!
На щастя за стільки років у нас вже були напрацьовані свої інструкції з онбордінгу для новачків. Завдяки ним замість 2х місяців розбиратися (як ми спочатку) — новачок міг засетапити собі девелопмент енвайромент за тиждень (ми намагалися брати у команду не нижче Middle+). Або не міг навіть за два — і тоді ми з такими прощалися (бувалі і такі «дуті синьори»).
Додатково ми вирішили що запишемо відео, у яких передамо увесь свій досвід. Починаючи з чистої віртуалки і усе по-кроках: налаштування енвайромента, усі тули, де що лежить у коді, окремо про білди, ПР, автотести, процес розробки фічі від вимог до деплоймента. Усі автори хто розробляв і добре знав якісь фічі — записували відео і показували де що як виглядає для юзера, як це працює «під капотом» і де у коді що реалізовано.
Нагадую: ми працювали на проєкті 5+ років, і мені здавалося що передати увесь досвід, аби вони не просто були новачками, а могли підхопити і продовжити нашу роботу — треба було б кілька місяців тренувати наступників.
Коли кожен записав усі відео, які хотів і вже відчував що більше нема нічого про що варте розказувати — ми зібрали відео в один фолдер. Сумарно усіх відео вийшло десь на 30 годин!
Це було для мене величезним відкриттям! Я пам’ятаю як важко ми розбиралися, як тільки на другий рік почали розуміти архітектуру і код достатньо аби почати не тільки фіксити прості баги — а і додавати нові фічі. І навіть синьйори які приходили потім і мали інструкції — вони також не з першого місяця добре орієнтувалися у коді.
І тут я уявив що прийшов би на такий проект. І мені дали 30 годин відео — а це менше ніж один тиждень на 40 годин. І у цьому відео поступово пояснюється усе: що, як, де, навіщо саме так зроблено. Як запустити, як дебажити, куди дивитися, на які помилки в логах звертати увагу, як виміряти перфоманс, де він може просідати і як це тюнити ... Зрозуміло що я б не міг відразу просто завантажити ці 30 годин і стати експертом — мені б довелося усе повторювати за відео і може десь помилятися.
Який висновок я з цього зробив? Коли приходить новий девелопер у команду — менеджер проєкту очікує що якийсь час він буде розбиратися і не зможе робити робочі задачі. А отже велосіті команди впаде. Якщо новенькому буде допомагати хтось зі «стариків» — то це буде його відволікати і перфоманс впаде ще більше. Тому новенькому дають інструкції, якщо є, і кажуть розбиратися самому. І він з часом якось розбереться: щось зрозуміє правильно, щось — ні і так перший час буде іноді робити лажу, поки хтось не побачить його ПР і не пояснить чому так не треба.
АЛЕ: якщо б менеджер при приході нової людини у команду запланував хоча б один тиждень роботи «старого» ментора, який би сів поруч і усе поступово показав і розказав, а потім ще вони б зробили разом одну таску від початку до кінця — то новачок був би готовий працювати вже за 2 тижні! І він був би цілком у контексті, розумів предметну галузь, розумів архітектуру і що де у коді і не робив би дурних помилок.
І головне: знання у нього в голові були б цілісні! Бо кожен, хто читає документацію чи розбирається сам — має знання «клаптиками». Тільки коли інша людина тобі розповість і пояснить — тоді усе складається до купи. Не дарма в інститутах читають лекції, а не просто кажуть «підіть почитайте оці дві глави у підручнику». Жива лекція дозволяє разом з лектором «слідкувати за його думкою» і як тільки ви втратили розуміння — спитати, попросити роз’яснити. Хороший лектор сам слідкує і перепитує чи усім зрозуміло хід його думок. Бо як тільки контакт втрачено — усе решта також стає незрозумілим.
На жаль жодного разу, коли я приходив на великий проєкт, над яким команда працює вже декілька років, усі мої спроби отримати когось з проєкту хто за декілька днів введе мене в курс діла зустрічали непорозуміння. «Ти ж синьор з великим досвідом — маєш сам усе зрозуміти і розібратися.» — приблизно так каже кожен менеджер.
Краще, чого я зміг свого часу добитися — це записувати на відео мітинги. Аби хоч можна було послухати про що говорили автори фічі коли робили її пів-року тому. Бо інакше буває дуже важко зрозуміти задум і чого її саме так реалізували у коді. Ніякі навички розуміння коду не дозволять відтворити «великої картини», яку автор бачив у своїй голові.
Висновок: живе пояснення від автора — найкращий і можливо єдиний спосіб передати знання повністю. І це не потребує дуже багато часу — не більше ніж витрачається потім на мітинги по синхронізації". Якщо ви автор якогось коду — не полініться записати відео і можливо наступники не зламають ваш задум через пів-року.

Відповісти
Підтримати
Просто Анон 02.08.2024 14:17
Коли кожен записав усі відео, які хотів і вже відчував що більше нема нічого про що варте розказувати — ми зібрали відео в один фолдер. Сумарно усіх відео вийшло десь на 30 годин!

І що воно вам дало?

А так індуси не змогли б освоїти саме, то вас по лінкендіну б виловлювали консультантами, за дуже хороші гроші.

Відповісти
Підтримати
Beaver Green
Vic Programmer 04.08.2024 13:00

Та там такий натяк, що існують системи настільки складні — що навіть дуже кваліфікованим людям потрібно більше двох років щоби засвоїтись з нею. Об’єм мінімально необхідних знань — це 30 годин відео інформації, яку при усіх інтенсивах людський мозок не засвоює не за місяць, не за два.
Скажімо для улюбленої нами місячної програми — документація на ракети Saturn V займала дві будівлі. Ракету будували у вкрай скорочені строки в умовах космічної гонки, дуже часто використовували обхідні та експериментальні підходи, а також «метод грубої сили» тобто брали 4 кратний запас : міцності, потужностей, дублювання і т.д просто під усяк випадок щоб не мати проблем та вкластись у строки, полетівши на Місяць згідно з графіком. Фінансувалась програма урядом як пріоритетна — тобто гроші не рахували, рахували час (TTM).
Зберігати документацію з рештою стало так дорого, що NASA довелось її просто утилізувати під час старту програми Space Shuttle. Крім того вона часто немала сенсу і була застаріла або не відповідна реальності. Набагато простіше було побудувати нову ракету за сучасними технологіями розробки і виробництва, ніж відтворювати Saturn V з урахуванням нової бюджетної політики.
От такі усі enterprice системи це часто і є такий собі Saturn V в більшій частині випадків. Підхід бізнесу часто в тому, щоб просто замінити робітників які її підтримують в країні де інші ринкові реалії.
Але не задача в тому, що десь історично є велика інженерна культура реверс інженерінгу. Були державні програми по відтворенню світової науки та техніки в умовах радянської промисловості. А десь власне взагалі було декілька століть деградації від найрозвиненіших цивілізацій древності до опіумних війн та колоніального статусу і лише в цьому тисячолітті пішло відновлення.

Відповісти
Підтримати
Просто Анон
Gremlin 09.08.2024 00:26
існують системи настільки складні — що навіть дуже кваліфікованим людям потрібно більше двох років щоби засвоїтись з нею.

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

Були державні програми по відтворенню світової науки та техніки в умовах радянської промисловості. А десь власне взагалі було декілька століть деградації від найрозвиненіших цивілізацій древності до опіумних війн та колоніального статусу і лише в цьому тисячолітті пішло відновлення.

в цьому столiтті ми сожремо планету. Буде війна за останній ковток води і шмат їжі.
Маск нікуди не улетить.

Відповісти
Підтримати
Vic
Gremlin 09.08.2024 00:09

Бобер, я думав, ти в плюс-мiнус нормальному проектi працював, а оно он як. Скрізь одна хня. Так то ще гарні часи були, коли до нас заходили різні крупні замовники.

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

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

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

Апдейт Confluence завжди повинен бути частиною таски, якщо вона щось додає або суттєво змінює. Інакше, потім будуть оті «таємні знання»

Відповісти
Підтримати
Beaver Green
Dmytro 02.08.2024 07:31

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

Відповісти
Підтримати
marchelloua 01.08.2024 22:52

Було, йшов з проекту і мав відпрацювати місяць після повідомлення (згідно з контрактом). Весь цей місяць писав дуже детальні доки і онбордив наступника в чаті, також через регулярні мітинги 1:1 і також робив розширені мітинги разом з іншими причетними до його майбутніх завдань. Навіть залишив свій номер whatsapp (щоправда, не знадобився). До речі, наступник знайшовся буквально через декілька днів після повідомлення — це якщо в когось колись були ілюзії про свою цінність і незамінність.

А ще був прикол на іншому проекті. Це була міграція, тому наступників не було — змігрував і пішов. Однак по ходу діла ще розробив одну фічу (насправді не одну, однак цей абзац стосується лише однієї з них). Отже, розробив фічу і розписав доку в confluence — там тексту на десять натискань кнопки pageDown. Пише мені в скайп CEO через декілька місяців — я тут збираю мітинг щоб впровадити твою фічу на інших підпроектах, чи зможеш підключитися. Я підключаюся, говорю спеціалісту який буде впроваджувати — відкрий конфлюенс і вбий ключове слово «назва_фічі_1». Відкрив, погортав — каже все зрозуміло. Вони навіть не читали мої труди, хоча я теґнув в конфлюенсі всіх потенційно причетних.

Відповісти
Підтримати
Oleksandr Abramov 01.08.2024 22:49

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

Відповісти
Підтримати
Olena Sharovar Node.js/JS в Waverley 01.08.2024 21:19

Я писала тонни документації і онбордила людей перед тим, як піти в декрет. На вісім місяців ходила, а перед тим місяця три+ зайняло хайринг/онбордінг/документація. Зараз просто на постійній основі підтримуєм документацію.

Відповісти
Підтримати
Вікторія Бохун 01.08.2024 21:18

Маю досвід людини, яку онбордили. Причому робила це людина, на місце якої мене взяли працювати. Особисто мені було набагато легше влитися в роботу після такого онбордингу, ніж після онбордингу, який проводив тім-лід (такий досвід теж є). Загалом, ми чудово поладили, і я дуже сподіваюсь, що зараз у мого попередника все добре:)

Відповісти
Підтримати
Slavik Savko 01.08.2024 17:47

Якось домовились із керівництвом що буде два місяці на те, щоб знайти мені заміну і заанбордити його. Я місяць писав документації, все вилизував щоб не соромно було. Вони шукали.
Запитую «Ну що там» — В процесі
3 Тижні до звільнення — В процесі
Мене жодного разу не викликали на співбесіду і підозрюю що співбесід і не було
2 Тижні — Альо, я звільняюсь. Ось моя заява (там по КзПП і два тижні обязаловка). Заяву приймають. Я попереджаю що це прям дуже крайній термін щоб все передати
3 дні — Приводять якогось чела зовсім не тямущого і скоріш за все влаштованого по знайомству. Кажуть натягай. Мені насрати вже — я по хорошому хотів розійтись, винні самі.

Все що міг зробив. Принайні хоч трохи навчив з bash працювати (LOL). Отримую трудову на руки і йду геть.
Відчуваючи що буде жопа я ще за 2 тижні до цього змінив номер, передав його усім знайомим (крім роботи) і змінив як фінансовий у банках. Вийшовши із підприємства просто вимкнув старий.
Через пів року по приколу вставив цю сімку і там було купа повідомлень про пропущені з різних номерів у тому числі із погрозами. Поспіхнувся і вибросив її в урну

Відповісти
Підтримати
Mykhailo Storozhuk FullStack Wordpress Developer 01.08.2024 23:35

ох уж ці ментальні феодали, вічно їм щось винні

Відповісти
Підтримати
Slavik Savko
Slavik Savko 02.08.2024 10:51
ментальні феодали

Там скоріш хронічні по***сти

Відповісти
Підтримати
Mykhailo Storozhuk
Сергій Машковський C# Developer 04.08.2024 00:34

чота вашого наступника (він теж напевне вам дзвонив) жаль стало. він-то в чому винен? (його розумові здібності винесемо за дужки)

Відповісти
Підтримати
Slavik Savko
Vic Programmer 04.08.2024 14:47

Ну то нажаль, наука влаштовуватись на роботу шляхом навчання на власних помилках.

Відповісти
Підтримати
Сергій Машковський
Slavik Savko 05.08.2024 14:28

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

Відповісти
Підтримати
Сергій Машковський
Yevhenii Oliinyk Software developer в Ciklum 01.08.2024 17:23

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

Відповісти
Підтримати
Олександр Маркусик DevOps 01.08.2024 17:17

Онбордив наступника і не здогадувався про це

Відповісти
Підтримати

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.