Большинство работодателей считают, что испытательный срок — абсолютно целесообразная вещь. Практически в 80% случаев компании берут в штат сотрудников только после успешно пройденного тестового периода и на то есть свои причины.
Спросили у Дениса Шаматажи, который за 5 лет работы онбордил десятки проектных менеджеров, зачем нанимающему менеджеру испытательный срок и как кандидату показать себя, чтобы закрепиться в компании.
Зачем работодателю нужен испытательный срок?
1.Определить непосредственно хард скилы
Руководству важно выяснить, насколько специалист, в данном случае PM, справляется со своими задачами, проблемами и челленджами.
Из того, что я вижу из своего опыта, очень часто компании могут быть снисходительными к отсутствию каких-то hard skills, если их с лихвой компенсируют soft skills, и все же в первую очередь стоит проверить, насколько хорошо вы разбираетесь в том, что вам непосредственно понадобится в работе.
2. Насколько специалист соответствует культуре команды
В стартап, например, спокойно берут джунов, миддлов и вообще любых ребят, которые горят проектом и готовы идти на какие-то денежные уступки, сокращения отпусков или больничных в ущерб себе, потому что само участие в развитии продукта их очень драйвит.
А теперь давайте представим Enterprise проект, в котором сотрудники очень скурпулезно относятся к процентам, бонусам и так далее. Сюда подойдут совершенно другие люди.
Как-то я работал в компании, команда которой была распределена между 11 часовыми поясами. Для нашего кейса такое количество людей с разными менталитетами и отношением к работе было приемлемым, но это скорее исключение, чем правило.
3. Насколько кандидат нравится на эмоциональном уровне
С учетом опыта рекрутинга не только РМ-ов, и того факта, что во многих проектах мне приходилось ставить процесс рекрутинга, я сталкиваюсь с тем, что субъективная оценка того, насколько нанимающему менеджеру или рекрутеру нравится этот человек, очень часто играет если не определяющую, то очень значимую роль.
Если человек отлично справляется со своими задачами и вообще душа команды, но при этом не нравится кому-то из людей, принимающих решения, есть вероятность того, что тестовый период он не пройдет. И это не хорошо и не плохо. Как есть.
Чего не стоит бояться
«Я не понимаю, помоги»
Когда вы приходите на проект и чего-то не понимаете — это абсолютно нормально! Об этом не нужно беспокоиться вообще!
К тому же, очень полезно учитывать мнения команды, так как backend разработчик объяснит вам функционал с точки зрения бизнес-логики, frontend расскажет по поводу совсем других вещей, а тестировщик раскроет те моменты, на которые backend даже не смотрит.
«Давайте расскажу, что было не так»
Можно во время испытательного срока рассказывать команде, какие в целом есть изъяны в процессе, что вы обнаружили, какой баг нашли и в каком направлении собираетесь копать.
Я всегда стараюсь максимально прозрачно объяснить коллегам, почему стоит принимать те или иные решения. Не во всех компаниях это приветствуется руководством, но практика отлично себя зарекомендовала!
«Что я сделал?»
Лучше не дожидаться, когда к тебе придут и спросят о результатах, даже если они просто выдающиеся! Старайтесь демонстрировать результаты до того момента, как у руководства сработает триггер поинтересоваться, на каком проценте сейчас находится прогресс.
«Это сделать невозможно»
Лучше как можно раньше честно отвечать руководству или стейкхолдерам, что задачу невозможно реализовать при данных условиях. Правда, вместо«невозможно» лучше использовать более конструктивную фразу: «Мне кажется, это очень сложно реализовать теми возможностями, которые у нас есть на данный момент. У нас нет достаточного количества людей, экспертизы и чего-либо еще».
Чего не стоит делать
Эти советы осознавалась на опыте и личных ошибках.
Распыляться на помощь другим!
Помогать другим очень важно, и во многих стартап-проектах, когда действительно некому было заниматься настройкой каких-нибудь инструментов Facebook или SQL запросов, руководитель попросил меня помочь с такими задачами.
Я говорил, что мы же утвердили другие KPI на испытательном периоде, и у меня в связи с ними очень много задач. Руководитель ответил, что вот сейчас реально очень сильно нужно помочь разобраться с SQL запросами. Ты начинаешь помогать ему, потому что хочешь быть молодцом! И в итоге проваливаешь свои KPI и требования.
У меня несколько раз такое было. То есть я, на самом деле испытательный срок не провалил ни разу. Так что в такие моменты я советую отвечать:
«Слушай ты понимаешь, что если я начну этим заниматься, то из основного scope работы, который я делал, будет выполнено чуть меньше. Либо мне придётся перерабатывать. Но я не очень хочу перерабатывать больше, чем уже перерабатываю сейчас».
Чаще всего, руководству достаточно этой фразы, чтобы понять, что я могу чего-то не успеть, и нужно сфокусироваться на самом важном.
Еще один вариант ответа: «А какую задачу сейчас важнее выполнить? Если эта таска важнее, чем другая, тогда ладно, черт с ним. Я возьмусь за это, без проблем. Но тогда учитывай, что я могу добиться не всех пунктов KPI в итоге!»
В одной из компаний мне сказали, что нужно выполнять задачи, не связанные с моими KPI. В итоге, мне указали на 3 пункта KPI, из которых реализован всего один. Действительно, как же так вышло-то?
Я говорю: «По сравнению с этим, вот сколько раз мы говорили о том, что придется сделать что-то другое, и смотри, каких результатов мы добились в этих направлениях по итогу. У нас хорошо работает одно, другое, третье, и так далее».
Такой путь хаоса в стартапе — очень распространенная тема, я с таким сталкивался, но это не самые хорошие показатели компании.
2. Создавать непрозрачный процесс!
Когда вам поставили какую-то фундаментальную задачу: добиться чего-то.
Раз в неделю приходят руководители с очевидным вопросом:
— Как дела?
— Всё отлично! Я скоро дам тебе результат.
— А сейчас как?
— Сейчас не буду показывать, я пока над этим работаю.
В таких случаях есть сразу 2 негативных момента.
- Никто не знает, получится ли у вас решить какой-то вопрос. Особенно, если он значимый.
- Очень вероятно, что в итоге вы сделаете совсем не то, чего от вас ожидали. Поэтому, чем быстрее вы сможете показать какие-то промежуточные результаты, тем быстрее вас по ним скорректируют и вы сможете достичь нужного вектора без каких-то очень больших переработок.
У меня как-то был кейс, когда одна из задач на время испытательного была привести в порядок документацию, потому что на проект приходило много новых разработчиков и тестировщиков. Документация должна была стать для них хорошим вводным пунктом для понимания проекта.
У меня не было возможности показать промежуточный вариант. В итоге, документация оказалась не совсем такой, которую от меня ждали руководители. Поэтому практически всегда, когда получаете какие-то задания, старайтесь максимально быстро дать промежуточный ответ, уточняя у руководства, в правильном ли направлении вы двигаетесь и так далее. Очень часто бывает ситуация, когда вы не до конца понимаете финальный результат, потому что у вас просто не хватает скиллов .
Пытаться разобраться во всем самостоятельно
PM – человек, который обязан уметь делегировать задачи, менеджить, и следить за их выполнением. Он ни в коем случае не должен зацикливать все задачи на себе.
Если у вас есть возможность получить экспертизу от человека извне, например разработчика, который расскажет о проекте и проблемах, лучше послушать его, чем потратить огромное количество собственного времени на то, чтобы докопаться самостоятельно. Чем больше вы будете интересоваться, тем быстрее у вас всё получится и абсолютно не нужно стесняться этого момента.
Вместо выводов
Мой вам совет: вместо того, чтобы чего-то бояться и распыляться по мелочам, лучше вложите усилия в анализ ситуации и попытку найти решение. Докопайтесь до сути, не нужно безоговорочно слушать руководство. В тестовом периоде нет ничего страшного и любую проблему можно решить либо дополнительным обучением, либо набитыми опытом шишками. В качестве вдохновения, рекомендую прочитать бизнес-новеллу «Цель» Элияху М. Голдратта. Да пребудет с вами сила!