Проклятие знания — термин, предложенный психологом Робином Хогартом для обозначения психологического феномена, заключающегося в том, что более информированным людям чрезвычайно сложно рассматривать какую-либо проблему с точки зрения менее информированных людей.
Эта штука встречается в работе чаще, чем нам бы этого хотелось.
Обучение и менторство
Видел много раз, что опытный наставник довольно непонятно и непродуктивно чему-то учит новичков. Он уже и забыл, как был сам начинающим специалистом, и что вот эти вот «простейшие азы, которые очевидны», на самом деле не простейшие, не очевидные, и требуют детального объяснения.
В итоге обучающий сыплет сложными терминами и абстракциями, а обучающийся готов провалиться под землю от чувства собственной ничтожности. Ведь наставник же говорит, что там всё легче легкого, значит, это обучающийся – плохой, глупый, неправильный.
Заказчик-исполнитель
В отношениях заказчиков и исполнителей тоже порой всё плохо. Заказчик выдает лишь половину нужной информации, потому что он знает уже хорошо свою доменную область и «ЭТО ЖЕ ОЧЕВИДНО» (оригинальная цитата, с которой я столкнулся в подобном случае).
Или наоборот, исполнитель рассказывает продавцу тортиков, какие он паттерны проектирования использует, как CI/CD настроит и почему синглтон нынче считают моветоном.
Абсолютно то же самое происходит во взаимодействии менеджер-программист. Один про код, другой про РОИ, ДАУ, МАУ, CJM и прочее.
Программист-программист
Уже вроде проще. Да, но нет.
Тут тоже сильно зависит от компетенции и знания глоссария. Кстати, здесь в какой-то мере помогает, например, теория паттернов проектирования. Ведь тут у всех появляется общий словарь и одинаковое понимание абстракций.
Что делать
На мой взгляд, надо хорошенько думать о собеседнике. Надо прикидывать, что он знает, что не знает. Давать как можно больше контекста по теме разговора. Надо уточнять, всё ли понятно. Ну т.е. совет, казалось бы, обо всём и ни о чем.
Давайте чуть более практический пример. Если я хочу, чтобы пентестеры проверили мой новый проект, я не напишу им «Доброго времени суток, коллеги! Прошу проверить мой проект.», как это могли бы сделать некоторые. Я сообщу им весь потенциально нужный контекст, которого они не знают.
Например, я объясню:
⁃ Что за проект и какая у него основная цель. Это нужно для общего понимания, на что делать упор при проверке.
⁃ Когда дедлайн по запуску. Чтобы сроки выполнения сматчить.
⁃ Есть ли пользовательский ввод и если да, то где и какой: формы, загружаемые файлы, регистрации, авторизации и прочее. Чтобы этому уделили максимальное внимание и ничего не осталось незамеченным.
⁃ Есть ли интеграции с внешними системами. Чтобы понимали, какие данные могут поступать извне и куда, в случае прорыва периметра, куда злоумышленник может попасть еще.
⁃ Какой стэк технологий, где конфиги, данные о внешних модулях и библиотеках. Чтобы выяснить все данные об известных уязвимостях.
⁃ Где конфиги сервера и как получить туда доступ. Ведь не только на уровне кода бывают уязвимости.
Все эти пункты дают ответы сразу на многие вопросы, которые потенциально возникали бы спустя часы бестолкового поиска вслепую. Заодно меньше шанс, что что-то пропустят, потому что не знали про это и оно лежало в каком-то неочевидном месте.
Возможно, этих данных окажется недостаточно, и тогда я готов отвечать на дополнительные вопросы. Но я буду знать, что я изначально покрыл большинство темных пятен и люди будут уже что-то уточнять, довольно неплохо ориентируясь в проекте.
Итог
Формирования общего глоссария с собеседником, передача полного контекста, мысль о том, что всё, что очевидно для тебя, может быть неочевидно для кого-то другого – всё это ведет к минимизации негативного эффекта проклятия знания, устранению лишней пустой работы и вопросов.
А еще это довольно уважительно по отношению к собеседнику. А люди любят, когда их уважают.