Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Как PM-у пройти испытательный срок

Статья написана в соавторстве с Мэри Ротарь, Co-Founder IAMPM.

Два года назад я решил уйти из Android-разработки в проектный менеджмент. Знаете, чего боялось руководство? Что я слишком много знаю, буду чрезмерно вовлекаться в технические моменты и не смогу нормально менеджить проекты. Но все получилось совсем иначе. Эта статья — попытка теоретизировать то, с чем я столкнулся на практике в проектном менеджменте: как со стороны соискателя, так и нанимающего менеджера. Расскажу о типах тестовых периодов, KPI на каждом из них, а еще поделюсь алгоритмом прохождения испытательного срока на примере одного из моих реальных кейсов. Enjoy!

Минутка фактов

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

Испытательный срок в Украине

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

Срок испытания при приеме на работу рабочих не может превышать одного месяца.

При работе с Европой или США тестовый период может достигать полугода или и того больше. Я однажды сталкивался с тестовым длительностью в полгода, и это совсем не так страшно, как кажется.

Для чего нужен испытательный

  • Понять, насколько хорошо специалист справляется с задачами.
  • Понять, насколько специалист соответствует культуре команды.
  • Понять, насколько кандидат «нравится».

Чаще всего, когда специалист попадает на тестовый период, о нем уже составили некое впечатление по резюме, всем кругам собеседований и тестовых заданий.

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

Чаще всего, когда кто-либо из специалистов попадает на тестовый период, у компании уже есть какой-то ряд впечатлений о нем: технических, субъективных, эмоциональных и так далее, и в процессе работы об этом нужно помнить.

Типы испытательных периодов

Из опыта моего взаимодействия с компаниями, испытательный период, вне зависимости от вашей позиции, бывает трех типов. О них и поговорим.

Ротация

Максимально простой тип тестового периода. Он случается, когда предыдущий (хороший) сотрудник уходит, а на его место ищут нового.

Ожидания после испытательного: новый сотрудник будет не хуже предыдущего.

На этом этапе KPI (метрики, по которым руководство будет понимать, насколько хорошо или плохо вы справились с испытательным сроком), скорее всего, будут либо точно такие же по своему характеру, как и у предыдущего специалиста, либо аналогичные остальным РМ-ам на вашей горизонтали.

Пример KPI

  • Estimated / Spent разработчиков должен варьироваться в пределе X.
  • Маржинальность проекта должна быть не меньше Y.
  • Процент задач, сделанных в спринте, должен быть не ниже Z.
  • Rework rate должен быть не выше W.

Самый распространенный KPI в аутсорсинге — маржинальность проекта должна быть не меньше, чем n%.

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

Не нужно пугаться таких KPI, на самом деле с ними достаточно просто разбираться.

Что делать

  • Если есть возможность, поговорить с бывшим PM, уточнить все детали и тонкости его работы.
  • Поговорить с каждым участником команды.
  • Попытаться понять, какие изменения, проблемы и аспекты процесса были на проекте.
  • Попросить каждого участника отдельно рассказать тебе о проекте и процессе в деталях.

Проблемная позиция

Второй тип тестового периода — это испытательный на какую-то проблемную позицию. Человека уволили, или возникла очень большая проблема, и никто ее не может решить. То есть вас нанимают на позицию, которая потенциально приносит вред и какие-то убытки бизнесу и компании.

Ожидания после испытательного: сотрудник должен исправить ситуацию, в которой мы оказались.

Пример KPI

У предыдущего PM-а все было плохо, потому что PM был плохой. Ты же хороший PM — сделай, чтобы все было хорошо!

Какая это ситуация? Опять-таки, чаще всего не та, которую описывает руководитель.

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

Что делать

  • Очень быстро работать.
  • Учитывать тот факт, что работодатель может даже не понимать, чего он на самом деле хочет.
  • Докопаться до самой сути проблемы.

Перспектива

Здесь поговорим об испытательных на какую-то новую позицию.

Например, компания расширилась, поняли, что команда стала слишком большой, и решили разделить ее на две, в связи с чем понадобился РМ. Или поняли, что какое-то направление в продуктовой разработке идет хорошо, и понадобился еще один человек. То есть просто какая-то потенциально новая позиция.

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

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

Такое происходит иногда и с проджектами, когда какие-то небольшие стартапы решают: «Все, у нас там начинается хаос, нам нужен проджект», но на полную катушку PM-а не задействуют. Это очень шаткая и наиболее редкая ситуация, но, тем не менее, о ней тоже нужно поговорить.

Пример KPI

  • Маржинальность проекта должна быть не меньше Y.
  • Процент задач, сделанных в спринте, должен быть не ниже Z.
  • Rework rate должен быть не выше W.

В таких ситуациях четких KPI может не быть или они могут строиться вокруг релиза или успешности проекта. У меня был такой кейс: инвестор собирал команду для того, чтобы реализовать продукт, соответственно, в первую очередь он нанял PM-a и сказал ему: «Вот у нас есть backend developer и дизайнер, давайте, начинайте работать».

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

Что делать

  • Уточнить, насколько этот профиль работы соответствует этому KPI.
  • Просмотреть существующие KPI сотрудников и разобраться в системе в компании.
  • Понять, для чего реально руководитель ищет сотрудника на эту должность.

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

Будет пять практических шагов. Они субъективные, но чаще всего интуитивно именно по ним я двигаюсь, когда попадаю на новую работу.

Соберите небольшой фидбек о себе

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

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

Второй момент — тестовые задания и технические собеседования могли выявить слабые стороны относительно позиции. То есть, условно, у вас не хватает какого-то хард скилла, или вы не очень хорошо себя показали в планировании, а может, у вас недостаточно экспертизы в основном профиле компании.

Как это выглядело у меня

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

Какой фидбек обо мне

  • Бизнес-команду беспокоит, что у меня много технических скиллов, и я буду отвлекаться на решение сторонних задач.
  • Один из отзывов был связан с моей плохой стрессоустойчивостью.

Когда я проанализировал фидбек, я расширил понимание, как меня воспринимает работодатель. Повезло, что мне об этом рассказали.

Определите четкие KPI, с которыми будут сверять вашу успешность

Обычно руководство говорит: «Все хорошо, завтра ты выходишь на тестовый период, тестовый период — это чуть меньше зарплата, не будет больничных. Давай приблизительно прикинем, что будет считаться успехом, а что — неуспехом за эти три месяца». Таким образом мы пытаемся сформировать с руководителем KPI, по которым будем двигаться.

Как это выглядело у меня

Давайте рассмотрим пример испытательного задания. Я приведу самый хардкорный кейс, с которым столкнулся сам. В одном из самых долгих, сложных и неоднозначных проектов, с которыми я работал, мой KPI на испытательном выглядел примерно так:

  • Gain a detailed understanding of the tasks that takes place when a client is onboarded and their dependencies.
  • Identify inefficiencies in current new client onboardings is documented with tickets on how to get these tools / improvements in place.
  • Document a structure on how to handle this new client onboarding with the ability to see and forecast which onboarding is green, yellow or red.
  • Implement a client-focused timeline expected deliveries that will allow us to communicate when we need what from the client on what date and work with sales to assure we have action plans made with emails and text messages that clearly communicates these expectations to the client.

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

Передо мной на испытательном сроке были поставлены следующие цели:

  • собрать все задачи и зависимости, необходимые для введения клиента в бизнес (введение клиента в бизнес — это проект);
  • задокументировать проблемные моменты в roadmap проекта и определить возможные улучшения процесса;
  • документировать структуру введения новых клиентов с возможностью видеть и определять риски проекта;
  • внедрить ориентированные на клиента майлстоуны ожидаемых поставок, которые позволят понимать, когда нам нужно что-то от клиента и на какую дату.
Если вы ничего не поняли из того, что сейчас происходит, это абсолютно нормально. Потому что у меня была точно такая же реакция. Когда мне в первый раз показали эти четыре тезиса, я вообще не понял, чего от меня хотят. Это сверхраспространенная ситуация, когда на испытательном говорят: «Слушай, ты должен разобраться с тем, почему у нас есть проблемы». И ты обещаешь разобраться, хотя KPI тебе не озвучили.

Я попытался понять, что конкретно от меня хочет лицо, принимающее решения, и начал задавать ему уточняющие вопросы:

Я: Какой процент существующих проектов сейчас реализовываются не в срок?

Он: Ну, половина проектов решается не в срок.

Я: Почему?

Он: Потому что никто не знает, кто что делает.

Я: Как команда работает сейчас? Можете описать процесс?

Он: Я получаю фидбек от клиента, кидаю это в команду, и она дальше сама самоорганизовывается, потому что мы работаем по SCRUM.

Я: Есть ли какие-то риски?

Он: Есть риск, что один из модулей, который мы реализовываем, займет больше времени.

Я: Из-за чего заваливаются дедлайны?
......

То есть какого-то четкого объяснения того, что происходит, нет — и вы, если, конечно, позволяет ситуация, должны приблизительно, на первичном уровне разобраться с причинами.

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

Чего хочет CEO на самом деле

  • 90% клиентов должны получать реализованный проект в срок (было 50%).
  • Каждый модуль должен быть задокументирован (длительность + риски + зависимости), определен минимальный и максимальный срок поставки (сейчас команда делает задачи по копипасте переписки с клиентом).
  • Процент переработок на каждом проекте должен быть не более 40% (сейчас 80%).
  • Команда должна наглядно видеть существующий прогресс по проекту (сейчас его нет).

Согласитесь, такое определение более понятно описывает мои обязанности как PM-а.

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

Далее, переходим к этапу получения фидбека от команды.

В обязательном порядке познакомьтесь со всеми

Я понимаю, что сейчас «познакомиться со всеми» звучит максимально банально. Но под этим я подразумеваю не только познакомиться с коллегами, но и понять:

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

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

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

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

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

Пример из моей жизни

Фидбек команды

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

Раскрою суть нескольких кейсов:

Команды заваливают дедлайны, потому что не знают актуального прогресса по всем модулям. Давайте представим, что мы делаем iOS приложение, Android приложение и backend. Одни не начинают задачу, потому что думают, что бэкенд еще не готов, а другие, наоборот, начинают делать задачу слишком рано, и получается, что все постоянно сталкиваются друг с другом, не понимая, что делать.

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

Разобрались с обратной связью от команды? Идем дальше.

Досконально изучите процесс

Вы должны понять, как вообще происходит последовательность процессов на проекте.

Как происходит переход задачи из созданной в завершенную, то есть какие вообще есть статусы. Условно, она приходит в статус to do, потом в in progress, code review, test, и в done. Где она может задерживаться? Отслеживаем каждый из периодов:

  • между тем, как разработчики закончили делать тестирование или на code review;
  • какие моменты бывают, как часто возвращают задачи на доработку, почему возвращают.

Параллельно с этим процессом можно изучить какие-то граничные кейсы.

На последнем проекте мы обратили внимание, что очень часто задача уходит в rework из-за того, что бизнес-сторона нечетко объясняет разработчикам, что нужно делать, разработчики нечетко выполняют эту задачу, и после того как код прошел code review и тестирование, оказывается, что есть проблема с тем, что разработчики сделали что-то не то. Особенно это касается каких-то больших CRM, e-commerce, интернет-магазинов.

Поэтому осматриваем полный путь, определяем проблемы, ищем узкие места.

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

Для бэкенда реализация каждой задачи оказывалась достаточно медленным процессом, и в какой-то момент на одном из статусов задач для бэкенда я увидел практически экспоненциальный рост. То есть в in progress у него находилось 20 задач, что прям совсем плохо, в to do — 100 задач, в code review — 2, в тесте — 3, и так далее. В тот момент я понял, что:

  • разработчика отвлекают;
  • у него накапливается очень много работы, и он попросту не успевает ее сделать.

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

Как это выглядело на деле

Процесс на проекте в данный момент

  • Sales опрашивает клиента, в результате чего получает список требований.
  • Sales отправляет сообщение команде.
  • Команда не знает, кто над чем работает.
  • В последний день оказывается, что X не хватает, sales связывается с клиентом.
  • Клиент недоволен.
  • Оказывается, что X не такой, как обычно, и требует +Y времени.
  • Клиент недоволен.
  • Проект готов.
  • Клиент недоволен, потому что это не то, чего он хотел.

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

Определите основные проблемы

Соберите в список все операционные и функциональные проблемы, которые существуют на проекте, после чего сделайте суммарный обзор 1-го и 2-го пункта/ Определите, какие из проблем связаны непосредственно с вашими KPI, и сформулируйте их.

Как это может выглядеть на деле

Если говорить о моем кейсе, я понял, что, скорее всего, вот эти моменты (о которых я упомянул выше) в процессе выглядят достаточно слабыми и, соответственно, повлияют на мой KPI. Например, бэкенды обещают сделать что-то за 10 часов, а делают за 20. Из-за этого они не успевают поставить фичи в срок, а клиент не получает свою функциональность в нужное время.

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

Составьте экспертизу

Соберите заметки в отчет и представьте его руководству с комментарием: «Я заметил вот такие проблемы». Сформулируйте в отчете план действий на время вашего тестового периода: «Тестовый период у меня три месяца. За первый месяц, помимо своей основной деятельности (sprint planning, daily scrum...), я собираюсь исправить вот эти проблемы, так как они непосредственно связаны с моими KPI». Узнайте у руководства, что они думают по поводу вашего плана, скорректируйте задачи и двигайтесь дальше. Такой подход работает практически во всех ситуациях.

Как это выглядело на деле у меня

Составляем алгоритм действий. Что нам нужно для того, чтобы исправить проблемы в процессах? В моей ситуации я понял, что нужно реализовать около 15 модулей. Каждый модуль — фича на восемь часов.

Пример действий

  1. Что нужно для реализации проекта (условно):
    • Фича 1
    • Фича 2
    • ....
    • Фича 12
  2. Какие зависимости есть у фич, есть ли риски:
    • 1 -> 7
    • 2 -> 10
  3. Какие фичи требуют дополнительного времени:
    • Фича 1 -> 30 часов
    • Фича 2 -> 10 часов (остальное в рамках дня)
  4. Можно сгруппировать задачи и разбить их на несколько этапов (например, три).
  5. Клиент видит результат каждого этапа, вносит свои правки.
  6. PM запрашивает дополнительные детали в начале следующего этапа.
  7. PM ежедневно синхронизирует команду по прогрессу, команда видит прогресс в Jira.

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

В начале каждого этапа РМ запрашивает дополнительные детали. Он ежедневно синхронизирует команду по прогрессу, который отражен в Jira. Это очень простое схематическое объяснение того, как можно докопаться до проблем, которые есть на проекте, и повысить метрики, по которым вас будут оценивать.

Как вас будут оценивать после окончания испытательного

На что будут смотреть в конце

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

Иногда вы даже не всё успеваете сделать, но создаете ощущение того, что вы добиваетесь прогресса, а еще люди чувствуют, что вы растете, предлагаете что-то новое. Это тоже очень значимо.

Как это выглядело на деле в моем случае, и к чему мы пришли в итоге

Результаты испытательного из примера

  • 90% клиентов получили проект в срок (нужно 90%).
  • Проекты были декомпозированы на 12 подзадач, определен проектный план.
  • Процент переработок по этому направлению разработки снизился до 30%.

По результатам испытательного периода 90% клиентов получили проект в срок. По этому критерию я прошел. Хотя через год процент опять упал :(. Но это уже другая история.
Проекты были декомпозированы на 12 подзадач, определен проектный план. Процент переработок по этому направлению разработки снизился до 30%. То есть итог моего испытательного срока получился вполне достойным.

Конечно, порой сделать можно далеко не все. Бывают моменты, когда непосредственно руководство должно поменять что-либо в устройстве процессов. Особенно когда вы взаимодействуете с другими командами и отделами.

В моменты, когда никто не шел на уступки, я просил мнение и экспертизу от CEO по поводу того, как он видит реализацию этой задачи, и пытался максимально безболезненно реализовать все согласно его видению, если это не совсем плохое видение :)

Это не всегда работает, но когда вы понимаете, что какое-то рациональное решение внедрить невозможно, не нужно конфликтовать! Лучше аргументированно подсказать, что и как можно сделать лучше. Не получается? Ищите компромисс.

Что, если тестовый продлили

У меня бывали такие ситуации. В этом нет ничего страшного.

Иногда это мотивация

То есть вам продлили тестовый период, потому что хотят еще немного замотивировать. Это не очень хорошо, но вполне нормальная ситуация. Я сталкивался с таким.
Иногда вы как работодатель понимаете, что человек чуть-чуть не дотягивает, но у него есть все шансы стать частью команды через месяц, и почему бы просто не дать ему эту возможность?

Тестовый могут продлевать из экономических соображений

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

Что, если вы не прошли тестовый период

И в этом тоже нет ничего страшного.

Это может означать

  • Вы не понравились руководству.
  • Ваш культурный код отличается.
  • Вам не хотят повышать зарплату.
  • Вас не «видят» на этой позиции.
  • В вас нет нужды.

У нас в компании бывало, что человек проходил тестовый период, и в итоге мы не понимали, зачем он нам нужен дальше. Это на самом деле хуже.

Сначала мы решили, что нам нужны два frontend developer-a, а в итоге оказалось, что у них больше времени уходит на синхронизацию между собой, чем на работу, которой было недостаточно. И в итоге пришлось сказать: «Слушай, так получилось, что у нас сейчас нет нужды во фронте. Поэтому, ну... извини». Иногда люди это понимают, но кто-то может справедливо обидеться.

Бывают случаи, когда вы просто не понравились руководству, или команде, или кому-нибудь еще. Это уже другой вопрос. Вообще не стоит обращать на это внимание. Просто двигайтесь дальше. Даже если вы очень хотели работать в этой компании.

Выводы

  1. Испытательный — это обычная практика в IT.
  2. Выясните измеряемые KPI, по которым вас будут оценивать в итоге.
  3. Соберите фидбек о себе.
  4. Коммуницируйте с командой, вводите их в курс дела на проекте.
  5. Услышьте все точки зрения.
  6. Старайтесь разобраться в самой главной боли и пытайтесь раскручивать ее, а не вечно бороться с синдромами.
  7. Демонстрируйте результаты своей работы до того, как вас о них спросят.
  8. Если испытательный продлили — пытайтесь выяснить причины. Если это — мотивация, ничего страшного, если экономические проблемы в компании — повод задуматься.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному7
LinkedIn

Схожі статті




10 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Благодарю, — хоть и, честно говоря, пробежалась глазами, детально не вчитываясь. Более чем очевидно то, что вы сами заметили: неумение чётко сформулировать, кто что хочет, почему и для чего. А главное, как собирается достичь того, чего хочет. В итоге подготовка проекта занимает месяцы вместо недель. Я уж не говорю о днях, которые в подобной атмосфере считаются космической скоростью. «Не видят», «нет нужды» и «доктор, я вас не понимаю» — симптомы одной болезни, которой сам доктор (то бишь, РМ) вполне способен дать чёткое название: «Ребята, вы планктоните. Прекращайте сливать деньги клиента, он вас за это не поблагодарит». Попробуйте встряхнуть утятник. Потом поделитесь эффектом.

Спасибо, интересная статья.

Достаточно полный список для испыталки для проджект менеджера, правильно расставлены акценты.

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

Для проджект менеджеров присоединение к уже сформированной корпоративной культуре происходит сложнее, чем для технических специалистов по различный причинам. Хороший и надежный вариант — ростить прождект менеджеров в своей культуре. О том, что для своего менеджера само собой разумеещееся, новый — может и не догадываться. Профессия такая, мы ее сами выбираем. Если что-то пошло не так и одни двери закрываются, другие открываются.

Кратко:
Докопаться все-таки, какие ожидания от твоей работы.
Соответствовать этим ожиданиям.

Статья интересная. Но, всегда были проблемы с определением KPI. Должен быть опыт как у менеджера, так и у организации.

Крутая статья. Испытательный срок — страх даже для специалистов с опытом.

Что бы пройти любой испытательный срок досточно одного: в***ывать. Все остальное от лукавого.

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

бывает еще так, что польза есть, но в зачет она идет другим (потому как это их задачи). а тебя нанимали для другого и там полное фиаско

Что, если вы не прошли тестовый период
И в этом тоже нет ничего страшного.

Это может означать
Вы не понравились руководству.
Ваш культурный код отличается.
Вам не хотят повышать зарплату.
Вас не «видят» на этой позиции.
В вас нет нужды.

а где «вы завалили свои КПИ»?

Ну и да, вы завалили свои KPI тоже конечно :). Вы правильно заметили.

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