Книга Команда как продукт. Практическое руководство по созданию и управлению продуктовой командой в IT - читать онлайн бесплатно, автор Владимир Александрович Пулион. Cтраница 3
bannerbanner
Вы не авторизовались
Войти
Зарегистрироваться
Команда как продукт. Практическое руководство по созданию и управлению продуктовой командой в IT
Команда как продукт. Практическое руководство по созданию и управлению продуктовой командой в IT
Добавить В библиотекуАвторизуйтесь, чтобы добавить
Оценить:

Рейтинг: 0

Добавить отзывДобавить цитату

Команда как продукт. Практическое руководство по созданию и управлению продуктовой командой в IT

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

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

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


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

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


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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

Примечания

1

UX – user experience – «пользовательский опыт».

2

API – Application Programming Interface – программный интерфейс, с помощью которого приложения, веб-сервисы и программы обмениваются информацией.

3

GMV – Gross Merchandise Value – общий объем оборота товаров.

4

CVP – Customer Value Proposition – ценностное предложение покупателя.

5

CPO – Chief Product Officer – «Директор по продукту».

6

CJM – Customer journey map – карта пути клиента.

7

R&D – Research and development – исследования и разработка.

8

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

9

Growth hacking – «хакерство роста», или «взлом роста».

10

FTE (Full-Time Employee) – сотрудник, работающий при полной занятости.

11

Human Resources – HR-специалист – сотрудник, который управляет человеческими ресурсами в компании.

Вы ознакомились с фрагментом книги.

Для бесплатного чтения открыта только часть текста.

Приобретайте полный текст книги у нашего партнера:

Полная версия книги

Всего 10 форматов