Материал на Habr / Карьера про испытательный срок собрал 28 тыс. просмотров и задел тему, которую в командах обычно обсуждают уже постфактум, когда оффер превращается в неловкое расставание. Главная мысль неприятная, но полезная: новичок может честно работать, закрывать задачи и все равно выглядеть для команды человеком, от которого мало понятной пользы.
Как пишет Habr / Карьера, речь не о слабом коде и не о провале по хард-скиллам. Автор описывает так называемую «ловушку видимости»: ситуацию, когда сотрудник тратит день на разбор легаси, чтение документации, уточнение контекста и разговоры с коллегами, но снаружи это выглядит как пустота. В тикете нет внятного апдейта, в командном чате тишина, на стендапе сказать особо нечего. Формально работа идет, но в памяти тимлида не остается короткой и ясной истории о том, что именно сделал человек и какой риск для команды он снял.
Для испытательного срока это критично, потому что решение о продолжении работы редко выглядит как бухгалтерия по Jira. В статье точно подмечен неприятный для многих механизм: руководители запоминают не количество часов и даже не число коммитов, а короткий нарратив. Кто разрулил блокер, кто ускорил следующую задачу, кто заранее подсветил проблему, а кто второй день молчит и заставляет гадать, что вообще происходит. В такой логике «я весь день работал» звучит как отчет о занятости, а не о пользе. Намного сильнее работает другая формулировка: что именно выяснено, какая неопределенность снята, что можно делать дальше и где нужен ответ от коллег.
Отсюда и главный конфликт первых месяцев в найме, особенно у джунов и сотрудников на удаленке. Им кажется, что скромность и автономность выглядят профессионально: не дергать старших по пустякам, молча копать проблему, не писать лишнего в чат. На практике это легко превращается в обратный эффект. Команда не видит прогресса, не понимает, где человек застрял, и начинает достраивать картину сама. А достраивает она обычно не в пользу новичка. Глупый вопрос на первой неделе стоит дешево; трехчасовое молчание с блокером почти всегда обходится дороже. Для рынка, где на одну стартовую позицию по-прежнему много откликов, это важная деталь: увольняют на испыталке не только за слабую технику, но и за непредсказуемость.
В статье предложен набор привычек, который выглядит трезво именно потому, что в нем нет советов из серии «стань экстравертом» и «будь заметнее». Базовый прием прост: писать короткий апдейт не тогда, когда начальник уже пришел с вопросом, а сразу после завершенного куска работы. Формула из четырех пунктов вполне рабочая и для разработчика, и для аналитика, и для продакта: что сделано, какой риск или боль это снимает, как результат проверить и что идет следующим шагом. В переводе на язык команды это означает: человек не просто был занят, а двигал задачу вперед и понимает последствия своих действий. Для новичка это особенно полезно, потому что такой след в тикете помогает и ревьюеру, и тимлиду, и самому сотруднику на встречах один на один.
Второй прием в заметке назван правилом 90/15. Если упростить: полтора часа на самостоятельные попытки, еще 15 минут на то, чтобы оформить вопрос и вынести его наставнику или коллеге. Не с сообщением «ничего не работает», а с коротким разбором: что уже проверено, что ожидалось увидеть, что происходит фактически и в чем самый узкий вопрос. Это хороший фильтр против двух крайностей, обе знакомы многим командам. Первая: новичок дергает старших по любой мелочи и быстро превращается в постоянный источник отвлечений. Вторая: человек героически варится в проблеме полдня, а потом выясняется, что его стопорила одна деталь, которую можно было снять за пять минут. В режиме испытательного срока вторая крайность обычно опаснее.
Отдельно автор бьет по романтике удаленки на старте. Не в духе «офис лучше», а по более приземленной причине: доверие и контекст лицом к лицу нарабатываются быстрее. Пара разговоров после стендапа, быстрый показ экрана, случайный комментарий коллеги про старый сервис иногда дают больше, чем длинная переписка в чате. Для гибридных команд вывод неприятный, но логичный: если есть возможность первые недели чаще появляться в офисе, это не про корпоративный ритуал, а про ускоренную сборку рабочего капитала доверия. Удаленный формат никто не отменял, просто в нем требования к видимости работы становятся выше, а не ниже.
Интересен и набор недельных маркеров, который предлагает автор. Пять коротких апдейтов без специальной просьбы со стороны, один нормально оформленный вопрос вместо бессмысленного кружения по Google, одна проговоренная с тимлидом неопределенность, которую сотрудник собирается закрыть на неделе, и три пункта перед очередным 1:1 о том, что изменилось благодаря его работе. Для русскоязычной IT-аудитории это полезно тем, что превращает абстрактные «софт-скиллы» в конкретное поведение. Не нужно становиться харизматичным спикером, продавцом себя или офисной радиоточкой. Нужно, по сути, сделать свой прогресс наблюдаемым в той форме, в которой его считывают люди, принимающие кадровое решение.
На фоне охлаждения найма в части сегментов и более жесткой оценки джунов этот тезис звучит особенно прикладно. Команды готовы терпеть неопытность, если видят обучаемость, предсказуемость и ясную коммуникацию. Зато плохо терпят черный ящик, даже если внутри него человек добросовестно пашет. В этом смысле испытательный срок все меньше похож на экзамен по чистому коду и все больше на проверку того, можно ли доверить сотруднику не только задачу, но и понятный рассказ о ее состоянии. Для новичков вывод простой: мало сделать работу, нужно еще оставить после нее след. И похоже, именно это в ближайшие годы окончательно станет базовой гигиеной входа в профессию.