ИСТОРИИ ИЗ ЖИЗНИ
Руководитель UX Питер Боерсма, который также имеет опыт в управлении продуктами, отмечает, что менеджеры продукта не принимают все окончательные решения. За дизайнерами остается последнее слово, когда нужно сделать критически важный выбор в UX. Инженеры должны быть ответственны за технические архитектурные решения, выбор фреймворка и так далее. У менеджеров продукта нет никакой монополии на принятие решений, и все же за какой-нибудь час они принимают решений больше, чем люди на других должностях.
Однако верно будет отметить, что в зрелой, обладающей полномочиями команде менеджер продукта организует принятие решений и обеспечивает, чтобы это происходило в сотрудничестве и привлечении знаний из смежных дисциплин.
Мэтт Лемей высказывает аналогичную точку зрения: «Хорошие менеджеры продукта привлекают к принятию решений других людей. Но мне доводилось видеть, как многие переходят на должности менеджеров продукта, потому что хотят быть „теми, кто принимает решения“, а потом мгновенно теряют доверие своей команды из-за того, что принимают решения в одиночку и ни с кем ничего не обсуждают. В любом случае я надеюсь, что люди, приходящие из UX, будут лучше понимать, что чувствуешь, когда тебя исключают из числа тех, кто влияет на процесс, и станут более внимательными партнерами в деле принятия решения».
Одна из самых сложных задач – это понять, что невозможно всегда принимать правильные решения. Вам необходимо примириться с тем фактом, что иногда вы будете ошибаться. Вам неизбежно случится принимать решения, которые не оправдаются или покажут, что другой выбор был бы лучше. Как сказал Клемент Као, соучредитель Product HQ: «Когда вы не принимаете решение, то на самом деле вы „решаете его отложить“. Многие начинающие менеджеры продукта полагают, что „если они еще не решили, то это не засчитывается против них“, но такое затягивание само по себе является скрытым решением со своими последствиями».
По разным причинам среди менеджеров продукта существует консенсус: даже если вы справляетесь, то все равно принимаете неправильные решения в 25–30 % случаев. Вам остается просто надеяться, что вы не совершите ошибку, которая погубит компанию. Основатель LinkedIn Рид Хоффман сформулировал одну из веских причин, по которой вам нужно освоиться с этой задачей. Он сказал, что если вас ни капельки не смущает продукт, который вы выпускаете, то вы слишком долго откладывали его выпуск.
То есть у вас не будет роскоши отслеживать каждый элемент данных и каждое мыслимое исследование вплоть до сведения критических реакций по каждому решению к минимуму, особенно когда вы принимаете буквально десятки решений в день.
Во всяком случае, современный процесс гибкой разработки предвидит эту проблему и акцентируется на «приблизительном согласии и работающем коде».
Еще одно значительное различие между менеджером и дизайнером заключается в том, что менеджер – это не дизайнер!
Хороший менеджер продукта заботится о дизайне, и эта роль действительно предполагает предоставление требований и других материалов для информирования дизайнеров, иногда управление дизайнерами и всегда организацию процесса и внедрение результатов дизайна. Но последнее, что нужно[24] дизайнеру – это менеджер продукта, который, желая помочь, рисует макеты или имеет несколько железобетонных идей о том, как это делать.
Хороший менеджер продукта будет защищать UX-практики, ценить и отстаивать дизайн, но при этом он будет следить, чтобы не вступать в область ответственности и не покушаться на прерогативы команды дизайнеров.
ИСТОРИИ ИЗ ЖИЗНИ
Когда я был старшим директором по управлению продуктом в CloudOn – стартапе, который мы впоследствии продали в Dropbox, – мы считали большой победой, если даже наши руководители разработки обсуждали технические решения, процесс или продукт в терминах UX и с апелляцией к улучшению пользовательского опыта.
Мы знали, что этот словесный поток может быть не более чем пустой болтовней, основанной преимущественно на личных представлениях о пользовательском опыте, а не на тщательном исследовании, результатах тестирования и так далее.
Однако это было стартовой площадкой для продолжения диалога о том, как лучше создавать программное обеспечение.
В то время я также руководил работой по UX. Но UX отчитывались именно мне не только поэтому (как это часто бывает у руководства по продукту во многих технологических компаниях), а потому, что у меня в то время не было лидера в команде, который мог бы поспорить о лучшем пути дальнейшего развития и тем самым помочь мне.
24
Здесь не стоит путать причину и следствие: дизайнеры появились, потому что этой работы стало много и ее потребовалось кому-то делегировать. А не потому, что без дизайнеров эта работа не делалась или делалась плохо. Соответственно, и менеджеры, и программисты, и кто угодно еще рисуют и будут рисовать эскизы интерфейсов. Это нормально и естественно. Использование такого поведения коллег на пользу, а не во вред итоговому результату – ответственность дизайнеров.