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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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