Привет! Меня зовут Михаил Чинаков. Я работаю продактом в крупном онлайн-магазине с бесплатной доставкой. В этой статье я расскажу, какие навыки нужны для моей должности и как я получил их прямо на рабочем месте.
С чего я начинал, когда ещё не был продактом и почему это оказалось важным
В конце 2020 года один из выпускников моего вуза вместе с партнёром запустил стартап доставки продуктов в Нью-Йорке — «1520». Так как у меня был понятный для них бэкграунд и общие знакомые, меня позвали в проект на неполный день.
Михаил Чинаков
Стал продактом, потому что пришлось
Тогда у компании не было ещё ни одного склада. Собственники планировали разработать приложение. Главной задачей было составить ассортимент первой тысячи SKU (единица складского учёта), которая бы попала к нам на полки. Я анализировал парсы ассортимента других компаний и делал продуктовые карточки, подготавливал контент, чтобы загружать его в систему.
Поскольку это был стартап, то заниматься приходилось всем. Мои обязанности были такими:
Операционная деятельность.
Аналитика: BI-дашборды, динамика среднего чека, выручка, среднее время заказов, доставки, сборки.
Исследования: рассчитывал описательные статистики для проверки гипотез или отслеживания результатов, следил за структурой продаж по категориям, то есть какие категории чаще встречаются в самых дорогих заказах.
Скрипты на Python.
Закупки и отслеживание наличия ассортимента на складе.
Как меня затянуло в продакты, что я сам не заметил
Со временем стало понятно: нельзя, чтобы один человек делал закупки на несколько складов вручную. Так у меня появилось две задачи:
Первая — автоматизировать процесс закупок. Нужно было написать небольшой скрипт на Python, который бы позволил пользователю получать удобоваримые отчёты для оценки товародвижения: какие товары стоит закупать, а какие нет.
Вторая — обучить новоиспечённую операционную команду в Америке. Я несколько месяцев показывал, как пользоваться скриптом, как работает ландшафт и решение для всех закупок.
Практически все свои задачи по закупкам и ведению контента я передал операционной команде, а у меня появился новый фронт работы в отделе разработки — я стал продактом. Команда разработки у нас была небольшая: два бэкендера, два фронтендера, QA, дизайнер, СPO. Я должен был информировать CEO о том, что происходит в разработке, бегал по всем сотрудникам и спрашивал, что происходит, еженедельно писал, что релизим или только собираемся. Это помогло стабилизировать релизный цикл, настроить процесс: планирование, ретро, расстановка задач.
В работе помогал большой операционный опыт, поэтому я выполнял обязанности ещё и продуктового аналитика: консультировал, как правильно делать софт с точки зрения процесса реализации. Всего у нас было три больших блока программных продуктов:
Клиентское приложение.
Приложение для работы курьеров.
Широкий спектр всех инфраструктурных сервисов: сервис, который отвечает за управление складами, управление сервисными зонами и так далее.
Плюс была WMS-система как коробочное решение, которое мы потихоньку переписывали.
Какие знания и навыки нужны продакту и какие из них можно освоить на ходу
Когда я только пришёл, большинство задач выполнял без специфических знаний. Главным преимуществом была способность быстро и хорошо учиться. Я мог работать в Excel, и это очень помогло, а всё остальное освоил по пути: SQL, Python, BI-инструменты, принципы работы веб- и мобильных приложений, особенности архитектуры, написание архитектуры приложения на Kotlin, и вообще всё, что мне нужно было знать.
На ходу пришлось осваивать Figma. Знание этого инструмента хотя бы на минимальном уровне пригодиться любому продакту. Потому что есть компании, где должности дизайнера и продакта совмещены. Даже если нет, часто приходится рисовать прототипы, прежде чем отдать проект дизайнеру. В свою очередь, дизайнеры свою работу тоже показывают в Figma.
В работе продакта удобно использовать трекер-системы. Их много и использовать можно по своему вкусу. Самая популярная — Jira. А документацию удобно вести в Confluence.
Базовые аналитические инструменты: SQL и Excel
Excel нужен, чтобы посчитать, получить данные, сверстать их в нужном формате и представить отчёт. Это необходимо почти на любой позиции, хоть как-то связанной с аналитикой. Чтобы работать с ассортиментом, нужно было создавать шаблон данных, которые я загружал в систему. Я составлял таблицу данных, пользовался функциями типа ВПР, чтобы собирать данные из разных таблиц или из SQL, выгружал цены из базы данных, чтобы это всё сопоставлять.
Python
Не могу сказать, что это must have, но знать его полезно. Python — очень гибкий язык разработки. На нём можно написать что угодно. Хардовые аналитики ценятся, если имеют представление о Python. Это действительно очень полезный навык.
Базовых знаний вместе с умением разбираться поверхностно в библиотеках и в функциях хватает, чтобы на коленке создавать промежуточные решения. Они могут быть ужасны, но даже такие лучше, чем ничего.
Приведу пример из практики. Передо мной стояла задача создать скрипт для реализации нескольких задач:
Запрос в WMS-систему, которая хранила данные о наших товарах, поставках на складах и товародвижении, о том, сколько товара мы продали, сколько списали и сколько лежит ещё на складе.
Подсчёт простых прогнозных метрик на основе полученного датасета: через сколько дней товар закончится, что нужно заказать.
Загрузка нужных данных в Google таблицы.
Мне пригодились две библиотеки в Python: pandas и NumPy. В них можно обработать данные, присвоить переменной значение таблицы, можно эту таблицу отформатировать, присоединить строки одной таблицы к другой, столбцы одной таблицы к другой, можно что-нибудь рассчитать и результат этого расчёта присовокупить к таблице.
API Google таблиц и WMS-систем
Программу мы запустили. Она делала запрос в систему, обсчитывала, создавала датасет и выгружала его в гугл таблицы. Но чтобы это всё заработало, мне потребовалось разобраться, как работает API Google-таблиц. Это всё хорошо задокументировано, прозрачно и доступно для изучения. API WMS-системы тоже подробно описаны: какие бывают методы, что можно спросить у WMS-системы и что она даст в ответ.
Веб-сервисы и принципы хранения данных
Без знания принципов работы сервисов не получится сделать техническое задание для программиста. Если упрощённо, программа — это всегда алгоритм, который получает одну информацию, отдаёт другую. Нужно понимать, как происходит взаимодействие баз данных, какой за этим стоит пользовательский интерфейс, какие алгоритмы под капотом сервисов. Как минимум представлять, что программа может посчитать сама, а что нужно сделать пользователю. Продакту важно понимать, какие обязанности у фронтенда и бэкенда, понимать, какая часть сервиса относится к интерфейсу, а какая — данные и инструментарий, который связывает таблицу с интерфейсом, делает расчёты, совершает действия после нажатия кнопки.
Базовые знания об архитектурах систем требуются везде или практически везде. Если вы хотите разработать программу, нужно составить чек-лист:
Написать, что должно происходить на фронтенде, какие должны быть кнопки, какой путь должен пройти пользователь, какой процесс он должен там реализовать.
Написать, что для этого должно происходить на бэкенде, какие данные собирать, как их обработать и что выдать в итоге.
Написать, какие данные в какие таблицы должны складываться.
BI-инструменты
Помогают строить графики на основе ваших данных и отслеживать важные метрики.
С их помощью я отслеживал средний чек, выручку, среднее время доставки и другие показатели, важные для бизнеса. Можно было бы каждый раз обращаться к базе данных, хранить их в Excel-документе и формировать ежедневные отчёты. Я воспользовался BI-инструментами, которые входили в базу данных за меня, брали необходимые данные и рисовали на их основе графики.
Эти инструменты можно использовать для разных целей. Я с их помощью две задачи:
Создавал описательные дашборды. Мне дали дежурный список нужных графиков, чтобы отслеживать основные операционные и коммерческие показатели: средний чек, выручка в разрезе по складам и так далее.
Решал частные задачи. Чтобы повысить чек, мы построили несколько дашбордов, которые в разных разрезах смотрели на пользователя. Построили таблицу, которая показывала структуры заказов по когортам, ценовым диапазонам — какой процент заказов был сделан с диапазоном среднего чека от 0 до 10 долларов, от 10 до 20 и так далее. Делали это, чтобы понимать, за счёт чего средний чек высокий или низкий.
Работа с BI-инструментами проще, чем кажется, любой десятиклассник может за два часа разобраться. Состоит из двух частей:
Настройка подключения к базе данных.
Построение графиков.
Как говорить с командой на одном языке
Работа с дизайнерами простая и приятная, они рисуют то, что вы представляете, и представляют вместе с вами. Продуктовый дизайнер на самом деле немножко продакт, просто он рисует, а продакт общается с другими людьми, чтобы собрать информацию о потребностях. Поэтому часто они уже говорят на одном языке.
Разработчиков не нужно просить быть продактами
С разработчиком не стоит обсуждать идеи продукта. То, что для бизнеса звучит как «давайте поставим другую кнопку», для разработчика звучит как «давайте построим архитектуру иначе». К разработчику нужно идти с пониманием, какие функции нужно реализовать.
Разработчик — человек, который продуктовые требования переводит в код. Поэтому к нему нужно приходить с техническим заданием и помогать разобраться в том, как правильно реализовать то, что вы придумали. Важно договориться о том, как будет выглядеть техническое задание заранее и соблюдать этот формат взаимодействия. Единой формы ТЗ нет, в каждой компании оформление документации может отличаться.
Для наглядности: вы продумываете механику скидок и хотите, чтобы поверх карточки продукта появлялась скидочная цена в течение установленного срока. И это нужно представлять и объяснить разработчику, а не спрашивать его, как лучше.
Две ключевых особенности работы продакта в стартапе и корпорации
Документация — это важно
У меня был опыт работы без документации в стартапе. Это было ужасно. Идеи возникали на ходу. Мы сразу же их тестировали и реализовывали. Когда команда небольшая, это ещё работает. Но с увеличением количества людей в команде проблемы нарастают как снежный ком. Люди перестают понимать, где и какую информацию им брать, где актуальные данные.
В больших компаниях требуют записывать всё, что вы делаете. Поначалу кажется странным фиксировать каждый шаг, кажется, если пропустить этот пункт, работать можно в пять раз быстрее. Со временем понимаешь: если ничего не записывать, начнутся проблемы с масштабированием. Придёт новый человек, придётся очень долго вникать в то, что происходит, читать код. Это тормозит работу. Продакт должен уметь составлять документацию быстро и вести её регулярно, тогда это не будет так сильно напрягать.
Объём работы нужно распределять
Когда я работал в стартапе, объём задач был огромный. Выходных не было несколько месяцев. Спектр задач был такой широкий, что касался практически всего, чем занимается бизнес.
В стартапе ты очень быстро бежишь. В большинстве задач тебе нужно сделать хоть что-то, чтобы оно начало работать. Ты на пустой поляне. Поэтому ты сделал минимум, и оно заработало. А вот масштабировать и дорабатывать стартап должны уже другие люди. Нужно расширять команду, которая будет создавать комплексные решения.
В крупной компании я уже понимал, что и как устроено, как ведутся дела: что такое складские операции, как организуется доставка, как должно работать приложение для пользователя. Но и круг обязанностей уже чётко очерчен. График нормированный. А объём работ распределяется на всех членов команды.
В стартапе вы точно научитесь многому и быстро, но и времени на раскачку не будет. В крупной компании обучаться можно постепенно, но работать вы будете в команде и придётся развивать коммуникативные навыки.
Продакт это не человек, которому говорят, что нужно делать. Это человек, который говорит, что делать.
Главное в работе продакта — никогда не останавливаться в развитии. Нужно максимально разбираться в бизнес-процессах, дизайне, разработке, аналитике. Всё это помогает правильно оценивать задачи, разбираться, почему не сработала та или иная фича. А в итоге производить продукт, который принесёт прибыль.