Login

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

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

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

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

Этот комментарий к первой статье сделал мой день:

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

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

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

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

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

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

Поговорим о базовых ошибках, которые зашиты в нас самих (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!

Похожие статьи:
Наприкінці 2022 року ІТ-ринок США накрила хвиля масових скорочень у Big Tech компаніях. Загалом, за даними сайту Layoffs.fyi, від початку 2023 року...
У дев’ятому випуску рубрики «Що має знати Senior» розглядаємо вакансії Senior Android Developer, опубліковані на DOU у вересні та жовтні 2021-го....
Уже известно, что до конца текущего года будет представлен новый смартфон OnePlus Mini, но подробностей о нем было немного. Теперь они...
У цій статті продемонструємо розробку PHP-пакету, розберемося, для чого це робити та як автоматизувати рутинні дії для його...
Ссылки, на которые лучше таки нажать (по мнению автора), отмечены знаком (!) Java is TIOBE’s Programming Language of 2015! Ну серьезно, это...
Switch to Desktop Version