Блог NunDesign

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

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

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

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

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

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

А может, и нет разницы между дискуссией и спором, и это очередная игра словами.

Разбираем-изучаем с утра по-раньше корпоративную почту; один из новых программеров, работающих на новом же проекте, удивлённо замечает: странно это, говорит, обычно когда разрабатывается новый сервис, люди сначала думают, а потом делают. А здесь как-то странно: сначала делаем, потом обнаруживаем траблы, переделываем; по результатам переделывания обнаруживаем ещё более стрёмные траблы, уже труднее решаемые, переделываем. Цикл может повторяться до момента, когда руководство разочаровывается в проекте, что автоматически означает — разочаровывается в разработчиках, этот проект наваявших. И правильно, кто виноват в том, что программа “не пошла”? Ессно, программеры. Собирается новая команда, которая получает исходные коды предыдущей версии с задачей “переделать”.

Но, извиняюсь, что такое “думать, потом разрабатывать”? Кто конкретно должен думать и о чём? Чем занимается штаб “думателей” до момента, когда программер создал пустой ещё проект и написал свою первую строчку кода? Это у кого как. Хорошо, когда думают все участники процесса, начиная от заказчика и дальше постановщиков (для непосредственных разработчиков на самом деле, как правило, и разницы-то никакой нет). Наблюдаю неоднократно (а, значит, локализовываем ещё один опасный камушек как не случайный) такое замечательное явление: заказчик предлагает разработать сервис (не важно, веб или виндовз приложение), основываясь на своей личной необходимости в нём. Как правило, такое происходит, когда у заказчика есть какой-то процесс, который он пытается автоматизировать с помощью компьютерных технологий и, видимо, находит для этого некие инструменты, программы или веб-сервисы, тестирует их, пытается использовать в работе и находит кучу недостатков. Знакомая ситуация, так ведь?

Поэтому когда заказчик говорит о том, что “рынок нуждается в нормальном инструменте для *таких-то целей*, есть много много людей, которые хотят такой инструмент, он будет продаваться, его только нужно сделать по-грамотному” – он (понятно, что речь вряд ли идёт об одном человеке) всё-таки опирается на свой какой-то уже наработанный опыт, и этот опыт автоматически распространяется на ВСЮ потенциальную аудиторию этого инструмента. Формулируются требования, пишется ТЗ, собирается команда, которая это ТЗ анализирует и приступает к работе. Не углубляясь в подробности описания жизненного цикла разработки сложного программного продукта перейду сразу к этапу тестирования сценариев поведения пользователя в программе на прототипах экранных форм.

Стоить заметить, что тестирование группой заказчика проходит при этом успешно, ему нравится (почти) всё, есть разумные замечания, есть нормальные рекомендации, это текущее и никого не пугает. Потом собирается фокус-группа для тестирования публикой совсем посторонней. Да, и вдруг оказывается, что обычный среднестатистический клиент со среднестатистическими навыками работы за компьютером сталкивается с тем, что ему непонятно ВСЁ. Как, зачем и куда. Аналитики отдела, который проводил тестирование, собирают информацию обо всех задачах, с которыми учасники фокус-группы не справились, трудных местах, на которых зависали, замечания, которые эти учасники высказывали в процессе. Кроме нескольких действительно конструктивных идей большая часть отчёта по результатам тестирования просто разгромная: это вообще не целевая аудитория подобных программ. То же самое, что для тестирования профессионального бухгалтерского приложения набрать ребят с ближайшего овощного ларька. Не, ну правда. Ок, может, не до такой степени, но похоже.

Получается, что мы должны (пусть ещё и в начале разработки, но всё же уже на лету) менять постановку задачи в целом: для кого всё-таки пишется инструмент? Если заказчик планирует выйти с ним на рынок и рекламировать для универсального пользователя, тех же домохозяек в том числе, он и должен получить продукт для универсального пользователя и домохозяек в том числе; ни к чему тогда такая развёрнутая функциональность, сложные формы, диаграммы и визарды разрешения конфликтов синхронизации данных (долго писать, но как раз этот визард, просто шедевр проектирования с моей точки зрения, удобный и понятный для всех наших и даже одобренный заказчиком, поставил в тупик 100% тестировавших из той самой фокус-группы неподготовленных пользователей). Да, разрабатывается совсем другая программа. И пусть весь интерфейс сводится к двум кнопкам, например, зелёной и красной (да, одной не обойдёшься, бывает), зато легко будет разобраться.

Всё-таки с большим подозрением отношусь пока к тестированию на экранных прототипах. К сожалению, не могла присутствовать лично — мы здесь, они там, за океаном, но что-то там недоработано имхо. Верится с трудом, к примеру, что на достаточно равномерном (скажем, тёмно-синем, ближе к чёрному, с белым текстом) интерфейсе с элементами форм в той же цветовой гамме – тёмно-синие бэкграунды и светлые+белые foreground`ы учасники фокус-группы не смогли выполнить “удалить пользователя” не смотря на то, что кнопка “Delete” – единственная ярко-красная, ещё и с соответствующим текстом. Может, что-то не то было в формулировке задачи?

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

Да, когда он на одной картинке “заполняет” формуляр поиска и “нажимает” кнопку поиска (ему перелистывают следующую картинку) и дальше получает экран с результатами поиска, и его спрашивают: где же список тех людей, которых ты искал, а он не может ответить на этот вопрос… Первая реакция у нашей команды: ну, наверное он совсем даун. На самом же деле он нормально сориентируется в том же экране при интерактивном интерфейсе: действие, и там, где была форма+пусто, появился список, не важно, боковым ли зрением заметит пользователь изменение или у него хватит мозгов смотреть в зону, в которой он заполнял форму и нажимал на кнопки.
Т.е. мне всё же кажется, что механизм тестирования на экранных прототипах должен быть либо как-то круто автоматизирован, чтобы совсем уж имитировать действие программы, или он на самом деле даёт огромную погрешность в результатах тестирования, из-за того же отсутствия интерактивности.

И третье, что беспокоит: всё-таки отсутствие мотивации работы с программой. Почему заказчику пришла идея разработать этот инструмент? У него была необходимость, он работал с уже существующими аналогами, и необходимость у него остаётся. Какая же мотивация у тех участников фокус-группы, которые тестировали прототипы? Разобраться с интерфейсом и поскорее реализовать свою задачу на этом инструменте? Вовсе нет. Время в фокус группе оплачивается, что-то от 10 до 20 уе за час работы. На этом цель обычно заканчивается. “Всё равно на улице скучно”, “и друзья попросили там помочь”, “и десять баксов-то не лишние”, ни один мотив не сходится с мотивом потенциального пользователя программы. А вот 10 баксов за то, что он в этой программе исполнит что-то продаваемое (т.е. если исполнит – получит $10, не исполнит – не заработает), и мы получаем фокус-группу совсем других участников, и смотреть они будут на программу совсем другими глазами.

Как вариант, сделать работающую версию программы в качестве прототипа для того же тестирования. Делаем. С тестовой базой данных. С ни разу не вылизанными до стерильности визуальными штучками интерфейса. Но со всеми теми же самимы положенными формами, кнопками, со всей предполагаемой интерактивностью. Всё равно огромный объём работ, функциональность-то по-любому сложная, и здесь уже программеры настороже: неужели опять недели рабочих подвигов сведутся к тому, что, (как в первом абзаце было) написали, не понравилось, переделываем?

«…оптимизатор аналитического склада ума» © АиП, No.214-РВ

Задали мне тут интересный вопрос – а зачем, собственно, я подписана на рассылку “Глас Рунета“? Вдаваться в историю и вспоминать, почему же лет 7 назад я вообще подписалась на эту рассылку не интересно, и не вспомню точно всех причин. С тех пор многое изменилось, поменялись интересы и цели, нет больше редактора Библиотеки Сайтостроительства; однако не отписываюсь от рассылки прежде всего потому, что лениво (это самый простой ответ). Есть и более сложный – мне в самом деле интересно, кто и на какую тему заказывает массовые опросы у Гласа? Кто, чем и зачем интересуется тенденциями, настроением, платежеспособностью в той или иной отрасли, как изменяется аудитория интернет-пользователей и прочее, прочее? В некоторых опросах принимаю участие, на некоторые с нетерпением жду обработанных результатов (вот таких, к примеру). Помните, я писала о любопытном опросе в конце прошлого года о социальных сетях, и даже попробовала сделать свои какие-то, вполне может быть ошибочные выводы (на основании только вопросов, не статистики)? Пост «Subscribe.ru и социальные сети (разведка)». Вчера пришли результаты этого опроса, сами по себе тоже достаточно любопытные.

Помните уже бородатый анекдот о том, что «в опросе об уровне интернетизации населения на вопрос, опубликованный на сайте васяпупкин.ком “Пользуетесь ли вы интернетом” 100% респондентов ответили утвердительно»? В современных опросниках подобная же ошибка встречается не так уж редко.
(more…)

Веб-мастера хорошо знают, как много смешного можно вытащить из логов – в частности, при анализе ключевых слов из источников трафика – обхохочешься! Я сначала не поверила, что это список (иллюстрация слева) – по моему блогу, мало ли, глючёк приключился (в конце прошлой недели добавила, как давно уже планировала, код гугловской статистики). Дело в том, что Google Analytics сейчас отдаёт вебмастерам два кода – старый urchin и новый ga (как вы догадались, краткое от “google analytics”); на сайте nundesign у меня пока что по-прежнему крутится urchin. Но из декабрьского анонса Google:

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

Но с кодом и статистикой оказалось всё впорядке – по такому эротичному запросу “эмулятор оргазма” в Google и в самом деле на пятой позиции находится этот блог, а если точнее – вот эта запись полугодичной давности, о корпоративных стандартах и ценностях. Могу себе представить разочарование того озабоченного юзера, который открыл по найденной ссылке мой пост! Но о дальнейшем поведении этого пользователя GoogleAnalytics умалчивает, увы – видимо, закрыл страницу сразу, а жаль, потому что именно такое словосочетание звучит как-то бессмысленно, не логично. Ладно бы “эмуляция”, или как-то ещё, хотя бы ясно было, какая у человека цель, или он(-о) в самом деле какое-то внешнее устройство, гаджет искал(-о); и, кстати, какого оно пола?

Пришли “результаты” очередного опроса от “Гласа Рунета”, тема интересная, об “основных типах пользователей Рунета”. Оставлю-ка я их себе на память и для ознакомления читателям. (more…)

Прикольно как. Обратить внимание на какую-нибудь игрушку, сервис или тулз, который по каким-то причинам забросил и какое-то время не мониторил, не пользовал. Зашла сегодня на блоговарную статистику – смотрю, удивляюсь, какими способами публика выкручивается бэклинками. Интересно, там кто-нибудь мониторит цитирование? Вроде бы про однобуквенные ссылки писали – типа, недопустимо, банят. Но способы мошенничества “щадящего” такого участия в игре могут быть разные… (more…)

Что представляет проектная матрица

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

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

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

Деятельность при анализе

ООА (объектно ориентированный анализ) является процессом, состоящим из анализационной деятельности, которая требуется для обеспечения формализованных моделей. Процесс описывается во фрейме, данном проектной матрицей.

Строка информационной модели. Работа, связанная с рамкой в строке информационной модели, подразделяется на несколько отчётливых видов деятельности:

• исследование;
• разработка модели;
• интеграция;
• просмотр.

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

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

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

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

Часто бывает так, что некоторые фундаментальные вопросы не могут быть рассмотрены достаточно быстро, поскольку зависят от решений, которые ещё предстоит принять заказчику или другому отделу в вашей организации. В этом случае у вас есть возможность приостанавливать работу над частной подсистемой до тех пор, пока не будут получены ответы. Альтернативно наилучший выход может быть в том, чтобы продолжать, готовя техническое замечание, документирующее опции. В дальнейшем выберите одну из опций, зафиксируйте ваш выбор как предположение в документе, озаглавленном “Контекст для просмотра подсистемы” и продолжите анализ. Несмотря на то, что эта стратегия несёт с собой риск, связанный с возможной необходимостью переработки части анализа, она, вероятно, облегчит процесс принятия решений, так как законченный анализ обнаружит любые вовлечения опций, которые вы выбрали для исследования, и может пролить некоторый свет на другие опции.

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

Просмотр. Вследствии того, что информационная модель – основа для всего анализа и проектирования – ещё создаётся, мы проводим детализированный технический просмотр работы в этой точке. При этом мы преследуем две цели: проверить, что существенные аспекты реального мира были точно сохранены в формальных моделях, и проконтролировать соответствие модели правилам ООА, которые состоят в том, что каждый объект имеет идентификатор, все связи формализованы и описаны и т.д. Команда для просмотра должна, следовательно, включать как экспертов предметной области (для обеспечения первой цели), так и экспертов по моделированию (для второй). Если вы не можете предоставить экспертов предметной области для просмотра, замените их аналитиками, не работавшими над этой частной моделью. Снабдите аналитиков-рецензентов техническими замечаниями, которые могут в дальнейшем использоваться как описание действительности, с которой сверяется модель.

Строка моделей состояний. Деятельность, связанная с рамкой в строке моделей состояний, – это разработка модели, вериикация взаимных действий, интеграция и просмотр.

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

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

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

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

Интеграция. Как только модели состояний и модель взаимодействия объектов завершены, сформируйте (или модифицируйте) модель взаимодействия подсистем для этого домена.

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

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

Разработка модели и интеграция. Разделите работу так, чтобы каждый аналитик отвечал за создания ДПДД* для некоторого количества моделей состояний. Во время этой работы каждый аналитик может поддерживать отдельную таблицу процессов состояний. Когда ДПДД* закончены, объедените отдельные таблицы процессов состояний и устраните все расхождения в именах и идентификаторах процессов. Затем создайте модель доступа к объектам для подсистемы и модифицируйте модель доступа к подсистемам для всего домена.

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

—
* ДПДД – Action data flow diagram – диаграмма потоков данных действий.

—
Источник: Объектно-ориентированный анализ: моделирование мира в состояниях.
Авторы: Салли Шлеер, Стефан Меллор
Книга издана в 1993-м году, на счёт переизданий – не в курсе; посвяцена изложению самых первых этапов процесса разработки сложных (программных, технических и других) систем.

Что такое аналитика? Что такое аналитика в вашем представлении? Чем занимается аналитик в IT сфере? А в экономике? А в бытовухе?

В общем случае строится модель “проблемной” системы для анализа и дальше – система декомпилируется на составляющие её объекты и связи между ними, изыскиваются исходные данные [от общего (от уже полученного результата) к частному (к причинам)], сопоставляются и пересопоставляются n-е количество раз и в результате – либо подготавливается очёт, как система в целом докатилась до такой жизни, либо даже строится /теоретическая/ модель той же системы, но уже оптимизированной. Вот это “либо”/”либо” – достаточно ли в качестве результата работы предоставить “мы попали в *C*, потому что складывали *A*+*B*” или результатом работы аналитика должно быть не только “как мы попали в *С*”, но и “если мы хотим попасть не в *С*, а в *Z*, мы должны брать не *А* и *В*, а *X* и *Y*”, да ещё и предоставить все доказательства, почему?

Неправильности часто встречающиеся:

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

1.а) Или не правильно обозначен период времени для сбора данных. На малом интервале получилось найти исходные значения – делаются выводы – только они не работают.

2. Не правильно построены, не построены, проигнорированы связи между группами данных, связи внутренние и внешние. Проверяем первую цепочку, строящую подсистему *А* – работает, вторую цепочку, которая отвечает за работоспособность подсистемы *B* – работает. А система в целом – не работает, потому что *А* и *В* между собой не договорились.

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

4. Аналитика – это не только цифры. Для того, чтобы сделать яишницу, нужно взять 1 сковородку, 2 яйца, 10 грамм соли и 30 грамм масла, жарить при температуре 100­°С, для того, чтобы порадовать этой яишницей подругу с утра, нужна чистая салфетка, красивая тарелка, зелень и оливки для украшения блюда (а как украсить – интуиция подскажет) и УЛЫБКА! (одна штука). Ладно, это не супер пример. Но тем не менее по п.4. – аналитика – это не только числовые данные.

Видимо, в каждой системе есть те, кто первую половину дня тупят в потолок, покуривая сигарету за сигаретой, вторую половину дня ищут виноватых в том, почему всё так, и те, кто копает траншеи.
Примеры рассматриваемых систем:
1. Общество/Политика.
2. Семья/Семейные отношения.
3. Офис/Бизнес.
Есть *А*, который создаёт, и есть *Б*, который потребляет. Потребитель в свою очередь по определению является разрушителем – съёдая сникерс, он разрушает/уничтожает то, что создал *А*. Так же именно он, *Б*, и может на самом деле выступить с критикой качества полученного им сникерса, или вообще самой необходимости создания сникерса – и соответственно качества и необходимости труда *А*. Сам *А* объективно провести оценку качества своего труда не способен – он находится внутри системы (он знает процесс, трудозатраты, но это не все факторы, которые влияют на значение ценности произведенного им сникерса + включение человеческого фактора – любое созданное – это “детище” создателя, и отношение к созданному всегда будет субъективно), но, с другой стороны, потребитель, *Б* – он тоже находится внутри системы, и так же не способен выступить с объективной критикой потребляемого им (+ тоже пресловутый человеческий фактор).

Для анализа системы из *А*, *Б* и *сникерса* разумно привлекать сторонних аналитиков (они вне системы, поэтому снижается риск влияния на результат анализа “человеческого фактора”, нет необходимости в процессе оценки “защищать себя” – и значит “искать того, кто виновен”). Поэтому как раз в системе из *А*, *Б* и *сникерса* редко возникает необходимость в стороннем объективном анализе, потому что для *Б* – это угроза его стабильности, у *А* на это нет времени, потому что ему нужно сегодня ещё “выкопать-две-траншеи/слепить-три-сникерса”, думать некогда, и такая система может оставаться неоптимизированной годами. А потом в одночасьё – рухнуть.

Можно обойтись и без стороннего беспристрастного аналитика. Включается здравый смысл и заложенная у всех без исключения способность видеть ситуацию (и себя в ситуации) со стороны, и этого достаточно. Но это делать так же не хочется (хотя и надо), как и вызывать стороннего аналитика. Это первое.
Второе. При анализе важно участие значимых объектов системы. В бизнесе – это обе стороны (к примеру, конфликт между подрядчиком и нанимателем), в семье – это искреннее желание и мужа, и жены изменить ситуацию (на самом деле как правило минимум один из ситуацию менять не хочет, только играет во “всё плохо”), в политике – то же самое.
Если объективную оценку жаждет кто-то один, второй же игрок от объективной – прячется – обесценивается сам факт анализа, и происходит то же самое – система рушится.