Евгений Савин, менеджер продуктов в «Яндекс.Еде», рассказал, как выстраивать отношения с командой разработки и какие технические навыки прокачать, чтобы быстрее решать свои задачи.
Сейчас я больше всего взаимодействую с командой backend-разработчиков. За это время я наметил себе определенную систему и для удобства делю разработчиков на три типа:
- Погруженные в продукт. Они хотят видеть результат своего труда и делать что-то непосредственно для пользователей. С ними удобно обсуждать продуктовые идеи, они быстро загораются, способны найти главные сценарии использования, подсказать какие-то решения, которые могут не прийти в голову менеджеру продуктов.
- Погруженные в технологии. Их больше интересует тайминг, чтобы сервис работал без сбоев, код был красивый. Они отлично понимают технический контекст, и когда перед ними есть четкая задача, качественно ее выполняют.
- Гибридный вариант. Они любят приводить в порядок технологии и хотят видеть результат своей работы в виде продукта.
Как поддерживать энтузиазм в команде разработчиков
Работа с техническими специалистами, которые аргументированно могут объяснить тебе, почему твоя идея 100% не будет работать, — это постоянный вызов для менеджера продуктов, а также отличный способ развить коммуникативные навыки и еще раз подумать, правильную ли задачу ты ставишь.
Допустим, вы говорите: «Я хочу построить звездолет, который работает таким-то образом — пользователю от этого станет хорошо, а мы вырастим такие-то метрики и получим такую-то выгоду». А в ответ слышите: «Нет, мы это сделать не можем, это слишком сложно. Давай вот тут обрежем, а тут упростим». И в какой-то степени разработчик прав: надо начать с MVP и провести A/B-тест. А если сразу сделать крутую штуку, потом наверняка придется править баги, изучать основные сценарии использования и т.п.
С другой стороны, если разработчик говорит, что на решение вашей задачи у него уйдут годы, значит, вы просто не смогли его увлечь проектом и он сделает все, чтобы сдвинуть сроки. Если же разработчик заинтересовался продуктом или сложной технической проблемой, он будет искать решения и делать так, чтобы все запустилось как можно быстрее.
Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.
Задача менеджера продуктов — дать разработчику тщательно продуманную и важную задачу, программный компонент, который потом не придется удалять. И обязательно продумайте, как будете улучшать свой продукт через неделю, месяц. Ведь если вы регулярно приносите свои задачи и потом много раз просите переделать результат, а разработчик вынужден удалять код и писать новый поверх старого — он оказывается в адской ситуации и демотивируется.
При этом все понимают, что менеджер продуктов постоянно тестирует гипотезы и отбрасывает нерабочие варианты. Поэтому заранее обсудите гипотезу с разработчиками, объясните, почему вы будете ее проверять, — они должны понимать, что делают. Это поможет сохранить их энтузиазм и вовлеченность Также с разработкой надо согласовать все метрики (что вы будете измерять, на что обращать внимание), а после эксперимента делиться результатами и рассказать, какие решения и почему отклонены, а какие будете прорабатывать дальше.
Большие задачи нужно реализовывать поэтапно. Сначала мы проверяем гипотезу и делаем ядро, функционал фичи. Затем создаем дополнительные фичи. Базовый функционал нужно обсуждать с разработчиками: даже если они из-за нехватки ресурсов могут реализовать только 80% из того, что вы хотите — это нормально. Главное, что разработчик доволен — а оставшиеся 20% новых функций вы постепенно добавите.
Разберем на примере. Допустим, вам нужно вывести текст на фотографию ресторана. Для этого необходим отдельный сервис. А еще надо выбрать ресторан, написать текст, решить, как он будет выглядеть. Получается двойная разработка: для клиента и для менеджера.
Как менеджер продуктов помочь разработчикам в такой ситуации? Имея даже минимальные технические навыки, он может написать простые скрипты и использовать их на этапе тестирования и изменения текста. Вы будете вносить все изменения напрямую, не обращаясь в бэк-офис. Если вы не умеете делать это сами, попросите программиста — он справится очень быстро. Не нужно добавлять новые поля, а потом удалять их за ненадобностью. Лучше сделать сырое решение, проверить его, и либо доработать, либо просто выбросить и больше к нему не возвращаться.
Еще разработчики помогают менеджеру продуктов увидеть, что и где может пойти не так. Даже если я просчитал все пользовательские сценарии, ребята могут подсказать какие-то ситуации, которые я не продумал. Например, они могут спросить: «А что ты будешь делать, когда после изменения этой фичи в такой-то API нашего сервиса произойдет такая ситуация?» Если вопрос по делу, я ухожу и пытаюсь найти другое продуктовое решение, которое потянет за собой новые технические особенности. В итоге вы вместе с руководителем команды разработчиков приходите к компромиссу: какие минимальные усилия требуются от его команды, чтобы доработать продукт для пользователя.
В этом случае полезно взглянуть на продукт с точки зрения технических метрик, построить дашборды. Можно измерить нагрузку на разные экраны сервиса, сравнить время использования разных сервисов, и таким образом понять, что интересно людям. В аналитике мы видим более поверхностные метрики конверсии — например, MAU и DAU, а технические метрики позволяют отследить просадку и увеличение трафика каждые 10, 20, 30 секунд, каждую минуту и более глубоко понять поведение пользователя внутри продукта.
Какие технические навыки нужны менеджеру продуктов
Эта тема периодически всплывает в сообществе и вызывает много споров. Должен ли менеджер продуктов большого IT-проекта разбираться в том, как работает сам проект? Кто-то говорит — нет, кто-то — да. А правы и те, и другие.
Вы можете быть прекрасным менеджером и не понимать, как все работает. Однако, на мой взгляд, полезно иметь хотя бы базовые представления о том, как устроен интернет, ваш продукт, как циркулируют данные. В этом случае, продумывая новую фичу или продукт, вы будете лучше понимать, к какой команде обращаться, какой разработчик ответит быстрее, кто лучше понимает, какие изменения нужно внести, чтобы реализовать задачу, и сколько времени на это потребуется.
Если вам непонятно, как работает сервис, то после каждого мозгового штурма вы приходите к техлиду и спрашиваете его, как все устроено. В принципе, в этом нет ничего постыдного — но на это уходит много времени. Если вы хотя бы поверхностно разберетесь в технических вопросах, то сможете прорабатывать гипотезы гораздо быстрее. Хорошо, когда один человек способен и придумать идею, и довести ее до результата.
Не у всех менеджеров продуктов есть техническое образование. Однако многие навыки можно приобрести самостоятельно. По образованию я физик и инженер, не программист. Но когда начал работать с IT (сначала со стартапами, а потом и в «Яндексе»), прокачал навыки программирования. Расскажу, что помогает лично мне.
- SQL. Умение создавать базовые запросы, простые выгрузки, условия (WHERE) и JOIN-таблицы, зайти в базу данных и посмотреть, какой эффект принесла фича, сколько было кликов. Вам не нужно ждать, пока все это сделают аналитики, вы сами можете за пять минут построить график. Выучить SQL — просто, надо всего лишь пройти двухдневный курс на Stepik или YouTube. Затем пробуйте, просите коллег помогать вам с запросами и примерами. Постепенно вы набьете руку и у вас появится запас базовых шаблонных запросов.
- Базовое знание языка программирования. Python — самый простой язык. Достаточно пройти два-три курса Stepik за несколько выходных и создать примеры, чтобы научиться писать несложные алгоритмы и понять, что такое переменные и функции, как работают циклы.
- Для практики рекомендую использовать HackerRank. Там можно решать легкие задачи, получать баллы, подсматривать примеры решений, общаться с другими программистами. Так вы постепенно научитесь писать простые скрипты.
- Также рекомендую Jupyter Notebook — веб-интерфейс, который позволяет писать программы на Python без необходимости компилировать их отдельно. В нем можно проводить простые вычисления. Также пригодятся Pandas и NumPy. За полчаса, пока вы на работе завариваете утренний кофе, ваши данные выгрузятся, прокрутятся в Jupyter Notebook и, возможно, вы найдете себе гипотезу на день.
- Базовое знание работы архитектуры сервисов. Чтобы в общих чертах понимать, как работают IT-сервисы, я советую освоить Python Flask. Это очень простой пакет для запуска сайтов. Начальные знания можно получить на YouTube — посмотрите любой ролик «как создать собственный сайт за полчаса». Соберите сайт и запустите его на локальной машине. Так вы поймете базовые концепции: сервер, запросы POST и GET, HTML. Можно построить красивый сайт на Bootstrap — тогда почти не понадобится писать HTML-код. Я, например, за час создал утилиту, которая помогла мне тестировать фичу, на Flask и Bootstrap. Разработчикам, которые делают то же самое по корпоративным стандартам, потребовалось бы на это гораздо больше времени. Тестирование прошло успешно и мы сделали рабочую версию этой утилиты — но если бы она не взлетела, ее было бы легко удалить.
- Базовое знание продукта, над которым вы работаете. Регулярно общайтесь со техлидом, спрашивайте, как работает сервис. Сначала многое может быть непонятно, но со временем вы разберетесь во всех важных нюансах. К тому же техлиду будет приятно, что менеджер интересуется работой сервиса, хочет понять, почему разработчики делают продукт не очень быстро, какие технические проблемы существуют.
Если у вас есть эти навыки, вы будете говорить с разработкой на одном языке, быстрее и точнее делиться мыслями, идеями, гипотезами. В противном случае вы приходите к разработчику и говорите: «Сделай мне, пожалуйста, продуктовую фичу». Он отвечает: «Нет, мы не сможем ее сделать, потому что есть технические проблемы». Если вы не знаете, как работает сервис, диалог заканчивается: менеджер говорит в терминах продукта, а разработчик — в технических терминах. Задача менеджера — подогнать продукт под требования техлида, понять его и подстроиться, но ни в коем случае не вмешиваться в техническую часть и ничего не советовать. Придумывать решения за разработчиков — большая ошибка.
Эмпатия к разработке и общение с техлидом и тимлидом
У менеджера продуктов должна быть своего рода эмпатия к разработке — умение правильно подбирать слова, учитывать особенности архитектуры, понимать, что такое технический долг.
Однако при всем своем интересе к разработке он не должен терять главное — продуктовое мышление. Иногда я слишком глубоко погружаюсь в технические детали: думаю о том, как сложно создать новую фичу, где и что нужно доработать. Такие мысли не должны беспокоить менеджера продуктов, это все же ответственность техлида и разработчиков.
Я считаю, что чрезмерная эмпатия к разработке может вызвать неприятие сложных продуктовых фич. А без них сервис не будет развиваться. Не стоит позволять техническим ограничениям тормозить процесс развития — наоборот, надо учиться убеждать команду в их целесообразности.
Получается, с одной стороны, погружаясь в технические детали, вы можете эффективнее общаться с разработкой и быстрее добиваться результатов. С другой — нужно всегда быть настороже. Эмпатия к технологиям должна помогать, а не мешать развитию продукта.
Когда вы приняли продуктовое решение и подтвердили гипотезу, необходимо понять, что будет дальше — через неделю или месяц. Приведу аналогию: допустим, вас просят построить избу. И вы строите хорошую избу с фундаментом. А потом вам говорят: «Слушай, построй, пожалуйста, на этой избе еще 10 этажей». Вы добавляете 10 этажей, они качаются, но стоят. Потом вас просят: «Вытащи, пожалуйста, избу из-под 10 этажей». Но такого быть не должно. Менеджер продуктов должен заранее сесть и подумать, будет ли он позднее строить над этой избой 10 этажей.
Теперь разберемся, кто такие техлид и тимлид. Тимлид — это опытный разработчик, который знает всю архитектуру и принимает технические решения. Менеджер продуктов берет на себя ответственность со стороны продукта, а тимлид отвечает за техническую часть. А техлид — это разработчик, который берет ответственность за конкретный проект.
Техлид и тимлид — это своего рода хаб, связующее звено между разработчиками и менеджером, он помогает всем быть на одной волне. Поэтому нужно регулярно с ними общаться и делиться видением продукта. В ответ они будут держать вас в курсе всех технических проблем.
Я считаю, что в успешной команде продукта все — и менеджеры продуктов, и бизнес, и разработка — должны мыслить в одном направлении, понимать миссию и цель. Менеджер продукта работает в связке с дизайнером над видением проекта. Но никогда нельзя забывать про техлидов. Их надо приглашать на ежедневные планерки по продукту, обсуждать с ними свои решения.
Я иногда прихожу к своей команде разработчиков и просто разговариваю о продукте, планах по его развитию. Благодаря этому на планерки, где мы обсуждаем фичи и особенности реализации, они приходят с более широким видением, понимают, как те или иные фичи помогают развиваться всему продукту. Это поддерживает в разработчиках энтузиазм.
Работа в команде и планирование
Не всегда команда погружена в продукт и интересуется им. Иногда разработчики занимаются чем-то только потому, что им за это платят. Это трудная ситуация. С идеей «я начальник, поэтому все остальные должны меня слушаться» хорошие отношения в команде не построишь.
Хотя лично я с такими командами не встречался. Обычно команде, с которой я работаю, интересен продукт. Поэтому мы просто развиваем отношения, много общаемся и взращиваем свой интерес к продукту. Месяц или два — достаточный срок для выстраивания отношений. За это время важно необходимо успеть две вещи:
- Реализовать одну фичу от идеи до продакшена.
- Показать что вы заботитесь о команде, а не просто накидываете задачи.
Вот еще несколько рекомендаций для адаптации менеджера в команде:
- Спрашивайте, чем можете помочь. Вас могут попросить выгрузить аналитику или написать какую-то документацию, которая более подробно покажет пользовательские истории.
- Будьте открытым, честным и старайтесь помогать другим.
- Планируйте грамотно и договаривайтесь с заказчиком о реальных сроках, даже если заказчик — вы сами. Главное — не торопитесь. Иногда я задавал слишком маленькие сроки и мне казалось, что они реальны. Но после срыва дедлайнов неприятно было всем — и заказчику, и разработчикам. Так отношения не наладить. Поэтому не обещайте невозможное, особенно без согласования с командой.
Зачастую мы неадекватно оцениваем свое время. В физике есть такое понятие — «сферический конь в вакууме». Если что-либо абстрактное помещено в вакуум, где нет трения с воздухом, вычисления делать очень просто. Но жизнь намного сложнее. В идеальном мире разработчик все восемь часов пишет код. Но в реальности ему нужно время, чтобы погружаться в тему и взаимодействовать с другими командами. А еще могут быть личные проблемы — он рано ушел с работы, заболел — или проблемы у других команд (например, сисадминов).
В книге «Мифический человеко-месяц» есть хороший совет: если в проекте на что-то запланирована неделя, закладывай минимум три. Если проект связан с другими проектами или командами, закладывай пять. Потому что если вы пообещаете выполнить задачу через неделю и не уложитесь в срок, ответственность ляжет на вас.
Менеджер продуктов несет ответственность перед бизнесом и продуктом. У технической команды немного другая зона ответственности и свои KPI. Конечно, хорошо, когда команда и менеджер чувствуют общую ответственность перед пользователем и движутся к единой цели. Как раз для этого менеджеру продуктов важно с самого начала заинтересовать команду, объяснить, почему то или иное решение сделает пользователей счастливее, заразить всех идеей. Ведь никто не станет торопиться только ради KPI менеджера продуктов.
Менеджер должен уметь не просто говорить «это важно», но и объяснять, почему это важно: «Почему мы исправляем баг? Не потому, что он некрасиво выглядит, а потому, что это затрагивает пользователей. Если мы его не исправим, то потеряем много пользователей и заказов».
Это важный аспект в поведении менеджера продуктов. Это формирует ваш образ в глазах коллег и закладывает ваш ROI. Менеджеру продуктов полезно понимать все стадии продукта и болеть им — причем работать не просто в рамках KPI-метрик и бизнес-требований, но и мыслить масштабно, видеть, как продукт растет.
Выводы
- Есть три типа разработчиков: сосредоточенные на продукте, сосредоточенные на технических решениях и смешанный тип.
- Разработчики — не просто исполнители «хотелок» менеджера продуктов, поэтому важно обсуждать с ними каждую задачу, «продавать» ее, чтобы техническая команда эмоционально не выгорала.
- Не стоит сразу выкатывать масштабное решение — многие вещи можно сделать «на коленке» и даже собственными силами без разработчиков. Пусть это будет не по гайдлайну, зато если идея не выстрелит, с ней не жалко расстаться.
- Менеджер продуктов должен смотреть вперед — что будет с фичей через месяц, полгода? Это помогает заранее закладывать возможность масштабирования там, где это будет необходимо, чтобы в будущем не пришлось переписывать код.
- Полезные технические навыки: SQL, Python, понимание архитектуры технологических продуктов.
- Эмпатию к разработке необходимо контролировать — техническая сложность идеи не должна становиться стопором для ее реализации.
