Аналитическая агония: симптомы и лечение

Зацепился я за тему "излишнего думанья" - держу курс дальше.

Слишком уж важной считаю эту когнитивную болезнь - мешает она буквально во всех сферах жизни и не дает счастливо жить и развиваться. Некоторые примеры я привел из родной области разработки, но все метафоры и сравнения переносятся на любой проект вне IT. Все же это болезнь людей, а не проблема в конкретной индустрии.

Откуда возникает болезнь

У каждого True шизоида есть внутреннее, животное желание все усложнять, все учитывать и уничтожать неопределенность в работе и жизни.

Такая аналитическая работа ничего не имеет общего со здоровой рациональностью, так как здесь сразу всплывают несколько когнитивных искажений:

Иллюзия контроля
Желание все учесть - это желание контролировать ситуации.
Если бы только мы могли все контролировать...
Уклон в сторону поиска информации
Это про те бесконечные часы, проведенные за поисковой строкой Google.
Амплификация.
Пытаемся планировать какую-либо деятельность, наивно думая, что мы имеем достаточно исходных данных для построения глубокого плана. Это в тему иллюзии контроля.

Симптомы болезни

Если не бороться с этими когнитивными искажениями, то болезнь продолжит прогрессировать и начнут проявляться следующие симптомы.

Парализовало

Правило Парето прекрасно описывает корень проблемы: на проработку 80% проблем тратим 20% усилий, а на оставшиеся 20% проблем - 80%.

За собой заметил, что мне сложнее принять хоть какое-нибудь решение, если я начинаю об этих 20% проблем думать. Возникает аналитический паралич.
В эти 20% обычно входят мелкие детали реализации, устранение неопределенность и теоретические размышления о будущем. Если глубоко копнуть в них, то можно сойти с ума и осознать масштаб неопределенность вокруг нас.

Притупилась креативность

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

Естественно, сравнивать все это - неоптимальное действие.
Так что можно забить на 20% проблем и работать продуктивнее.

Повысилась тревожность

Сидишь, формулируешь проблемы, кучу кода пишешь, думаешь. И в момент "обдумывания" все проблемы кажутся такими существенными и важными. Даже ЧСВ повышается, ты же думаешь...

А потом БАЦ, БАЦ и как-то тревожно начинаешь себя чувствовать.

И не только ты.

Твой тимлид, менеджер, CEO, CTO и любой, кто хоть как-то от тебя зависит.

Ты сидишь и пытаешься объять всю сложность и многогранности задачи.
+тревожность

Тимлид на daily слушает тебя и не видит никакого прогресса, все ждет завершения задачи уже 5-й день.
+тревожность
CEO деньги считает и не понимает, почему пара важных фич уже 2-й спринт висит и "дорабатывается", а аналитика "требует уточнений".
+тревожность
А в повышенная тревога в долгосроке - это выгорание и хроническая усталость.

Смерть

Продукта, который ты делаешь.

20% проектов так и не завершается - 8% выходят плохими.
Лучше бы сделали не очень хорошо.

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

Есть в теории систем один закон - закон Галла.

Любая работающая сложная система развивается на базе работающей простой системы. Сложные системы, созданные с нуля, никогда не будут работать в реальном мире, поскольку в процессе разработки на них не влияли факторы отбора, присущие среде

Этот закон можно связать с одной классификацией сложности в Software Design.
Фред Брукс в своей книге "No Silver Bullet—Essence and Accident in Software Engineering" ввел понятия essential complexity и accidental complexity - естественной сложности и непреднамеренной сложности.

Естественная сложность - это необходимая сложность, минимально-достаточная для реализации полезного продукта. Рынок и существующие бизнес-процессы создают эту сложность.
Непреднамеренная сложность - эта уже сложность, которую разработчики сами создали.

Непреднамеренная сложность не помогает зарабатывать денег. Она существует только из-за изъянов в мышлении людей, сложности общедоступных технологий и отсутствия опыта в индустрии.
С ней как раз нужно бороться, иначе весь проект станет песочницей в руках шизоида (разработчика/Product менеджера/основателя) и адаптация к рынку замедлится.

А для системы, которая так и не была протестирована в бою - это смерть.

Лечение

Любая умственная работа провоцирует болезнь, но если регулярно проверяться, то можно избежать последствий.
Составил небольшой check-up для выявления болезнь на ранней стадия.

Ответы на эти вопросы помогают мне не сбиваться с пути и быть чуть результативнее.

Тесты на резистентность к неопределенности

Готов ли я сейчас подстроиться под изменения в будущем?
Я привык действовать, как действую сейчас, или так надо действовать?

Тесты на осмысленность действий

Зачем я это делаю?
Я понимаю текущие приоритеты?
Какие критерии качества у результата?

Тест на результативность

Сколько времени я потратил на размышления? Сколько на работу?
Могу ли я приложить меньше усилий и получить достаточно хороший результат?
Что мне даст увеличение времени на размышления сейчас? Обязательно ли его тратить сейчас?

Про то, как лечить это все в рамках разработки IT-продукта я напишу в других статьях - непаханое поле для рассуждения об Agile, TDD, XP и принципах в Software Design.

Материалы

Телеграмм-канал: https://t.me/vasiliy_shiz

Me: https://t.me/Albert_Spoon