Дорогие читатели!
Погружаясь глубже в профессию продакт-менеджера (PM), решил написать цикл статей на продуктовую тему, в которых, вместе с вами рассмотрю ряд компетенций, важных как для старта, так и для развития в профессии.
Сегодня я остановлюсь на одной из "суперсил" PM - умении описывать задачи и передавать их разработчику или команде разработки, а также познакомлю вас с таким веб-сервисом как GitHub.
Для начала, мне хотелось бы сделать "трибьют" замечательному сообществу профессионалов Product University, которое вдохновило меня на написание данных строк.
Прежде чем я сфокусируюсь на теме сегодняшней статьи, немного введу вас в тему общего понимания кто же такой продакт-менеджер? (полагаю мою статью будут читать в том числе люди, знакомые с профессией даже не через одно рукопожатие)
Немного отклоняясь в сторону юмора, возможно PM это новый Александр Андреевич Чацкий, герой известной комедии Грибоедова, предвестник "сверхчеловека", только с поправкой на гипотезу, что он никогда не станет идеалистом, разочаровавшимся в своих идеалах. Из множества определений и формулировок должности в профессии, мне нравится простая и понятная - PM это предприниматель или entrepreneur внутри компании, результатом труда которого, является цифровой продукт, удовлетворяющий потребностям людей.
Какими "суперсилами" обладает PM?
- определяет видение продукта и его стратегию на каждом этапе жизненного цикла
- понимает потребности клиентов, постоянно исследуя их
- умеет работать с метриками и экономикой как продукта, так и рынка на который выходит с этим продуктом
- определяет какие компетенции нужны продукту и выставляет приоритеты
- синхронизирует работу над продуктом с общими бизнес целями компании
- взаимодействует с продуктовой командой, включая подкоманду разработки продукта
На последней "суперсиле", в части взаимодействия с разработчиками мы и остановимся сегодня. Коммуникации занимают до 50% времени в работе PM, и доля от этих коммуникаций приходится на описание задач и их постановку команде разработчиков. Разработчики, это по сути производители продукта для пользователей, целью работы которых, является оптимальным способом реализованная версия продукта, которая является наилучшей для сценариев и запросов пользователей. В зависимости от цели продукта или же его стадии, состав и количество разработчиков может варьироваться, но приведу список общих компетенций, которые нужны для разработки цифрового продукта, вне зависимости от количественного состава и должностей:
- руководство разработкой
- дизайн и проектирование продукта
- фронтэнд разработка - код той части продукта, которая видна пользователю
- бэкенд разработка - код той части продукта, которая не видна пользователю
- тестирование продукта - устранение ошибок и багов в функциональном исполнении продукта
Продакт-менеджер, тот человек, который на момент производства продукта, уже определил его стратегию, провел исследования аудитории, проанализировал и проверил различные гипотезы по продуктовым метрикам и продвижению продукта, самостоятельно или с помощью бизнес-команды разработал пользовательские сценарии, создал список задач и ранжировал их по степени важности. Соответственно, контекстом по задаче владеет PM, из чего логически складывается необходимость контроля процесса разработки и отслеживания статусов по задачам.
Каждый цифровой продукт, которым пользуется клиент - это реализация технического решения или комплекса решений, сложной либо простой логики. PM описывает задачи по пользовательским сценариям разработчикам, определяет требования к продукту. Совместно, должно быть принято решение о технических особенностях цифрового продукта, которые будут соответствовать смыслу и целям продукта, а также главному и сопутствующим каналам, через которые продукт должен "достучаться" до своей аудитории. Например, если это платформа, позволяющая пользователю слушать музыку, это одно техническое решение, если же это маркетплейс товаров и услуг, то технические требования к разработке платформы носят иной характер. Если просто, то в техническом типе реализации продукта, вклад ингредиентов PM в рецепт конечного блюда - контекст, потребности клиентов, сценарии, бизнес-цели, а ингредиенты разработчиков - технологии, фреймворки и платформы разработки, применяемые в создании продукта. В итоге получается подбор наилучшего рецепта, или генерация ответа на задачу - каким техническим характеристикам будет соответствовать продукт. Создавать конкретный список задач от PM разработчику я не буду, так как конкретные задачи могут различаться в зависимости от требований проекта или же стадии продукта (новый продукт для рынка или же запуск новой фичи в существующем продукте) но сформулирую общие важные параметры, которые должны быть учтены:
- требования к продукту должны быть тщательно изучены разработчиками, в том числе нефункциональные требования, для правильной реализации функциональности
- продукт должен соответствовать отработанным в процессе discovery пользовательским сценариям
- разработчики должны использовать свои знания и экспертизу, чтобы создать компоненты продукта
- пользователи продукта должны быть защищены
- законы должны соблюдаться
- продукт должен быть защищен от угроз
- нужно предусмотреть чтобы технический функционал продукта в будущем позволял решать вопросы по интеграции или масштабированию
Мы с вами легонько прикоснулись к части взаимодействия в области продуктовых метрик, но помимо работы над функциональностью продукта, продакт-менеджер и разработчики должны придерживаться производственных метрик в работе над продуктом, определять, какой объем работы и какие задачи в продуктовом бэклоге должны быть завершены за конкретный период времени, за конкретную итерацию. Это зона контроля продакт-менеджера (в данной статье я не буду касаться роли проектного менеджера и его отличия от PM) Реализация производственных коммуникаций в процессе разработки продукта может осуществляться в разных каналах, разными способами и с применением разной методологии, в зависимости от роли PM в процессе delivery и точки коммуникации в нем. Сегодня, мы представим сценарий, что бюджет на разработку продукта не позволяет ввести отдельную должность менеджера разработки, который управляет людьми в подкоманде разработки и PM покрывает эту роль и компетенцию, а значит одна из зон его ответственности, в соответствии с ролью - обеспечение взаимодействия и выбор технического инструмента для разработки продукта.
Одним из таковых инструментов является GitHub.
Что такое веб-сервис GitHub?
Представьте GitHub как расцветающий сад с множеством разных растений - проектов. Каждый проект - это уникальное растение со своими функциями и особенностями. Разработчики могут сотрудничать и садить новые "растения", делая сад GitHub еще красочнее и разнообразнее. Садовников и растений, или пользователей сервиса и проектов - миллионы.
Платформа поддерживает все популярные языки программирования, от JavaScript и Python, до Kotlin и Scala (согласно отчету веб-сервиса за 2022 год, самым популярным языком уже несколько лет остается JavaScript, "серебро" получает Python)
Веб-сервис можно сравнить с центральным хранилищем для кода и проектов, где разработчики могут работать вместе, отслеживать изменения, управлять версиями и сотрудничать над различными задачами. GitHub это:
- файловое хранилище - каждый проект это отдельная папка, на платформе именуются репозиториями, содержащими все файлы - компоненты проекта: исходный код, документацию, изображения, настройки и другие ресурсы
- социальная сеть для разработчиков - пользователи могут следить за другими разработчиками, ставить лайки, комментировать и обсуждать код и проекты
- платформа коллаборации - множество разработчиков могут работать над одним и тем же проектом, вносить изменения, рецензировать код и предлагать изменения через запросы на слияние - pull requests
- платформа для открытого и проектного программирования - хостинг открытых и приватных проектов, которые могут быть доступны для других разработчиков или ограничены конкретными участниками команды
- инструмент управления версиями - на основании распределенной системы контроля версий Git, предоставляет удобный интерфейс для отслеживания изменений, создания веток, объединения изменений и управления версиями проекта.
Система контроля версий Git - это распределенная система управления исходным кодом, разработанная Линусом Торвальдсом, которая позволяет разработчикам отслеживать изменения в исходном коде и кооперировать при работе над проектом. Существует ряд аналогов GitHub, которые также предоставляют сервис хостинга репозиториев и поддерживают систему контроля версий Git (GitLab, Bitbucket, Azure DevOps, etc.)
Как ставить задачи и работать с версиями?
Версии в GitHub, это различные состояния кода и проекта, сохраненные в репозитории и содержащие набор изменений, внесенных в код или файлы и имеющие уникальный идентификатор. Каждая версия называется commit и представляет из себя фиксацию конкретной версии кода в определенный момент времени. Коммиты содержат информацию об изменениях, авторе, дате и времени, а также уникальный хеш-код для идентификации. Можно просматривать и отслеживать историю коммитов в репозитории, откатывать код к предыдущим состояниям и создавать новые ветки - branch, что позволяет девелопить разные версии проекта параллельно. Сервис также дает возможность использования tags для указания конкретных значимых моментов в истории репозитория, например релизы или реперные точки проекта. Summary абзаца:
- коммиты - способ сохранения истории изменений
- ветки - отдельные линии разработки, которые позволяют вносить изменения в проект не затрагивая основную линию разработки, которые можно объединять с основной линией с помощью операции "слияние"
- теги - метки для коммитов, дающие возможность помечать важные моменты в истории проекта, например релизы
Возможность работать в ветках над различными версиями независимо друг от друга - отличный инструмент, нивелирующий конфликты в совместной работе. Кроме того, Git предлагает механизмы разрешения конфликтов при слиянии веток, например указывает на файлы в которых возникли противоречия.
GitHub замечателен тем, что позволяет организовать производство, непрерывность процесса и контроль, lean-менеджмент и коммуникационную сеть в одном месте, на одной платформе, в одном интерфейсе. При этом, как я уже писал выше, дает возможность группироваться в ветки. В контексте данной статьи, PM покрывает компетенцию менеджера разработки, которая детерминирует различные функции, одной из которых является постановка задач людям, пишущим код. В GitHub, задачи организуются в функционале issues, это вкладка на странице репозитория, позволяющая создавать новую задачу. Создавая задачу, важно помнить о степени важности понимания разработчиком конкретного требования к продукту, соответственно:
- заголовок задачи должен нести четкую и понятную суть, например:
"добавить функцию оплаты за товар"
- описание задачи должно содержать смысловую нагрузку операции, чтобы автор решения, реализующий задачу, понимал, какую работу конкретная задача или часть функциональности должна выполнять для конечного пользователя, например:
"мы хотим добавить функцию оплаты за товар в наш интернет-магазин, чтобы пользователи могли совершать покупки онлайн. Это позволит упростить процесс заказа и улучшить пользовательский опыт"
- требования к задаче должны быть структурированы и понятно описаны, например:
"интегрировать платежный шлюз (например ЮКасса) для обработки онлайн-платежей"
"разработать интерфейс для ввода данных карты и выбора способа оплаты"
"обеспечить безопасность и защиту данных пользователей при передачи информации о платеже"
"обработать успешное и неуспешное завершение платежа и обновить статус заказа соответственно"
- к требованиям по задаче, можно добавить дополнительную информацию, важную с точки зрения пользовательского опыта, например:
"платежный шлюз должен поддерживать популярные способы оплаты, такие как кредитные карты и электронные кошельки"
"реализуйте возможность сохранения данных карты для удобной повторной оплаты в будущем"
"обеспечьте пользовательскую интеракцию и обратную связь на каждом этапе оплаты"
Функциональность сервиса в части постановки задач, также позволяет производить их классификацию посредством меток. Например, можно добавить метку "enhancement" (улучшение) или "bag" (ошибка) - что сразу задает задаче нужный контекст. Также, можно назначить ответственного по задаче, добавив имя в поле "assignees" (назначенные). Задачи добавляются в проект с опцией установления дедлайна и направляется на исполнение.
Подводя итог задачи, важно сразу получить обратную связь от разработчиков и убедиться что задача понятна и принята в работу, собрать вопросы, и при их наличии, снабдить дополнительной информацией.
Функционал позволяет отслеживать состояние, комментировать, изменять приоритет, корректировать тип, предлагать изменения, обсуждать детали и следить за прогрессом. Для контроля статуса задачи, можно отслеживать количество открытых и закрытых задач в репозитории и в определенной метке. По факту выполнения задачи, ответственный закрывает ее и может добавить комментарий, например описать как складывался маршрут ее выполнения.
Хочется отметить, что широкий спектр возможностей, доступных в реализации производства и сопутствующих коммуникаций в GitHub, это инструменты, в которые встраиваются командные принципы, самоорганизация, планирование работы, система принятия решений и оценка результатов (инкрементов продукта) Иными словами, должен быть фрейм для управления процессом , который PM (действуя в этой роли) задает команде разработки и с помощью которого, вырабатываются общие командные паттерны поведения. А вот какие общепринятые своды правил и принципы, базирующиеся на разработанных методологиях будут в помощь PM в этом деле, я постараюсь раскрыть в своей следующей статье...
The profession that leads to a new lifestyle