Бесплатный фрагмент - Команда как продукт

ВВЕДЕНИЕ

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

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

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

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

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

— — — — — — — — — — — — — — — — —

Кейс: из каменного века в век цифровизации

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

Мы начинали свой путь в одной крупной компании федерального масштаба, в которой на тот момент насчитывалось более 300 тыс. сотрудников по всей стране. Это была компания, которая располагала собственной ИТ-инфраструктурой и решениями, но на тот момент это больше напоминало 20-е годы и всем в то время привычный синий экран в стиле Norton’а и окон от Windows 98. Обслуживать цепочку взаимосвязей на уровне всей страны — тяжелейший труд, но команде компании удалось добиться в этом огромных успехов. Но сейчас мы поговорим немного о другом.

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

Не сказать, что это был совсем каменный век в области цифровизации, но о UX и API в то время точно никто еще не думал, как и об оптимизации процессов на уровне всей компании. А деревянные счеты порой не вызывали агрессивной реакции у сотрудников. Это интересное для нас состояние и стало отправной точкой для начала работы.

Биллинг 1.0

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

По итогам работы нашей команды уровень цифрового взаимодействия вышел на очень высокий уровень и достиг 70% в части взаимодействия b2b клиентов с компанией через WEB, а уровень внутренней оптимизации процессов и оцифровка работы сотрудников компании позволили поддерживать этот уровень на должном качественном уровне. Внутренняя CRM система обеспечивала моментальное заключение договора оферты с новым клиентом, давала плавный переход в личный кабинет компании и старт работы уже в течение 24 часов, когда ранее на это уходило до 1,5 месяца.

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

— — — — — — — — — — — — — — — — — — — —

ПРЕДИСЛОВИЕ

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

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

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

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

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

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

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

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

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

Специально для наших читателей мы создали отдельный Телеграм канал @komandakakproduct для возможности общения и активной помощи в решении нестандартных ситуаций в работе команды.

ГЛАВА 1
ФОРМИРОВАНИЕ КОМАНДЫ
ㅤ
ㅤ

---

Структура продуктовой команды

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

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

Начнем наш разбор структуры команды с более административной части, если это можно так назвать.

— — — — — — — — — — — — — — — — — — — —

Кейс: владелец продукта — друг или начальник?

Суть: работая в окружении огромного количества команд, особенно в крупных компаниях, наблюдаешь очень интересную и в то же время очень грустную картину. Владелец продукта считает себя руководителем тех людей, кто работает над созданием продукта в продуктовой команде. Довольно часто встречаются два вида работы такой команды. Первый — когда владелец продукта является действующим административным руководителем, например занимает должность руководителя отдела или направления, а в его подчинении находятся все участники команды. Второй — когда владелец продукта является внешним сотрудником для команды продукта, как и все ее участники, например вертикаль дизайна или тестирования, разработки, а может и аналитики. В таком случае команда собирается под продукт из разных доменов и начинает работать над созданием продукта, после чего с большой долей вероятности переключается на следующие продукты, а иногда и вынуждена отключаться или переключаться на другие задачи вертикали. В первом варианте владельцы продукта допускают очень частую ошибку — ставят себя руководителями, а не членами команды. Кто такой владелец продукта в команде, спросишь ты. Да все просто: такой же сотрудник в команде, выполняющий множество задач, связанных с созданием или развитием продукта, общением со стейкхолдерами, планированием и стратегий и т. д. Так почему он руководитель? Он скорее проводник команды и капитан корабля, движущийся к достижению поставленных целей. Это очень тонкая грань: быть в меру руководителем и одновременно быть другом наравне со всеми, кто совместно с владельцем продукта создает ценность.

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

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

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

— — — — — — — — — — — — — — — — — — — —

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

— — — — — — — — — — — — — — — — — — — —

Кейс: техлид и тимлид в одном лице — такое возможно?

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

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

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

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

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

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

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

— — — — — — — — — — — — — — — — — — — —

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

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

---

Поиск и найм команды

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

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

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

— — — — — — — — — — — — — — — — — — — —

Кейс: системный и бизнес-аналитик в одном лице

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

Именно тут и кроется распыление активностей в аналитике. Если быстро перейти к проработке системной аналитики, не уделив должного внимания самому процессу, то впоследствии это превращается в ряд доработок после обсуждения с владельцем продукта или проведением внутреннего демо для бизнес-заказчика. А все потому, что не учтены специфические нюансы бизнеса и, как следствие, процесс, дальнейшее описание работы системы и ожидаемый после разработки результат являются ложными. К сожалению, такие вещи несут под собой не только double costs для команды и компании, но и сильно увеличивают time to market для критических для бизнеса фичей. А теперь представьте ситуацию: в Сибири появился новый логистический хаб, куда свозят товары крупнейшие поставщики из Китая или других стран. В ритейл-компаниях появляется задача оптимизации логистики до конечных клиентов, которая учитывает изменение маршрутов с учетом наличия ассортимента на новом складе. Если поддержку такой бизнес-фичи затянуть, то конкуренты, оптимизировав доставку раньше, смогут снизить цены на товары в своих интернет-магазинах и, как следствие, для тебя и твоей компании это будет потеря GMV и просадка по остальным бизнес и продуктовым показателям.

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

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

— — — — — — — — — — — — — — — — — — — —

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

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

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

— — — — — — — — — — — — — — — — — — — —

Кейс: дизайнер или продуктовый дизайнер

Суть: нам неоднократно приходилось сталкиваться с очень частым кейсом: «нарисуй баннер», «сделай иконку», «сюда надо картинку придумать» и т. п., да еще и в очень короткий срок, потому что компания, оказывается, «завтра» планирует запустить какую-нибудь акцию или рекламную кампанию. Конечно же, в продуктовой команде никогда нет выделенного ресурса в виде графического дизайнера, а если такое и встречается, то это нетипичная ситуация и считай тебе повезло. Графический дизайн в компании — это обычно отдельное подразделение, ресурсы которого распределяются на все активности компании и быстро получить там специалиста, как правило, невозможно. Что происходит в таких случаях? Владелец продукта обращается к продуктовому дизайнеру и просит помочь в решении этого вопроса. Почему это плохо? Да все просто на самом деле: продуктовый дизайнер обычно занят созданием нового клиентского пути по одной или нескольким приоритетным фичам, взаимодействует с потенциальными пользователями, исследует, формирует CJM. Вторгаясь в этот процесс, ты очевидно нарушаешь его, заставляешь человека переключиться на не типичную для него работу, которую он, если сделает классно, то пожертвует основными активностями и ты проиграешь в другом месте, закрыв текущую потребность. Но это лишь вершина айсберга. Если продуктового дизайнера постоянно загружать такой работой, то он просто выгорает, как и любой другой специалист, которого заставляют работать над непрофильными задачами. Береги продуктовых дизайнеров, без них ценность твоего продукта станет намного меньше, а проверка любой гипотезы через R&D гораздо дороже.

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

— — — — — — — — — — — — — — — — — — — —

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

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

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

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

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

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

— — — — — — — — — — — — — — — — — — — —

Кейс: тестировщик или разработчик — кто первый?

Суть: мы смогли поработать как в нескольких крупных компаниях, так и в стартапах, что позволит рассказать об особенностях работы с тестированием под разными ракурсами. Начнем, пожалуй, со стартапов. Работа в стартапе характерна совмещением нескольких функциональностей в одной роли, это может быть как две, так и три роли в одном участнике, ведь задача стартапа быстро собрать MVP продукта и показать его конечному потребителю, чтобы проверить гипотезу и CVP, которые необходимо донести. Если собирать стартап командой, уровень которой ниже чем middle+ / senior, то шанс попасть в те самые девять из десяти погибающих стартапов становится выше, ведь правильно заложенная архитектура продукта — это залог его успешного масштабирования в дальнейшем, а если речь идет об использовании одного бэкенда для web-приложений и мобильных приложений, то ценность высококвалифицированных специалистов на ранних стадиях становится еще выше. В ситуации, когда собирается стартап, функционал тестировщика минует множество бюрократических аспектов крупных компаний, и создания большого количества артефактов от тестирования также не требуется. Это значит, что тестировщик вполне может приступать к работе только после того, как готов первый блок функциональности, который можно проверять, сверять с макетами или требованиями и заводить дефекты. Раньше, чем есть первая кодовая база, привлекать тестировщика на стартап совершенно бессмысленно, если только у вас нет лишнего бюджета или желания вовлечь тестирование в процесс пораньше.

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

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

— — — — — — — — — — — — — — — — — — — —

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

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

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

---

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

Если говорить о новой команде или стартапе, то важно оценить ритм, в котором необходима поставка ценности бизнес-заказчику или стейкхолдеру. Если нужен агрессивный ритм, а обычно это именно так и бывает, то без специалистов с уровнем не ниже 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 и кандидатами, следи за воронкой специалистов и оперативно реагируй на появление в ней интересных для тебя людей.

— — — — — — — — — — — — — — — — — — — —

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

---

Требования к кандидатам и условиям работы

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

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

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

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

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

Что касается поиска владельца продукта, давайте для начала сформулируем общее понимание, что такое продукт. Наиболее емко продукт — это система, создающая ценность, которая состоит из команды людей, бизнес-процессов и инструментов для их исполнения. У продукта есть владелец, а если несколько продуктов управляются одним человеком, то во главе обычно стоит Chief Product Officer, который отвечает за группу продуктов со своими владельцами. Разберем подробнее, кто же такой владелец продукта и чем он занимается.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— — — — — — — — — — — — — — — — — — — —

Кейс: рост владельца продукта из junior в senior?

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