Продакт менеджмент и UX совершенно по‑разному видят свои обязанности

No items found.
Аудио перевод статьи
0:00
0:00
·

Резюме: Опрос профессионалов в области опыта взаимодействия с пользователем и в сфере управления продуктом, показывает, что они расходятся во мнениях относительно того, кто должен нести ответственность за многие ключевые задачи, такие как предварительное исследование и ранние этапы проектирования.

За прошедшие годы мы столкнулись со множеством случаев, когда не было ясно, является ли задача или конечный результат сферой ответственности продакт менеджмента (PM) или направления, связанного с опытом взаимодействия с пользователем (UX). Как UX специалисты, мы часто думали, что функции UX не были достаточно хорошо регламентированы, чтобы быть понятными для UX профессионалов или людей, которые занимаются созданием продукта. Это привело к двусмысленности в отношении функциональных обязанностей. Мы также слышали, как мои друзья, продакт-менеджеры, жалуются на неопределенность работы UX, и как UX профессионалы делают то, что является сферой ответственности PM.

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

Наше исследование

Наш опрос профессионалов UX и PM был направлен на то, чтобы получить ответы на следующие вопросы:

  1. Переходят ли другие функциональные обязанности границы работы PM и UX, и если да, то как часто?
  2. Какие функциональные обязанности пересекаются между PM и UX?
  3. Почему происходит дублирование работы?
  4. Каковы последствия частичного дублирования работы?
  5. Кто, по мнению PM и UX, за какие действия и результаты несет ответственность?
  6. Кто находится у власти в организации?

Последние два вопроса обсуждаются в этой статье. Дополнительная статьяохватывает первые четыре пункта.

В данной статье анализ проведен, исходя из ответов 372 профессионалов, которые описали свою основную функциональную роль,либо в UX (279 человек), либо в PM (93 человека). Весь опрос включал более 500 ответов людей, выполняющих различные функции при создании продукта.

Большинство респондентов (60%) работали в сфере PM или UX от 3 до 10 лет, 21% — менее двух лет и 19% — более 10 лет.

Большая часть из них (54%) были из США; следующая по величине группа (27%) была из Европы.

Продакт-менеджеры и UX специалисты не единодушны в том, кто за что должен отвечать

Мы попросили наших респондентов рассказать нам, кто по их мнению должен нести ответственность за некоторые часто выполняемые действия, связанных как с UX, так и с PM:

Опросный лист: Над многими вещами мы работаем совместно, как одна команда. Но в отношении большого числа действий и результатов кто-то принимает окончательное решение или несет наибольшую ответственность. Какая функциональная роль по вашему мнению, должна нести наибольшую ответственность за каждое из следующих действий? Функциональные роли: контент, CX (степень удовлетворенности клиента качеством обслуживания), разработка, маркетинг, PM (управление продуктом), PO (ответственный за создание продукта), QA (контроль качества), поддержка, UX и т.д. Действия:

  • проводить предварительные исследования
  • проводить интервью с пользователями
  • проводить пользовательское тестирование
  • придумывать идеи, обеспечивать командное формирование идей в отношении новой архитектуры дизайна
  • устанавливать очередность потребностей пользователей при проектировании
  • определять информационную архитектуру (IA)
  • определять алгоритм выполнения задач в части пользовательского интерфейса (UI)
  • создавать каркас или набросок UI разработки на самых ранних этапах проектирования
  • создавать UI прототипы
  • принимать решения о том, как дизайн будет выглядеть и восприниматься
  • создавать окончательные визуальные элементы в UI
  • решать какие области будет исследовать команда UX
  • принимать решения о том, какие характеристики команда UX будет проектировать
  • определять, какой контент войдет в UI
  • отслеживать то, что исследование пользователей и рассмотрение результатов являются частью карты пути
  • доносить мнение потребителя до команды разработчиков продукта
    объяснять дизайн-проект руководству
  • получать одобрение на дизайн от заинтересованных сторон
  • собирать требования со стороны бизнеса (высшего руководства) для проекта
  • создавать концепцию продукта
  • обозначать приоритеты для потребностей бизнеса
  • принимать решения в отношении требований к продукту
  • обеспечивать соответствие проекта требованиям бизнеса
  • создавать карту пути продукта
  • решать, какие характеристики в конечном итоге будут у продукта
  • принимать решения о том, какие функции будут реализованы при разработке
  • поддерживать актуальный список функций, элементов, задач которые заинтересованные стороны хотят получить от продукта
  • устанавливать очередность потребностей клиентов
  • отслеживать процесс выполнения проекта для его своевременной сдачи
  • оценивать, соответствует ли продукт или услуга целям по доходу
  • понимать конкурентную позицию продукта
  • продвигать продукт в рамках компании и за ее пределами
  • сообщать о статусе продукта руководству

Мы провели статистический тест, чтобы понять, была ли существенная разница у респондентов UX и PM в распределении каждого действия между функциональными ролями. В дальнейшем все обсуждаемые различия являются статистически значимыми (при p <0,05), если не указано иное.

Задачи, связанные с UX

PM и UX не достигли соглашения по вопросу о том, кто должен нести ответственность за следующие ключевые задачи UX:

  • проведение исследования пользователей
  • проектирование
  • определение информационной архитектуры (ИА) сайта
  • управление проектированием
  • передача знаний о дизайн-проекте и потребителях
  • определение содержания

Проведение исследования

На графике показаны 3 задачи, связанные с исследованиями, и процент PM и UX специалистов, которые пришли к соглашению о том, кто должен отвечать за каждую из них: PM или UX.

Наши результаты показывают, что хотя в большинстве ответов PM и UX интервью с пользователями и пользовательское тестирование относились к UX, разница в цифрах значительно отличалась. Наибольшее расхождение во мнениях относилось к предварительным исследованиям, но даже в таких стандартных UX задачах, как пользовательское тестирование, отмечались значительные разногласия. Только 46% продакт-менеджеров отнесли эту деятельность к UX.

Один респондент UX написал о проблемах, возникающих в связи с тем, что люди, которые проводят исследования, не обладают навыками в этой сфере: “UX исследования, которые осуществляются не специалистами в этой области, часто не соответствуют нашим стандартам качества или технологическим стандартам. Это приводит к тому, что пользовательские тестирования, результаты и рекомендации не отражают фактического поведения пользователей и негативно влияют на продукт. Если предлагаемые решения выполняются и дают сбой, это сводит на нет ту положительную работу, которую мы с исследовательской группой выполняем или собираемся выполнить”.

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

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

Проектирование

Когда дело дошло до проектирования, мы обнаружили как согласованность, так и расхождения во мнениях между респондентами UX и PM.

Согласованность. В опросе, который содержал следующие 3 задачи, связанные с проектированием, PM и UX пришли к соглашению, что они должны быть сферой ответственности UX:

  • принимать решения о том, как будет выглядеть и восприниматься дизайн (82% продакт-менеджеров и 80% UX специалистов посчитали, что это должно быть ответственностью UX)
  • создавать UI прототипы (82% продакт-менеджеров и 88% UX специалистов решили, что UX должны это выполнять)
  • создавать окончательные визуальные элементы в UI (79% продакт-менеджеров и 78% UX специалистов поручили это UX)

Расхождение во мнениях. И PM, и UX, как правило, относили к UX следующие действия, но респонденты UX делали это чаще, чем респонденты PM:

  • формирование идей
  • определение алгоритма выполнения задач
  • создание каркаса или наброска проектов
  • установление очередности потребностей пользователей
На графике показаны 3 задачи, связанные с проектированием, и процент респондентов PM и UX, которые пришли к соглашению о том, кто должен отвечать за каждую из них: PM или UX.

В частности, наибольшие противоречия отмечались в области формирования идей и расстановки приоритетов потребностей пользователей при проектировании: более трех четвертых респондентов UX и только около трети респондентов PM считали их обязанностью UX. А другая треть PM определила их своей сферой ответственности.

Проектирование должно быть совместным. UX, PM, разработка и большинство других функциональных должностей обязательно должны участвовать в проектировании. Но опрос мнений касался того, кто должен нести ответственность, а не принимать участие. Если неясно, кто отвечает за проектные работы, сложно управлять процессом дизайна и финализировать его.

Комментарий одного из респондентов UX выражает общее мнение о людях, не обладающих навыками UX, которые занимаются проектированием: "Мой босс, старший UX менеджер, известен тем, что всегда говорит: "Каждый является UX специалистом". Представьте себе, что вы бухгалтер, врач или генеральный директор и кто-то сказал такое? Такой взгляд на то, что эта функциональная должность не имеет смысла, является неуважительным по отношению к сотрудникам, которые годами работали в этой области. Я думаю, частично это связано с тем, что UX — это широкий термин, который открывает возможности для подобного типа негативного мышления".

Информационная архитектура (IA)

Респонденты PM и UX также разошлись во мнениях относительно того, кто должен отвечать за определение информационной архитектуры сайта. Большинство (50%) продакт-менеджеров посчитали, что разработка должна нести ответственность за IA, и только 27% из них решили, что она должна быть частью работы UX, в то время как 75% UX специалистов решили, что UX является ответственным за IA.

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

Хотя верстка архитектуры, безусловно, является сильной стороной разработки, создание категоризации и информационной иерархии в приложении — это работа информационного архитектора, должность которого относится к UX. UX имеет возможность изучать, как размещать и называть ссылки и команды понятными для пользователей способами с помощью таких методов, как сортировка карточек, тестирование дерева сайта и тестирование кликов.

Управление проектированием

Респонденты PM и UX также разошлись во взглядах на то, кто должен руководить проектированием. Как правило, большинство респондентов PM (около 50%) посчитали, что ответственность за эти управленческие функции должна быть возложена на PM. Напротив, мнения респондентов UX были более разнообразными: некоторые относили их к UX, другие — к PM, а третьи посчитали, что за них отвечают ответственные за создание продукта (PO). Интересно, однако, что наиболее частым ответом среди UX специалистов (более 38%) было то, что UX должен осуществлять все эти управленческие действия. В целом, данные показывают предрасположенность функциональных обязанностей и UX, и PM к соответствующей управленческой работе, связанной с дизайном.

На графике показаны 3 задачи, связанные с управлением проектированием, и процент PM и UX специалистов, которые пришли к соглашению относительно того, кто должен нести ответственность за каждую из них: PM, UX или PO.

Решение о том, какие области будет исследовать UX команда, было самым ярким примером присвоения функций: UX специалисты считали, что это должен делать UX, а PM менеджеры думали, что PM должен их выполнять.
Легко понять, почему UX специалисты и продакт менеджеры не согласны с тем, кто должен осуществлять данные действия: эти задачи имеют четкий компонент, связанный с управлением и другой, связанный с пользователем, поэтому по определению они неоднозначны. Вот почему для организаций очень важно в открытой форме устранить неопределенность и установить правила в отношении того, кто должен выполнять эти действия. Это одни из самых сложных решений, которые необходимо принять в процессе разработки цифровых продуктов, даже не беря в расчет вопросы, связанные с ответственностью за продукт. Вы практически можете представить себе, как люди из PM и UX указывают в разные стороны, когда им задают эти вопросы.

Передача знаний о дизайн-проекте и потребителе

В этой области мы также обнаружили большое несоответствие между PM и UX. Респонденты UX снова были склонны оставлять за собой все эти функции (по крайней мере, 49% UX специалистов закрепляли их за UX), в то время как PM придерживались более разнонаправленных взглядов на то, чья это ответственность.

На графике показаны 3 задачи, связанные с передачей знаний о потребителе и дизайн-проекте, а также процент PM и UX специалистов, которые пришли к соглашению относительно того, кто должен отвечать за каждую из них: PM, UX, PO или CX (ответственный за качество обслуживания клиентов).

Передача мнения потребителя команде разработчиков продукта была задачей в этой категории, в отношении которой PM специалисты разделились в наибольшей степени: одни PM (25%) считали, что это должна быть работа PM, другие (29%), что CX, а 16 % PM полагали, что эту функцию следует поручить PO. Только 9% PM отнесли ее к UX (по сравнению с 54% респондентов UX).

Что касается двух других действий (объяснение дизайн-проекта руководству и получение одобрения от заинтересованных сторон), мы также увидели присвоение со стороны респондентов PM: большинство PM считали, что эти задачи должны быть работой PM (45% и 53% соответственно), но следующим распространенным ответом PM было то, что они должны быть обязанностью UX (29% и 23% соответственно). Эти результаты показывают несоответствие между UX и PM, когда дело доходит до вопроса о том, кто должен нести ответственность за убедительное изложение и объяснение дизайна.Независимо от задействованных функциональных должностей, не рекомендуется, чтобы кто-то, кроме дизайнера, представлял дизайн - докладчик может неправильно понимать причины каждого решения и не сможет точно передать обратную связь дизайнеру. Более того, этот тип сценария (где PM представляет проекты руководству и заинтересованным сторонам) лишает UX возможности стать заметными в организации. В конечном итоге, это может снизить авторитет и рост позиции UX, UX команд и UX специалистов.

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

Определение содержания

PM и UX также в некоторой степени не пришли к соглашению о том, кто должен определять контент: они оба склонялись к тому, чтобы отнести эту задачу либо к UX, либо к отделу по контенту. Но PM, как правило, чаще определял ее, как ответственность PM (23% ответов), по сравнению с UX, которые отнесли ее к сфере PM только в 5% случаев. (Другие различия между процентами респондентов PM и UX, определяющими ответственных за контент, не были значительными — например, даже если 28% PM и 41% UX относили это действие к UX, эта разница не была значимой).

График показывает процент PM и UX специалистов, которые пришли к соглашению относительно того, кто должен нести ответственность за задачу определения того, какой контент будет помещен в пользовательский интерфейс: PM, UX, PO или специалисты по контенту. Отдел по контенту — это подразделение UX, но некоторые организации по-прежнему считают его отдельной функциональной единицей, поэтому в этом обзоре мы выделили его отдельно. Но если мы объединим UX и специалистов по контенту, 61% PM и 79% UX согласятся, что UX/специалисты по контенту должны нести ответственность за эту деятельность. Столбцы с узорной заливкой указывают на то, что различия между PM и UX не были статистически значимыми.

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

Задачи, связанные с управлением проектами

PM и UX не пришли к соглашению о том, кто должен отвечать за следующие ключевые задачи, связанные с управлением проектами:

  • концепция продукта и расстановка приоритетов для потребностей бизнеса и характеристик продукта
  • управление проектом и оценка результатов
  • продвижение продукта и результатов команды
  • понимание конкуренции

Концепция продукта и расстановка приоритетов

Большинство респондентов PM (более 63%) посчитали, что все задачи, связанные с концепцией, расстановкой приоритетов для потребностей бизнеса и характеристик продукта, должны быть их ответственностью. Для сравнения UX специалисты обычно распределяли эти задачи между ответственными за создание продукта и продакт-менеджерами. Все эти задачи больше респондентов PM, чем UX, отнесли их к PM. Напротив, больше UX респондентов передали ответственность PO за эти концептуальные и стратегические действия. Исключением стали определения требований к продукту и решения о том, какие функции должны быть реализованы при разработке, где разница между процентом PM и UX, когда они относили эти задачи к ПO, была незначительной (p = 0,054 и p = 0,09, соответственно).

На графике показаны 7 задач, связанных с расстановкой приоритетов, а также процент PM и UX специалистов, которые пришли к соглашению относительно того, кто должен нести ответственность за каждую из них: PM или PO. Столбцы с узорной заливкой указывают на то, что различия между PM и UX не были статистически значимыми.

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

До того, как Lean и Agile стали популярными и представили позицию ответственного за создание продукта, управление проектом и его графиком было функциональной обязанностью менеджера проекта. Эта должность обычно принадлежала менеджеру по разработке программного обеспечения. Позиция руководителя проекта также была довольно распространена. Руководители обладали большими административными функциями и обеспечивали оперативную работу. Кажется, что нынешний ответственный за создание продукта берет на себя (большую часть) прошлые задачи менеджера и руководителя проектов и является хранителем церемоний Agile. Но с учетом того, что деятельность ответственного за создание продукта потенциально настолько велика, возможно, что продакт менеджерам придется время от времени выполнять некоторые из этих задач, и это совпадение, вероятно, вызовет некоторую путаницу в отношении обязанностей.

Управление проектом и оценка результатов

В целом, даже несмотря на то, что респонденты UX и PM были склонны передавать PM следующие задачи, процентные показатели в целом отличались:

  • Поддерживать актуальный список функций, элементов, задач продукта: больше PM, чем UX специалистов, как правило, относили эти функции к PM, а разница в процентном соотношении PM и UX профессионалов, которые считали, что они должны быть переданы PO, не была статистически значимой.
  • Отслеживать процесс выполнения проекта для его своевременной сдачи: эта задача была единственной, которую UX специалисты чаще, чем профессионалы PM, относили к PM. Разница в процентном соотношении PM и UX специалистов, которые считали, что она должна быть передана PO, не была статистически значимой.
  • Оценивать, соответствует ли продукт целям по доходу: даже несмотря на то, что больший процент PM, чем UX специалистов (59% против 48%) отнесли эту задачу к PM, эта разница не была статистически значимой (p> 0,1). Тем не менее, больше UX специалистов, чем PM посчитали, что она должна быть передана PO (и эта разница была статистически значимой).
  • Обеспечивать соответствие проекта требованиям бизнеса: PM решили, что эта задача должна быть передана PM, но UX специалисты отнесли ее к PO. Оба различия были статистически значимыми.
График показывает 4 задачи, связанные с управлением и оценкой, а также процент PM и UX специалистов, которые пришли к соглашению относительно того, кто должен нести ответственность за каждую из них: PM или PO. Столбцы с узорной заливкой указывают на то, что различия между PM и UX не были статистически значимыми.

В целом, в этой категории самое большое разногласие было связано с тем, кто должен обеспечивать соответствие проекта требованиям бизнеса. UX специалисты чаще путали компетенцию PM и PO. Опять же, должно быть четкое разграничение между PM и PO.

Продвижение продукта

Респонденты PM, как правило, были склонны забирать себе задачи из этой категории, а UX специалисты разделились во мнениях между передачей их PM или PO. В целом, больше PM, чем UX менеджеров относили их к PM, и больше UX специалистов, чем PM, передавали их PO. Большинство ответов UX (41%) показывали, что ответственный за создание продукта должен продвигать продукт (в отличие от большинства ответов PM, которые относили эту задачу к PM). В то время как большинство респондентов PM и UX заявили, что отчеты о статусе продукта должны предоставляться PM, больше PM, чем UX специалистов, отнесли эту задачу к PM (72% против 53%) и больше UX менеджеров, чем PM, передали ее PO (40% vs. 22%).

График показывает 2 задачи, связанные с продвижением, а также процент PM и UX специалистов, которые пришли к соглашению относительно того, кто должен нести ответственность за каждую из них: PM или PO.

Конкуренция

Респонденты PM и UX также по-разному понимали, кто должен исследовать конкурентоспособность продукта. PM взяли на себя эту задачу, но пользователи UX разделились между тем, чтобы отнести ее к PM, PO или маркетингу. Больше PM, чем UX специалистов, передали эту деятельность PM, и больше UX менеджеров, чем PM, отнесли ее к PO. Сопоставимое процентное соотношение PM и UX профессионалов поручили данную задачу маркетингу (21% против 24%; разница не была статистически значимой, p> 0,1).

График показывает задачу понимания конкурентной позиции продукта, а также процент PM и UX специалистов, которые пришли к соглашению относительно того, кто должен нести ответственность за нее: PM, PO или маркетинг. Столбцы с узорной заливкой указывают на то, что различия между PM и UX не были статистически значимыми.

Влияние функциональных ролей

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

Чтобы понять, как профессионалы UX и PM воспринимают баланс сил в своей организации, мы задали следующий вопрос:

Опрос мнений: какая из следующих функциональных ролей имеет наибольшее влияние в вашей организации? Пожалуйста, расположите роли в порядке их влияния: 1 — самая сильная, а 10 — самая слабая. Каждый номер можно использовать только один раз.

Мы рассчитали средний рейтинг для каждой из функциональных ролей, присвоенный PM и UX. В целом, обе группы респондентов распределили все роли примерно одинаково. Единственная статистически значимая разница (по ранговому критерию Вилкоксона, p <0,05) заключалась в том, что ответственный за создание продукта был оценен PM выше, чем UX.

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

Нет универсального регламента должностей в области разработки нового продукта

Вполне возможно, что человек, официально нанятый на одну должность, может иметь навыки и отвечать за задачи, которые обычно выполняются лицом, занимающим другую позицию. Например, в стартапе могут работать продакт менеджер и разработчики, но не быть специалиста по UX. В этом случае все исследования могут проводиться PM, а проектирование может быть разделено между PM и разработчиками. Стартап или высокоразвитая компания, позиции разработчиков нового продукта не будут регламентированы одинаково во всех организациях, поэтому респонденты нашего опроса, возможно, сталкивались с различными распределениями задач, указанных в наших вопросах. Вероятно, они ответили на наш опрос, основываясь на своем опыте и идеях о том, что может быть наиболее эффективным, даже если может существовать гораздо лучшее распределение задач.

За последние годы некоторые команды разработчиков сосредоточили свое внимание на найме сотрудников в соответствии с навыками, а не должностями. Анализ пробелов в навыках команды может показать, что команде нужны люди с опытом, который охватывает несколько общепринятых должностей. Так, например, вместо того, чтобы нанимать продакт менеджера или визуального дизайнера, команде может потребоваться кто-то, кто может создавать концепцию продукта или прототип с высокой точностью. Такой низко детализированный, ориентированный на навыки подход к подбору персонала может быть более гибким, чем обычный подход, основанный найме в соответствии с требованиями к должности.

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

С другой стороны, у такого варианта работы есть отрицательные стороны, такие как:

  • Меньше практики: кто-то может не полностью развить навык, если он не будет задействовать его часто, поэтому результат может быть более низкого качества и требовать больше времени для его достижения.
  • Отсутствие знаний: удовольствие - это не навык. Просто потому, что люди находят интересным что-то делать или они видят в этом необходимость, не означает, что они в этом хороши. Кажется, есть много людей, которым нравится заниматься деятельностью, связанной с UX.
  • Недостаток опыта: UX настолько специфичен, что людям, не работающим в этой сфере, может быть сложно понять, хорошо ли выполнена работа, связанная с UX. Тот, кто не умеет создавать программное обеспечение, не станет пытаться выполнять работу программиста. Если они это сделают, то далеко не уедут. Тот, кто не знаком с целями и ограничениями бизнеса, не создаст актуальный список функций, элементов, задач которые заинтересованные стороны хотят получить от продукта. Если они создадут такой список, никто не будет его придерживаться. Любой может загрузить инструмент для создания прототипа и начать делать наброски или зарегистрироваться в приложении для онлайн тестирования пользователей и начать исследование. Возможно они даже проведут большую работу. Но часто они не будут знать, когда работа выполнена некачественно. И в этом вся загвоздка. Несмотря на то, что UX деятельность имеет низкую стоимость входа, вероятность того, что кто-то с небольшим опытом или знаниями будет делать ее хорошо, также мала. И вероятность того, что они выполнят ее лучше, чем обученный или опытный UX профессионал, еще ниже.
  • Снижение эффективности: в организации может быть кто-то другой, кто сможет работать лучше и быстрее. Например, UX специалист может провести совещание и разработать концепцию продукта, но PM может сделать это более тщательно и привлечь к участию нужные заинтересованные стороны высокого уровня. PM может быть в состоянии набросать начальный процесс проектирования, но опытный UX специалист учтет принципы проектирования и воспользуется данными и знаниями о пользователях, которые они, возможно, собрали ранее.
  • Сложности с наймом сотрудников: если опыт, который нужен команде, должен быть разносторонним, возможно будет трудно найти кого-то, кто обладает этим конкретным набором навыков.

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

Заключение: приведите в соответствие обязанности лиц, задействованных в вашем проекте

У каждой организации есть своя культура, должностные обязанности и методы работы. И многие люди не ограничены в выполнении тех немногих действий, которые обычно связаны с их должностью. Однако вызывает недоумение то, что у продакт менеджеров и UX специалистов очень разные взгляды, и во многом они не согласны в своих оценках относительно того, кто должен нести ответственность за ключевые области, связанные с проектированием и управлением проектами. Фактически, почти все ответы об обязанностях отличались.

Некоторые из самых больших разногласий относились к исследованиям, а именно: кто должен проводить предварительные исследования, придумывать новые дизайн-проекты и определять алгоритм выполнения задач в пользовательском интерфейсе. Решение о том, какую работу должен выполнять UX, например, какие функции UX команда будет исследовать и проектировать, также было несогласованным. А разъяснение дизайна, в частности донесение дизайна руководству и получение одобрения от заинтересованных сторон, были другими областями разногласий.

Во всех вышеупомянутых сферах, а затем и в других, PM полагали, что они несут ответственность, в то время как UX специалисты считали ответственными себя. Это был интересный и ясный пример присвоения, склонность PM и UX думать, что все это было их работой.

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

Что делать с отсутствием согласованности? Мы могли бы предложить огромный проект по стандартизации мировых должностных инструкций для продакт менеджеров и для каждой роли UX, которая существует. Но к тому времени, когда мы закончили бы создавать описания, которые можно было бы применять так широко, мир бы уже изменился, и инструкции бы больше не работали. Это было бы похоже на покос травы на большом участке земли. К тому времени, как вы закончите, трава на полях, с которых вы начали, уже вырастет, и вам нужно будет начинать заново.

Итак, сегодня, на самых ранних этапах проектов, продакт менеджеры и UX специалисты должны по-настоящему синхронизировать исследования и проектирование, а также конкретно указать, кто будет проводить предварительные исследования, формулировать идеи, делать предварительные наброски и организовывать рабочие процессы проектирования. Синхронизация не только сгладит некоторые из самых серьезных проблем, но и создаст основу для общения, делегирования и расстановку границ в начале проекта.

На протяжении всего проекта четкое определение задач, над которыми должен работать каждый, может помочь людям преуспеть и почувствовать уверенность в своей работе. Каждый человек должен знать, что ему нужно делать в каждом проекте или на каждом этапе. Кроме того, другие члены группы разработки продукта также должны знать об этих обязанностях. Четкие определения, вероятно, улучшат сотрудничество между функциональными группами и избавят от ощущения, что «я должен делать все». Если все будут знать, к кому и за чем идти, работа, вероятно, будет более приятной, продуктивность повысится, а результаты улучшатся.

У вас есть совет или история о том, как UX и функциональные должности, связанные с созданием продукта хорошо работают вместе? Поделитесь здесь. Мы планируем написать еще одну статью, которая будет состоять из собранных советов.

Источник:
nngroup.com
·
comments powered by HyperComments