Заблуждения и ошибки приоритизации

22 листопада 2017
Сергей Бережной, Solutions Architect
Заблуждения и ошибки приоритизации
Повторим, сказанное в первой части нашего рассказа: процессы приоритизации — сложный многофакторный анализ. Тем не менее мы часто ими пользуемся, не всегда напрягаясь.

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

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

Этот комментарий к первой статье сделал мой день:
«У нас у всех разные вкусы. Мама любит белый хлеб. Дети — сладкую сдобу. Дедушка — черный „Бородинский“. Но когда мы собираемся за столом, мы все едины в одном: пожалуй, старый хрыч обойдется без „Бородинского“».

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

Создать полноценную справедливую систему, которая подходит на все случаи жизни, — задача утопическая. Попробуйте решить ее хотя бы на примере покупки хлеба в семье. Постоянно будут всплывать ситуации, в которых чьи-то интересы будут учтены в большей или меньшей степени (может, бедный дедушка получит «Бородинский» на Рождество).

Цель приоритизации — согласие участников процесса с расставленными приоритетами. Методы приоритизации помогают синхронизировать для всех шкалу приоритизации (по какому принципу измерять-то будем?) и дать почву для обсуждений.

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

Ловушки приоритизации

Поговорим о базовых ошибках, которые зашиты в нас самих (BIOS, ДНК, называйте, как хотите, разобраться в этом — точно не цель статьи). Эти ошибки проявляются в восприятии мира вообще, страдает из-за них и приоритизация.

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

Ловушка «принадлежности»

Наши идеи, проекты, мысли и догадки по умолчанию всегда важнее идей других людей. Хотя исключения случаются.

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

Пример:

На собрании нескольких команд обсуждается последовательность задач и ресурсов, необходимых для их выполнения. Вы можете представить следующую ситуацию? Часть менеджеров встанет и скажет: «Вы знаете, у других ребят настолько крутые идеи, что мы забиваем на свои и переключаемся на них. Пес с ними, нашими годовыми бонусами и обещаниями! Эти идеи настолько круты, что надо бросить на них все силы». Мне это очень сложно представить.

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

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

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

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

Программисты даже приведут вам 100500 фактов, которые подтверждают их точку зрения: «В прошлом проекте у нас так было» или «В другом проекте не построили сначала платформу, а потом в этом давнокоде жили два года и плакали» (произносится замогильным голосом).

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

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

Кстати, такой же ловушке подвержены люди, которым вы не безразличны. Если спросите маму: «Как тебе мой новый продукт или идея?» — с большой долей вероятности получите позитивный отзыв. Личные симпатии сильно отражаются в процессе приоритизации, склоняя приоритеты в чью-то сторону. Просто понаблюдайте!

Как избежать ловушки принадлежности?

Избежать этого достаточно сложно. Мы люди, мы субъективны, и собственные идеи нам всегда будут ближе. Но осознание проблемы уже превращает задачу из невыполнимой просто в задачу «со звездочкой».

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

Та же техника Six Thinking Hats подразумевает рассмотрение проблемы с разных сторон: факты, эмоции, позитивные идеи, критика и «креатив». Просто выделив время на каждый из аспектов (а чаще всего как минимум половину упускают), мы сможем привести группу к более удачному решению.

Еще один подход — избегать «молчаливого согласия». Это ситуация, когда решение принимается после вопроса: «Кто не согласен?». Сразу вспоминаются слова священника: «Пусть говорит сейчас или молчит вечно». Молчаливое согласие убрать достаточно просто: каждого участника встречи спрашивают: «Скажи, пожалуйста, ты согласен с этим решением? И почему ты считаешь его верным?».

Если уходить от техник работы с группами, хорошие результаты показывает подход с data-driven decisions. Когда решения принимаются на основе цифр (конверсия, рост среднего чека, просмотры), а не просто красочного описания идей. Хотя, признаться честно, очень немного компаний доросло до такого подхода.

Можно назвать еще много приемов и техник для уменьшения влияния ловушки принадлежности. Но эта тема выходит далеко за рамки статьи.

Ловушка незнания

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

А как мы видели в первой статье нашего цикла, почти при каждом подходе к приоритизации есть параметры: стоимость и полученный результат.

Степень влияния сильно зависит от того, насколько вы некомпетентны в вопросе и как далеко зашли по кривой Даннинга-Крюгера.

Идет составление Roadmap для бета-версии нового продукта. Встает вопрос о приоритете продвижения продукта и затратах на него: промосайты, видеоролики, маркетинговые кампании, продвижении и т. д.

Разработчики говорят: «Вот разработаем приложение, сделаем кучу классных фич, дадим рекламу в Facebook или AppStore и наберем свои первые 10 000 активных пользователей. Дальше будет эффект сарафанного радио, главное — чтобы продукт был красивым. Т. е. давайте маркетинг отложим, пока нет всех фич».

Они явно недооценивают затраты на привлечение — цифра в 10 000 активных пользователей потребует сотен тысяч долларов на рекламу в AppStore. Маленькая компания редко может позволить себе такие прямые расходы. Надо искать более бюджетные и трудозатратные способы: блоги, growth hacking и т. д. Результаты они дают не быстро, поэтому срочность (а вместе с ней и приоритет) этой задачи возрастает.

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

Как избежать подобной ошибки?

Самый простой способ — опираться на оценку людей, которые уже решали подобные задачи. Провокационный вопрос «Сколько раз ты уже это делал?» поможет оценить, насколько можно верить расставленным приоритетам. Хотя вы в любом случае не получите 100-процентной гарантии правильного выбора.

Ловушка цифр

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

Прекрасный пример манипуляции цифрами — рейтинг отелей на сайте booking. Вы как пользователь сравниваете зачастую три параметра: цена, локация и рейтинг. Если с локацией играть невозможно, с ценой тоже не разыграешься, самый крутой хак системы — поиграть с рейтингом.

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

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

Переходя к вопросам продуктовой разработки и приоритизации, мы замечаем, что подход с получением интегральной оценки «вес фичи» уменьшит количество обсуждений (Ура! Мы же трушные инженеры, мы ненавидим болтать, нам надо работать!). Но он заставит проигноровать важный момент: мы не подумаем, почему цифры так близки. Что мы упускаем? Что еще поможет разобраться?

Как бороться с этой проблемой?

Чаще всего, для решения таких конфликтов нужно:

  • Понять, какое из значений в других измерениях дало такой высокий балл для фичи a или b. Выиграла чистота или состояние номера? Что важнее для нас сейчас? Я всегда в голове держу пример букинга и неказистого номера «зато в центре».
  • Если первый вариант не дал результатов, нужно добавлять дополнительные параметры, которые не участвовали в получении финального результата. Если мы делаем какой-то продукт, можно спросить: «А какой из этих запросов поможет создать дополнительные информационные поводы для прессы? Какую из этих фич больше ждут наши новые пользователи?» и т. п.

Вывод

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

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

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

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

Третья статья будет о том, как мы пытаемся обмануть систему приоритизации в вопросах прикладного планирования. Stay tuned!