- PVSM.RU - https://www.pvsm.ru -
В этой статье попробуем разобраться нужно ли инженеру продуктовое
Привет! Меня зовут Ил. И я работаю в стартапе. Нас около 20 человек – половина команды (русскоязычная) занимается технологиями, вторая половина (англоязычная) занимается бизнесом. Официальный язык общения – английский. Мы (как продукт, бизнес и команда) быстро растём, итерируемся, меняемся и развиваемся. Поэтому для нас критически важно чтобы было отличное взаимопонимание между бизнесом и технологиями. Обычно в компаниях эту функцию выполняют продуктовые менеджеры или аналитики. И у нас они тоже есть. Даже двое. Но каждый из них работает над продуктовыми задачами только 50% времени, совмещая эту роль с другими ролями. Поэтому суммируя, можно сказать что у нас в команде один Product Manager. А скорость изменений такая, что в полной мере формализовать, описать и декомпозировать задачи у PM-команды времени физически не хватает. Поэтому большинство задач у нас описываются достаточно высокоуровнево с акцентом на «что хотим получить после того как задача будет выполнена». Процесс декомпозиции задачи, поиск возможных путей решения, выбор оптимального способа и более детальная проработка задачи (в том числе с точки зрения требований и продукта) обычно делегируется инженерам.
Я бóльшую часть времени занимаюсь бэкендом, но как часто бывает в стартапах по факту занимаюсь очень разными задачами. Несколько примеров задач из реальной жизни (которые инженеры обычно не решают):
Сделать research по barcodes (штрих-коды на товарах). Понять какие для них есть международные стандарты, как они различаются в раличных странах, какой у них формат, как их валидировать и прочее;
Создать план тестирования и/или миграции для большой фичи меняющей поведение в критически важном месте системы;
Спроектировать новую архитектуру для критической части системы на основе опыта и ошибок первой версии. Сюда входит в том числе проработка и формализация новых требований, поиск того что нужно изменить в бизнес-процессах, проектирование сценариев работы и т.д.;
Поискать готовые 3rd party решения для той или иной задачи и оценить что в данный момент эффектнее – взять один из них или написать самим.
В какой-то момент я внезапно осознал, что непосредственно инженерными задачами я занимаюсь не более 50-60% времени. А иногда и того меньше. Вторая половина моего времени уходит на другие активности:
звонки, обсуждения, обмен знаниями о продукте;
интервью кандидатов, участие в hiring-процессах;
изучение PRD [2] (по русски — ТЗ), поиск в нём "багов" заложенных ещё на уровне описания идеи и логики, выявление слабых мест, поиск мест которые можно сделать лучше, проще или оптимальнее, оценка времени необходимого на разработку;
эксперименты, проверка гипотез (продуктовых), POC’и (proof-of-concepts);
написание спецификаций, инструкций и других документов для фрилансеров (часть задач мы аутсорсим) и коллег;
координация с другими командами и членами команд;
выявление слабых мест в процессах, и улучшение процессов;
поиск готовых решений для не mission critical задач (чтобы не изобретать велосипед) и анализ как прагматичнее поступить в конкретном случае – запилить своё решение или взять готовое;
smoke-тестирование;
работа с продуктовыми метриками в Amplitude;
генерация кастомных отчётов.
Ещё один важный момент. Когда мы обсуждаем новую фичу (либо для фичи уже есть PRD, и мы делаем техническое ревью) требования почти всегда очень туманные, и бизнес команда смутно понимает чего хочет. Поэтому существенная часть времени уходит на то чтобы:
понять чего хочет бизнес;
понять чего хочет бизнес на самом деле (обычно 20-50% требований меняется в процессе обсуждения, ещё до начала реализации);
уточнить неочевидные детали, краевые случаи;
проанализировать и найти оптимальное техническое решение.
При этом крайне желательно донести до всей команды особенности выбранного в итоге решения, в том числе его ограничения и недостатки. Потому что выбранный вариант решения задачи это почти всегда trade off (причём достаточно жёсткий): между скоростью разработки, качеством, масштабируемостью и расширяемостью.
Все перечисленные факторы приводят к тому что становится критически важно мыслить не только инженерными ценностями (должно работать быстро, стабильно, безопасно) но и продуктовыми (с вероятностью 80% через несколько месяцев мы удалим этот код или полностью его перепишем). Если не подходить в ежедневной работе с подобной точки зрения, удовлетворённость от работы очень сильно снижается.
Ещё одна важная культурная деталь нашей команды – достаточно плоская структура и то, что каждый инженер лично отвечает за свою задачу, от момента её придумывания до user adoption. И написание кода это лишь один из этапов. «Лично отвечает» – не значит что если что-то пойдёт не так, то человека уволят или лишат премии. Нет. Это значит что нужно будет вернуться назад и переделать. И прагматичное, рациональное, продуктовое
У такого режима работы определённо есть как плюсы, так и минусы. Попробуем в них разобраться.
Разберём плюсы. Почему это круто:
Ты намного лучше понимаешь приоритеты, чётко знаешь что важно, а что второстепенно (в мире стартапов "второстепенно" и "не важно" по сути синонимы). Следовательно, понимаешь каким частям кода следует уделять больше внимание, а в каких в данный момент можно на*****кодить
Ты начнёшь понимать мотивы продуктовых решений, почему решили сделать так, а не иначе. Соответственно ты будешь в курсе дальнейших планов на проект/фичу. Это поможет выстроить более адекватную архитектуру
Тебе будут чаще давать более глубокие, сложные, интересные задачи. Ты получишь больше свободы. И больше ответсвенности
Это интересно. Понимать продуктовые метрики и особенности поведения пользователей – это увлекательно. И это затягивает
Когда начнёшь думать не только о коде, но и о продукте, у тебя постепенно начнёт меняться
Качество твоих фич и решений будет увеличиваться. Как следствие, качество всего продукта тоже будет расти. Вместе с продуктом, твоя ценность в команде тоже будет становится всё больше
Тебе откроются новые возможности – это может стать первым шагом к своему стартапу, или крутой карьере в FAANG [3], или повышению на текущем месте, или удачному exit-у (если у тебя есть опционы)
Почему это не круто:
Частые смены контекста вредят здоровью. Они не только значительно повышают уровень стресса, но и могут пагубно влиять на
Тебе придётся делать то, что раньше ты скорее всего никогда не делал, потому что это делали за тебя твои коллеги. Например: работать с системами продуктовой аналитики, системами для рекламы, маркетинга, сервисами для мокапов, прототипирования, дизайна. Тебе придётся разбираться с множеством смежных областей и инструментов в этих областаях. Быть проактивным. Пушить других людей, если они не реагируют вовремя (в том числе твоих менеджеров). Назначать встречи/звонки. И это не вместо кодинга, а вместе с кодингом
Ты начнёшь замечать конфликты в своём
Определённости и чётких ответов в твоей жизни станет ещё меньше, чем сейчас
Вот мы и подходим к тому, с чего начали в заголовке статьи.
Термин Product Engineer пока ещё не очень популярен, но я думаю что в скором времени его популярность будет расти. Возможно для этой роли придумают другие названия, но суть не поменяется.
Драйверов развития этой роли несколько:
Новым IT-компаниям становится сложнее найти своё место на рынке, юникорны появляются всё реже. При этом зарплаты инженеров продолжают расти, как и общие затраты на команды. Ведь с насыщением и усложнением индустрии растёт и количество человеко-часов которые нужно инвестировать чтобы построить успешную высокотехнологичную компанию. В таких условиях продуктовые инженеры могут оказаться редкими покемонами, которых хочет к себе в команду любой стартап. Ведь один человек способен закрыть сразу две позиции (а как бонус ещё и меньше overhead’а на коммуникацию)
Сейчас наблюдается бум продакт менеджеров. Появилось много курсов на которых их обучают, некоторые из них дают реально очень качественные знания. В продакт менеджеры переходят из смежных сфер (разработка, дизайн, тестирование, аналитика) и из совсем других сфер. Это говорит о том, что в целом в индустрии есть постоянно растущий спрос на людей способных создавать и развивать продукты.
В таких условиях, с учётом того что продуктовый менеджмент будет усложняться, вполне гармонично может появиться новая роль на стыке между инженерами и менеджерами – продуктовый инженер. Примеров появления новых профессий на стыке двух других уже было очень много:
Сисадмин/программист → DevOps;
Программист/бизнесмен → Product Manager;
Рекламщик/веб-мастер → SEO-шник.
Достаточно отважен и хабр храбр?
Успей запрыгнуть в поезд! Но помни – тормозов у этого поезда, похоже, нет.
Автор: Илья
Источник [6]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/360439
Ссылки в тексте:
[1] мышление: http://www.braintools.ru
[2] PRD: https://en.wikipedia.org/wiki/Product_requirements_document
[3] FAANG: https://www.businessinsider.com/what-is-faang
[4] 1: https://www.forbes.com/sites/travisbradberry/2014/10/08/multitasking-damages-your-brain-and-career-new-studies-suggest/
[5] 2: https://www.inc.com/geoffrey-james/multitasking-reduces-your-intelligence-by-17.html
[6] Источник: https://habr.com/ru/post/536266/?utm_source=habrahabr&utm_medium=rss&utm_campaign=536266
Нажмите здесь для печати.