Гайд по прохождению испытательного срока
За свое время работы аналитиком я встречался с разными ситуациями - у меня самого были и провалы, и успехи. Были проблемы с разными коммуникационными вопросами (то что называется софт скиллы). В результате сформировалось понимание как правильно действовать, строить коммуникацию на новом месте работы, чтобы влиться в команду и успешно пройти испытательный срок.
Итак, вы устроились на новое место работы аналитиком. Разберем в деталях что дальше происходит и как я советую действовать.
Получение доступов, первая неделя работы
На первой неделе вам выдают рабочую технику, доступы, знакомят с командой.
Нужно настроить рабочий VPN, получить доступ к базе данных, доступ в Jira (система планирования задач), Confluence (там документация и статьи), доступ в git (куда выкладываются разные версии кода).
У вас есть формальный руководитель (допустим, его зовут Алексей). Я советую как можно быстрее с ним наладить коммуникацию. Обсудить задачи на испытательный срок, предложить назначить регулярную встречу 1-1 хотя бы раз в 2 недели (если она еще не назначена), поддерживать контакт и регулярно запрашивать обратную связь.
Для спокойствия я советую вам все прямо проговаривать. Например, в начале работы стоит уточнить цели на испытательный срок.
Не факт, что они вообще есть. Часто их может не быть, либо в самом общем виде "погрузиться в проект, понять устройство базы данных". Но таким вопросом вы сможете себя обезопасить - если спросите руководителя, какие у вас цели, он назовет какие-то пункты, вы можете уточнить, есть ли критерии, по которым вы сможете понять что вы их выполнили? Тогда меньше шансов будет потом, что к вам придерутся и скажут, что вы что-то не сделали, хотя должны были.
Не факт, что задачи вам будет ставить именно формальный руководитель Алексей. Иногда может быть такое, что он просто контролирует проект и в детали не погружен, а задачи вам ставит по факту его подчиненный. Тогда вы уточняете у него эту информацию - например он говорит, твой заказчик Петр, все вопросы по задачам и обратной связи к нему. Тогда стоит считать, что ваш руководитель Петр, потому что именно на основе его оценки вашей работы будет приниматься решение по вам. И все описанное теперь применяется к нему.
Итак, у вас есть руководитель, вы уточнили у него задачи на испытательный срок, выписали их себе, по возможности уточнили более четкие критерии. Допустим, вы работаете в складской логистике, и вам говорят "надо разобраться в работе склада". Вы можете уточнить - что конкретно это значит? Например, он вам говорит - надо понимать как устроены тарифы хранения на складе, какие модели доставки есть и в чем их особенности (FBS, FBO, DBS), какие типы складов есть (дарксторы, еще какие-то) и тд. Тогда выписываете себе и потом проверяете, что вы узнали все эти пункты.
Погружение в работу
В начале работы вам обычно дают простые задачки, чтобы вы просто погрузились в процесс. Например - выгрузи статистику продаж по складам за последние 2 недели. Посмотри причины задержек товаров и составь разбиение по причинам. Добавь небольшую деталь в дешборд по складам.
Основная сложность на данном этапе в том чтобы понять где что лежит. В какой базе данные, корректные ли они, что надо учесть при подсчете. По внутренним вопросам связанным с процессами часто придется уточнять у команды (если этого нет в документации), по техническим вопросам надо разбираться самому и лишний раз руководителя и команду не напрягать.
Например, частая ошибка: вы пытаетесь подключиться к базе, не хватает драйвера, надо его скачать. Если вы не смогли разобраться, надо этот вопрос загуглить, спросить у gpt - ожидается что вы сделаете это сами.
А вот какой-то вопрос касательно работы складов в этой конкретной компании вы нигде не узнаете - и его придется спросить у коллег.
Работа по спринтам
Далее работа обычно проходит по недельным или 2-недельным спринтам, на каждый из которых вам ставят задачи.
Задачи вам ставит либо непосредственно ваш лид (Петр), либо коллеги из соседних отделов.
Типичная практика такая: вам ставят 2-3 задачи на спринт + в течение спринта могут прийти заказчики с небольшими доп задачами и попросить их тоже взять в спринт.
Алгоритм действий при получении задачи
Вам ставят любую задачу, не важно какую. Первое что надо сделать - уточнить срок задачи в явном виде. Это нужно для прозрачности коммуникации + чтобы вам также подстраховаться и вас не смогли потом обвинить, что вы что-то долго делаете.
Вы уточняете срок - допустим, он неделя. Ок, в течение недели сделаю.
Если срок слишком маленький - скажем, 2 дня, но у вас есть и другие задачи с тем же сроком - вам надо сразу это обговорить с заказчиком. Насколько важна эта задача, можно ли сделать позже? Нет, нельзя? Тогда мне надо обсудить с руководителем, какая задача в приоритете - ту которую он дал или новая от заказчика. Идете к руководителю, он принимает решение, сообщаете заказчику.
Всегда поддерживаете прозрачность в плане того, что с задачей заказчика, в какие сроки вы ее сделаете, если есть задержка по ней - сообщаете ее причину.
Например, может быть ситуация, что задача зависит не только от вас - вы свою часть уже сделали, передали разработчику и ждете результата от него. Тогда стоит это сообщить заказчику - чтобы потом не подумали, что задача долго тянется по вашей вине.
Или наоборот, вам перед тем как приступить к задаче, нужно чтобы разработчик сделал свою часть. Тогда изначально так и говорите - нужен результат от разработчика, после этого с моей стороны срок 2 дня.
Работа с непонятными задачами
Бывает что задача поставлена в размытом виде, непонятно что конкретно делать или каким образом. Например - сказали проанализировать причины роста опозданий на складе за последний месяц. А как это сделать, вы без понятия.
Что делать в такой ситуации? Во-первых, можно базово обсудить задачу с GPT или с ментором (на моем курсе ученики в такой ситуации всегда могут обсудить со мной). Конечно, без раскрытия GPT конфиденциальной информации.
Какие примерно подходы могут быть, о чем вообще речь.
После этого составить базовый план решения задачи, сообщить о нем руководителю.
Петр, привет. По этой задаче планирую действовать следующим образом:
- посмотреть опоздания по складам в разбиении по регионам, в каких выросло больше
- посмотреть в разбиении по категориям товаров, ценовым сегментам
- посмотреть причины обращений в саппорт в то же время, был ли рост, если да то какие причины обращений
Пишете это лиду. Если с его стороны ок или нет комментариев - идете действовать по этому плану. Либо он вносит свои корректировки: ты выбрал неверный подход, по такой-то причине, или посмотри еще вот эту причину. Согласовываете с ним план действий и идете его выполнять.
Почему это важно? Без этого вас могут обвинить, что вы делали вообще не то. Например, вы не обсудили план решения, проходит неделя, причина опозданий не найдена. Лид спрашивает: чем ты вообще занимался неделю, почему нет результата. - я смотрел такие-то причины - так ты вообще не то смотрел, надо было другое.
А в моем сценарии, даже если результата нет - у вас есть результаты проверки обсужденных с ним гипотез. Смотри, мы обсудили такие-то гипотезы, которые надо проверить, вот я это сделал, результата нет, надо сформулировать следующие и уже идти их проверять. И до вас нельзя доебаться, что вы что-то сделали не так: вот же, мы согласовали план действий.
Прозрачность в ежедневной работе
Обычно в айти регулярно проходят дейлики. Раз в день идет созвон минут на 30, на котором члены команды обсуждают что сделали за прошлый день, какие проблемы.
Я раньше часто приходил на дейлик и говорил о себе в формате: "продолжаю работу над задачей по складам, еще в процессе".
Как я считаю лучше говорить? Более детально описывать, что вы сделали. Вероятно, за прошлый день было много мелких задачек, которые вы тоже сделали, но могли уже забыть. И будет лучше, если вы ответите в формате:
"Вчера работал над задачей по складам, изучил документацию в Confluence. Сформировал список из 3 вопросов по ней, сможете подсказать? Далее говорите сами вопросы (сами вопросы не тупые, а по делу). Также вчера сделал выгрузку данных для менеджера логистики, внес правку в дешборд по опозданиям, получил доступ к базе. Сегодня продолжу работу над задачей."
Так будет видно, что вы реально много что сделали, продвинулись по задаче, сформировали вопросы. Если вы двигаетесь в неверном направлении, делали что-то не то - вас смогут поправить и сказать как подкорректировать курс. Если так не скажут, то и вы себя обезопасите - до вас не смогут позже доебаться, что вы что-то не то делали. Вот же, я говорил про это прямо на дейликах, спрашивал в верном ли я направлении иду.
Если вы действуете как описано - вы сможете поддерживать прозрачную коммуникацию и до вас даже при желании будет очень сложно доебаться.
Если вы так не делаете - доебаться могут.
- Что сделано за последние недели?
- Ну, я делаю такую-то задачу, изучил документацию..
- А почему эту задачу делаешь так долго, уже 2 недели?
- Ну, мне не сказали точный срок.. (вам надо было самому уточнить - прим.)
- А что конкретно по ней сделано?
- Ну, я сделал то и то..
- Так ты вообще не то делал все это время, надо было иначе.
- (и вам уже нечего возразить)
Если все корректно проговаривать - такое будет невозможно. Почему делаешь задачу так долго? Я при получении уточнил срок у заказчика, он неделя, в него укладываюсь. Почему делаешь не то? Ну как же не то, я писал про свой план действий в чат, на дейлике про него рассказывал, вы сказали что все ок (или ничего не сказали, как бы тоже дав понять что это ок).
Создание правильного впечатления
В первое время работы стоит создать о себе правильное впечатление. Вы опытный амбициозный специалист, вам интересен проект, эта работа, вы хотите активно ебашить и развиваться. Иногда стоит остаться в офисе и поработать уже после конца рабочего дня - показать что вам важно успеть закрыть задачу в срок.
На первом этапе вам важно разобраться в проекте, сработаться с руководителем, понять его характер, что для него важно. Где можно подзабить а где прям важно корректно сделать.
После испытательного уже сможете немного расслабиться, но пока не время для этого.
Глубокое изучение проекта
Испытательный срок - время чтобы детально погрузиться в ваш проект. Кроме технических навыков, вам нужно будет узнать детали конкретного проекта, например складской логистики. Разобраться в этой сфере - как все работает, какие нюансы, какие другие практики на рынке, какие проблемы. Стоит сделать это на этапе испытательного срока - там это нормально и ожидается. А если пройдет полгода, и выяснится что вы еще не узнали что-то важное для вашей сферы (например, чем отличается модель доставки DBS от FBS) - могут возникнуть вопросы.
Как не напрягать руководителя и команду
Вас нанимают чтобы облегчить работу. В идеале - чтобы вам можно было отдать задачу и забыть про нее. Быть уверенным, что вы сами погрузитесь в ее контекст, зададите дополнительные вопросы заказчику, составите план решения, проверите свое решение.
Не стоит закидывать коллег вопросами вроде:
- а как делать эту задачу?
- подскажите мне глупый вопрос, ответ на который можно узнать в гугле за 5 мин, но мне лень
- а что лежит в таблице такой-то? (если вы сами могли найти ответ в документации отдела в Confluence)
Стоит избегать любых ситуаций, которые напрягут руководителя и создадут ему проблемы.
Из недавних кейсов: ученику надо было отработать в субботу пропущенные дни. Офис был закрыт, он стал искать способы туда попасть, звонить в субботу утром руководителю и добиваться ответа. Так делать не надо.
Регулярная обратная связь
Важно регулярно узнавать у руководителя обратную связь. Или у формального руководителя, или у того, кто по факту вам ставит задачи. Даже если вам кажется, что все ок, или он вам так говорит - стоит попросить встречу 1-1 раз в 2 недели. На ней чаще всего выяснятся мелкие моменты, которые вам до этого не говорили, потому что они не настолько значимы чтобы отдельно обсуждать. Но если вы явно спросите обратку, вам это скажут, и вы сможете улучшить работу.
Если же вы регулярно спрашиваете обратку, и вам говорят что все ок - вы тоже себя подстрахуете. Вам потом не смогут сказать: что-то ты плохо работаешь последние 2 месяца, заказчики жалуются. Подожди, как жалуются, я же регулярно у тебя обратку спрашиваю, ты говорил что все отлично, проблем нет.
Вопросы
Стоит избегать любых глупых вопросов. В любой непонятной ситуации потратьте 10-15 минут, поищите в гугле, забейте в GPT контекст ситуации и ваш вопрос. Если ответ на поверхности, вам нужно найти его самим, а не напрягать коллег.
Для подстраховки можно использовать следующий принцип. Допустим, вы хотите что-то спросить, не знаете глупый вопрос или нет. Можно спросить GPT: смотри, вот такая ситуация, такая задача, лид написал следующее. На основе этого я делаю вывод, что мне надо уточнить у коллег, как работает модель доставки DBS, в открытом доступе этой инфы нет. Я верно оцениваю ситуацию или может что-то глупое сейчас спрошу и могу сам найти ответ?