Исповедь менеджера продукта +28


image

Я работаю в продуктовой компании. Что это значит?

Мы не разрабатываем проекты на заказ, мы делаем продукт, который продаем клиентам.
Для своих команд я формирую видение продукта, принимаю решение, какие из “хотелок” пользователей мы будем делать и объясняю команде (иногда на уточках), зачем они нужны. Описываю задачи с точки зрения ценности для бизнеса, формулирую и проверяю гипотезы.
Мои требования к разработке зачастую сформулированы нечетко, фичи часто приходится переделывать или дорабатывать после запуска.

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

И я хочу рассказать, зачем я делаю это снова и снова.

Продукт должен решать боль


У менеджера продукта есть видение того, что необходимо создать компании, чтобы не потратить зря время и силы дорогих (во всех смыслах!) разработчиков.

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

Продуктовая команда


Раньше у нас были функциональные команды, которые делают только свою часть фичи (например, пишут фронтенд). Нас не устраивала скорость разработки, нарушение коммуникации, процесс передачи задач между командами и отслеживание их статусов.

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

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

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

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

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

И это противоречие становится самой частой причиной споров между мной и разработчиком.

MVP VS Идеальная архитектура


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

А бывает еще сложнее — пользователь может не знать, что у него есть проблема. Он жил так много лет, боролся с трудностями и считает это нормой. И если я спрашиваю: “А какая у тебя проблема?”, часто в ответ слышу: “Никакой, у меня все хорошо”.

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

Мы поняли, что без customer development почти невозможно создать ПО, которое с радостью будут покупать. Моя задача, как менеджера продуктов, искать целевую аудиторию, проводить интервью, выявлять потребности, описывать персонажей и их боли. Но даже это не всегда гарантирует успех. Я тоже человек и тоже могу ошибаться.

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

Но часто, когда я прихожу к команде и говорю, что нам нужно сделать функционал “на коленке” и запустить его в работу через неделю, в ответ я слышу, что это невозможно. Нужно продумать архитектуру! Нужно учесть все сценарии! Нужно полное ТЗ с описанием всего функционала! А что будет, если один из 1000 пользователей сделает не то, что мы ждали, и у него все сломается?! Нельзя написать и провести ревью кода в такие сжатые сроки!

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

Работа в стол


И вот, мы все-таки запилили функционал, который не нужен пользователю.

Хорошо, если мы потратили на это мало времени и с ним не жалко расставаться. Но если разработчик душу в него вложил? Ночами не спал, рисовал идеальные кнопки с “продающим зелёным”? Учел и обработал все сценарии? Сделал гибкую архитектуру, которую можно безболезненно покрыть тестами? Написал статью и всем коллегам рассказал о том, как круто он применил новейшие технологии?

А потом прихожу я и говорю фразу, которую ненавидят все программисты: “Нужно эту фичу переделать”. И случается в ответ услышать то, что ненавидят все менеджеры: “Я старался, все по ТЗ делал, а вы с пользователями не оценили. Ничего переделывать не буду”.

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

Когда я слышу от разработчика фразу “Ну вот, опять в стол поработали”, я снова и снова пытаюсь объяснить, что это не так, его работа принесла компании выгоду — мы проверили гипотезу, не потратили на нее много денег, и поняли, что рынку нужно не это. Мы сделали шаг вперед. Разработчик помог не сделать ошибку.

Продуктовое мышление


Я и раньше постоянно общалась с конечными пользователями, видела их проблемы. Но вот беда — я не задумывалась о том, чтобы рассказать о своих исследованиях команде. А ведь задача ребят — как можно скорее сделать то, что решит боль клиента.

А потом я подумала: “Как может разработчик думать о человеке, которого ни разу не видел и с которым не говорил?”

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

Он никогда не видел, кто и в каких условиях использует его продукт. В его мире все очевидно — клиент должен разобраться во всех настройках сам. А клиент почему-то злится.

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

Я знаю об этом и понимаю, что функционал нужно доработать — убрать ненужные настройки, сократить количество действий, добавить новые сценарии, которые не предусмотрели раньше. Но разработчик противится. Он не хочет несколько раз переделывать одно и то же, вставляя новые “костыли”. “Почему сразу нельзя было это сделать?” — слышу я от него.

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

Потому что о сложных кейсах использования клиент мне не рассказал на интервью (или я не смогла вытянуть).

Потому что забыли “повесить” аналитику.

Потому что менеджер тоже может ошибаться.

Поэтому я стараюсь наладить коммуникации в команде. Потому стараюсь научить всех членов команды думать в первую очередь о продукте и как клиент его использует.

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

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

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

И так же часто я ловлю себя на мысли, что не всегда делюсь с командой как клиент использует их продукт. Забываю сказать разработчику, что он сейчас “пилит” не полноценный функционал, а только MVP, который может и не взлететь. Я не объясняю, какую проблему решает их фича, а просто набрасываю задачи в бэклог, надеясь, что команда сама придет ко мне с вопросами.

Мечты сбываются


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

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

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

P.S.: Автор статьи Stratanovich, у нее пока readonly, а нам очень хотелось опубликоваться.




К сожалению, не доступен сервер mySQL