Все сталкивались с ситуацией, когда нужно было объяснять что-то другому человеку — будь то коллега, ребенок, друг или родственник. Иногда это происходит легко и непринужденно, а иногда… превращается в настоящую пытку. Особенно когда человек, которому мы объясняем, никак не может «включиться» и понять.
В такие моменты мы начинаем думать: «Как это можно не понять? Это же элементарно!» или «Он просто прикидывается, чтобы я сделал его работу!». Но, скорее всего, истина лежит гораздо глубже. Мы забываем, что когда-то и сами этого не знали. И в этом замешано проклятие знания.
Проклятие знания — ошибка мышления, из-за которой мы предполагаем, что другие люди обладают теми же знаниями, что и мы. Когда человек владеет определенной информацией, зачастую ему трудно представить, каково было бы не знать ее. Для него это элементарно. Он не понимает позицию другого, и это значительно усложняет общение.
В этой статье попробуем разобраться в том, как проклятие знания влияет на разработку и как избежать его негативных последствий.
Немного истории
Систематические ошибки в мышлении называют когнитивными искажениями. Они являются врожденной особенностью нашего мозга и помогают ему справляться с переизбытком информации. Когнитивные искажения упрощают понимание мира, заполняя пробелы в знаниях стереотипами и данными из прошлого опыта.
Одним из таких предубеждений является проклятие знания, или, как его еще называют, проклятие опыта. Проклятие знания крепко запечатлено в нашей психологии. В детстве нам часто не хватает теории разума, то есть умения осознавать, что у других людей есть собственное внутреннее состояние, которое отличается от нашего.
Исследования в области психологии показывают, что маленькие дети, получившие доступ к информации о местоположении спрятанной игрушки, предполагают, что все остальные, даже люди за пределами комнаты, также должны знать, где она находится. По мере взросления мы обычно преодолеваем эту предвзятость, но не полностью. Наши глубоко укоренившиеся инстинкты заставляют нас думать, что все воспринимают мир так же, как мы, хотя мы и знаем, что это не так.
Этот феномен был изучен психологом Барухом Фишхоффом. В 1975 году он провел эксперимент. Испытуемым предлагали короткую историю с четырьмя возможными исходами, после чего некоторым участникам сообщали правильный вариант, а другим — нет. Позже все участники оценивали вероятность выбора каждого исхода. Фишхофф обнаружил, что испытуемые, которым сообщили правильный результат, были склонны придавать ему более высокую вероятность.
Сам термин «проклятие знания» предложил психолог Робин Хогарт. Но в научных кругах это понятие стали использовать в 1989 году после статьи экономистов Колина Камерера, Джорджа Левенштейна и Мартина Вебера. Они использовали термин «проклятие знания» для того, чтобы проиллюстрировать особенность экономических транзакций.
Их исследование показывает, что продавцы, хорошо знающие свой товар, могут оказаться в невыгодном положении по сравнению с менее осведомленными. Им бывает сложно адаптировать свою речь к клиентам и убедить их купить продукцию. Также они знают больше как о достоинствах, так и о недостатках продукта, поэтому они могут ставить более низкую цену.
В 1990 году психолог Элизабет Ньютон провела серию экспериментов, которые наглядно продемонстрировали проклятие знания. В одном из них она разделила участников на «исполнителей» и «слушателей».
«Исполнители» выстукивали мелодии, а «слушатели» пытались угадать их. «Исполнители» предполагали, что «слушатели» смогут узнать около половины песен. Но в результате эксперимента выяснилось, что они отгадали только 3 песни из 120. «Исполнители» не смогли абстрагироваться от собственного знания песни и переоценивали, насколько легко ее определить.
В чем проклятие?
Проклятие знания тесно связано с когнитивной предвзятостью. Это результат обобщения информации на основе личного опыта и полученных ранее знаний.
Знания — это результат усвоения информации. Однако с каждым шагом обработки данных объективный контекст в нашем мозгу заменяется персонализированным смыслом. Память о том, как мы приобрели знания, время и контекст событий, постепенно стираются. В результате мы становимся заложниками предубеждения задним числом, неспособными вспомнить, как мы мыслили и что знали до того, как получили новую информацию.
Опытные люди, обладающие глубокими познаниями в определенной области, часто подвержены проклятию знания. Каждый хоть раз сталкивался с учителем или преподавателем, которые, несмотря на огромный багаж знаний, не могли адекватно донести материал до учащихся.
Например, как в этом шуточном видео, которое на курсах по ораторскому мастерству приводят в качестве иллюстрации по-настоящему плохого выступления.
Лектор перегрузила слушателей информацией и отказалась объяснять термины. Она аргументировала это тем, что если студенты не знают этого материала, им не стоит находиться в аудитории.
Проклятие знания негативно сказывается на общении, приводит к проблемам в командной работе. И в таком сложном процессе, как разработка программного продукта, когнитивные искажения могут доставить массу проблем.
Рассмотрим несколько ситуаций, где разработчик может столкнуться с проклятием знания.
Разработчик и новичок
В мире технологий роль наставника и ментора очень важна. Однако опытный специалист, обладая внушительным багажом знаний, может забыть, что не все вещи очевидны для новичков. Он начинает использовать специфические термины и абстрактные понятия. И вместо того, чтобы «расшифровать» сложные моменты, может неосознанно создавать у ученика чувство неуверенности и глупости.
Когда новый сотрудник присоединяется к проекту, ему необходимо адаптироваться, вникнуть в процессы. У него постоянно множество вопросов, на которые ему хочется получить ответ.
Конечно, техническая документация может стать ценным помощником для новичков. Но она не всегда доступна. Часто всей необходимой информацией по проекту владеет только тимлид. Но даже если документация в наличии, полностью избавиться от вопросов не получится. Она может быть весьма объемной и в ней будет трудно разобраться.
Или, наоборот, потребуется более детальное объяснение каких-то моментов.
Как решить проблему
Наставнику
1. Нужно помнить о проклятии. Не забывать, что опыт каждого человека индивидуален.
2. Использовать метод Фреймана. Объяснять информацию нужно словами, понятными даже подростку. Это помогает укрепить собственные знания, потому что объяснить концепцию без сложных терминов очень непросто.
3. Использовать техническую документацию. Как минимум нужно собрать артефакты проектных процессов: флоу процесса разработки, график, бэклог продукта, список контактов и т. д. Хорошо написанные документы экономят уйму времени.
4. Пояснять контекст заданий и процессов.
Новичку
1. Повышать уровень знаний.
2. Ценить чужое время. Задавать конкретные и точные вопросы.
3. При работе с документацией обращать внимание на все, что вызывает вопросы. Нужно использовать свежий взгляд нового сотрудника, чтобы предложить улучшения в процессах и документации.
4. Не бояться признаться, если чего-то не знаешь.
Разработчик и заказчик
В отношениях между заказчиками и исполнителями также часто возникают сложности из-за проклятия знания. Заказчик может не объяснить важные моменты, полагая, что эта информация и так очевидна. Исполнитель может сделать работу так, как он ее понял. И в результате ситуация будет напоминать знаменитый мем с качелями.
Додумывать за заказчика — ошибка, которая может дорого обойтись. Недостаток информации может привести к разработке системы, которая не решает реальную проблему.
Как решить проблему
1. Задавать уточняющие вопросы, чтобы понять потребности заказчика, избежать ненужных трат времени и ресурсов. Если, не разобравшись в деталях, начать выполнять задание, можно потратить время и силы на то, что не принесет результата.
2. Использовать открытые вопросы. Вместо вопроса: «Вам нужна голубая кнопка?», спросить: «Какую цель вы преследуете, добавляя эту кнопку на сайт?».
3. При создании продукта важно фокусироваться на бизнес-логике, стремиться понять цель и причины действий и предлагать улучшения, если что-то кажется нелогичным.
Разработчик в команде
В идеальном мире продуктовая команда работает как единый организм, где все понимают друг друга с полуслова. Но реальность такова, что даже при наличии общего словаря и единой картины мира, могут возникать недопонимания, особенно когда речь идет о технических аспектах.
Наиболее ярко проклятие знания проявляется в попытке разобраться с рабочим кодом. Иногда кажется, что код не нуждается в комментариях. Но с течением времени проект развивается, требования меняются, а код переписывается. Несоблюдение единых правил форматирования, наименования переменных и функций, а также структуры кода делает его сложным для восприятия.
Через какое-то время и собственный код может казаться программисту чем-то запутанным и непонятным. А чужой код — еще тот темный лес.
Если в команде возникают разногласия, проклятие знания мешает понять позицию оппонентов. Диалог превращается в спор, а это очень непродуктивно.
Но, когда все сотрудники придерживаются единой позиции, могут возникать коллективные заблуждения. Если, несмотря на отсутствие объективных доказательств, вся команда уверена в правильности своего решения — это не очень хорошо. Вполне возможно, что в компании нет пространства для критики и альтернативных предложений.
Так, например, устойчивое мнение руководителей IBM о том, что рынок персональных компьютеров никогда не станет массовым, привело к тому, что компания не закрепила за собой полные права на операционную систему MS-DOS. И в результате понесла многомиллиардные убытки.
Как решить проблему
1. Составить четкие технические спецификации, комментировать код, использовать единые стандарты оформления.
2. Комментарии к коду должны быть структурированы. Они нужны, чтобы пояснять непонятные или спорные моменты, а не просто дублировать код. Лучшие комментарии отвечают на вопрос «зачем это тут происходит», но если ответ на этот вопрос понятен из самого кода, комментарий не требуется.
3. Важно, чтобы в команде каждый мог задавать вопросы, не боясь быть осмеянным, поощрялись разные точки зрения, было пространство для конструктивной критики и альтернативных предложений.
Разработчик и пользователь
Проклятие знания не только влияет на то, как мы работаем друг с другом, но также может оказать негативное влияние на юзабилити. Это когнитивное искажение может стать серьезным препятствием для создания удобных и понятных интерфейсов.
Дизайнеры, которые сами хорошо разбираются в продукте, могут невольно создавать сложные и запутанные интерфейсы, не осознавая, что для пользователя они могут быть непонятными.
Также проблемой могут стать неясные инструкции. Ведь для пользователя даже инструкция «нажмите кнопку “сохранить”» может быть непонятной, если кнопка находится в непривычном месте.
Проклятие знания заставляет забыть о том, что не все пользователи имеют одинаковый уровень знаний. Одни могут быть экспертами, а другие — новичками, и если не предоставить им необходимую информацию, их взаимодействие с продуктом превратится в кошмар.
Как решить проблему
1. Необходимо представить себя на месте пользователя. Можно переустановить программу и обратить внимание на каждый этап процесса. Или использовать продукт на новом устройстве.
2. Тестирование юзабилити также позволит увидеть, как продукт воспринимается реальными пользователями и какие проблемы они испытывают.
3. При создании инструкций нужно объяснять все действия пошагово и избегать неясных формулировок.
4. Можно создать систему подсказок. Она поможет пользователям разобраться в интерфейсе и выполнить необходимые действия. Использовать визуальные элементы. Изображения, графики и видео могут сделать информацию более доступной и понятной.
Вывод
Проклятие знания — естественная часть мышления. Оно мешает четко доносить мысли до других людей, понимать их позицию, продуктивно общаться. Признав существование проклятия знаний, можно избежать многих ошибок. Главное — помнить об ограниченности восприятия, рассматривать разные точки зрения и не бояться получать обратную связь от коллег и пользователей.
Автор статьи Роман Андреев
НЛО прилетело и оставило здесь промокод для читателей нашего блога:
— 15% на заказ любого VDS (кроме тарифа Прогрев) — HABRFIRSTVDS
