Когнитивные искажения и принципы мышления
| Название | Альтернативное название | Правило / принцип | Описание |
|---|---|---|---|
| Принцип Парето | Принцип 80/20, Закон значительного меньшинства | 20% усилий или причин дают 80% результата или последствий | Небольшая часть действий приносит большую часть успеха, в то время как остальные усилия дают лишь малый эффект. Цифры 80 и 20 условны, они служат удобным ориентиром, а не жёстким математическим законом. |
| Закон Мёрфи | Закон подлости, Закон хронического недоверия | Всё, что может пойти не так, пойдёт не так | Если существует возможность совершения ошибки, она обязательно произойдёт. Этот закон напоминает о необходимости тщательного планирования и создания резервных вариантов действий для минимизации рисков. |
| Принцип Питера | Принцип карьерного роста | Любой человек склонен занимать должность, выше которой он некомпетентен | В иерархической организации каждый работник стремится к повышению. Со временем каждый сотрудник достигнет своей «некомпетентности» — уровня, на котором уже не может эффективно работать. В результате должности часто занимают некомпетентные специалисты. |
| Бритва Оккама | Принцип экономии мышления, Закон простоты | Не следует умножать сущие без необходимости (Entia non sunt multiplicanda praeter necessitatem) | Из нескольких возможных объяснений данного факта следует выбрать наиболее простое. Чем меньше допущений — тем надёжнее вывод. Этот принцип лежит в основе научного метода и эффективной отладки. См. также: Бритва Кванты. |
| Эффект Даннинга — Крюгера | Эффект перевала глупости, Синдром самоуверенного новичка | Люди с низкой компетенцией склонны переоценивать свои способности | Некомпетентные люди не способны осознать свою некомпетентность. Чем больше человек знает, тем лучше он понимает границы своих знаний. И наоборот — новичок часто считает себя экспертом из-за отсутствия метакогнитивных навыков. |
| Закон Гудхарта | Проблема индикаторов, Закон подмены целей | Когда мера становится целью, она перестаёт быть хорошей мерой | Как только показатель (KPI) становится целью для достижения, он перестает быть надёжным индикатором реального положения дел. Люди начинают оптимизировать метрику, а не реальный результат, что приводит к искажениям и манипуляциям. |
| Бритва Кванты | Бритва скептиков, Принцип достаточного доказательства | Сила утверждения пропорциональна силе доказательств. «Чрезвычайные Claims требуют чрезвычайных доказательств» | Карл Саган: если кто-то утверждает сверхъестественное — бремя доказательства на нём. В разработке: новый фреймворк «революционный» — покажи бенчмарки и миграционные кейсы. См. также: Бритва Оккама. |
Продуктивность и управление временем
| Название | Альтернативное название | Правило / принцип | Описание |
|---|---|---|---|
| Закон Паркинсона | Закон расширения задач, Закон раздувания сроков | Работа расширяется до времени отведённого на неё | Сколько бы времени ни было выделено на задачу, она займёт всё это время. Если на проект дан месяц — он будет делаться месяц. Если год — будет делаться год. Контроль сроков и жёсткие дедлайны — ключ к эффективной работе. |
| Принцип Хофштадтера | Закон Хофштадтера, Закон многократно ошибочного планирования | Работа всегда занимает больше времени, чем ожидается, даже с учётом закона Хофштадтера | При планировании сроков практически невозможно корректно оценить сложность задачи, особенно на последних этапах. Всегда следует добавлять существенный запас времени к любой оценке, так как неизбежно возникнут непредвиденные сложности. |
| Закон Декки | Линейный закон времени, Закон 50% | Если задача занимает уже половину отведённого срока, она займёт удвоенное оставшееся время | Эволюция закона Хофштадтера. Если вы потратили половину предполагаемого срока на полпути к цели — вы будете работать вдвое дольше запланированного. Помогает своевременно корректировать ожидания и сроки. |
| Матрица Эйзенхауэра | Матрица приоритетов, Разделение задач | Распределяй задачи по 4 квадрантам: важное/срочное — неважное / не срочное | Квадрант I: сделать сейчас. II: запланировать. III: делегировать. IV: удалить. Критический инструмент для борьбы с «пожарами» вместо стратегической работы. |
| Принцип 1–3–5 | Правило планирования дня, Метод приоритизации дня | В день: 1 большая + 3 средних + 5 малых задач | Реалистичный лимит продуктивности: за день реально сделать только ~9 задач, если их ранжировать по сложности. Предотвращает перегрузку и выгорание. |
| Эффект Цейгарник | Эффект незавершённых действий, Закон незакрытых циклов | Незавершённые задачи запоминаются лучше завершённых | Мозг «висит» на открытых циклах. Решение: записывай всё, декомпозируй, закрывай. Используется в трекерах задач и GTD-методологии для снижения тревожности. |
| Law of the Last Responsible Moment | Закон последнего ответственного момента, Принцип максимума откладывания | Не принимай решения раньше времени — информация со временем становится ценнее | Ранние решения фиксируют варианты и блокируют гибкость. Откладывание до последнего возможного момента сохраняет максимум альтернатив. Основа Agile и Lean. |
Программирование и разработка
| Название | Альтернативное название | Правило / принцип | Описание |
|---|---|---|---|
| Принцип KISS | Keep It Simple, Stupid; Будь проще | Стремись к максимальной простоте в решениях и дизайне | Большинство систем работают лучше всего, если они простые. Не следует усложнять там, где можно сделать проще. Простые системы легче поддерживать, отлаживать и масштабировать. См. также: YAGNI. |
| DRY (Don't Repeat Yourself) | Не повторяйся, Принцип единого абстрактного представления | Каждая часть кода должна иметь одно и единственное представление | Любое знание или логика в системе должны быть представлены однократно. Повторяющийся код приводит к рассинхронизации, багам и трудностям поддержки. Выноси общую логику в функции, модули или библиотеки. См. также: Boy Scout Rule. |
| YAGNI (You Ain't Gonna Need It) | Ты этого не будешь использовать, Принцип отказа от прогнозов | Не добавляй функциональность, пока она реально не понадобилась | Всегда реализуй то, что нужно в данный момент — и больше ничего. Предсказания о будущих потребностях почти всегда ошибочны, а преждевременная оптимизация усложняет код и замедляет разработку. См. также: KISS. |
| Принцип наименьшего удивления | Principle of Least Astonishment (POLA), Закон ожидаемости | Поведение системы должно соответствовать ожиданиям пользователя | API, интерфейс или код должны вести себя так, чтобы это было максимально предсказуемо и интуитивно понятно. Если функциональность ведёт себя неожиданно — это плохо спроектированная система, независимо от её мощности. |
| Boy Scout Rule | Правило бойскаута, Принцип очистки | Оставляй код чище, чем ты его нашёл. Каждое изменение — мини-рефакторинг | Каждый раз, когда вносишь правку, улучши Surrounding-код: убери дубли, переименуй, упрости. Накопительный эффект — вечный рефакторинг без отдельной фазы. См. также: DRY. |
| Закон Дилберта | Закон накопления проблем, Эффект Матрёшки | Количество накопленных проблем растёт пропорционально числу людей, решающих эти проблемы | Больше участников = больше решений = больше побочные эффекты и новых проблем. Масштабирование команды без синхронизации ухудшает систему. |
| Test Pyramid (Майк Кон) | Принцип пирамиды тестов, Иерархия тестирования | Чем ниже уровень теста — тем больше их должно быть; E2E-тесты — вершина пирамиды, очень мало | Баланс: много юнит-тестов → среднее число интеграционных → минимум E2E. Быстрая обратная связь на низком уровне предотвращает дорого-стоящие регрессии. |
| Broken Windows Theory (в разработке) | Теория разбитых окон, Эффект деградации кода | Признаки деградации привлекают новые признаки; мелкие «косяки» ведут к системному упадку | Прогнившие окна в здании сигнализируют: здесь никому нет дела. В коде: не зачищенные TODO, плохие имена, дубли — всё это снижает стандарт команды и ускоряет деградацию. |
Архитектура и проектирование
| Название | Альтернативное название | Правило / принцип | Описание |
|---|---|---|---|
| Закон Фолкса | Закон необходимости, Формула Фолкса | Не выбирайте решение, пока не изучите все существующие альтернативы. «Прежде чем выбрать инструмент отказа — изучи всё, что уже написано» | Самый известный закон в разработке ПО: прежде чем писать своё решение, проверь — нет ли уже готового. Связан с принципом «не изобретай велосипед». |
| Закон Хаммера | Закон инструмента, Эффект молотка | Для каждого проблемного взгляда на мир остаётся достаточно молотков. «Если у вас есть молоток — каждая проблема выглядит как гвоздь» | Склонность видеть все проблемы через призму привычных инструментов и методов. Приводит к неоптимальным решениям: программист пытается «закодить» то, что решается процессом или коммуникацией. |
| Закон Гэммона | Закон ускорения, Убегающий рубеж | Когда производительность объекта увеличивается — потребность в объектах растёт, сводя на нет ожидаемый эффект повышения эффективности | Автоматизация одного процесса без оптимизации остальных создаёт «бутылочное горлышко» elsewhere. Масштабирование отдельных элементов без системы даёт лишь иллюзию улучшения. |
| Теорема Конвея | Закон соответствия архитектуры, Обратная теорема Конвея | Организация, проектирующая систему, обязана пройти структуру, которая её воспроизводит. «Коммуникационные структуры диктуют структуру кода» | Архитектура продукта зеркально отражает архитектуру команды. Если команды разделены — и код будет монолитом из silos. Для микросервисов нужны кросс-функциональные команды. См. также: Закон Конвея. |
| Закон деметера (LoD) | Принцип наименьшего знания, Закон малоинформированности | «Только разговорься со своими непосредственными друзьями» — не обращайся к промежуточным членам внутренних модулей других объектов | Минимизация связанности: объект должен знать только о своих непосредственных зависимостях. Уменьшает хрупкость и упрощает рефакторинг. |
Управление и организация
| Название | Альтернативное название | Правило / принцип | Описание |
|---|---|---|---|
| Закон Конвея | Конвергенция архитектуры и организации, Закон коммуникационных структур | Системы проектирования не избегают коммуникационных структур организаций | Архитектура ПО напрямую отражает структуру команды, которая его создаёт. Чтобы улучшить архитектуру системы, часто необходимо перестроить коммуникационные потоки внутри команды. Разделили команду — разделили и систему. См. также: Теорема Конвея. |
| Принцип Диогена | Не трогай работающее, Закон невовмешательства | Если работает — не исправляй (If it works, don't fix it) | Существующая работающая система является лучшим решением, чем потенциально лучшая, но нереализованная. Любое изменение несёт риски и затраты — они должны быть строго обоснованы измеримой выгодой. |
| Закон Рикрофта | Закон взаимных аргументов, Закон контраргументации | Любое громкое заявление имеет равный ему по силе контраргумент | В любом споре или обсуждении можно найти как сторонников, так и противников практически любой точки зрения. Это не означает, что все мнения равнозначны — но важно искать аргументы за и против для формирования взвешенного суждения. |
| Правило двух пицц (Amazon) | Оптимальный размер команды, Закон Джеф Безоса | Команда должна питаться двумя пиццами — не больше ~8 человек. Больше — слишком много коммуникации | 9 человек = 36 возможных связей. Эффективная команда — 5–8 человек. Для масштабирования: разбивай на несколько автономных команд с чёткими API-контрактами. Связан с теоремой Конвея. |
| Закон Шентона | Закон совместимости команд, Принцип распределения задач | Задачи должны распределяться по команде пропорционально их способности решать эти задачи | Если одна команда берёт на себя слишком много — она становится узким горлышком. Распределяй нагрузку, учитывая экспертизу и загрузку. Иначе — перегрузка лидеров + простой остальных. |
Общие принципы и эффекты
| Название | Альтернативное название | Правило / принцип | Описание |
|---|---|---|---|
| Эффект плацебо | Обратное плацебо, Эффект иллюзии полезности | Вера в эффективность воздействия способна вызвать реальный физиологический или психологический результат | Если человек верит, что получает помощь — она с большей вероятностью поможет. Обратный эффект (ноцебо) — ожидание негатива может усугубить симптомы даже при безобидном воздействии. Влияние сильно в проектах: «рецепт работал у всех» часто помогает и на твоём проекте. |
| Эффект Бербона | Закон деградации интерфейсов, Парадокс улучшений | Пользователи не принимают улучшения системы, если они меняют привычный интерфейс | Чем лучше становится система с точки зрения разработчика — тем меньше пользователи готовы её использовать, если это нарушает их устоявшиеся привычки. Изменения нужно внедрять плавно, сохраняя обратную совместимость и интуитивность. |
| Эффект ореола (Холло) | Гало-эффект, Эффект сияющего ореола | Общее впечатление о человеке или продукте искажает оценку его отдельных качеств | Если объект воспринимается положительно в целом, мы склонны переоценивать и все его свойства — даже те, которые не проверили. В разработке: красивый UI заставляет верить в качество «под капотом», что может быть обманчивым. |
| Эффект обрамления | Фрейминг-эффект, Эффект контекста подачи | Одно и то же содержание воспринимается по-разному в зависимости от способа подачи | «95% без жира» звучит лучше, чем «5% жира». Один и тот же код, описанный как «решение проблемы» или «дополнительная функция», получает разную реакцию команды. Контекст и формулировки критически важны при коммуникации. |
| Эффект якоря | Эффект привязки, Anker-Effekt | Первая полученная информация существенно влияет на последующие решения и оценки | Начальная цифра или факт служат «якорем», к которому затем адаптируются все последующие суждения. В переговорах первый озвученный номер часто становится базой для сделки. В разработке: первоначальный план проекта задаёт тон всем дальнейшим оценкам. |
| Фундаментальная ошибка атрибуции | Эффект соответствия, Гипотеза соответствия | Склонность объяснять поведение других внутренними качествами, игнорируя внешние обстоятельства | Если коллега опоздал — мы думаем: «он безответственный». Если опоздали мы — «пробки были». Мы переоцениваем характер человека и недооцениваем влияние ситуации. Ведёт к конфликтам в командах и неверным выводам о причинах проблем. |