Инженер с продуктовым мышлением: кто он и зачем компании
Привет! Меня зовут Александр. Я продакт-менеджер с инженерным бэкграундом. Вот уже 11 лет я работаю в компании Railsware, где вместе с командой развиваю культуру продуктового подхода к веб-разработке. Будучи инженером больше 10 лет, я постепенно начал брать на себя дополнительные активности на проектах, в которых частично участвовал. Это помогло мне на практике почувствовать себя в смежных ролях, не отходя от написания кода.
Сегодня я с удовольствием делюсь с вами опытом расширения профессиональных возможностей и повышения своей ценности как инженера для проекта и компании в целом.
Этот материал будет полезен для инженеров, которые хотят развиваться в продуктовом направлении, продолжая писать код. Продакт-менеджеры также смогут почерпнуть для себя важные моменты, которые помогут им в коллаборации с командой.
Среда, которая влияет на карьерный выбор
ИТ-индустрия молода и все еще продолжает формироваться. Она пока далека от того же сельского хозяйства, где процессы, роли и модели планирования уже давно устоялись. При том, что по всему миру технологии внедрялись относительно в одно и то же время, некоторые различия в регионах все же есть. Это значит, что бизнес-культура и типичный карьерный рост специалистов явно отличаются. Например, спрос на навыки в Восточной Европе далек от того, что в Северной Америке. Отличаются не только названия должностей, но и их наполнение.
Состояние отрасли неизбежно влияет на наш карьерный путь. Например, в Восточной Европе и Юго-Восточной Азии преобладает бизнес-модель аутсорсинга, что требует от специалиста наличия определенного набора навыков и мышления. Главная особенность этой модели в том, что команда разработчиков не участвует в процессе создания продукта от А до Я, видя лишь ту часть, которую ей передали в аутсорс. Здесь есть свои преимущества, но главный недостаток состоит в том, что без понимания целостной картины проекта, у специалистов часто формируется неправильная причинно-следственная модель. Например, когда проект закрывается с неясным комментарием от бизнеса «закончился бюджет», команда R&D может интерпретировать это как «слишком много потрачено на маркетинг и недостаточно инвестировано в улучшение кодовой базы». Это происходит потому, что команда видит лишь код, и не располагает в полной мере информацией, чтобы сделать другой вывод. В действительности же все может выглядеть иначе: «слишком много ресурсов потрачено на полнофункциональный продукт, недостаточно быстро внедряли инновации и проиграли конкуренту».
Во всем мире уже давно наблюдается культурный сдвиг от классической каскадной модели разработки и корпоративных процессов к более простой — где реализация проекта быстрее, а команды меньше и не изолированы друг от друга. Это означает, что в организациях стираются явные границы ответственности. 15 лет назад в украинских компаниях было обычным делом, когда менеджеры согласовывали требования и вели все коммуникации, инженеры писали код, а тестировщики занимались тестами. Если у клиента возникали вопросы к качеству продукта, а QA интересовали конечные пользователи, каждому приходилось миновать несколько уровней коммуникаций. Это было утомительно, демотивировало задавать вопросы и интересоваться смежными направлениями. Сегодня QA может напрямую общаться с клиентом, а клиент может присутствовать на стендапах команды разработки.
Очевидно, что акценты смещаются в сторону широкопрофильных специалистов, которых мы также называем T-shaped специалистами. Это люди, талантливые в своем ремесле, которые также имеют определенные знания в других областях и способны видеть более широкую картину проекта. Инженеры не исключение. В Railsware мы всегда уделяли много внимания идее продукта, проблемам, которые продукт должен решать, а также процессам разработки и чистоте кода. Инженеры подключаются к проекту со дня обсуждения идеи и участвуют во многих смежных активностях. Это помогает глубже понять предметную область, для которой разрабатывается продукт.
Таким образом у нас в компании сформировалось понятие роли продакт-инженера. Кто он и в чем суть этой роли? Инженер по продукту — это парадигма, в которой инженер понимает общую картину проекта и может повлиять на любую часть разработки. Здесь инженеры не просто пишут код, они создают продукт.
Я предлагаю не вдаваться в теорию и разобрать основные характеристики продакт инженеров на реальных кейсах, с которыми я лично сталкивался. Дальше в этой статье мы поговорим про:
- важность коммуникативных навыков у инженера;
- работу с требованиями и приоритезацию;
- ориентацию на долгосрочное взаимодействие и работу над общими целями;
- подготовку демо как процесс, который помогает делиться результатами и получить обратную связь.
Коммуникации: do you read me?
Разработка продуктов — это командный вид спорта, где участники просто обязаны говорить на одном языке, понятном для всей команды. В противном случае есть все шансы столкнуться с недоразумениями.
Разработку продукта можно сравнить со строительством дома или ремонтом квартиры. Ведь это тоже сложные проекты, в которых неизбежно пересекаются специалисты разных профилей. Без хотя бы примерного понимания полной картины работ, а также желания найти со всеми общий язык, проект может, в лучшем случае, затянуться, в худшем — развалиться на этапе фундамента.
Представим, что команда должна разработать новую фичу — мастер оценки в государственной больнице. Анкета должна помочь оценить качество работы больницы и сформировать в конце общий балл. Проверяющий бы пришел в больницу и, воспользовавшись данной функцией, отметил, что хорошо, что плохо, и сформировал отчет. Для разработки такой фичи инженер формулирует ряд задач: на создание моделей и таблиц в базе данных, визуализации и API. Начинается разработка.
Через некоторое время QA спросит, что он может протестировать. И тут начинается самое интересное :) Рассмотрим два варианта развития событий:
Негативный. «Вы можете запустить AddHospitalController и StartAssessmentController с начальными данными и проверить, что таблицы Hospital, Cleanliness и Maintenance заполнены в базе данных. А затем можете проверить, отображает ли ScoringView все оценки». Для QA это будет звучать как птичий язык, и он явно захочет подождать финального пользовательского интерфейса. Очевидно, что тестирование отложится, и логические ошибки будут обнаружены на более поздних этапах.
Позитивный. «Мы реализовали логику для оценочных листов в больнице, но пользовательского интерфейса пока нет. У нас есть лишь упрощенный интерфейс, чтобы увидеть список оценок». С таким ответом QA, вероятно, попросит создать простой пользовательский интерфейс для тестирования добавления больниц и оценочных листов, или же спросит, как это сделать с консоли. В таком случае логические ошибки (например, в иерархии критериев оценки) будут обнаружены уже сейчас.
Иногда достаточно просто иметь возможность экспортировать данные из приложения, если пользовательский интерфейс сложный и еще не готов, или же показать его в сгенерированной панели администратора для дальнейшей проверки.
Стивен Кови в своей книге «The 7 Habits of Highly Effective People» выделил три уровня взаимодействия людей в группе: зависимость, независимость и взаимозависимость.
- Зависимость. Худший случай, когда все зависят друг от друга. Здесь зависимость — это «ты заботишься обо мне». В таком случае возникают блокеры, которые не позволяют двигаться вперед. Снижается скорость и могут возникать конфликты.
- Независимость. Когда специалист может все или многое делать самостоятельно и действует независимо. Для этого не нужно быть экспертом во всех областях, но вы всегда можете разблокировать себя. Т-shaped специалисты обычно независимы во многих аспектах. Они понимают общий контекст в рамках своего основного навыка, могут играть разные роли и говорить на понятном для всех языке.
- Взаимозависимость. Кажется, что предыдущий уровень — самый оптимальный, но это не так. Дело в том, что независимость все же имеет свои границы. Да и один в поле не воин... Гораздо позитивнее все развивается на следующем уровне — взаимозависимости. Здесь все участники команды повышают навыки друг друга, помогают и понимают друг друга. Они с легкостью взаимозаменяются при необходимости. Важно то, что каждый вносит свой вклад в общий успех продукта и принимает лучшие решения во время такой командной работы.
Работая на проекте, важно помнить, что все движутся к одной цели, и стараться сохранять единство. Формулировать свои потребности так, чтобы информация была понятна не только техническим специалистам. Быть ответственным и переживать не только за свой кусок работы, но и думать о коллегах, которые будут продолжать работать над продуктом, используя ваши наработки.
Работа с требованиями
Общей цели не всегда достаточно для слаженной работы. Согласованные действия и четкие коммуникации играют важную роль, ровно так же, как и уровень причастности инженера к созданию продукта в целом.
Я уверен, что многие инженеры сталкивались с непонятными требованиями. Здесь можно выбрать путь пассивного слушателя и покорно писать код согласно предоставленным требованиям, а позже тратить время на рефакторинг, если не все ваши догадки оказались верными. Продакт-инженер, скорее всего, пойдет другим путем: он с самого начала примет участие в составлении требований и посоветует, что можно улучшить, если увидит такую возможность.
Иногда кажется, что если бы продакт-менеджеры готовили четкие требования, то код приложения можно было бы писать прямо по ним. Насколько подробными должны быть требования к коду? Я думаю, это одна из самых горячих тем.
Преобразовать бизнес-требования в функциональную систему сложно, и многие вещи могут пойти не так. Кроме того, ни одно из требований не бывает исчерпывающим. Никогда. Потому что невозможно продумать все заранее. Именно поэтому коммуникация между инженерными командами и бизнесом является здесь ключевой. Основное правило для бизнеса — это объяснять, что нужно сделать, а не как. Вы ведь не хотите, чтобы менеджер или генеральный директор указывал вам, как надо выполнять вашу работу. Тем не менее часто дискуссии поднимаются как раз относительно того, «как».
Однажды нам нужно было классифицировать строки согласно десяти условиям: количество слов в строках, наличие в этих строках определенных слов или их комбинаций. Звучит легко до тех пор, пока не погрузишься глубоко в задачу. Позже обнаружилось, что некоторые строки могут попадать в несколько категорий или что формы множественного / единственного числа и статьи влияют на категоризацию. Было слишком много граничных условий, и инженер потребовал описать алгоритм категоризации.
Частично из любопытства, частично из желания помочь и ускорить разработку, продакт-менеджер решил углубиться в детализацию требований.
Помимо примеров для всех возможных случаев, он добавил утверждение «if-else» и приоритеты для каждой категории. Например, если несколько категорий совпадают в одной строке или не совпадают никакие категории. Конечно, это был далеко не идеальный план реализации, и возникало все больше вопросов, которые продакт-менеджер продолжал описывать в требованиях.
Проделав колоссальнаю работу, оказалось, что это не решило проблему: реализованная категоризация работала плохо и медленно, а инженер продолжал жаловаться на качество требований.
В конце концов пришлось все переделать с нуля. Организовали сессию, на которой команда вручную классифицировала множество примеров, объясняя, почему та или иная строка перемещается в определенную категорию. На этот раз все сработало. Такое описание помогло инженеру построить в голове собственную модель, которая не имела ничего общего с документом «if-else», который составил продакт-менеджер.
А вот еще один случай: как-то инженер решил уточнить у продакт-менеджера детали реализации, потому что при внедрении предыдущей фичи ему пришлось переписать некоторые части кода. Изначально требования были неоднозначными, но он продолжил работу, положась на свои догадки. Позже выяснилось, что некоторые предположения оказались неверными.
Чтобы избежать похожей ситуации, для следующей фичи он описал бизнес-требования используя BDD-подход, в котором вместо реальных функций и переменных используются понятные для нетехнического специалиста описания. Над таким уровнем детализации инженер и продакт-менеджер с легкостью могли работать вместе и отлавливать логические ошибки.
Классический пример Railsware с Calendly: владелец Calendly пришел к нам со своей идеей продукта, и захотел внедрить все возможные интеграции с разными календарями одновременно. Мы задокументировали все требования должным образом и помогли сосредоточиться лишь на одной интеграции с календарем Google, поскольку он был самым популярным. К нашему совету прислушались. Сегодня Calendly — это многомиллиардный продукт, и они все еще работают над этими интеграциями.
Видя более широку картину продукта, которая выходит за рамки кода, мы можем быть более проницательными, творческими, и приносить больше ценности в долгосрочной перспективе.
Ориентация на долгосрочную перспективу
В большинстве случаев инженер может не видеть долгосрочную перспективу свой работы для продукта. Он занят своей частью проекта, без малейшего понятия и желания знать, что будет происходить с его кодом дальше. Такой подход приводит в лучшем случае к ситуация, когда вроде бы и работы сделано много, и усилия приложены большие, и эстимейтов придерживались, но результат ни к чему не привел. Что еще больше, бизнес остался недоволен. Но в худшем случае все сводится к тому, что большую часть проделанной работы нужно переписывать или рефакторить после каждой итерации, потому что изначально не было понимания целостной картины и конечного результата. Дедлайны двигаются бесконечно, все вокруг нервничают, создается давление и всеобщие упреки.
Одной из таких ситуаций я хотел бы поделиться. Она возникла на проекте, который занимается импортом данных с различных приложение (Hubspot, Xero, Shopify, etc). Работа с данными имеет свою специфику, так как некоторые сервисы не могут возвращать данные достаточно быстро, а иногда таких данных может быть очень много.
Разработчик взялся за задачу формата данных, в котором продукт сохраняет информацию. Эта работа заняла некоторое время, но в конце оказалось, что тот формат данных не поддерживает дата-стриминг, который является необходимым при работе с большим количеством данных. Пришлось потратить дополнительное время, чтобы переделать решение. В результате задержался релиз, и стоимость проекта для бизнеса возросла. Это хороший пример того, как без понимания долгосрочных целей, конечного результата и целостной картины, можно негативно влиять на продукт.
В тоже время, работая над интерфейсом визарда в Coupler.io мы изначально вовлекли всю команду на самых начальных этапах. Инженеры участвовали над ревью ресерчей и прототипа интерфейса, который подготавливал продакт-дизайнер. Они видели результаты тестирования прототипа, которое проводил продакт менеджер вместе с пользователями. Помогали планировать этапы разработки, чтобы выпустить первую версию в продакшин как можно быстрее. И уже после этого все двигались шаг за шагом к конечному варианту, который был запланирован.
Таким образом получилось избавиться от постоянных стадий рефакторинга и даже, когда нужно было вносить незапланированные изменения в поведение фичи продукта, инженеры знали об этом на очень ранних этапах, видя и понимая конечную долгосрочную цель, к которой двигается команда.
Демо, которое всем интересно и понятно
Демо помогает поделиться своими результатами и получать обратную связь. Для инженера эта задача может оказаться не всегда такой простой, как кажется. Тем не менее, усилия того стоят.
Умение оформить демо своей работы для команды или клиента — это важный коммуникативный навык, который, к сожалению, часто недооценивают. Продакт-инженеры должны уметь делиться результатами своей работы, и понимать, что есть другие команды, чья работа также зависит от качества их результатов. Именно поэтому важно оформлять демо презентации с пониманием, для чего ты это делаешь и желанием поделиться с командой результатами своей работы.
Представьте, что у вас запланировано демо в конце итерации, и инженер говорит: «у меня нет ничего для демо, это все бэкэнд». Или такой вариант: инженер буквально перечисляет все реализованные им функции и классы, что вовсе не будет полезно для команды и окажется пустой тратой времени.
И в первом, и во втором случае, основная мысль, которую мы прочитаем между строк: «я сделал что-то настолько скучное, что даже не хочу делиться этим» или «я что-то сделал, но не уверен в конечной цели и не могу оценить результат». Команда может сделать свой вывод: «этот парень не приносит ценности продукту»
Некоторые думают, что работу над back-end и DevOps нельзя задемить. Однако, даже такую работу всегда можно представить в виде простой визуализации архитектуры в виде блок-схемы, рассказать на этом примере почему была использована именно такая модель, на какие компромиссы пришлось пойти, и как это приближает нас к первой версии фичи. Такая презентация даст прекрасный контекст для всех участников команды.
Инженеру важно помнить, почему и для чего он передает информацию, какова цель его работы и общая цель команды. Изучите свою аудиторию и говорите на понятном ей языке, добавьте в демо что-нибудь личное — что вам было трудно или что вам больше всего понравилось.
С командой Coupler.io мы проводим демо-сессии раз в две недели. В них участвует вся команда: разработчики, маркетологи, дизайнеры, контентщики, аналитики, а также ребята из поддержки. Такие сессии помогают команде поддержки понять, как изменения в продукте влияют на их взаимодействие с клиентом, какие ошибки уже исправлены. Получить информацию о том, что функциональность, которую они просили, или ошибка, о которой сообщил несколько дней назад клиент, уже в разработке или исправлена.
Маркетинговая команда видит, как далеко мы находимся от конечной цели и когда они могут приступать к подготовке коммуникаций.
В случае с моим проектом Coupler.io хорошо еще и то, что все члены команды сами являются пользователями продукта и могут поделиться обратной связью на ранних этапах. Ребята не стесняются быть проактивными и задавать вопросы, если не понимают чего-то. Инженеры, которые работают над определёнными фичами, демонстрируют их. Это помогает нам практиковать «human language».
Как развить продуктовое мышление
Начните больше интересоваться тем, что не входит в написание кода. Это поможет понять цели и процессы в смежных командах на продукте. Интересуйтесь у менеджера, клиента или продакт-оунера, какую пользу продукт приносит конечным пользователям. Прислушивайтесь к коллегами в команде, старайтесь понять их. Все это в конечном итоге поможет вам доносить собственные идеи, формулировать проблемы и вопросы, на понятном окружающим языке.
Бывают случаи, когда не все зависит только от нас. Я слышал много историй о людях, которые пытались изменить процессы в своих компаниях, задавали менеджменту неудобные вопросы, старались внедрять инновации и улучшать процессы. Все было безрезультатно.
Порой вы можете прилагать много усилий, но без понимания и поддержки со стороны руководства, они ничего не будут стоить. Окружение всегда будет играть здесь важную роль. Если вы чувствуете, что можете больше и хотите развиваться, а текущее место работы не позволяет это сделать, меняйте работу. Но перед этим стоит обязательно убедиться, что для изменения ситуация на текущем месте вы сделали все, что было в ваших силах.
Преимущества и недостатки продуктового мышления у инженеров
У любого подхода есть свои преимущества и недостатки. Наш случай не исключение. Давайте рассмотрим плюсы и минусы продуктового мышления с двух сторон: со стороны компании, в которой работают продакт инженеры, и со стороны самого инженера.
Начнем с преимуществ для компании:
- Работая в команде с продакт инженерами, есть возможность если не искоренить, то свести к минимуму микроменеджмент. Команда будет более независимой, сможет принимать решения самостоятельно и делать это правильно.
- Такие команды выгоднее с точки зрения бюджета. Особенно это хорошо видно на начальных этапах развития продукта. Это достигается за счет сокращения времени на взаимодействие между большим количеством людей.
- Снижение bus factor-а, когда критичные знания и умения сосредоточены в руках или голове одного или нескольких человек. Зная и понимая смежные роли и процессы, люди могут заменить друг друга с минимальными потерями для бизнеса.
Преимущества для специалиста:
- Возможность попробовать новые подходы, активности и функции в безопасной среде без смены своей роли.
- Тренировка адаптации к переменам во внешней среде. Открываются возможности для потенциально интересного места работы.
- Большее влияние на продукт, на его направление развития и возможность строить что-то полезное.
Если говорить о недостатках, то для компании он, наверно, единственный: тяжело нанимать людей, которые были бы хорошими специалистами и в то же время имели широкий кругозор (Т-shaped специалисты).
Для специалиста это скорее не недостатки, а необходимость дополнительных усилий:
- Выход из зоны комфорта, который не всегда приятен.
- Работа с большим количеством разных контекстов и хорошие навыки самостоятельной организации своего рабочего времени.
Вкладывать смысл во все, что мы делаем
В последнее время все больше людей переходят от простого написания кода к реализации чего-то более значимого для них. Кто-то создает собственные продукты, другие же находят более логичным шагом свое участие в бизнес-части продукта и процесса. Это можно назвать кризисом среднего возраста в индустрии, но в хорошем смысле. Люди ищут смысл в том, что они делают, а для этого нужно понимать, что происходит вокруг. Увеличьте масштаб, посмотрите на общую картину и переосмыслите свой вклад.
52 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів