Что такое тавтология?
По заголовку, скорее всего, вообще не будет понятно о чем этот пост, но тема на мой взгляд ОЧЕНЬ важна.
Некоторое время назад я учился у Елены Федурко мыслительным инструментам Голдратта. Одно из ужасных осознаний свелось к тому, что в большинстве случаев для большинства из нас ясно и четко мыслить - неподъемная задача.
Следующее ужасное осознание - это масштаб и количество решений разной степени важности, которые на самом деле были приняты не на основе логических рассуждений, а на основе логических ошибок.
Этот пост посвящен логической ошибке, которая в книге Голдратта "Выбор" называется тавтология или логика замкнутого круга, хотя я еще слышал вариант рекурсия.
Это ошибка в обосновании логической связи между двумя утверждениями, заключающаяся в том, что вместо обоснования связи мы используем полный повтор этих двух утверждений.
Пример из книги:
Ты не чувствуешь разочарования, потому что подавил его в себе
Здесь есть два логических утверждения:
- Ты не чувствуешь разочарования
- Ты подавил в себе разочарование
И слово потому что говорит о том, что я верю в существование причинно-следственной связи между ними.
Но, каждая причинно-следственная связь должна быть обоснована. Однако, стоит спросить: "А почему ты решил, что я подавил в себе разочарование?", как ответ будет: "Ну ты же его не чувствуешь".
Давайте еще пример:
Для того, чтобы быстрее исправлять ошибки мы должны разработать документацию
Причинно-следственная связь должна комфортно ложиться в конструкцию:
Для того чтобы <Следствие> мы должны/нам нужно <Причина>
При этом и причина и следствие должны быть полноценными логическими утверждениями, а не обрывками фраз вида "плохая приоритезация", "отсутствие стратегии", "нечеткие планы"
Если мы научились формулировать стройные конструкции с причинно-следственными связями, то обоснование этой связи будет естественным продолжением в формате:
Для того чтобы <Следствие> мы должны/нам нужно <Причина> потому что <обоснование>
И вот тут крайне важно следить за отсутствием тавтологии, чтобы не получилось:
Для того, чтобы быстрее чинить систему мы должны разработать документацию, потому что ну... документация помогает быстрее исправлять ошибки...
Не только же меня коробит это логическое высказывание?
Давайте еще пример:
Для того, чтобы повысить продажи нашего сервиса мы должны разработать новую фичу Х, потому что фича Х нужна для увеличения продаж.
Не коробит?
Давайте еще пример:
Для того, чтобы повысить эффективность работы отдела нам нужна актуальная стратегия компании, потому что без стратегии мы не можем эффективно работать.
Ну в этом примере по идее вообще ущербно все, но обоснование причинно-следственной связи - особо.
И тут вопрос: а как часто вы сталкиваетесь (в явной или не явной форме) с подобными тавтологическими обоснованиями?
И если эти примеры обоснований плохие, то как правильно?
Третий элемент
Признаюсь, как правильно я сам узнал совсем недавно. И до этого во всех моих рассказах о мыслительных инструментах Голдратта этого не хватает и из-за этого эти рассказы практически мало полезны. Увы. Список этих малополезных рассказов будет в самом конце.
Про правило формулировки исходной посылки (так в мыслительных инструментах называется обоснование причинно-следственной связи) я узнал на тренинге Елены Федурко. И это правило просто и изящно.
Правильная посылка должна в себе содержать слова:
- относящиеся к первому утверждению
- второму утверждению
- не относящиеся ни к первому, ни ко второму утверждению. То есть третий элемент
Давайте я приведу примеры более-менее адекватных обоснований причино-следственных связей из предыдущих примеров. В этих обоснованиях я жирным отмечу то, что считаю третьим элементом.
Для того, чтобы быстрее чинить систему мы должны разработать документацию, потому что большинство сбоев - типовые, а служба технической поддержки (ответственная за их устранение) не имеет доступа к коду, чтобы самостоятельно во всем разбираться.
Для того, чтобы повысить продажи нашего сервиса мы должны разработать новую фичу Х, потому что результаты опроса потенциальных клиентов показывают, что N% респондентов отказываются от покупки исключительно из-за отсутствия этой фичи.
Для того, чтобы повысить эффективность работы отдела нам нужна актуальная стратегия компании, потому что мы хотим остановить работу над проектами, не вписывающимся в стратегию и сконцентрируемся на оставшихся проектах.
Ну как? Лучше?
Что важно, каждый раз, когда в обосновании причинно-следственной связи вам удается выделить третий элемент у вас появляется возможность найти какое-то решение (если причинно-следственная связь описывает проблему) или альтернативный способ (если связь описывает какое-то решение).
Попробуйте сами ниже в комментариях сформулировать причинно-следственную связь и обосновать ее, обращая внимание на наличие третьего элемента.
Мои бесполезные рассказы о мыслительных инструментах
Это рассказы 6-7 летней давности:
Два года назад я уже начал понимать, что рассказывал не всю правду:
Но в прошлогоднем видосе все равно не хватало самого важного - рассказа про третий элемент.
На самом деле эти рассказы не совсем бесполезные. Они бесполезны без этой статьи, а именно без понятия о третьем элементе!
А вот тут я запилил видео-версию этой статьи:
Для того, чтобы видеть больше контента о мыслительных инструментах, я должен наградить этот пост, потому что так автор поста будет видеть потребность в своих публикациях, получит моральное удовлетворение и мотивацию публиковать другой контент о мыслительных инструментах.
Пример плохих выводов в post-mortem'e (инцидент-репорте, это когда разбираются причины краха какой-то системы):
"Чтобы избегать таких инцидентов в будущем, мы должны работать над качеством кода. Текущая ошибка могла быть замечена на этапе Code Review, поэтому стоит в первую очередь улучшать процессы ревью".
Универсальный вывод, который несет в себе нулевую полезность.
Тавтология в этом моменте: "Делайте Code Review лучше" ссылается на "Пишите более качественный код". Т.е. в "Делайте Code Review лучше" мы по сути говорим "Мы должны работать над качеством кода".
Универсального ответа "Как надо писать выводы" - нет. Root cause каждого инцидента свой, совет в общем - избегать выводов-генерализаций вида "пишите более качественный код" (и дальнейших наслоений вида "Делайте лучше код ревью", "Уделяйте больше времени тестированию" etc).
5 Whys to the rescue!
Для того, чтобы завершать большие тендеры/проекты, надо работать по ним практически ежедневно, потому что чем глубже мы ежедневно вникаем в документацию, тем больше открывается скрытых деталей и потенциальных опасностей тендера и тем лучше мы оцениваем объем предстоящей работы.
Максим, шикарная тема на мой взгляд! Здесь мы будем только "третий элемент" обсуждать, или вообще тему рационального мышления?
Цитата: "Одно из ужасных осознаний свелось к тому, что в большинстве случаев для большинства из нас ясно и четко мыслить - неподъемная задача.
Следующее ужасное осознание - это масштаб и количество решений разной степени важности, которые на самом деле были приняты не на основе логических рассуждений, а на основе логических ошибок."
Максим, все так!
Самое интересное, человек в разных состояниях (спокойное, задерганное), в разных ситуациях (стресс, размеренный ритм работы...) - будет принимать разные решения! То есть что первично, знание о проблемах логических построений, или состояние человека в каждый конкретный момент?
Вообще для меня поднимаемый тобой вопрос достаточно сложен!
Я логически понял необходимость"третьего элемента".
Однако, не вполне уверен что в условиях практики я всегда буду использовать это знание!?!
Есть упражнения, что бы хоть как то минимально выработать этот навык?
Для того чтобы избежать задержек по строительному проекту, нужно сделать график проекта, потому что на основании графика и срока производстве материалов, мы сможем приоритизировать контрактование и увеличить шанс начать работы и закончить проект во-время.
Мне интуитивно думается что не всегда есть только 1 третий элемент. Возможно бывает так что есть и 4 и 5. Не так ли?
Для того, чтобы заработать побольше денег с новой повести, надо выкладывать по кусочку каждый день, потому что я уже обещала читателям выкладывать каждый день и они настроены читать новый текст каждый вечер, а если я обману их ожидания, они могут на меня забить.
Про то, что решения принимаются по нерациональным соображениям - я периодически принимаю решения не потому, что оно рационально обосновано, а потому, что определённый выбор утихомирит мою тревожность. Например, при выборе заказать в интернете или сходить в магазин, я могу выбрать сходить в магазин, хотя это дольше и дороже и потом у меня будет меньше сил на что-то важное, но я чувствую, что организм надо отпустить побегать ))
Для того, чтобы быстрее чинить систему мы должны разработать документацию, потому что основное назначение документации - описывать ожидаемое поведение системы, что позволит техподдержке отличать баг от фичи не отвлекая разработчиков на лишние разъяснения.
Прям по больному.
Когда весной возвращаюсь с дачи по той же дороге, то на скорости свыше 80 км/ч ощущаю вибрацию руля, поэтому нужно купить переносной Керхер и положить его в багажник.
Весной дорога грязная и вибрация может быть следствием дисбаланса колес вызванная налипанием грязи на внутреннюю часть диска.
Честно говоря я не поняла про тавтологию: во всех примерах как обоснование взято что-то непоясненное и принято за аксиому, а оно аксиомой не является, разве не это основная проблема? Не в тавтологии же дело? Тавтология в этом случае просто маскирует проблему
Поделюсь цитатами с одного совещания.
Существующие проблемы говорят о том, что нам нужно менять процесс написания документации.
Почему требуют:
Решение:
Теперь попробую построить логическое утверждение.
Для того чтобы понимать, что все функции приложения описаны корректно для каждой версии приложения, нужно свести всю документации в одном месте (для каждой версии приложения место свое) и убедиться, что документация понятна и полезна пользователям, потому что в документации разбросанной по нескольким документам трудно найти нужное описание и даже если найти нужное описание, то может оказаться, что описание устарело.
Во, прям в тему :)
как раз можно сформулировать для своей текущей задачки
Для того, чтобы предотваритить пустой расход мыслетоплива сотрудников отдела интернет-маркетинга, необходимо внедрить процесс обработки входящих по методикам ДТ, так как этот процесс уберет лишние переключения между задачами, которые являются причиной расхода мыслетоплива.
Пояснения
Я в растерянности.
Вроде бы и "Выбор" Голдратта захотелось прочитать.
И текущую книгу не хочется бросать и откладывать.
А в список книг "к прочтению" заносить - тоже вроде бы пагубная практика...