За это моего коллегу уволили с испытательного срока

Сегодня расскажу про то как не нужно проходить испытательный срок. На самом деле на моей памяти это первый случай когда моего коллегу не оставили в штате после испытательного срока. Но сейчас кризис найма, найти нового разработчика проще чем раньше, по этому думаю таких случаев будет больше.

Как ни странно по моему опыту больше всего проблем с синьор разработчиками. У них уже есть какой то опыт и виденье как делать правильно. И часто такие разработчики не особо готовы подстраиваться под окружающую среду, а пытаются сразу все менять. В этот раз была именно такая ситуация. Для удобства повествования давайте назовем нашего героя Пол.

Проблема 1:

Пол, не разобравшись в текущей архитектуре, стал вводить какие то новые архитектурные подходы. При чем он устраивал прям митинги, где объяснял как это должно работать. В целом может показаться что это хороший подход. Пол тем самым показывал свою проактивность и экспертность. Но проблема в том, что у него еще не было авторитета внутри компании. По этому люди относились к таким изменениям с недоверием.

Когда ты пришел на новое место, тяжело сразу увидеть реальные проблемы команды. Зачастую такие люди просто предлагают поменять что то, чтоб было так же как на их прошлом месте работы, но в этом может не быть никакой необходимости. И естественно у остальной команды будет сопротивление к изменениям. В итоге сколько ты митингов не проводи, не погрузившись в контекст работы команды, тебе вряд ли удастся переубедить другую часть компании в том что новый подход стоит применять.

Проблема 2:

Параллельно с убеждением использовать новый подход Пол начал его уже использовать в новой фиче, которую он разрабатывал. В итоге обсуждения его PR длились несколько дней. Нарастало недовольство им не только от других коллег из смежных команд, которые ревьюили его задачу, но и от менеджера, чьи задачи он затягивал.

Проблема 3:

Недооценивал задачи. В принципе по началу в этом нет ничего страшного. Ты еще изучаешь кодовую базу и проект. Но зачастую Пол занижал оценку задач, которую ставили его коллеги. Делал это постоянно и постоянно в эту оценку не укладывался. Это происходило на протяжении нескольких месяцев. Когда твоя оценка системно не совпадает с реальностью, к тебе появляются вопросы. Так как основное отличие джуна от синьера не скорость работы, а умение увидеть и предсказать возможные проблемы в задаче и правильно ее оценить. То тут появлялось сомнение в его экспертизе и опыте. В данном случае Пол вместе с разработкой продуктовой задачи начинал делать какой то рефакторинг, что то переписывать, что сильно влияло на сроки выполнения. В итоге он не выполнил на моей памяти ни одной цели спринта, на которые сам соглашался

В итоге коллега отработал около 5 месяцев и руководитель решил что стоит с ним расстаться.

Какая правильная стратегия поведения на испытательный срок:

За испытательный срок важно завоевать авторитет предсказуемого разработчика, который делает задачи в срок и качественно. Заметьте я ни слов не сказал о скорости, он вообще не важна. Не стоит сразу пытаться все изменить и подстроить под свой привычный лад. Первое время изучите как уже устроена работа в команде. Для меня самый лучший способ, это парное программирование. Берете задачу из спринта и просите коллегу вместе ее поделать. Либо просите вместе поделать задачу коллеги. Таким образом у вас не будет вопросов на ревью, а если и будут то у вас в союзниках коллега с которым вы задачу делали. Я стараюсь первый спринт стараться побольше парно программировать. Единственное многие не совсем правильно это делают и часто это превращается в то что опытный разработчик пишет код, а второй просто смотрит. Так делать не стоит

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

Или огонечек если хотите почитать про то как я считаю нужно вводить новые подходы в команде(такой вопрос часто задают на soft skills сессии)