Третий элемент и обоснование причинно-следственных связей

 Публичный пост
22 марта 2022  4545
OXHEHHO ⨯4 Голова! ⨯2 Слезы прозрения

Что такое тавтология?

По заголовку, скорее всего, вообще не будет понятно о чем этот пост, но тема на мой взгляд ОЧЕНЬ важна.

Некоторое время назад я учился у Елены Федурко мыслительным инструментам Голдратта. Одно из ужасных осознаний свелось к тому, что в большинстве случаев для большинства из нас ясно и четко мыслить - неподъемная задача.
Следующее ужасное осознание - это масштаб и количество решений разной степени важности, которые на самом деле были приняты не на основе логических рассуждений, а на основе логических ошибок.

Этот пост посвящен логической ошибке, которая в книге Голдратта "Выбор" называется тавтология или логика замкнутого круга, хотя я еще слышал вариант рекурсия.

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

Ты не чувствуешь разочарования, потому что подавил его в себе

Здесь есть два логических утверждения:

  • Ты не чувствуешь разочарования
  • Ты подавил в себе разочарование

И слово потому что говорит о том, что я верю в существование причинно-следственной связи между ними.

Но, каждая причинно-следственная связь должна быть обоснована. Однако, стоит спросить: "А почему ты решил, что я подавил в себе разочарование?", как ответ будет: "Ну ты же его не чувствуешь".

Давайте еще пример:

Для того, чтобы быстрее исправлять ошибки мы должны разработать документацию

Причинно-следственная связь должна комфортно ложиться в конструкцию:
Для того чтобы <Следствие> мы должны/нам нужно <Причина>

При этом и причина и следствие должны быть полноценными логическими утверждениями, а не обрывками фраз вида "плохая приоритезация", "отсутствие стратегии", "нечеткие планы"

Если мы научились формулировать стройные конструкции с причинно-следственными связями, то обоснование этой связи будет естественным продолжением в формате:
Для того чтобы <Следствие> мы должны/нам нужно <Причина> потому что <обоснование>

И вот тут крайне важно следить за отсутствием тавтологии, чтобы не получилось:

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

Не только же меня коробит это логическое высказывание?

Давайте еще пример:

Для того, чтобы повысить продажи нашего сервиса мы должны разработать новую фичу Х, потому что фича Х нужна для увеличения продаж.

Не коробит?

Давайте еще пример:

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

Ну в этом примере по идее вообще ущербно все, но обоснование причинно-следственной связи - особо.

И тут вопрос: а как часто вы сталкиваетесь (в явной или не явной форме) с подобными тавтологическими обоснованиями?

И если эти примеры обоснований плохие, то как правильно?

Третий элемент

Признаюсь, как правильно я сам узнал совсем недавно. И до этого во всех моих рассказах о мыслительных инструментах Голдратта этого не хватает и из-за этого эти рассказы практически мало полезны. Увы. Список этих малополезных рассказов будет в самом конце.

Про правило формулировки исходной посылки (так в мыслительных инструментах называется обоснование причинно-следственной связи) я узнал на тренинге Елены Федурко. И это правило просто и изящно.

Правильная посылка должна в себе содержать слова:

  1. относящиеся к первому утверждению
  2. второму утверждению
  3. не относящиеся ни к первому, ни ко второму утверждению. То есть третий элемент

Давайте я приведу примеры более-менее адекватных обоснований причино-следственных связей из предыдущих примеров. В этих обоснованиях я жирным отмечу то, что считаю третьим элементом.

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

Для того, чтобы повысить продажи нашего сервиса мы должны разработать новую фичу Х, потому что результаты опроса потенциальных клиентов показывают, что N% респондентов отказываются от покупки исключительно из-за отсутствия этой фичи.

Для того, чтобы повысить эффективность работы отдела нам нужна актуальная стратегия компании, потому что мы хотим остановить работу над проектами, не вписывающимся в стратегию и сконцентрируемся на оставшихся проектах.

Ну как? Лучше?

Что важно, каждый раз, когда в обосновании причинно-следственной связи вам удается выделить третий элемент у вас появляется возможность найти какое-то решение (если причинно-следственная связь описывает проблему) или альтернативный способ (если связь описывает какое-то решение).

Попробуйте сами ниже в комментариях сформулировать причинно-следственную связь и обосновать ее, обращая внимание на наличие третьего элемента.

Мои бесполезные рассказы о мыслительных инструментах

Это рассказы 6-7 летней давности:


Два года назад я уже начал понимать, что рассказывал не всю правду:

Но в прошлогоднем видосе все равно не хватало самого важного - рассказа про третий элемент.

На самом деле эти рассказы не совсем бесполезные. Они бесполезны без этой статьи, а именно без понятия о третьем элементе!

А вот тут я запилил видео-версию этой статьи:

Связанные посты
56 комментариев 👇

Для того, чтобы видеть больше контента о мыслительных инструментах, я должен наградить этот пост, потому что так автор поста будет видеть потребность в своих публикациях, получит моральное удовлетворение и мотивацию публиковать другой контент о мыслительных инструментах.

  Развернуть 1 комментарий

@cowabunga, в идеале еще выделить третий элемент в обосновании :)

  Развернуть 1 комментарий

@cartmendum, выделил)

  Развернуть 1 комментарий

Пример плохих выводов в post-mortem'e (инцидент-репорте, это когда разбираются причины краха какой-то системы):

"Чтобы избегать таких инцидентов в будущем, мы должны работать над качеством кода. Текущая ошибка могла быть замечена на этапе Code Review, поэтому стоит в первую очередь улучшать процессы ревью".

Универсальный вывод, который несет в себе нулевую полезность.
Тавтология в этом моменте: "Делайте Code Review лучше" ссылается на "Пишите более качественный код". Т.е. в "Делайте Code Review лучше" мы по сути говорим "Мы должны работать над качеством кода".

Универсального ответа "Как надо писать выводы" - нет. Root cause каждого инцидента свой, совет в общем - избегать выводов-генерализаций вида "пишите более качественный код" (и дальнейших наслоений вида "Делайте лучше код ревью", "Уделяйте больше времени тестированию" etc).

5 Whys to the rescue!

  Развернуть 1 комментарий

@zakirullin, универсального ответа как надо - нет. Но есть универсальные ответы как не надо :)
Если есть третий элемент - это еще ничего не значит. Если его нет, то обоснование - это тавтология.

А теперь к примеру.

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

Почему, кстати? Попробуй написать обоснование и подчеркнуть третий элемент.

  Развернуть 1 комментарий

@cartmendum,

Универсального ответа "Как надо писать выводы" - нет

Это я наверное зря написал. Можно было и конкретный пример с третьим элементом накидать. Ближе к вечеру смогу вернуться с мыслями :)

  Развернуть 1 комментарий

@cartmendum, Для того, чтобы снизить вероятность инцидентов мне нужно улучшать процессы ревью кода потому что большинство дефектов возникает из-за так называемого "Эффекта замыленного взгляда". Свежий взгляд коллег может уменьшить кол-во дефектов до 80%.

Повторный свежий взгляд самого автора кода может в большинстве случаев выявить дефект - подобная система "Pointing-and-Calling safety systems" сделала японские железные дороги одними из самых надежных в мире.

P.P.S. Суть системы проста: мы указываем на что-то пальцем, и проговариваем вслух (или про себя). Напр.: "Я смотрю направо, машин нет, я смотрю налево, машин нет" (при переходе дороги).

P.S. Следующий шаг - тесты, т.к. ревью кода все же не является инструментом для предотвращения багов в системе. Т.к. "запускать в голове код" каждому из ревьюверов - дорогая и тяжелая задача (к тому же подвержена человеческому фактору), code review преследует иные цели.

  Развернуть 1 комментарий

большинство дефектов возникает из-за так называемого "Эффекта замыленного взгляда". Свежий взгляд коллег может уменьшить кол-во дефектов до 80%.

Это факт (то есть, есть четкие доказательства), мнение (кажется, что это факт, но доказательств пока нет) или предположение?..

Кстати, а что в этом контексте означает "улучшать процессы ревью кода"?

  Развернуть 1 комментарий

Факт. Можно проследить на основе исторических данных (прошлых инцидентов в системе).

Кстати, а что в этом контексте означает "улучшать процессы ревью кода"?

Я такую формулировку привел как неудачное обоснование. Не ясно как эту "успешность" измерить, да и что вообще подразумевается под "улучшением" - не понятно =)

  Развернуть 1 комментарий

Попробуйте сами ниже в комментариях сформулировать причинно-следственную связь и обосновать ее, обращая внимание на наличие третьего элемента.

Я это прочитал как "Приведите пример с тавтологией, а потом добавьте третий элемент".

  Развернуть 1 комментарий

@zakirullin, ааа :)
Я-то надеялся на правильный пример, в котором только третьего элемента и не хватало.

  Развернуть 1 комментарий

@cartmendum, Можно так, по-простому:

C тавтологией:
Для того, чтобы снизить вероятность инцидентов нам нужно внердять процессы тестирования, потому что тесты уменьшают вероятность инцидентов.

С третьим элементом:
Для того, чтобы снизить вероятность инцидентов нам нужно внердять процессы тестирования, потому что тесты позволяют обнаружить бОльшую часть возникающих у нас дефектов на раннем этапе.

  Развернуть 1 комментарий

@zakirullin, ну вот да...

Для каноничности все же стоит избегать фраз типа "внедрять процессы". Слишком абстрактно.

"Запускать автотесты после каждого изменения" - уже лучше

  Развернуть 1 комментарий
Андрей Кольченко, Project Manager/Sales Manager для международных телеком операторов 25 марта в 11:29

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

  Развернуть 1 комментарий

@debasser, ну тут немного не понятно. А что значит "работать по тендеру"? Это и есть "вникать в документацию"?

В принципе с наличием третьего элемента - все ок. Но наличие третьего элемента не доказывает существование логики. А вот отсутствие третьего элемента доказывает отсутствие логики.

Я допускаю, что чем глубже я вникаю в документацию, тем больше открывается скрытых деталей, но... А что значит "глубже вникать в документацию"? Не является ли это как раз поиском тех самых деталей?...

Но вот связь между ежедневной работой и глубоким вниканием мне не очевидна. Почему нельзя за один день погрузиться? Почему нельзя глубоко погрузиться, если работать по 2 дня в месяц?... Или по одному дню в неделю?...

  Развернуть 1 комментарий

@cartmendum, спасибо за такой развёрнутый ответ. Когда тебе отвечает сам создатель Джедайских техник, чувствуешь своего рода прилив сил или прозрение что ли.

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

Ну я попробую перефразировать:
Для того чтобы успешно выигрывать большие тендеры до конца, надо практически каждый день продвигаться хотя бы на маленький шажочек вперёд, потому что чем раньше мы посвятим себя во все детали и узнаем о скрытых опасностях, тем больше шансов на них отреагировать и предоставить все документы в срок.

Так получше?

  Развернуть 1 комментарий

Для того чтобы успешно выигрывать большие тендеры до конца, надо практически каждый день продвигаться хотя бы на маленький шажочек вперёд, потому что чем раньше мы посвятим себя во все детали и узнаем о скрытых опасностях, тем больше шансов на них отреагировать и предоставить все документы в срок.

Ну а самому-то как? :)
По-моему заметно лучше.

То есть посыл такой, что когда ты знакомишься с документацией в спешке, то вникаешь не глубоко, и часто подписываешься на то, что еще до конца не взвесил и не оценил.

  Развернуть 1 комментарий
Олег Легостаев, Продвигаю и продаю светотехнику и источники питания ТМ Camelion 23 марта в 03:19

Максим, шикарная тема на мой взгляд! Здесь мы будем только "третий элемент" обсуждать, или вообще тему рационального мышления?
Цитата: "Одно из ужасных осознаний свелось к тому, что в большинстве случаев для большинства из нас ясно и четко мыслить - неподъемная задача.
Следующее ужасное осознание - это масштаб и количество решений разной степени важности, которые на самом деле были приняты не на основе логических рассуждений, а на основе логических ошибок."
Максим, все так!
Самое интересное, человек в разных состояниях (спокойное, задерганное), в разных ситуациях (стресс, размеренный ритм работы...) - будет принимать разные решения! То есть что первично, знание о проблемах логических построений, или состояние человека в каждый конкретный момент?
Вообще для меня поднимаемый тобой вопрос достаточно сложен!
Я логически понял необходимость"третьего элемента".
Однако, не вполне уверен что в условиях практики я всегда буду использовать это знание!?!
Есть упражнения, что бы хоть как то минимально выработать этот навык?

  Развернуть 1 комментарий

@OlegLego,

Максим, шикарная тема на мой взгляд! Здесь мы будем только "третий элемент" обсуждать, или вообще тему рационального мышления?

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

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

Ну моя позиция в том, что знание в принципе очень сильно переоценено ;) Состояние влияет сильнее.

Однако, не вполне уверен что в условиях практики я всегда буду использовать это знание!?!

Есть упражнения, что бы хоть как то минимально выработать этот навык?

Есть :) Я в ближайшее время сделаю анонс пилотного мероприятия для членов клуба, где мы соберемся и будем отрабатывать.

  Развернуть 1 комментарий

@cartmendum, "Есть :) Я в ближайшее время сделаю анонс пилотного мероприятия для членов клуба, где мы соберемся и будем отрабатывать."
Прекрасная новость!

  Развернуть 1 комментарий

@cartmendum,

Есть :) Я в ближайшее время сделаю анонс пилотного мероприятия для членов клуба, где мы соберемся и будем отрабатывать.

Ждём очень-очень!

  Развернуть 1 комментарий

@OlegLego, осторожнее с рациональным мышлением, так можно дойти и до фанфиков по Гарри Поттеру https://www.lesswrong.com/s/PtgH6ALi5CoJnPmGS

  Развернуть 1 комментарий

@Unencrypted, прекрасное же произведение :)

  Развернуть 1 комментарий

@Unencrypted, Мою обезьяну так просто не победить!

  Развернуть 1 комментарий

@Unencrypted,
"For it is a sad rule that whenever you are most in need of your art as a rationalist, that is when you are most likely to forget it."

  Развернуть 1 комментарий
denis.gritsiyenko, Construction Project Manager 25 марта в 10:56

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

Мне интуитивно думается что не всегда есть только 1 третий элемент. Возможно бывает так что есть и 4 и 5. Не так ли?

  Развернуть 1 комментарий

@denisgritsiyenko, во-первых, может быть много "третьих элементов". А во-вторых, может быть много обоснований ;)

  Развернуть 1 комментарий
Юлия Жукова, преподаватель, писатель 25 марта в 12:29

Для того, чтобы заработать побольше денег с новой повести, надо выкладывать по кусочку каждый день, потому что я уже обещала читателям выкладывать каждый день и они настроены читать новый текст каждый вечер, а если я обману их ожидания, они могут на меня забить.

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

@OlegLego, ну это не совсем физическая нагрузка. Это не ради физической нагрузки, это чтобы нервяк стравить )

  Развернуть 1 комментарий

@Kikimorra, физ нагрузка, лично мне, как раз и помогает стравить лишнюю нервую энергию. Если у Максима в книге: "в любой непонятной ситуации - думай", то у меня по жизни: в любой непонятной ситуации - иди гулять. Первая часть прогулки успокаивает нервы, вторая - способствует думанию)

  Развернуть 1 комментарий

@SofyaN, ну хз, может, мне трудно воспринимать поход в магазин как физ нагрузку. ))

  Развернуть 1 комментарий

Для того, чтобы заработать побольше денег с новой повести, надо выкладывать по кусочку каждый день, потому что я уже обещала читателям выкладывать каждый день и они настроены читать новый текст каждый вечер, а если я обману их ожидания, они могут на меня забить.

Во! Пример как по учебнику! :)

Про то, что решения принимаются по нерациональным соображениям - я периодически принимаю решения не потому, что оно рационально обосновано, а потому, что определённый выбор утихомирит мою тревожность.

Это совершенно нормально. Мы не обязаны рационализировать все наши поступки.
В корпоративном мире стремно видеть обоснования вида: мы запускаем новую фичу, чтобы увеличить продажи, потому что эта фича поднимет продажи...

  Развернуть 1 комментарий
Софья, Спец по техподдержке 25 марта в 14:40

Для того, чтобы быстрее чинить систему мы должны разработать документацию, потому что основное назначение документации - описывать ожидаемое поведение системы, что позволит техподдержке отличать баг от фичи не отвлекая разработчиков на лишние разъяснения.

Прям по больному.

  Развернуть 1 комментарий

отличать баг от фичи не отвлекая разработчиков

Прекрасный третий элемент.

Но обоснований (и третьих элементов) может быть много ;) Это же не единственное возможное обоснование? ;)

  Развернуть 1 комментарий

@cartmendum, спасибо) Про типовые сбои не стала повторять вас.
Можно ещё так добавить: Для того, чтобы быстрее чинить систему мы должны разработать документацию, потому что по ней можно будет быстро обучать новых участников процесса.

  Развернуть 1 комментарий

@SofyaN, а теперь поясните, как обучение новых сотрудников помогает быстрее чинить систему :)

  Развернуть 1 комментарий

@cartmendum, быстрое обучение ;) чем быстрее новичок обучится, тем быстрее его можно допустить к починке. Чем больше обученных может занимается починкой, тем меньше времени будет каждый баг проводить в очереди.
Или речь про то, что нужно было это сразу встроить в исходную цепочку?)

  Развернуть 1 комментарий

@SofyaN, ну да. Если бы это было встроено сразу в исходное пояснение, то сразу было бы понятно.

А теперь да, кажется правдоподобно.

  Развернуть 1 комментарий
Artur Fedorov, Бизнес-психолог 26 марта в 08:03

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

Весной дорога грязная и вибрация может быть следствием дисбаланса колес вызванная налипанием грязи на внутреннюю часть диска.

  Развернуть 1 комментарий
Ася, моушен-дизайнер 28 марта в 13:26

Честно говоря я не поняла про тавтологию: во всех примерах как обоснование взято что-то непоясненное и принято за аксиому, а оно аксиомой не является, разве не это основная проблема? Не в тавтологии же дело? Тавтология в этом случае просто маскирует проблему

  Развернуть 1 комментарий

@asya_ts, обоснование не должно быть аксиомой ;) Может быть, но не должно.
Если оно является аксиомой, тогда нет сомнений в причинно-следственной связи. Если это не аксиома, то сомнения в причинно-следственной связи остаются. Может быть сомнений становится меньше, все зависит от качества обоснования.

  Развернуть 1 комментарий

@asya_ts, привет. Еще раз взглянул на примеры. На мой взгляд принцип в уточнении, который основан на опыте и анализе. Не просто разработать новую фичу Х, (заметь нет аксиомы что фича поможет)

А провести опрос потенциальных клиентов показывающий, что N% респондентов отказываются от покупки исключительно из-за отсутствия этой фичи.

  Развернуть 1 комментарий

Поделюсь цитатами с одного совещания.

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

Почему требуют:

  1. Требования фрагментированы
  2. Нельзя понять дублируют ли части документации друг друга
  3. Нельзя понять какая часть документации актуальна, а какая устарела
  4. Поиск в документации вызывает боль

Решение:

  1. Документация должна храниться в одном месте
  2. Нужно улучшить шаблон для создания новых документов
  3. Нужно понимать как документация менялась от одной версии продукта к другой
  4. Работа с документацией должна быть простой

Теперь попробую построить логическое утверждение.
Для того чтобы понимать, что все функции приложения описаны корректно для каждой версии приложения, нужно свести всю документации в одном месте (для каждой версии приложения место свое) и убедиться, что документация понятна и полезна пользователям, потому что в документации разбросанной по нескольким документам трудно найти нужное описание и даже если найти нужное описание, то может оказаться, что описание устарело.

  Развернуть 1 комментарий

@evgenij, пример очень сложный.
Но тут проскакивает намек на то, что документация разбросана по нескольким документам. Но если это будет один документ, то как это поможет избежать устарелости документации?

Ну и нужны более подробные описания того, что значит "в одном месте" (один документ? А три документа, но в одной папочке - это в одном месте? А три папочки, но на одном сервере?...) и что значит "убедиться".

  Развернуть 1 комментарий

@cartmendum, на этом совещании первые 20 минут я вообще не понимал о чем идет речь.

В одном месте - это два параметра продукт+версия. Все что данная версия продукта умеет делать хотят описать в одном документе (PDF с десятками тысяч страниц). Сейчас инкрементальный подход. Есть документ описывающий новую и измененную функциональность продукта. То, что удаляют к сожалению не описывают.

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

  Развернуть 1 комментарий

@evgenij, это то, что называется конфигурационным управлением :) Головняк :)

И все же, как выглядит решение (причина) и какая именно проблема после этого решения должна устраниться (следствие)?

  Развернуть 1 комментарий

@cartmendum, интересно как перевести гловняк на английский? Может быть headaching)

Эх как хотелось одним предложение по шаблону написать: для того чтобы <Следствие> мы должны/нам нужно <Причина> потому что <обоснование>. Что-то не получается одни предложением.

Решение (причина): уйти от подхода писать документы в формате: в этом релизе появились и обновились такие-то возможности. Прийти к одному документу на релиз. В документе убрать устаревшие описания и убрать повторы.

После этого решения (следствие): пользователь будет искать информацию в одном документе (если функциональность появилась в первом релизе, то сейчас нужно посмотреть все релизные документы до первого релиза). Пользователь найдет нужную информацию, т.к. в документе описаны все функции приложения. Пользователь не будет обманут документацией, т.к. в документации не будет устаревших данных.

  Развернуть 1 комментарий

Решение (причина): уйти от подхода писать документы в формате: в этом релизе появились и обновились такие-то возможности. Прийти к одному документу на релиз. В документе убрать устаревшие описания и убрать повторы.

Один документ на релиз - это с новой версией программы поставлять новую версию документации? Сразу готовую, а не diff к предыдущей версии?

  Развернуть 1 комментарий

@cartmendum, да и да.

Вопрос смотреть diff между версиями тоже поднимался. Считается, что diff легко вычислить из двух документов. Пока не увижу, как это работает мне сложно поверить, что это легко и удобно.

  Развернуть 1 комментарий

@evgenij, А почему бы не сделать готовый целостный документ, который будет начинаться с "Новое в этой редакции"?
Ну типа объединение и того и другого.

  Развернуть 1 комментарий

@cartmendum, мне кажется, что такая идея не обсуждалась.
Хотели релиз ноуты в очень кратком виде — это один маленький вспомогательный документ. И большой документ на релиз, где описано вся функциональность релиза — это главный документ.

Закину идею с "новое в этой редакции" на обсуждение.
Спасибо за идею.

  Развернуть 1 комментарий

@evgenij, во!!!! А все дискуссия вокруг третьего элемента :)

  Развернуть 1 комментарий

Во, прям в тему :)
как раз можно сформулировать для своей текущей задачки

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

Пояснения

  1. Нафига сохранять мыслетопливо? В контексте нашей работы - чтобы чаще привлекать рационального типа, который позволит искать рациональные способы решения задач, тогда как обезьянка будет делать как придется / как интересно / как уже делала раньше.
  2. Ок, а есть другие способы сохранения мыслетоплива? Да, их много. Начинаем просто с самого очевидного
  3. Что такой за "процесс обработки входящих по методикам ДТ". В контексте задачи это - отключение всех возможных уведомлений, регламент о том, что проверка входящих уведомлений не чаще, чем 1.5 часа, и т.п. Плюс устное пояснение, зачем все это делается, немного теории про обезьянку.
  Развернуть 1 комментарий

@Timonissimo, Вообще шикарно :) Сначала руки потянулись занудствовать типа "А что значит внедрить процесс ...", а потом дочитал до конца и... Хорошо :)

  Развернуть 1 комментарий

Я в растерянности.
Вроде бы и "Выбор" Голдратта захотелось прочитать.
И текущую книгу не хочется бросать и откладывать.
А в список книг "к прочтению" заносить - тоже вроде бы пагубная практика...

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб