Большой гайд по разработке для продактов

Перед тобой гайд-помощник по продуктовой разработке для продакт-менеджеров уровня Junior и Middle. Мы изучили самые релевантные открытые источники и поговорили с продактами уровня Junior, Middle, Senior, Head of Product,  чтобы найти практически применимые советы, как разобраться, что же такое продуктовая разработка.

В твоей работе есть два больших блока: Discovery и Delivery. Про этап Discovery напишут наши коллеги по интенсиву для продакт менеджеров Валерии Розовой. Мы здесь сосредоточимся только на этапе Delivery.

Этап Delivery — это процесс непосредственной разработки продукта и доставки его до пользователя. Им занимается команда инженеров: фронтенд, бэкенд, мобильные инженеры, devops-инженеры, QA (тестировщики), тим-лид, delivery менеджер или проджект, а также продуктовые дизайнеры. В зависимости от особенностей набора технологий, которые использует команда, список ролей может пополняться или уменьшаться. На данной стадии продакт менеджер тоже играет важную роль, почему мы этому и посвящаем гайд.

Внутри гайда — ответы на вопросы:

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

#valerie

Для кого этот гайд и как им пользоваться

Тебе точно нужно прочитать этот гайд, если ты:

• Хочешь пройти собеседование на роль продакта и переживаешь, что завалишь интервью с техлидом.
• Хочешь стать продактом в IT, но у тебя нет опыта в разработке.
• Уже получил оффер и вышел на работу, но не знаешь, с чего начать и как говорить с разработчиками на одном языке.
• Уже работаешь 1-3 года с командой разработки и постоянно встречаешься с проблемами вида “разработчики опять увеличили сроки на задачу”, “я не понимаю, чем занимаются разработчики и теряю контроль”, “разработчик потерял мотивацию — что делать?”.

Глава 1. Начинаем с теории

1. Методологии разработки

Методология разработки  — это система, которая определяет порядок и сроки выполнения задач внутри этапов жизненного цикла, методы оценки и контроля. Бюджет и сроки выполнения проекта и метод разработки связаны и зависят друг от друга.

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

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

Scrum — методология разработки, которая предполагает разделение работы на небольшие цели, которые могут быть достигнуты в четкие сроки, итерации, которые называются спринтами.

Kanban — методология разработки, которая фокусируется на continious delivery (непрерывном выпуске продукта) и не перегружает команду встречами (митингами).

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

Роли scrum часто путают с профессиями, но это не корректно. Путают понятия Product Manager и Product Owner, но Product Owner — это роль в scrum, и не всегда эту роль выполняет продакт, это может быть, например, маркетолог, дизайнер или проджект менеджер.

‍

Давайте сравним SCRUM и Kanban:

Преимущества и недостатки SCRUM и Kanban:

2. Команда продакта, его задачи и обязанности‍

Команда разработки — что это?

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

• Продакт менеджер (Product Manager) определяет стратегию продукта, анализирует рынок и требования клиентов, а также определяет приоритеты для команды разработки.
• Тимлид (Team Lead) отвечает за техническое руководство команды разработки, принимает ключевые технические решения и обеспечивает соответствие архитектурным и техническим стандартам.
• Разработчики или инженеры (Developers) занимаются программированием и созданием кода для реализации функциональности продукта. Они бывают следующих подвидов:
  a. фронтенд (Frontend): занимаются созданием пользовательского интерфейса веб-приложений, используя такие инструменты как HTML, CSS и JavaScript;
  b. бэкэнд (Backend): работают над серверной частью веб-приложений, обрабатывая данные, взаимодействуя с базами данных и реализуя бизнес-логику с использованием языков программирования, таких как Java, Python или PHP;
  c. мобильная разработка: специализируются на создании приложений для мобильных устройств, таких как смартфоны и планшеты, используя платформы и языки программирования, такие как Swift или Kotlin для iOS и Android соответственно.

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

• Дизайнеры (Designers) отвечают за создание пользовательского интерфейса (UI) и пользовательского опыта (UX) продукта, а также разработку дизайн-макетов.
• Тестировщики (Testers, QA-инженеры) проводят тестирование продукта на соответствие функциональным и качественным требованиям, выявляют ошибки и обеспечивают высокую производительность и надежность продукта.
• Бизнес-аналитики (Business analyst) анализируют бизнес-требования, определяет функциональность продукта и помогает команде разработки понять потребности клиентов. Иногда эту работу выполняют системные аналитики или технологи.
• DevOps (Development and Operations) отвечает за автоматизацию процессов разработки и операционную деятельность, включая управление инфраструктурой, непрерывную интеграцию и доставку (CI/CD), обеспечивая стабильность, масштабируемость и надежность работы системы.

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

#subscribe

Задачи и обязанности продакт менеджера в команде разработки

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

• Определение стратегии:
  Продакт менеджер работает с командой разработки, чтобы определить стратегию развития продукта. Он учитывает потребности пользователей, анализирует конкурентную среду и совместно с командой разработки определяет цели и планы для достижения успеха продукта. Стратегия должна дать понимание основных метрик команде и на какие KPI команда должна полагаться.
• Планирование и приоритезация разработки:
  Продакт менеджер работает с командой разработки, чтобы планировать и приоритезировать задачи разработки продукта. Он учитывает бизнес-стратегию и требования пользователей, определяет приоритеты задач и управляет бэклогом продукта.‍
• Согласование требований и коммуникация:
  Продакт менеджер является связующим звеном между командой разработки, бизнес-аналитиками и другими заинтересованными сторонами, включая другие продуктовые команды. Он обеспечивает эффективную коммуникацию, согласование требований и управление ожиданиями между командой разработки и другими участниками проекта.
• Анализ и мониторинг продукта:
  Продакт менеджер отслеживает производительность продукта, собирает обратную связь от пользователей и анализирует данные для принятия информированных решений в команде разработки. Он также отвечает за измерение успеха продукта и достижение поставленных целей вместе с командой разработки."
• Ретроспектива и улучшение эффективности работы команды:
  Продакт менеджер активно участвует в ретроспективных сессиях, где команда анализирует прошедшие итерации разработки, обсуждает проблемы и ищет пути для улучшения процесса и эффективности работы. Он помогает инициировать изменения и внедрять улучшения, чтобы команда стала более продуктивной и достигала лучших результатов.

Какие задачи не входят в прямую зону ответственности продакта

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

Однако в некоторых компаниях может возникать ситуация, когда на продакта возлагают задачи, не относящиеся к его зоне ответственности, например:

• Непосредственное программирование: Продакт менеджер не занимается написанием кода или разработкой технических решений. Это задача разработчиков и технического лидера.
• Подробное составление технических задач: Продакт менеджер определяет функциональные требования и бизнес-цели, но не должен подробно описывать технические детали или создавать технические задачи. Эта задача обычно выполняется техническим лидером или разработчиками.
• Управление процессом разработки: Продакт менеджер не является ответственным за управление всем процессом разработки, включая планирование сроков, назначение задач и контроль выполнения. Это обычно относится к области ответственности технического лидера, delivery лид или тимлида.
• Тестирование продукта: Продакт менеджер не проводит тестирование продукта на соответствие требованиям и обнаружение ошибок. За это отвечают тестировщики или инженеры по обеспечению качества (QA).

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

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

С чем надо уметь работать?

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

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

• Slack: Инструмент для коммуникации внутри команды и сотрудниками, обмена сообщениями, файлами и интеграции с другими инструментами.
• Jira: Инструмент для управления проектами и задачами, отслеживания и приоритезации задач, совместной работы и отслеживания прогресса выполнения.
• Figma: Инструмент для создания интерфейсов и дизайна, позволяющий команде разработки и дизайнерам совместно работать над проектами, создавать прототипы и делиться дизайнами.
• Amplitude: Инструмент для аналитики и сбора данных, который помогает анализировать поведение пользователей, измерять эффективность функций продукта и принимать информированные решения.
• Confluence: Платформа для создания и совместного редактирования документации, включая спецификации продукта, руководства пользователя и базу знаний.
• GitLab: Платформа для разработки и совместной работы над проектами, предоставляющая инструменты для управления кодом, CI/CD и контроля версий.

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

3. Tech-минимум. Что нужно знать продакту о разработке

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

Про архитектуру продукта

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

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

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

Про основы сетевой инфраструктуры и хранения данных

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

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

Про Backend и Frontend

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

• ‍Обмен данными: Frontend отвечает за пользовательский интерфейс, который взаимодействует с пользователем. Когда пользователь взаимодействует с интерфейсом (например, заполняет форму или нажимает кнопку), Frontend отправляет запрос на Backend для обработки и получения данных. Backend обрабатывает запрос, взаимодействует с базой данных при необходимости и возвращает результаты Frontend для отображения пользователю.‍
• API (Application Programming Interface): набор способов и правил, по которым различные программы общаются между собой и обмениваются данными. Backend предоставляет API, который определяет, как Frontend может обращаться к функциональности и данным, предоставляемым Backend. Frontend использует API для отправки запросов на Backend и получения ответов. API обеспечивает стандартизированное взаимодействие между Backend и Frontend, что позволяет разработчикам работать независимо и эффективно коммуницировать друг с другом.‍
• Безопасность: Backend отвечает за обеспечение безопасности и защиты данных. Он обрабатывает проверку подлинности пользователей, авторизацию и другие меры безопасности. Frontend в свою очередь обеспечивает пользовательскую защиту данных на уровне интерфейса, например, через валидацию форм или ограничение доступа к определенным функциям.‍
• Оптимизация производительности: Коммуникация между Backend и Frontend также включает оптимизацию производительности. Backend отвечает за оптимизацию работы сервера, обработку запросов эффективным образом и масштабирование при необходимости. Frontend, с другой стороны, может оптимизировать загрузку страниц, кэширование данных и другие аспекты, чтобы улучшить пользовательский опыт и ускорить отклик приложения.‍
• JSON (JavaScript Object Notation): формат обмена данными, основанный на тексте, который широко используется для передачи структурированных данных между клиентской и серверной частями веб-приложений. JSON представляет данные в виде пар "ключ-значение" и может содержать простые типы данных (строки, числа, логические значения), а также составные типы данных (объекты, массивы). Стоит помнить, что JSON — это только один из текстовых форматов наряду с XML и HTML, но используется чаще в силу его лаконичности и простоты читаемости компьютерами.

Таким образом, backend и frontend взаимодействуют друг с другом через API. Frontend отправляет запросы к backend, чтобы получать данные или выполнять действия. Обычно данные передаются между backend и frontend в формате JSON, поскольку он легко читаем и понятен для компьютеров. Backend принимает запросы от frontend, обрабатывает их, извлекает или модифицирует данные в базе данных и возвращает результаты в формате JSON, которые frontend использует для обновления пользовательского интерфейса. Процесс представлен на схеме:

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

Про технологический стек

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

Кстати, фреймворками в программировании называют готовые шаблоны для программной платформы, на основе которого можно дописать собственный код. Примеры распространненных фреймворков во фронтенд-разработке: Bootstrap для сайтов с адаптивной версткой, Angular.JS для динамических веб-приложений, Vue.js помогает реализовать модульный подход.

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

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

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

Про SQL

SQL (Structured Query Language) это стандартный язык программирования, используемый для работы с реляционными базами данных. Он предоставляет средства для создания, изменения и управления данными в базе данных, а также для выполнения запросов и анализа данных.

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

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

В любом случае, понимание основ SQL может ускорить работу продакта и расширить его возможности по принятию решений. Как отмечают опрошенные нами продакты, в среднем на изучение базовых SQL-запросов у них ушло 1-2 рабочих дня

Важное от разработчиков

• Технический долг (technical debt) — частая ситуация при работе по скрам-методологии. Это ситуация, когда в процессе разработки из-за сжатых сроков или срочных изменений приняли “быстрые” решения в разработке, которые создают проблемы в коде. Как результат, возникает "долг", который нужно будет выплатить в будущем, чтобы исправить недочеты или улучшить код.
• Legacy Code — устаревший, унаследованный код. Это код, написанный на устаревших или неактуальных технологиях, который может быть сложным для поддержки или модификации. Обычно он создается в результате долгого существования программного продукта и непрерывного добавления новых функций и изменений без переписывания всего кода.Технический долг со временем может привести к образованию legacy кода. Если не уделять достаточно внимания исправлению технического долга, он будет накапливаться и превращаться в устаревший код. Legacy код может быть сложным для поддержки, добавления новых функций или изменения существующего кода, что затрудняет разработку и обслуживание программного продукта. Для избежания этого у разработчиков есть процесс рефакторинга — систематическое переписывание частей кода для улучшения его структуры и читаемости.
• Код-ревью — это принятая в IT-командах практика, когда один разработчик проверяет и анализирует код, который написал другой разработчик. Цель код-ревью — обнаружить и исправить возможные ошибки и проблемы, обеспечить соблюдение стандартов и улучшить качество кода, а еще код-ревью помогает обучать и развивать разработчиков.
• Логирование — процесс записи и сохранения информации о событиях, происходящих в программном обеспечении или системе. Событиями могут быть ошибки, предупреждения, информационные сообщения. Логирование позволяет сохранять эти события в специальных файловых журналах — логах. Логирование позволяет быстро обнаруживать проблемы, отслеживать действия пользователя, анализировать производительность и исправлять ошибки.
• Деплой (deploy) — это развертывание и запуск веб-приложения или сайта в его рабочей среде, то есть на сервере или хостинге. Для понимания этого нужно знать, что код приложения сначала пишется на компьютере разработчика, а потом запускается в другом месте, которое называется "продакшен". Продакшен — это боевая среда, где код работает. Если приложение небольшое, то продакшен может быть одним сервером, а если приложение большое и сложное, то продакшен может включать в себя тысячи серверов.
• Баг — нежелательное или не соответствующее исходной документации поведение программы. Баги возникают, когда программа не работает так, как ожидается, или не соответствует спецификациям и требованиям. Причин для возникновения багов довольно много: ошибки в коде, неправильная обработка данных, некорректная логика или недостаточное тестирование программы перед ее выпуском. Решение багов обычно включает процесс исправления кода, тестирования решения и выпуска обновленной версии программы

Какие бывают баги в IT продукте

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

Классы ошибок, с которыми ты можешь столкнуться:

Глава 2. Переходим к практике

Ситуация 1. Подготовка к собеседованию на роль продакта

От чего зависит уровень технических требований к продакту

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

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

• ‍Позиция, на которую ты подаешься. Как правило, более глубокого понимания технической разработки, архитектуры и технологического стека требуют, начиная с позиции Senior. Это специалисты с опытом 4-6 лет. Требования обычно описаны в вакансии, а также в блоке про Responsibilities — это задачи, с которыми кандидат будет работать ежедневно. От продактов уровня Middle будут ждать общего понимания архитектуры мобильного или веб-приложения, но без глубокого погружения, а для Junior-специалистов зачастую на первом месте будут другие компетенции, такие как работа с метриками, исследования, структурное мышление. Здесь важно пояснить, что отсутствие бэкграунда с разработкой на позиции Junior не блокирует тебе возможность работать продактом, но для позиций уровня Middle и выше необходимо будет разбираться в архитектуре и технологическом стеке хотя бы на базовом уровне.‍
• Продукт и индустрия, куда ты подаешься. Есть продукты, обладающие высокой технологической сложностью, например, связанные по большей части с backend разработкой. Продактов для этих продуктов часто выбирают из бывших разработчиков с tech бэкграундом. О таких требованиях обычно пишут в вакансии, и это можно узнать по определенным словам-маркерам в разделах Requirements (требования) и Responsibilities (обязанности). Также в вакансии могут указывать индустрию или тип продукта, опыт в которых предпочтителен. Вот примеры слов-маркеров, по которым можно понять требования к техническому бэкграунду кандидата:

Requirements (требования):
‍- Минимум 2 года лидирования потребительских продуктов в Fintech.
- Глубокое техническое понимание веб-технологий, архитектуры SaaS и того, как они влияют на время разработки.
- Опыт поддержки/развития бэк-офисных биллинговых и платежных систем в международном масштабе.
- Опыт работы с моделями монетизации мобильных приложений на основе подписки.
- Понимание работы с API, техническими продуктами и продуктами B2B SaaS.

Responsibilities (обязанности):
‍- Управление разработкой продуктов для бэк-офиса.
- Управление процессами выпуска релизов и QA (контроля качества).
- Подготовка спецификаций и постановка задач команде (программисты, дизайнеры, аналитики).

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

Как подготовиться к интервью с техническим лидом

• Опиши для себя логику продукта, в который ты идешь. Можно разложить на простые составляющие для собственного понимания, кто является клиентом продукта, для чего клиент пользуется продуктом, какие действия клиент совершает при использовании продукта, как продукт монетизируется.
• Познакомься с ключевыми технологиями, языками программирования и архитектурными принципами, которые используются в сфере твоего продукта (например, Foodtech, Edtech, Fintech). Для поиска информации можно использовать Chat-GPT, профильные подкасты и ютуб-каналы (ссылки на подробный список ресурсов представлены ниже).
• Подготовь вопросы, чтобы узнать больше о технических аспектах продукта. Тебе необязательно задавать специфические и профессиональные вопросы о техническом стеке, но можно подумать с точки зрения бизнеса и задать вопросы, связанные с возможностями и ограничениями технологии или с масштабируемостью продукта.
• Познакомься с основами Agile-методологий. Можно заранее узнать, по какой методологии происходит процесс разработки в команде, и прочитать несколько статей, объясняющих логику методологии.Рекомендуем использовать официальные источники от создателей методологии, например, Scrum-гайд или Agile-манифест.‍
• Продемонстрируй компетенцию коммуникации с разработкой: важной частью роли продакт менеджера является эффективное общение с техническими специалистами. Подготовься к тому, чтобы продемонстрировать свою способность объяснять сложную техническую информацию простым языком и задавать релевантные вопросы. Тебе также могут дать сценарное задание, например, разыграть ситуацию между тобой, заказчиком и тех. лидом, где тебе нужно сначала понять, что необходимо заказчику, какая цель его запроса, а затем поставить задачу тех. лиду.

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

Ситуация 2. Первый месяц на новом месте

Здесь мы собрали практические рекомендации о том, что можно сделать продакт-менеджеру на новом месте работы в первые дни-недели-месяцы, чтобы быстрее освоиться в технических аспектах продукта.‍

Команда

• Познакомься со всеми участниками команды. Разберись, кто чем занимается, какие у них компетенции и в чем специализируются (бэк / фронт / фул-стек; веб / iOS / Android), кто к кому ходит на код-ревью. Пойми, с кем в первую очередь лучше обсуждать технические аспекты работы и задавать вопросы: это техлид? системный аналитик? проджект? кто-то из инженеров? Проясни ожидания от своей работы с командой и стейкхолдерами: если в команде нет выделенного проджекта, то означает ли это, что его функции будешь выполнять ты?
• Постарайся узнать каждого тиммейта (участника команды) не только со стороны его роли, но и как человека. Тут можно назначить 1-to-1 встречи или поговорить с техлидом (если он есть). Пойми уровень / грейд ребят из команды, их сильные и слабые стороны, выясни их личные цели и мотивирующие факторы. Даже если формально ты не менеджер для команды, это все равно полезно: например, в процессе работы в спорах ты сможешь подбирать аргументы, которые будут работать лучше всего.
• Важно понять, какая степень погружения в бизнес-контекст будет оптимальна для команды разработчиков: кто-то хочет быть максимально в курсе, интересуется выручкой и бизнес-показателями, исследованиями пользователей, продуктовыми метриками, и даже готов участвовать в рисерче (исследовании), а кому-то достаточно верхнеуровнево понимать только то, что помогает писать красивый код.
• Также полезно расспросить, как давно команда вместе, насколько они сработаны, кто там формальный и неформальный лидер. Если команда еще не прошла стадию шторминга (см. модель Такмана), то это обязательно отразится на производительности, и это надо будет иметь в виду при планировании.
• Проанализируй бас-факторы: есть ли в команде кто-то, чей отпуск или болезнь может значимо повлиять на сроки? Если в команде есть проджект или тимлид, то это можно обсудить с ними.
• Разберись, как устроены смежные команды в компании: кто продакт-менеджеры тех продуктов, на которые мы влияем или которые на нас влияют? С какими кейсами взаимодействия ребята разбирались раньше? Обязательно познакомься: назначь зум-созвон или позови на кофе. Достань организационную схему устройства команд, а если в компании ее еще нет — набросай сам в Miro или “на салфетке” и пошарь с коллегами.‍

‍Продукт

• Разберись, какие составляющие есть в продукте, на каких платформах он работает: это сайт, веб-приложение, iOS, Android. Как устроено управление, взаимодействие, бэклоги.
• Проанализируй имеющиеся фичи: зачем они нужны, на что влияют и как соотносятся с целями бизнеса. Есть ли на них есть техническая документация — изучи, заложив на это несколько недель. Не старайся понять всё, просто следи, что у тебя начинает складываться картинка, и готовься задавать вопросы. При этом нормально, что документация есть далеко не на все компоненты.
• Отдельно узнай, какие сторонние внутренние и внешние сервисы использованы: какие продукты/сервисы влияют на нас? А на что влияет наш продукт? Какие параметры у API? Какие библиотеки и базы данных задействованы?
• Понять логику взаимодействия между элементами поможет схема архитектуры: она либо хранится в базе знаний компании, либо ее может набросать для тебя техлид. Если непонятно — задай вопросы.‍

Процессы

• Узнай, какая методология разработки используется и почему именно она. Работает ли команда по спринтам, если да — какова его продолжительность и сколько команда успевает сделать за 1 спринт.
• Разберись, как тут устроен производственный процесс: как фича проходит от этапа идеи до передачи в прод (выпуск продукта) и тех поддержки (после запуска продукта).
• Разберись, какой тут процесс деплоя, какие среды используются, какие приняты подходы к тестированию. Если в команде есть devops-инженер — самое время поговорить и с ним тоже.
• Разберись, как тут принято писать технические требования: выясни, что именно от тебя ожидает команда разработки, как это делалось раньше. На каком языке написано: ближе к техническому или к “человеческому”? Даже если ты не будешь заниматься этим непосредственно, понимать этот аспект полезно.
• Какие инструменты использует команда для проектного управления. Та же Jira поначалу может казаться сложной, т.к. там много зависимостей. В каждой компании свои правила ведения трекера. В идеале должен быть гайд, но если его нет — попроси продакта соседней команды или своего CPO показать все особенности. Часто они влияют на аналитические дашборды, поэтому тут довольно важно не делать ошибок.
• Что тут с аналитикой? Как настроен процесс взаимодействия разработки с аналитиками? Проводятся ли AB-тесты? Если да — загляни в систему, прикинь зависимости экспериментов от других команд. Расспроси, как планируют эксперименты.‍

Технологический стек

• Узнай, какой стек применяется: языки программирования, фреймворки, базы данных. Разберись, какие из-за этого могут возникнуть сложности и ограничения, какие показатели надежности, какие в последнее время были аварии. Загляни в артефакты пост-мортем анализа — отчеты, в которых команда разбирается в причинах инцидентов и в том, как их избегать.
• Спроси про технический долг и легаси: как здесь с ним работают, какие ограничения он создает, как делают рефакторинг. Можно уточнить у техлида, что, по его мнению, нужно обязательно рефакторить, — это полезно будет занести в бэклог. Так ты примерно поймешь, какой запрос на задачи по тех. долгу.‍

Советы

• Главное правило: не бойся задавать “глупые” вопросы — ты новичок, это нормально. Проси повторить и объяснить другими словами (”а теперь, пожалуйста, по-русски”, “а объясни так, как бы ты пятикласснику это объяснял”). Но перед тем, как что-то спрашивать, все же сначала поищи сам в Гугле / спроси у Chat-GPT: вероятнее всего, после этого твои вопросы станут более сфокусированными, и отвечать на них будет проще.
• Ходи на встречи разработки, даже если тебя не зовут. Особенно на дейли (созвоны с командой). Поначалу непонятным может казаться примерно всё: не бойся, записывай, чтобы потом задать вопросы / загуглить.
• Заведи спейс, куда будешь выписывать свои вопросы, наблюдения и открытия. Это может быть тетрадка, страничка в Notion или телеграм-канал на 1 читателя (тебя) — что-то, что всегда будет в близком доступе. Помимо прочего, систематизация знаний полезна еще и потому, что это может стать хорошей основой для онбординга новых членов команды.
• Не старайся сразу же предлагать революционные улучшения. Сначала разберись и пойми, чем именно обусловлены особенности.
• Полезно поговорить с предыдущим продактом, кто тут до тебя работал. Такой разговор можно планировать не на первую неделю, а на чуть позже, когда у тебя накопятся вопросы, часть которых уместно будет адресовать такому человеку;
• Помни, что даже опытному специалисту может понадобиться до полугода, чтобы разобраться в технической части и процессах.
• Не стремись освоить все смежные специальности сразу, не ругай себя, если не всё понятно в разговоре разработчиков (всё и не должно быть понятно: они специалисты, а не ты). Нормально, если первое время почти ничего не будет понятно. Главное — фиксировать инсайты и не сдаваться. Помни, что ты продакт и это круто.

#chatbot

Ситуация 3. Продакт в процессе работы

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

Операционные задачи

1. Оценка сроков разработки

Проблема: cамая главная проблема для продактов разных уровней, как начинающих, так и более опытных — оценка сроков на выполнение задачи разработкой. Неправильная оценка сроков, постоянные затягивания и переносы могут повлиять на ожидания стейкхолдеров, время и деньги на проверку гипотезы, а также на мотивацию команды. Эта проблема встречается у большинства респондентов. Многие не понимают, когда сроки реально адекватные, а когда разработчики их завышают.

Решение:

• Основные пути решения у более опытных продактов — закладывать дополнительное время на изменения сроков, также обсуждение проблем с командой разработки и внедрение процесса планирования и фактической оценки сроков.
• Для того, чтобы тренировать оценивание сроков в компаниях часто используют специальные игры-процессы, наподобие покера разработчиков (planning pocker), где делают ставки, сколько будет весить та или иная задача в сторипоинтах.
• Договоритесь с командой о системе оценки сроков. Многие разработчики не хотят говорить срок с точностью до часа, так как не всегда понимают объем до того как приступили к задаче.
• Используете оценки задач с диапазоном, например, можно договорится что 1 storypoint это 1-2 дня работы.
• Если у разработчика нет никакого представления как делать задачу и сколько она займет, можно поставить задачу на Research. Задачу на Рисерч программист оценивает отдельно. Например, через 3 дня он завершит Рисерч, узнает с какой кодовой базой ему придется работать и после сможет сказать более точный срок по самой задаче на разработку.
• Следите за выработкой сторипоинтов в каждом спринте, в этом поможет отчет velocity chart. Отчет позволит сделать вывод о скорости команды, и, после декомпозиции и оценки задач, дать прогноз о сроке на основе данных о количестве завершенных сторипоинтов в предыдущих спринтах.
• Сроки могут сдвигаться из-за ситуаций независящих от разработки, например, может быть зависимость от смежных команд. Убедитесь, что в вашем jiraflow  есть статус Blocked, а тимлид держит в фокусе эти задачи и стремиться проактивно устранять блокеры

2. Написание технического задания (ТЗ)

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

Решение:

• Попросите кого-то из вашей команды дать шаблон ТЗ или хороший пример. Скорее всего, у вашего руководителя или команды разработки такой имеется. Если нет, попробуйте изучить документы других продактов компании, в которой вы работаете.
• После написания попросите кого-то из коллег, например, тимлида или руководителя, прочитать ТЗ и дать фидбек
• Часто функциональность в техническом задании описывают с помощью:
  • User story (юзерстори) — это короткая история с описанием возможных вариантов применения  пользователем продукта. User story  составляется по формуле “Я как (тип пользователя), хочу (действие или цель пользователя), чтобы (получить следующий результат или выгоду)”.  Другими словами, юзерстори описывает потребность пользователя.
  • Usecase (юзкейс) - это описание сценария взаимодействия пользователя с продуктом. Юзкейсы же про конкретные сценарии, которое нужно встроить в продукт, чтобы удовлетворить потребность.
  • Definition of ready / Definition of done — должны быть прописаны до того, как задача будет взята в работу. Пока это не прописано, задача даже не является элементом бэклога, как только написали — можно брать

• Несмотря на то, что стандарты технических заданий могут отличаться в разных компаниях, ниже перечислили список пунктов, которые полезно иметь в ТЗ, если они релевантны процессам и продукту над котором работаете:
  
  Часть про продукт:
  • Команда - опишите кто будет работать над новой функциональностью, кто продакт менеджер, дизайнер, аналитик, тимлид, исследователь и другие ответственные и их контакты в смежных командах
  • Цель - какая цель внедрения новой функциональности
  • Стратегическое соответствие - почему новая функциональность соответствует стратегии вашего продукта
  • Влияние на метрики - опишите, на какие KPI, локальные, прокси метрики планируете повлиять
  •CJM - при возможности можно приложить схему с экранами, по которым будет идти пользователь
  •Дизайн АБ теста - опишите, какие гипотезы будете проверять, какие метрики замеряете
  
  Часть, которая нужна разработчикам:
  • Описание самой функциональности - опишите новую фичу с помощью userstory и/или usecase
  • Макеты - приложите ссылку на макеты, убедитесь что они готовы под все необходимые платформы и ссылка откроется у каждого из команды
  • Эпик - убедитесь, в ТЗ есть ссылка на эпик, чтобы разработчикам было сразу видно куда декомпозировать задачи. Также любой человек может увидеть прогресс работы над фичей при переходе в эпик
  • Логи аналитики - описание логов аналитики которые нужно поддержать разработке, с подробным описанием в какие таблицы их нужно записать, эта часть может составляться совместно с аналитиком
  • Техническая информация - здесь информация заполняется и дополняется преимущественно тимлидом. Тут могут быть описаны тогглы, ендпоинты, новые методы и другая информация, которая поможет любому разработчику быстрее погрузиться в подробности технической реализации фичи

3. Работа с таск-трекером

Проблема: некоторые продакты испытывают сложности в  работе с таск трекерами (самый популярный таск-трекер jira) Например, бывают сложности с пониманием процесса работы над задачей или вопросы по функциональности трекера.

Решение:

• Многие респонденты отмечают, что разобраться в принципах работы jira не так сложно, продукт давно на рынке, он интуитивно понятен и имеет большую базу знаний с инструкциями и видео материалами
• Спросите у членов команды, какие этапы проходит задача от создания до выполнения (jiraflow). Эти этапы влияют на скорость и качество работы команды. Вы можете договариваться о смене процесса работы над задачами, если вам нужно добавить или убрать какой-либо из этапов
• Пример jiraflow
  • ToDo - задача в бэклоге
  • In Progress - задача в работе
  • Ready for QA - задача готова к тестированию
  • Done -  задача сделана. в каждой команде определяется  или прописывается в задаче свой defenition of done (DoD)
  • Reopened - задача переоткрылась, например, пофикшеный баг появился опять
  • Blocked - задача заблокирована, например, не хватает информации или есть зафисимость от другой задачи или команды

Взаимодействие с командой

1. Мотивация команды разработки

Проблема: разработчики делают задачи формально, выгорают, не вовлекаются или завышают сроки

Решение:

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

2. Страхи при взаимодействии с командой

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

Решение:

• Лучше сразу признаваться в сложностях и просить о помощи: “не понимаю, я не врубаюсь, помоги”. Конечно, в IT-командах могут встретиться и токсики, которые пошлют, но гораздо чаще люди помогут и не будут думать о тебе плохо. Тут нужно идти через страх, не боятся показаться глупым.
• Не делать вид, что ты всё понимаешь: чем ты  больше задаёшь вопросов, тем лучше, чтобы понять, о чем разработчики говорят. Это повышает доверие, открыто говорить ребятам, что ты чего-то не знаешь.
• Самое главное донести контекст задачи до разработчика, либо, если лояльный разработчик, то пригласить его на встречу со стейкхолдером или заказчиком. Когда разработчик понимает контекст, у него появляется интерес.

Команда разработки - это ваши партнеры (с). Не надо ставить себя выше или ниже, а также отдаляться от команды.

Заключение

Как мы писали гайд

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

Тип исследования: качественное исследование.

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

Респонденты: мы проводили интервью с респондентами из 3 основных групп:

• начинающие — Junior продакты со стажем работы до 2 лет, без внушительного технического бэкграунда;
• опытные: продакты уровней Middle со стажем работы от 3 лет, которые уже имеют опыт управления командой разработки или пришли из технических профессий: разработчик, бизнес-аналитик;
• эксперты: продакты уровней Senior, Head of Product и CTO, которые имеют опыт найма других продактов, членов команды разработки и глубоко разбираются в вопросах продуктовой разработки.

Сферы и компании, в которых работают респонденты: Fintech (СБЕР, Tinkoff), Edtech (Яндекс Практикум), Martech, SaaS b2b, Foodtech, Gamedev, Social Media, CRM.

Количество проведенных интервью: 20.

Кто работал над гайдом

Гайд написали мы, выпускники 4-го потока интенсива Валерии Розовой для продакт-менеджеров Wannabelike: Анастасия Сараева, Екатерина Гудач, Елена Чуйко, Олег Крылов, Зоя Мелешкова.

Отдельно хотим выразить благодарность за помощь в проведении исследования и написании гайда нашим респондентам и экспертам:

Александру Первухину, Александру Рубцову, Алёне Горопека, Андрею Менде, Антону Старцеву, Анне Дулеповой, Валерии Кулеминой, Виктории Минаевой, Давиду Осипову, Евгению Арнауту, Егору Лукьянову, Ирине Яхно, Ксении Касьян, Ксении Смирновой, Марии Царевой, Наталье Шевченко, Никите Ефремову, Ольге Проскуриной, Полине Гончарук, Станиславу Лабач, Шинар Есентаевой.

Как прокачать свои знания и навыки в разработке

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

Теория

Читать

• Scrum. Революционный метод управления проектами, Джефф Сазерленд
• Искусство объяснять,  Джефф Сазерленд
• Impact Mapping, Gojko Adzic
• How to speak Tech, Vinay Trivedi
• Архитектура приложений и интеграции: гайд по основным понятиям простыми словами / Хабр (habr.com)
• What Is A Product Spec? 10 Components Of A Great Product Spec — Reforge
• Creating Flow and Value in Product Development | Amplitude
• Why Continuous Delivery and DevOps are Product Managers' Best Friends - Mind the Product
• 3 steps to taming technical debt with Jira - Work Life by Atlassian
• The Product Managers' Guide to Continuous Delivery and DevOps - Mind the Product
• Why every development team needs continuous delivery (atlassian.com)
• Какие технические аспекты нужно обсудить с CTO на старте
• Разграничение обязанностей продакта и проджекта
• 11 друзей продакта. Проджект
• 11 друзей продакта. Тимлид
• Как оценивать задачу в стори поинтах и зачем это нужно
• Посты о том, что такое технических долг: раз, два
• Подборка постов про процессы и артефакты продуктовой разработки
• Какие аспекты обсудить с CTO на старте
• Канал о продуктовой разработке изнутри: https://t.me/product_developer
• Канал о продуктовом менеджменте и продуктовой разработке: https://t.me/vladimir_merkushev

Смотреть

• Продуктовая разработка в ЦИАН. Дмитрий Григорьев, ЦИАН - YouTube
• Продуктовая разработка в Dodo Pizza. Дмитрий Павлов - YouTube
• Современные процессы разработки — Дмитрий Сухолет - YouTube
• Современное техническое устройство сервисов — Павел Пушкарёв - YouTube
• Технические скиллы для менеджеров продукта для работы в tech гигантах за рубежом - YouTube
• АйТи Борода — канал белорусского айтишника, смотреть видео о реальных компаниях (“Как устроена Яндекс музыка”), интервью с разработчиками и другими техническими специалистами.

Слушать

• 19 вопросов про техническую сторону разработки для продакта: https://t.me/vladimir_merkushev/1198
• Как стать продакт-менеджером в IT слушать онлайн на Яндекс Музыке (yandex.ru)
• Железо, дата-центры и хостинги. Настоящий хардовый выпуск слушать онлайн на Яндекс Музыке (yandex.ru)
• Тестирование. Зачем тыкать на 1 000 кнопок в секунду и скармливать код мутантам слушать онлайн на Яндекс Музыке (yandex.ru)
• Запуск завтра: Окно в веб. Как работает браузер on Apple Podcasts
• Запуск завтра: [Запуск++] Python. Второй язык после английского on Apple Podcasts
• Запуск завтра: [Запуск++] JavaScript придумали за 10 дней, а он захватил веб. What? on Apple Podcasts
• Запуск завтра: [Запуск ++] С++. Как устроен один из самых востребованных языков программирования on Apple Podcasts
• Запуск завтра: [Запуск++] HTML, CSS и байки про фронтенд on Apple Podcasts
• О разработке hardware-продуктов — этапы, сложности, сроки и стоимость с Алексеем Пышкиным слушать онлайн на Яндекс Музыке (yandex.ru)
• О языке программирования как продукте с Андреем Бреславом и Егором Толстым слушать онлайн на Яндекс Музыке (yandex.ru)
• «Podlodka Podcast»: «Podlodka #321 – SQL» в Apple Podcasts
• «Podlodka Podcast»: «Podlodka #316 – Письменная культура в IT» в Apple Podcasts
• «Podlodka Podcast»: «Podlodka #308 – Ruby» в Apple Podcasts

Учиться

• Технические знания для продакта (productdo.it)
• Tech Skills for PMs & Business Leaders – Verbetcetera course (taplink.cc) — 6 занятий проходят онлайн, еще есть тестовое интервью, чтобы вы потренировались, если сейчас проходите отбор в международные компании. Все проходит на английском
• Learn SQL | Codecademy
• Курс по SQL на платформе Stepik с удобным тренажёрном
• Курс “Менеджер проектов” от Яндекс Практикум

Практика

• Реши тест на технические скиллы для продакта: https://kavaleuski.me/tech-test, отметь непонятные для себя слова и проблемы и составь краткий конспект
• Сборник задач для разработчиков https://leetcode.com/studyplan/top-100-liked/ - универсальный измеритель скилла разработчика. Некоторые из них соревнуются, сколько порешали задач из него. Ты можешь решать 20-30 задач в месяц по часу в день, чтобы лучше понять, как работает мышление разработчика
• Пойми принципы, как устроено программирование. Например, посмотри видео “как написать простого бота” на 2 языках (js, python, например) и попробуй сделать это самостоятельно
• Попробуй взять 2-3 простые задачи на разработку для себя. Можно подойти к разработчику и спросить: “Если ты мне напишешь инструкцию, как сделать эту задачу, я смогу её сделать самостоятельно?” И попробуй реализовать ее своими руками, так ты начнешь постепенно разбираться в контексте твоей команды разработки
• Составь для себя таблицу или карту языков и фреймворков, которые используют в твоем продукте, опиши их преимущества и недостатки. Для более подробного углубления спроси свою команду разработки, знакомых разработчиков и продактов