5 вещей о разработке, которые важно знать продактам

Какими техническими навыками должен обладать продакт-менеджер? Должен ли продакт-менеджер самостоятельно кодить?

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

GoPractice публикует адаптированный перевод материала «The top 5 things PMs should know about engineering», опубликованного в блоге Ленни Рачицки (Lenny Rachitsky). Автор материала — Джастин Гэйдж (Justin Gage), автор рассылки Technically.

Содержание

• Знание №1: Технологический стек компании
• Знание №2: Чувствительные куски кода
• Знание №3: Процессы разработки и релиза в вашей компании
• Знание №4: Как вносить изменения в код
• Знание №5: Основы технической грамотности

***

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

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

Знание №1: Технологический стек компании

Что нужно знать: Какие технологии использует приложение, сайт и инфраструктура вашей компании. Например, Technically.dev построен на базе React и Next.js, развернут на Vercel и написан с использованием HTML, CSS и JavaScript.

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

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

В первую очередь изучите репозитории вашей компании на GitHub. Вы наверняка найдете, какие языки программирования применяются в компании, а также на какие фреймворки опирается приложение. Ниже — скриншот главного репозитория Supabase, open source конкурента Firebase. Обратите внимание, что GitHub указывает, на каком языке написан код (справа внизу).

Помимо языков, структура проекта вашей команды может указывать на используемые фреймворки. Если в названиях файлов есть “.next”, то ваша команда с высокой вероятностью использует NextJS. А если вы видите “import { useState } from ‘React’ ”, то команда, скорее всего, пользуется React. Изучать файлы с кодом — не самое веселое занятие и не лучшая трата вашего времени, но, изучив хотя бы несколько, вы получите минимально необходимый контекст. 

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

Знание №2: Чувствительные куски кода

Что нужно знать: Как взаимосвязаны различные подсистемы вашего продукта/приложения. Какие компоненты зависят от других. Насколько сложно вносить изменения в конкретную подсистему.

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

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

Знание №3: Процессы разработки и релиза в вашей компании

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

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

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

Как это узнать: Спросите у ваших разработчиков. Предварительно рекомендуется самостоятельно изучить пул реквесты (pull request / PR), которые были добавлены в главную ветку (актуальную версию) приложения, и какие проверки GitHub запускает во время сборки приложения. Ниже — пример для Superbase. По всей видимости, команда использует Vercel для релиза, поскольку бот Vercel прокомментировал PR ссылками на предварительные просмотры релиза.

Это полезное знание. Изучив документацию на сайте Vercel, вы обнаружите, что их продукт позволяет делать развертывание быстро и просто, в пределах пяти минут. Позже, например, вы будете понимать, можете ли вносить изменения непосредственно перед дедлайном, или просить об этом разработку будет не слишком удачным решением. Чтобы найти pull requests в репозитории вашей команды на GitHub, откройте репозиторий, найдите вкладку “pull requests” и выберите любой. 

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

Развивайтесь в профессии продакт-менеджера с помощью GoPractice.

→ «Профессия: продакт-менеджер».

→ «Симулятор управления продуктом на основе данных».

→ «Симулятор управления ростом продукта».

→ «Симулятор SQL для продуктовой аналитики»

→ «Симулятор управления ML/AI-проектами».

→ «Генеративный AI для продакт-менеджеров: мини-симулятор».

→ Не знаете с чего начать? Пройдите бесплатный тест для оценки навыков управления продуктом и подпишитесь на телеграм-канал GoPractice.

Знание №4: Как вносить изменения в код

Что нужно знать: Как вносить изменения в код и открывать pull request, в особенности для небольших изменений вроде корректировки текста и новых цветов. 

Почему это важно: Качественный продукт характеризуется качественными текстами, но вам не стоит полагаться исключительно на разработку, если вы хотите исправить опечатку. Умение самостоятельно вносить изменения (например, поправить текст или border-radius) открывает дорогу к более быстрому улучшению продукта. Но не берите на себя слишком много: достаточно ограничиться изменениями в части текста или дизайна. Даже такие небольшие доработки позволят вам заработать авторитет среди разработчиков. 

Как это узнать: Обратитесь к разработчику из вашей команды, с которым у вас лучше всего налажены отношения, и попросите его показать, как вносить изменения в код. В общих чертах процесс похож на клонирование репозитория вашего приложения, его локальный запуск, внесение изменений в код и открытие pull request на GitHub. Если изменения не сопряжены с большим риском, их можно вносить сразу на GitHub (см. пример ниже).

​​

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

Знание №5: Основы технической грамотности

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

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

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

1. Читайте блоги разработчиков

Часто они написаны довольно простым языком, и вы освоитесь с терминами, которые разработчики используют в повседневной работе. Лично мне нравятся блоги Segment, Slack, Netflix и Stitch Fix. Обычно команды ведут их, чтобы привлекать новые кадры («Смотрите, какие классные штуки мы строим!»), но и для вас они могут стать ценным источником знаний. Большая часть того, что мы называем технической базой, это понимание, как ПО работает на практике, и блоги разработчиков сильно помогают в этом.

2. Ищите все, что не знаете

Технические тексты и речь строятся на нескольких слоях концептов, и вам потребуется начинать с самых низов, чтобы понимать верхушку. Не игнорируйте, а лучше поищите онлайн значения терминов, которые вам непонятны. В интернете не очень много централизованных ресурсов, которые гарантированно сделают вас технически подкованным, но для некоторых важнейших концептов есть неплохие эксплейнеры. Хороший пример — гайд Duo Security по SAML (Security Assertion Markup Language). Уделите достаточно времени на поиск, и вы наверняка найдете наиболее понятный для вас стиль эксплейнеров.

3. Подружитесь с разработчиком за пределами компании

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

_{Спасибо Арсению Шкункову за помощь в переводе материала.}