How Cognitive Biases Affect our Software Architectures • Birgitta Böckeler • YOW! 2022

Это интересный доклад для архитекторов, в котором рассматривались следующие предубеждения, которые важны нам при проектировании софта:

• Confirmation biases характеризуется тем, что люди подсознательно работают с информацией так, чтобы подтвердить свою точку зрения. Это приводит к тому, что люди с трудом принимают изменения и склонны к повторению своих предыдущих решений и действий. Именно поэтому часто нам так сложно менять устоявшиеся процессы разработки или архитектуру решения - обычно это требует от руководителей мастерского управления изменениями. Я часто сталкивался с этим bias у других, да и ловил его у себя самого.
• Zero risk bias — этот bias влияет на то, как люди управляют рисками. Зачастую есть желание полностью исключить небольшой риск, а не смягчить общий риск даже на большую величину. Это относится к security рискам, избеганию vendor lock in или наличию преждевременных оптимизаций, которые могут защитить нас от рисков масштабирования, но часто не пригождается в итоге, а стоят дорого. Этот bias можно обойти, если иметь фреймворк для работы с рисками и использовать его в своих проектах.
• Availability heuristics - этот bias про принятие быстрых, но иногда не самых правильных решений. И мы строем свои выводы на доступной информации. В разработке софта это например проявляется в том, что часто про техдолг забывают, так как он бывает явно не зафиксирован и его как бы нет:) Поэтому стоит идти от обратного - делать так, чтобы информация о важных вещах была легко доступна. В разработке софта это относительно легко сделать используя логи, метрики, трейсинг как для технических систем, так и для самих процессов разработки.
• Base rate fallacy - этот bias влияет на то, как мы оцениваем вероятность разных сценариев, а дальше как мы распределяем силы своих команд. Часто мы уделяем больше внимания edge cases, про которые мы знаем много, в ущерб каким-то более общим сценариям. Этот bias влияет на приоритизацию усилий, поэтому классно, если у вас есть +/- стандартные метрики для оценки и сравнения важности задач между собой.
• Outcome bias - этот bias про то, что люди оценивают принятые решения на основании результатов. У нас есть поговорка “победителей не судят” и она как раз про это. Но гораздо продуктивнее поменять подход к оценке решения, ориентируясь на ту информацию, которая была доступна в момент принятия решения. В разработке этот подход применяют, когда используют процессы с написанием RFC (request for comments) и ADR (architecture decision records). Это позволяет постфактум оценивать качество решений, а не просто отталкиваться от результатов.
• Self-serving bias - этот bias о том, что люди склонны приписывать успех своим способностям и усилиям, а неудачи - внешним факторам. Это тоже влияет на то, как мы оцениваем свои решения. И этот bias мешает нам расти над собой, потому что мы свои точки роста выводим из своей зоны контроля апеллируя к слепому случая. Гораздо конструктивнее следовать пословице “на ошибках учатся”.

P.S. Доклад хорошо продолжает вчерашний пост про Sunk cost fallacy (Невозвратные затраты)

#Thinking #CriticalThinking #Reasoning #Philosophy #SelfDevelopment #Brain #Management #Leadership