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

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

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

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

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

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

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

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

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

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

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

Ротация

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

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

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

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

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

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

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

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

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

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

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

Перспектива

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

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

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

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

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

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

Какие 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 у меня трансформировались в:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Соберите в список все операционные и функциональные проблемы, которые существуют на проекте, после чего сделайте суммарный обзор 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% клиентов получили проект в срок. По этому критерию я прошел. Хотя через год процент опять упал :(. Но это уже другая история.
Проекты были декомпозированы на 12 подзадач, определен проектный план. Процент переработок по этому направлению разработки снизился до 30%. То есть итог моего испытательного срока получился вполне достойным.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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