Когда я только начинал свою карьеру в продукте, я чувствовал, что со временем захочу стать веб-разработчиком. Я знал, что есть путь от младшего менеджера проекта до развития; это уже было сделано раньше другим коллегой, который теперь был опытным бэкэнд-разработчиком. Мой начальник был так любезен, что предложил мне и этот вариант карьерного роста, так что я им воспользовался! Конечно, теперь я понимаю, что этот продукт определенно нравится мне больше, чем программирование (по крайней мере, в профессиональном плане), но я был в восторге от того, что научился использовать те же технологии, что и наши разработчики. В 2019 году я прошел буткемп для полного сертификационного курса, ориентированного на Javascript. Он вознаградил меня так, как я не ожидал, несмотря на то, что он был чрезвычайно сложным. Хотя я не рекомендую тратить 12 тысяч долларов на буткемп за то же образование, которое я получил (гав), прохождение этого курса научило меня значительно улучшать мой подход к управлению проектами четырьмя ключевыми способами:

  1. Понимание технического жаргона
  2. Получить перспективу
  3. Согласование ключевых требований к команде инженеров
  4. Находиться на одной волне (технически, эмоционально и профессионально)

Понимание технического жаргона

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

Здесь возникает пара реальных проблем. Непонимание технических аспектов вашего собственного продукта не только приводит к реальной трате времени и денег, но и может привести к долгосрочным проблемам с точки зрения планирования и исполнения. Кроме того, разработчики не будут доверять своему руководителю продукта, если не будут чувствовать, что он/она понимает (глубоко) продукт, которым они управляют. Как правило, это проявляется в пресловутом закатывании глаз разработчиками в ответ на команду разработчиков, когда они просят их предоставить решение, которое кажется простым, но на самом деле представляет собой гораздо большую техническую гору, которую нужно преодолеть. Это приводит к потере доверия к продуктовой команде. Мой старший брат — опытный Java-разработчик в финансовой компании. Он часто рассказывает мне о проблемах, которые возникают у него с командой разработчиков:

Они никогда не слушают нас, и они всегда меняют свое мнение о том, что они хотят! Если бы они только понимали, как сложно просто раскрутить API…

Мой старший брат немного нытик 😉, но в данном случае он прав. Непросто просто раскрутить API для фронтенд-команды. Еще сложнее, когда вы хотите показать этот API пользователям или другим командам разработчиков. Необходимо учитывать так много технических аспектов, от аутентификации и маршрутизации трафика до управления полезной нагрузкой или от управления состоянием до нормализации данных. Не говоря уже о ДОКУМЕНТАЦИИ, которую НИ ОДИН разработчик не любит писать (да и зачем?). Когда я начал часть моего буткемпа, где мы создали приложение полного стека с бэкэндом Node.js, я быстро понял, насколько это сложно. Даже не создавая действительно потрясающее приложение, теперь я знал, о чем говорю. Это устраняет так много блокировщиков, когда я могу понять, что имеют в виду разработчики, когда говорят об этих технологиях. Конечно, PM может узнать, работая с разработчиками, что эти вещи означают, но требуется время, чтобы усвоить эту информацию, точно так же, как изучение реального разговорного языка. И, как говорится с теми (и я могу ручаться из личного опыта), всегда легче учить язык, когда ты погружен в него.

Получение правильной точки зрения

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

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

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

Согласование ключевых требований

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

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

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

Та же длина волны

Это немного личное для меня. Когда я был на своем первом проекте PM, нам поручили создать новую интеграцию с Netsuite. Старый, который использовали клиенты, был устаревшим и нестабильным в своей работе. Клиенты были разочарованы, и в конечном итоге это стало обычным фактором оттока. Я знал, в чем проблема, и знал, что конечной целью является функциональная и стабильная интеграция с Netsuite. Тем не менее, я также знал, что технические требования были огромными, благодаря моему обучению на буткемпе. Было очень мало доступной документации для того типа интеграции, который мы хотели создать, поэтому разработчику (благослови ее сердце) пришлось просеивать сотни страниц несвязанной документации, чтобы найти части, необходимые для продолжения ее работы. Я заранее знал, что ей нужно для продолжения построения интеграции, и поэтому технически и профессионально был на одной волне с ней. Мы были на одной волне, а другие члены компании — нет. Для них это была интеграция — насколько это может быть сложно? Ну очень тяжело.

Дошло до того, что из-за отсутствия технической согласованности между разными командами разработчик был обременен стрессом до такой степени, что ему нужно было взять несколько выходных. Я знал это, как и вице-президент по инженерным вопросам. Он хотел защитить ее из-за огромного давления, связанного с проектом. Я согласился на 100%, и мы дали ей отгул. Другие сотрудники компании, в том числе несколько продакт-менеджеров, с которыми я работал, были разочарованы. Почему мы приостановили этот проект, когда он уже был в самом разгаре? Мне нужно было привести других в соответствие с масштабностью задачи, которая была поставлена ​​перед разработчиком. Оглядываясь назад, я должен был гораздо яснее сформулировать свои ожидания относительно того, насколько сложной будет эта задача для инженера. Если бы я сделал это, я, вероятно, предотвратил бы невероятно напряженные несколько недель. Как бы то ни было, плюсом здесь было то, что я смог общаться с ней более лично — даже эмоционально — благодаря моему опыту в этом буткемпе. В этот момент вложенные 12 тысяч долларов стали того стоить.

Урок, который следует усвоить, состоит в том, что разработчики — люди и подвержены тем же стрессам и проблемам, что и мы в продукте. Просто для них это преподносится по-другому. Можно констатировать, что разработчики должны лучше понимать продуктовую сторону (и они должны), но лично я предпочитаю придерживаться противоположного подхода и обучаться технической стороне этих проектов. Это доказало, что я могу устранить препятствия, связанные с техническим жаргоном, и понять ключевые требования, благодаря чему я могу больше взаимодействовать с командой инженеров. Они мои друзья! Они замечательные люди и отлично работают. Мне было очень приятно иметь возможность устранить эти распространенные препятствия, чтобы я мог подняться на их уровень. Когда им нужна была профессиональная или даже эмоциональная поддержка, я мог ее оказать. Насколько это ценно?! Иногда кажется, что ничто не может спасти разработчика больше, чем владелец продукта, который по-настоящему понимает свою работу или, по крайней мере, большую ее часть.

Вывод

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