Happy trial: як випадково не відсіяти хорошого працівника

Вітаю! Мене звати Костя, я PS Department Manager на одному з проєктів-партнерів аутстафінгової компанії SD Solutions.

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

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

Скільки часу має тривати випробовувальний термін

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

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

Я не рекомендую відводити на випробувальний термін менше ніж 3 місяці, адже тоді є ризик втратити цінних співробітників. Люди різні, багатьом потрібно більше часу на те, щоби пристосуватися. Одного разу двоє новеньких у моєму департаменті почали одночасно, і спочатку я був впевнений, що один є сильнішим за скілами. Але за якісь два тижні моя думка змінилась: обидва могли легко впоратися з різними тасками та неординарно розв’язували задачі.

Якщо є найменші сумніви, можна запропонувати навіть 4 місяці, щоб точно не проґавити крутого спеціаліста. А от пів року, на мою думку, вже забагато. Через 6 місяців вже можна зробити перший перегляд зарплатні, адже за цей час людина точно встигне проявити себе і показати свої найсильніші сторони.

Онбординг з ментором

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

У «велкам бук» варто обов’язково додати:

  • Інформацію про те, чим займається компанія. Очевидно? Так, але це варто згадати. Якщо це фриланс, то необхідно описати загальну концепцію проєкту, на який направлено новачка. Якщо проєкти чергуються, то вказати індустрію та поширити приклади. Якщо продукт — вдатися в деталі: на яких технологіях починали, продовжили та закінчили; як працює; хто користується тощо.
  • Організаційні питання. Як і де ведуться таски; хто за що відповідає; який KPI на конкретній позиції; як проводяться перфоменси, рев’ю коду й подібне.
  • Базові поняття, необхідні для роботи. Наприклад, на моєму проєкті це — клієнт, товар, назви таблиць у базах даних.

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

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

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

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

Критерії, за якими варто оцінювати результати випробовувального терміну

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

Час, витрачений на проходження базового тренування

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

а) людина дуже уважна і прискіплива до деталей;

б) початківець затягує навчання або не може розібратися з базою.

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

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

Скіли

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

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

Рев’ю коду VS рев’ю рішення

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

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

Чи існує ідеальний код

Згадайте самі, як ви пишете код: через рік дивитесь його і хапаєтесь за голову, хочете внести купу правок. Це пов’язано з нашим персональним розвитком як спеціалістів. Хоча прагнути до ідеалу — абсолютно природно, краще змиритися, що ні ваш, ні чийсь код не буде ідеальним.

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

Проте буває, що неточність критична, наприклад: людина навчилась користуватись jQuery і замість того, щоб вчити Angular, бере знайомий jQuery. Треба спитати в самого себе: «Як я допустив таке?» Очевидно, тут є де допрацювати ментору.

Запитання

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

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

Був кейс, коли один з новачків пройшов тренінг, після чого я дав таску в живій системі та пояснив, як зробити так, щоб нічого не зламати. Потім хлопець пішов до колеги, де йому пояснили знову. І так було тричі. Напротивагу цьому існують запитання, відповіді на які має лише тимлід чи менеджер. До прикладу такий запит: «Чому не приходять усі дані?» має лише одну відповідь — «бо є проміжна база, до якої немає доступу». Або якісь унікальні реалізації, які не є завданням новачка: є 3 кнопки, а клієнт говорить про четверту — не потрібно придумувати цю кнопку, можна запитати або попросити її створити.

Щоб уникнути непорозумінь, страху й міскомунікації, ментору слід:

  1. Окреслити межі запитань: які варто ставити, а з якими потрібно попередньо погратися самим.
  2. Наголосити, що запитувати потрібно по суті. Якщо є нестача конкретних знань, то необхідно уточнити в ментора, щоб уникнути ситуації, що таску, розраховану на один день, менті виконує півтора тижня, бо не був спрямований правильно.
  3. Відповідати конкретизовано. Якщо є зв’язка систем, і менті запитав за одну, то давати відповідь потрібно лише про неї. У такий спосіб людина вчиться правильно обдумувати питання, ставити їх одразу і прослідковувати причинно-наслідкові зв’язки між відповідями.
  4. Правильно ставити таски. Часто здається, що все очевидно, а на практиці це зрозуміло тільки ментору.
  5. Не позиціонувати себе як надто зайняту і недоторкану особу, щоб у менті не виникло страху запитувати.

Правильно поставлене запитання збільшує вірогідність отримати конкретну і структуровану відповідь. Вони мають підводити до рішення, а не навпаки — відвертати увагу від кореня проблеми чи завдання.

Повна відсутність запитань — теж дзвіночок, що комунікація має прогалини, а між ментором і менті зародилась недовіра чи страх.

Типові помилки ментора

Занадто детальні описи завдань

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

Коли приходить час описувати наступну таску, то віднімаєш якусь інформацію. У кінці опис задачі має бути приблизно таким: підключи платіжну систему. А вже менті має поставити конкретні запитання: яку систему; який метод платежу.

Коли ментор дозволяє менті думати, то питань стає менше.

Не дає живі таски

Давати реальні завдання — must have для випробування вмінь новачка. Потрібно дати живу таску в безпечний спосіб, що залежить від спеціалізації компанії. Можна зробити це в реальному продукті, але пояснити чітко, чого робити не варто. Тоді людина відчуває відповідальність за роботу, яку виконує.

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

Дає таски з термінових проєктів

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

Тоді не буде достатньо часу для того, аби він сам покопирсався і детально проаналізував помилки.

Дає задачу іншої людини

Погляньмо на конкретний приклад. Є ментор Олег та його менті Віталій. Поряд з ними в команді є Марія, на яку навалилось занадто багато задач. Перевантажена Марія може попросити у Віталія допомогти із завалом тасків, щоб добитись своїх результатів.

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

Прив’язується до менті

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

Часто навіть думається: «Не хочу знову когось вчити і звикати ще раз», — але якщо людина не впоралась, то потрібно прощатися.

На якому моменті припиняти розжовувати

Що ж, підсумуємо: окрім відсутності необхідних для команди скілів або вірогідності не спрацюватися, потрібно прощатися, коли новачок:

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

Це дзвіночки, які прямо-таки кричать, що буде легше самому виконати роботу, аніж витрачати час на навчання того, хто не збирається вчитися.

Що робити, коли людина не пройшла випробовувальний термін

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

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

  1. Казати правду. Ймовірність того, що правда випливе на поверхню і залишить у людини неприємні спогади, дуже висока.
  2. Представити конкретні причини. Перерахуйте, що було не так, і поясніть, чому це важливо виправити.
  3. Вказати на сильні сторони. Не потрібно бути негативно налаштованими, виділіть напрями й таски, які виходили в людини найкраще.
  4. Скерувати, на що звернути увагу при пошуку нової роботи. Закінчувати найліпше підсумуванням сильних і слабких сторін, а також певною порадою. Та не потрібно наполягати або стверджувати. Радити, але не нашкодити.

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

Коли можна давати таски під ключ

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

Якщо ставить правильні запитання, дотичні до завдання, то наступні два кроки очевидні: відповісти на питання і проконтролювати результат. Коли людина справилася, то з наступною подібною задачею її можна залишити наодинці.

Варто вміти довіряти команді, адже це не лише розвантажить тебе, але й у менті буде відчуття обов’язку і відповідальності, через що результати будуть у рази кращими.

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

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

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

👍ПодобаєтьсяСподобалось6
До обраногоВ обраному3
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

Цікава стаття, одне що те як описувати таску це досить спірний момент. Як на мене я б завжди описував таску максимально з описом, якщо цей опис відомий. Без діталей це хіба що ти знаешь що там робити і сам же плануєшь її робити.

Бо вікриваєшь борду, там тобі таску заассайнили з описом

Підключи платіжну систему.

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

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

М’який знак після «Ш» в українській не пишуть ;)

Якщо сумніваєшся, то пропускай. Ти відчуєш, коли знайдеш потрібну людину.

А може, краще зробити процес найму таким, щоб після найму була 95 відсоткова впевненість, що людина пройде випробувальний термін?)

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

На практиці я за останні 6 років бачив тільки два випадка, коли спец не відповідав вимогам до позиції, і в обох випадках виявилось, що помилки були саме у процесі найма (1 випадок — не помітили матеріальне незадоволення кандидата стосовно оферу, 2 випадок — зверхня технічна співбесіда).

До речі, є компанії, де випробувальних термінів нема взагалі, та процент звільнень у першій рік там менше, ніж 1%.
Також, 3+ місяця ВТ ще не зустрічав (може, мені везло з компаніями).

спец не відповідав вимогам до позиції
1 випадок — не помітили матеріальне незадоволення кандидата стосовно оферу

Яким боком гроші до вимог до позиції?

2 випадок — зверхня технічна співбесіда

А це як? Кандидата образили на співбесіді і він все одно погодився на офер?

зверхня технічна співбесіда

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

1) Кандидат погодився на офер, но сума компенсації його не влаштовувала, тому через 2 місяці він перейшов у іншу компанію на більшу зп. Гроші в цьому випадку дотичні, бо було відомо, що зп очікування співробітника значно вище, і, навіть, якщо він погодився на меншу зп — логічно, що він залише компанію як тільки йому запропонують компенсацію, яка його влаштує.

2) На позицію були вимоги к досвіду в програмуванні на рівні Middle+. Випадково сталось, що співбесіду проводили співробітники, які майже не кодили (General QA), і коли співробітника найняли, виявилось, що він елементи з явними унікальними аттрібутами шукає по плейсхолдеру / авто-генерованому класу (це тільки один із прикладів).

Краще було би сказати не «зверхня», а «поверхнева», вибачте за мою українську)

Ставить запитання, які є неприйнятними на 3 місяці траялу.

Можете поділитись списком цих запитань?

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

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

Західна (дефолтна) культура навпаки спонукає та підтримує будь-які питання незалежно від того скільки ти часу працюєш, а токсична пост-радянська з точністю до навпаки — «не задавать тупих вопросов». Десять років тому це було доволі сильно помітно, але ті діди старої закалки вже в більшості ментально видохлись, хоча час від часу трапляються цікаві персонажі, а на ДОУ таких багато :)

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