Читать книгу: «Команда как продукт. Практическое руководство по созданию и управлению продуктовой командой в IT», страница 2

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

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

– — – — – — – — – — – — – — – — – — – —

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

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

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

Особенности найма в стартап или новую команду

Если говорить о новой команде или стартапе, то важно оценить ритм, в котором необходима поставка ценности бизнес-заказчику или стейкхолдеру. Если нужен агрессивный ритм, а обычно это именно так и бывает, то без специалистов с уровнем не ниже Senior просто не обойтись, ведь некогда погружать людей, тратить ресурс на обучение и адаптацию – есть конкретный скоуп задач, которые приведут тебя и твой продукт к заданной цели. Собирать команду стартапа с жесткими сроками из специалистов другого уровня практически бессмысленно, выживает всего один из десяти стартапов и срок его выхода на рынок зачастую играет ключевую роль. Стартапы, которые не требуют жестких сроков реализации, а делаются в спокойном режиме, вполне себе могут быть собраны специалистами уровня middle или middle+, но с точки зрения комплексных архитектурных решений, потенциала масштабирования продукта и его кроссплатформенности лучше иметь в команде хотя бы одного специалиста уровня senior.

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

– — – — – — – — – — – — – — – — – — – —

Кейс: джун или мидл – кто принимает решение?

Суть: был в нашей жизни очень запоминающийся кейс. Мы пришли на интервью кандидата в разработку в нашу первую большую команду. Тут, конечно, стоит отметить, что команда была и правда большая – на тот момент в ней было уже более 20 человек, включая аналитику, дизайн, разработку и тестирование. Стали общаться с человеком, разбираться в его ценностях и стремлениях, затронули несколько вопросов по технической части, несмотря на то что техническое интервью было проведено ранее. Беседа длилась больше часа, что позволило кандидату хорошо погрузиться в особенности работы нашей команды, в цели и задачи продукта, который ему предстоит развивать, а главное – была проведена оценка потенциала и желания роста и развития кандидата. Обратная связь от технического собеседования была следующая: кандидат уверенный джуниор. В процессе общения с кандидатом стало понятно, что он далеко не джуниор, а очень перспективный мидл-разработчик. Система оценок на техническом интервью в разных компаниях весьма специфическая: кто-то смотрит на опыт, количество лет на позиции, участие в энтерпрайз-проектах, а кто-то гоняет кандидата по всем особенностям и тонкостям конкретной позиции. Есть еще один важный аспект: на интервью, особенно техническом, кандидат волнуется и переживает, и его реальные знания и полученные в процессе диалога ответы очень часто отличаются. Важно помнить об этих особенностях, когда ты собираешь свою команду.

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

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

– — – — – — – — – — – — – — – — – — – —

Особенности найма в действующую команду

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

Еще на этапе воронки нужно очень внимательно рассматривать кандидатов под разными углами, ведь даже начинающий аналитик, тестировщик или разработчик может прокачаться в проекте буквально за несколько месяцев. Если у кандидата есть только базовые знания, но очень сильная тяга к знаниям, обучению, саморазвитию и росту, то такой сотрудник впоследствии может оказаться намного ценнее нанятого с рынка Senior-специалиста. Почему? Да все просто. Когда Senior-специалист приходит на новый проект, у него, по сути, два пути – просто быть разработчиком/аналитиком/тестировщиком и т. д. и заниматься развитием или созданием функционала продукта или сразу развиваться в руководящую позицию. И первое, и второе для тебя плохой сценарий, потому что срок, на который хватает такого специалиста в проекте, варьируется обычно от полугода до года. Далее создается напряжение и попытки выбрать между новым проектом или переходом в руководящую позицию. Период в несколько месяцев, безусловно, обеспечит буст развития продукта, но потом появляются другие сложности – бас фактор. Как бы странно это ни звучало, но вам всегда стоит думать над вопросом – какое количество участников моей команды, при «попадании которых под автобус» (bus factor), проект не сможет быть завершен оставшимися сотрудниками. Именно специалисты высокой квалификации оказывают влияние на этот фактор, и отключение одного, а тем более нескольких таких специалистов от продукта может нанести всему проекту колоссальный урон.

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

– — – — – — – — – — – — – — – — – — – —

Кейс: круговорот специалистов в IT

Суть: при переходе из одной компании в другую нас ожидал очередной сбор продуктовой команды под ключ для создания нескольких продуктов. Символично получилось, что в эту компанию нас позвала коллега, с которой мы ранее работали вместе и она помогала создавать нам продукты для бизнеса. Сбор команды мы, конечно же, начали с аналитики и дизайна, но в этом кейсе мы расскажем про аналитика. Так получилось, что вместе с нами в предыдущей команде рос и бизнес-аналитик, приумножая свои компетенции в этой области, и первым делом мы позвали его к нам. Прошло буквально две недели и аналитик уже вышла на свою новую работу вместе с нами делать новый продукт для новых пользователей. Специалист проработал в предыдущей компании много лет и настолько проникся существующей там атмосферой, что старт работы в новой кампании, новом коллективе оказался непосильным трудом, и нам всем пришлось сделать шаг назад. Аналитик вернулся в предыдущую компанию, но уже на другой проект, а мы в это время нашли другого аналитика. Связи в наше время, да еще в таком тесном мире, как IT, конечно, многое решают. С уходящим аналитиком мы заключили джентльменское соглашение по передаче знаний, которые были собраны на протяжении почти полутора месяцев. Договоренности действовали даже после ухода специалиста из компании в течение полутора месяцев. В итоге за более чем полтора года нашей совместной работы новый аналитик очень хорошо прокачалась и при переходе с нами в новую компанию уже стала полноценным владельцем продукта с соответствующей мотивацией.

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

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

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

– — – — – — – — – — – — – — – — – — – —

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

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

Итак, рассмотрим с вами следующую ситуацию. В компании поднимается приоритет по какому-то продукту и начинается агрессивный найм или замещение текущего состава команды по какой-то причине. Начинается оценка перформящих людей на разных позициях с целью произвести ротацию из менее приоритетных проектов в более приоритетные. У каждой продуктовой команды есть свой дух, своя волна и зависимости людей друг от друга, поддержка и взаимовыручка. Как только одно звено этой цепочки разрывается, это начинает инерционно накладывать одну проблему на другую. Тут появляется проблематика не только со стороны команды, но и со стороны самого сотрудника – его вырывают из привычной атмосферы и погружают в совершенно другие задачи и другую команду со своими устоями. Складывается впечатление, что человека можно просто вытащить из одной розетки и вставить в другую, снова включить и ждать, что ничего не изменится. А ведь это совсем не так. Есть разные люди со своими особенностями, которые, например, являются интровертами и уходит не один месяц, чтобы найти нужные подходы к человеку, нащупать области его максимальной вовлеченности и результативности. Периодически складывается такое ощущение, что об этих важных человеческих особенностях никто не задумывается в период ротации, так как обсуждение идет не на уровне людей, а на уровне отдельных FTE¹⁰. В чем же проблема не только для тебя, но и команды и, конечно же, компании? Да все просто, давай разберем подробнее. Человек, который долго привыкал к одной команде и как он сам, так и команда искали наилучшие точки соприкосновения друг в друге, переходит куда-то по инициативе компании. Это с высокой долей вероятности приведет к тому, что на новом месте он не уживется и уйдет, соответственно компания теряет человека, совершив очевидно недальновидный шаг. В этой ситуации команде HR придется искать уже двух человек, а командам погружать новых коллег в процессы и продукт, тратя ресурс специалистов внутри, и все это выливается в дополнительные затраты для компании, замедление развития продуктов и, как следствие, в снижение выручки или потенциальной выручки от работы продуктов.

– — – — – — – — – — – — – — – — – — – —

Кейс: нанять и уволить за три месяца

Суть: была у нас интересная ситуация, когда мы решили усилить команду в системном анализе и открыли найм на эту позицию. Это были 2019—2020 годы и тогда на рынке было сложно с хорошими системными аналитиками, которые действительно обладали хорошим и разносторонним опытом, и нам пришлось снизить ожидания от кандидата, рассмотрев уровень Middle-специалиста.

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

Взвесив все «за» и «против», мы приняли решение взять кандидата на испытательный срок и проверить его в деле. Некоторые сомнения в нем, конечно, были, но уровень знаний в системной аналитике был достаточно уверенный, а нам нужно было оперативно усиливать команду. Две недели за кандидатом присматривали лишь коллеги по цеху, погружая его в процессы и в продукт, а дальше кандидат перешел к самостоятельной работе. Основная проблема как раз и крылась в самостоятельности и желании биться за продукт, понимая, какие цели стоят как перед продуктом, так и перед всей продуктовой командой. Спустя месяц качественных результатов работы не наблюдалось, и в команде стали внимательнее присматриваться к тому, что делает сотрудник. Смотрели на его активности, проводили ревью созданных артефактов, и к концу второго месяца стало понятно, что человек просто просиживает время. Как и полагается, мы встретились с ним разобрать ситуацию и проблему, договорились о способах ее разрешения и сформировали новые цели и сроки. Таких встреч с сотрудником, к нашему большому сожалению, было две, после второй встречи мы так же разобрали его типичные ошибки и проблемы в работе, попытались понять, что мешает человеку качественно выполнять свою работу, но блокеров не выявилось. Пока мы «нянчились» с сотрудником, чтобы найти способ взбодрить его и направить на результативность, проскочил испытательный срок, мы в потоке как-то пропустили этот момент, пытаясь наладить работу.

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

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

– — – — – — – — – — – — – — – — – — – —

Поиск нового сотрудника – это всегда не быстрый процесс, требующий максимального вовлечения как менеджмента продуктовой команды, самой команды и всех ее участников и HR¹¹ подразделения. В нашей практике участие HR-специалистов в найме команды часто было минимальным. Почему так сложилось, сложно сказать, вероятнее всего, это длительный срок поиска кандидатов, бэклог на найм и многое другое. Если говорить о процентном соотношении людей, которых мы пригласили в команду с рынка через HR-специалистов, то это не более 10% от общего числа. Возможно, это не совсем стандартный подход, но ты же собираешь команду мечты – сильную продуктовую команду, нацеленную на результат, а значит, стандартные подходы работать не будут практически никогда. Конечно, всегда есть исключения, и пусть ты как раз попадешь в число везунчиков, но мы предлагаем посмотреть на это с другой стороны.

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

– — – — – — – — – — – — – — – — – — – —

Кейс: как нанять разработчика за шесть месяцев?

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

Заведение заявок на найм не сопровождалось чем-то особенным, все стандартно, заполнили потребности, описали требования к кандидатам и передали в рекрутмент все потребности. Дальше все происходило максимально медленно и на это было, конечно же, несколько причин. Первая причина – агрессивный найм в компании и, как следствие, большой поток запросов от продуктовых команд. Вторая причина – внутренняя конкуренция. Разберем сначала агрессивный найм и его влияние на результаты найма в команду. Агрессивный найм всегда сопровождается масштабной активностью на стороне HR-специалистов, всегда сопровождается большой нагрузкой вакансий на одного специалиста и очевидным переполнением капаситета. Скорость роста HR-специалистов всегда будет медленнее, чем скорость генерации запросов на найм в такой период. В итоге поток обрабатывается существенно медленнее, появляются приоритеты найма в конкретные команды, на которые сделаны ставки в компании, и если твой продукт в этот период не попал в ТОП, то по твоим задачам работы будут проводиться в последнюю очередь. Повлиять на этот процесс ты скорее всего не сможешь, его придется принять или бороться за попадание в ТОП, объясняя свою потребность понятными метриками и целями. В период агрессивного найма всегда происходит замедление в подборе и скорость закрытия вакансий сильно снижается. Зачастую мы слышим слова, что мы наняли несколько десятков или сотен человек за месяц и выполнили KPI сверх нормы, но с кем бы в продуктовых командах не приходилось общаться, никто этих результатов не подтверждал. Если учесть, что некоторые специалисты на рынке попадаются крайне редко, как правило, их мониторят крупные компании и делают one day offer, забирая с рынка одним днем, то промедления в найме на такие позиции заведомо приводят к негативному результату.

Что касается внутренней конкуренции в компании, это еще один камень преткновения для тебя, ведь когда достойный кандидат успешно проходит первичный и технический скоринг, за него начинается борьба уже внутри продуктовых команд. Вот эта ситуация и должна стать для тебя драйвером для быстрого найма. Ты хорошо знаешь продукт и его особенности, знаешь, к каким целям нужно прийти и каких результатов достигнуть. Если проект является еще и социально значимым для b2c или b2b сегмента, то мы говорим о масштабе и важности продукта уже в широкой аудитории. Кандидаты очень любят работать на проектах, где их результаты приносят значимую пользу людям и компании, когда каждая фича выражается в конкретных цифрах или позитивной обратной связи от конечных клиентов. Продай свой продукт, сделай это красиво и достойно, не говори о проблемах и сложностях, говори только о том, какой он крутой, какую ценность несет для пользователей, какие масштабные у него амбиции и как быстро он будет развиваться и кандидат вместе с ним. Расскажи о возможностях роста в компании и о том, какая уже собралась классная команда, в которой каждый готов помогать для достижения общего результата. Этим можно в достаточном количестве случаев замотивировать кандидата, и он обязательно выберет твой продукт, а не чей-то другой. Таким образом, эта причина полностью контролируема: подготовься как следует к продаже своего продукта и команды кандидату и с каждым новым разом это будет проходить уже на автомате.

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

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

– — – — – — – — – — – — – — – — – — – —

Кейс: найм в период реорганизации?

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

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

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

– — – — – — – — – — – — – — – — – — – —

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