×

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

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

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

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

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

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

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

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

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

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

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




12 коментарів

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

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

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

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

Спасибо за ваш комендарий. Мне импонирует то, что в целом вы согласны :)

Логическая манипуляция.

Да я и не отрицаю! Скорее использовал для создания эффекта «драмы». Вся фраза написана в такой манере, которая резков выделяется из других.

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

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

Спасибо за ваш комендарий. Мне импонирует то, что в целом вы согласны :)

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

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

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

Леша, я рад, что ты «продолжаешь настаивать». Давай придумаем еще один хотя бы один универсальный параметр для приоритизации?
* правильная — отпадает
* обьективная — отпадает
* «оптимум» — тоже не подходит
* ... ваш вариант
Консенсусов всегда больше одного. Пример с бородинским показывает, что решений всегда больше одного. Но критерий выхода — согласие участников и «заинтересованных лиц».

Не надо универсальный, зачем же.

Но критерий выхода — согласие участников и «заинтересованных лиц».

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

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

// см. комментарии предыдущей части :)
Оказывается в русском языке правильно приоритИзация. Сам был в шоке, но что делать :)

Хмм, забавно, мой словарь думает, что приоритезация. Нужно его выкинуть. Вот такое объяснение нашел new.gramota.ru/...​search-answer?s=приоритиз.

Первоначальная основа: приоритет. Усекается ет, остается приорит + глагольный морф изирова + ть = приоритизировать. От этого глагола образовано существительное приоритизация.

Тут вопрос на самом деле несложный. ПриоритЕзация напрашивается как производная от слова «приоритет». Но если базовое priority, то и производным будет prioritization, то есть сабж. А судя по всему, приоритизацию придумали именно англоговорящие...

Сначала тоже так подумал, но приоритизация — это сокращение от приоритетизации для удобства произношения. Хотя, может, это просто англицизм, на самом деле.

Підписатись на коментарі