что такое аллюр три креста

АЛЛЮР ТРИ КРЕСТА

Смотреть что такое «АЛЛЮР ТРИ КРЕСТА» в других словарях:

Аллюр три креста! — бежим отсюда! уходим! Возм. из уг … Словарь русского арго

Аллюр в два (три) креста — 1. Народн. Очень быстро (о скорости движения). БМС 1998, 23. 2. Жарг. угол. Шутл. Быстрый уход с места преступления. ББИ, 18; Елистратов 1994, 21; Балдаев 1,15. /em> Из речи казаков, где оборот обозначает быструю езду на коне. БСРЖ, 34 … Большой словарь русских поговорок

аллюр — а м. allure f. 1138. Лексис.1. Разновидность движения, хода лошади. Сл. 18. Правому флангу менажировать себя, как возможно, во всех аллюрах (движениях). УКС 42. Вид движения лошади (шаг, галоп, рысь, карьер), а также упражнения по выездке… … Исторический словарь галлицизмов русского языка

Аллюр — Рысь Галоп Аллюры (фр. allure «походка») виды походки лошади: шаг, рысь, галоп и иноходь. Аллюры делятся на естественные и искусственные. Содержание … Википедия

АЛЛЮР — в два (три) креста. 1. Народн. Очень быстро (о скорости движения). БМС 1998, 23. 2. Жарг. угол. Шутл. Быстрый уход с места преступления. ББИ, 18; Елистратов 1994, 21; Балдаев 1,15. /em> Из речи казаков, где оборот обозначает быструю езду на коне … Большой словарь русских поговорок

Первый Кубанский поход — Не следует путать с Великий Сибирский Ледяной поход. Первый Кубанский поход Гражданская война в России … Википедия

ЛЮБАШЕВСКИЙ Юрий Яковлевич — ЛЮБАШЕВСКИЙ Юрий Яковлевич, продюсер кинокомпании «Аллюр три креста», президент Московского товарищества «Дягилев центръ». 1991 НОМЕР «ЛЮКС» ДЛЯ ГЕНЕРАЛА С ДЕВОЧКОЙ (см. НОМЕР ЛЮКС ДЛЯ ГЕНЕРАЛА С ДЕВОЧКОЙ) продюсер, актер 1992 ШОУ ДЛЯ ОДИНОКОГО… … Энциклопедия кино

ЛЮБОВЬ ФРАНЦУЗСКАЯ И РУССКАЯ — «ЛЮБОВЬ ФРАНЦУЗСКАЯ И РУССКАЯ», Россия, Аллюр три креста, 1994, цв., 80 мин. Мелодрама. Приехавший в Москву француз полюбил молодую русскую женщину. У нее не все ладится в жизни муж сидит в тюрьме, пятилетняя дочь живет у свекрови, на работе… … Энциклопедия кино

ПРИЮТ КОМЕДИАНТОВ — «ПРИЮТ КОМЕДИАНТОВ», Россия, РОСКОМКИНО/АЛЛЮР ТРИ КРЕСТА, 1995, цв., 78 мин. Лирическая комедия. В одном из старинных ялтинских домов живет старая женщина. Когда то Нелли Евгеньевна (Н.Е.) работала костюмером в театре ей всегда есть что вспомнить … Энциклопедия кино

Источник

Аллюр три креста, или Почему проекты так трудно закончить в срок

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

Tar pit (англ., дословно смоляная яма) — 1) неразрешимая проблема, 2) битумное озеро (место, где подземный битум выходит на поверхность, создавая участок природного асфальта). [Англо-русский словарь] Животные, попавшие в битум, не могут выбраться обратно, поэтому такие озера являются отличным местом для раскопок доисторических скелетов [Википедия].

«Воображение представляет динозавров, мамонтов и саблезубых тигров, пытающихся высвободиться из смолы. Как бы ни был силен или ловок зверь, в конечном итоге ему уготована гибель. Такой смоляной ямой в последнее десятилетие было программирование больших систем. » [1, с.16] С этого яркого образа начинается классическая книга Фредерика Брукса, впервые увидевшая свет в далеком 1975 году. Другая классическая книга, опубликованная в столь же древнем 1987-м, начинается ничуть не лучше: «А в это время где-то гибнет проект» [2, с.23]. Идут годы, человечество вступает в новое тысячелетие, но и в 2014 году очередной бестселлер начинается все с той же вечной истории: «3 марта 2010 года Федеральное бюро расследований решило приостановить свой крупномасштабный и многообещающий план модернизации управления информацией… В бюро пытались обновить свою компьютерную систему уже более десяти лет, и, похоже, их постигла катастрофа» [3, с.14].

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

По данным CHAOS Studies от Standish-Group [4]

Почему прогресс в науке управления (воплотившийся в 6 изданий PMBoK и нескольких десятках других толстых книг) за 40 лет (!) так и не привел к улучшению качества самого управления (если, конечно, под качеством управления понимать вероятность прибытия в заданную точку)? Чтобы разобраться с этим вопросом, начнем с основной проблемы любого проекта, обозначенной во всем известной книге Брукса.

Первая проблема: сложность создаваемого продукта

Если спросить первого попавшегося айтишника — «Что главное в Мифическом человеко-месяце?» — ответом скорее всего будет: «Что все человеко-месяцы разные, у новых работников совсем не те, что у старых». Даже сам Брукс называет «законом» положение, сформулированное в самом начале книги («Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше»). Но это лишь эмпирическое наблюдение, известное каждому, что хоть раз «менял коней на переправе»; вопрос заключается в том, как же планировать проект, когда все человеко-месяцы — разные?

«Мифический человеко-месяц» потому и стал бестселлером, что дает ответ на этот вопрос. Вот как Брукс формулирует свое понимание основной проблемы проектирования:

«… классические трудности разработки программного обеспечения проистекают из этой сложности сущности и ее нелинейного роста при увеличении размера. Сложность служит причиной трудности процесса общения между участниками бригады разработчиков, что ведет к ошибкам в продукте, превышению стоимости разработки, затягиванию выполнения графиков работ. Сложность служит причиной трудности перечисления и тем более понимания всех возможных состояний программы, а отсюда возникает ее ненадежность… Сложность структуры служит причиной трудностей при развитии программ и добавлении новых функций так, чтобы не возникали побочные эффекты. « [1, с. 167]

Принципиальное отличие проекта от любого другого производства заключается в том, что создаваемый в нем проект производится впервые [мы в курсе, что многие задачи вроде «прикрутить счетчик посещений на сайт» тоже называются «проектами», но речь-то о настоящих проектах]. Как и любая реальная вещь, этот новый продукт (неважно, программный или «аппаратный») состоит из большого числа компонентов, способных на самые неожиданные взаимодействия (как негативные — талидомид, так и позитивные — виагра). Предвидеть заранее, как все это будут работать вместе, чрезвычайно сложно, и для этого требуются в буквальном смысле «лучшие умы», а вовсе не бесконечные «человеко-месяцы»:

«Выдающиеся проекты создаются выдающимися проектировщиками. Создание программ является творческим процессом. Крепкая методология может придать силу и освободить творческий ум, но она не может воспламенить или вдохновить того, кто занят нудной работой… Поэтому… я считаю, что единственное и наиболее важное усилие, которое мы можем предпринять — это развивать способы воспитания выдающихся проектировщиков» [1, с. 185-186]

Из основного положения Брукса (проектирование это творчество, а творческий процесс невозможно осуществлять толпой) прямо вытекает все реальное содержание «Мифического человеко-месяца»: и требования «диктатуры архитекторов», и «эффект второго проекта», и рекомендация «планируйте выбросить первую версию». Но из него же следует и самый забываемый тезис Брукса — что в управлении проектами «нет серебряной пули»! Сложность проектов объективна, ее невозможно преодолеть ни с помощью новых языков программирования (даже графических), ни подключением искусственного интеллекта. Справляться со сложностью приходится каждый раз заново, и если таланта проектировщика для этого не хватит — проект не будет успешным.

Главный враг проекта по Бруксу — сложность создаваемого продукта. С каждой строчкой нового кода, с каждой страницей технологической документации эта сложность растет, и растет нелинейно. А одновременно с этим в распоряжении менеджера остается все меньше ресурсов — как времени, оставшегося до конца проекта, так и денег, оставшихся до конца бюджета:

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

К следующему проекту, названному «Страж», ФБР приступило сразу, в 2005 году. Цена вопроса — 451 миллион долларов, и система «Страж» будет полностью работоспособной в 2009 году… В марте 2010 года компания Lockheed Martin, подрядчик, опаздывала на год, осуществив лишь половину проекта и потратив 405 миллионов. Для завершения, по оценкам независимых экспертов, ей потребовалось бы еще от шести до восьми лет, и дополнительно 350 миллионов долларов. [3, с.17-18].

Но позвольте! Если мы с 1975 года знаем, что сложность проектов растет, к примеру, квадратично, — что мешает точно так же квадратично увеличивать бюджет и команду? Почему все новые поколения менеджеров продолжают вести проекты с прогнозируемой успешностью в 30%, когда можно просто добавить денег?

Вот теперь пришло время перейти к следующей книге.

Вторая проблема: сложность совместной работы

Как мы уже знаем, появившийся через двенадцать лет после «Мифического человеко-месяца» мировой бестселлер «Peopleware» («кадровое обеспечение», переведенное на русский как «Человеческий фактор») начинается с констатации высокой смертности проектов. «Около пятнадцати процентов проектов кончились ничем… В случае крупных проектов картина еще хуже, крах постиг двадцать пять процентов проектов, длительность которых составляла от двадцати пяти человеко-лет» [2, с.24] Это написано в 1987 году (еще был жив СССР!), со ссылкой на исследования 1981 года (еще был жив Брежнев); а что у нас на сегодняший день?

По данным CHAOS Report 2015 [5]

Средний разработчик стоит сегодня 100К долларов в год, добавив накладные расходы, получим, что 25 человеко-лет — это примерно 3-6M долларов. Как видите, с тех давних лет ситуация не изменилась: провал ожидает 26% средних проектов и 43% больших, и мы ничего не можем с этим поделать. Но почему так происходит? Демарко и Листер спросили разработчиков о причинах провалов, и вот что получили в ответ:

«В подавляющем большинстве случаев не было ни одной объясняющей неудачу причины из области технологии. Чаще всего участники наших опросов в качестве причины краха называли »политику»

Вовсе не сложность разрабатываемого продукта, и не недостаточность ресурсов, как можно было бы ожидать, глядя на «крест Брукса»! «Политика», взаимоотношения людей внутри и вовне команды (то, что Демарко и Листер предпочли назвать «социологией») — вот что по мнению разработчиков больше всего мешало добиться успеха.

Вдумайтесь в этот факт: те самые люди (разработчики, начальство и заказчики), которые на первый взгляд были больше всего заинтересованы в успехе, объединившись ради проекта, устраивали в нем «политику», чем и доводили проект до краха! «Мы встретили врага, и он это мы» [6]; у проекта обнаружился второй злейший враг — его собственная команда.

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

Рис. 2 из статьи Putnam, Myers [7]

Собрав численные характеристики 491 проекта по разработке программ от 35 до 95 тысяч строк кода, Патнэм и Майерс пришли к результатам, в которые практически невозможно поверить. Сопоставимые по размерам проекты завершались командами разной численности практически в одно и то же время, причем командам большей численности требовалось не меньше, а больше времени. Закон Брукса («добавить разработчиков — замедлить проект») оказался работающим не только при угрозе срыва проекта, но и с самого начала, начиная с добавления девятого программиста. Если представить те же результаты в терминах пресловутых человеко-месяцах, получается еще более выразительный график. Сколько денег (в месячных окладах) требуется, чтобы решить одну и ту же задачу силами команд разной численности:

Рис. 3 из статьи Putnam, Myers [7]

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

Книга Демарко и Листера содержит массу примеров «социологии», подменяющей работу над проектом работой по поддержанию «порядка» в коллективе. Офисы опен-спейс, где начальству видно, кто отлынивает от работы (а работники постоянно отвлекают друг друга); детальное планирование и постоянные требования выдерживать сроки (заставляющие торопиться и ведущие увеличению числа ошибок); мелочная регламентация (заставляющая тратить массу времени на отчетность о проделанной работе и сдвигающая мотивацию работников с кода на «бумажку»). Все эти меры кажутся необходимыми для организации совместной работы — но, будучи применены в полном объеме, на саму работу уже не оставляют времени.

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

Но что если поменять сами принципы организации совместной деятельности? Демарко и Листер рекомендовали это еще в 1987 году: Чтобы эффективно управлять людьми в области интеллектуального труда, необходимо принимать меры, противоположные перечисленным выше. [т.е. регламентации, стандартизации, работы под страхом увольнения и запрета на какую-либо инициативу]. Предполагалось, что в Peopleware достаточно ясно написано, как должны выглядеть «противоположные» меры [на самом деле, нет]. Посмотрим еще раз на график успешности проектов. И где результат от книги, до сих пор входящей в must read любого менеджера? Что-то не видать.

Так почему? Неужели на пути к эффективному управлению проектами стоит еще один крест?

Третья проблема: сложность планирования нового

На первый взгляд, третье препятствие на пути к совершенному управлению проекта заключается в необычности правильного способа руководства творческим процессом. Один из таких способов, ныне широко известный как Scrum, был описан в статье [8] еще в 1986 году, даже до выхода «Peopleware». Уже через несколько лет, в 1993 году Джефф Сазерленд впервые применил в своем проекте отдельные элементы Scrum, и остался доволен результатом:

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

Однако подробное описание основных идей Scrum было издано лишь через двадцать лет, буквально на днях, в 2014-м году [3]. Все это время Scrum существовал как полусектантская методология, передаваемая буквально от учителя к ученику, и набирал популярность исключительно за счет «сарафанного радио». Все дело в том, что основная концепция Scrum, прямо вытекающая из его философии, не вписывалась в любую разумную логику управления:

Вот о чем я постоянно твержу руководству: «Я смогу назвать срок, только когда увижу, насколько эффективно будет действовать команда» [3, с.28).

Если понимать под «управлением проектом» обеспечение создания продукта с заданными свойствами в заданный срок в пределах бюджета, получится, что Scrum вовсе не является «управлением»! Центром философии Scrum является категорический отказ от придумывания «заданного срока» с потолка (в отрыве от реальной команды и ее производительности), а первым следствием такого отказа — полностью нетрадиционный подход к планированию проекта:

Я пошел к главе компании и заявил, что мы отказываемся от диаграмм Ганта. Возмущенный услышанным, он потребовал объяснений.
— Со сколькими диаграммами Ганта вы сталкивались за свою профессиональную деятельность? — спросил я.
— С сотнями, — сказал он.
— Сколько из них соответствовали действительности?
— Ни одна, — ответил он, на минуту задумавшись.
Тогда я объяснил, что вместо никому не нужных графиков и таблиц к концу месяца мы дадим ему часть вполне работоспособной системы, которую он сам сможет опробовать и воочию убедиться, в правильном ли направлении идет разработка» [3, c.50]

В рассказываемой Сазерлендом истории босс согласился попробовать. Но мы знаем, что такое «ошибка выживших», и прекрасно понимаем, что на одного такого босса найдется десять, которые пошлют подальше подобного «менеджера проектов». Что за бред, платить деньги под честное слово, что «мы будем работать и через месяц кое-что покажем»? Какой идиот так делает?

Из книги Сазерленда мы довольно точно знаем, какой: тот, кто уже пробовал сделать проект классическим способом, и потерпел катастрофическую неудачу. Лишь загнанный в угол руководитель, которому нечего терять, осмелится отказаться от базового принципа управления «ресурсы — только под план их использования». Конечно, через двадцать лет применения Scrum отношение к нему несколько изменилось, но и сегодня большинство разговоров «срок и сумму я назову, когда соберу команду и начну работать» рискуют на этом и закончиться.

Идеология Scrum настолько противоречит общепринятым представлениям о проекте («Заказчик обязуется оплатить, а Исполнитель выполнить следующие работы. »), что впору задаться вопросом: а почему Сазерленд вынужден был пойти на такой революционный шаг? Неужели нельзя было оставить диаграммы Ганта «для галочки» и сосредоточиться на организации работы команды (например, на ежедневных совещаниях стоя, в которых многие видят самое главное в Scrum)?

Судя по горячности, с которой Сазерленд атакует в своей книге «диаграммы Ганта», нельзя:

При управлением проектами традиционно требуется наличие двух вещей — подконтрольность и предсказуемость. Такой подход неминуемо приводит к возникновению огромного количества документации, таблиц и диаграмм… Месяцы труда тратятся на то, чтобы предусмотреть все до мельчайших деталей, не допустить ни единого сбоя, не перерасходовать финансовых средств и продвигаться согласно графику. [3, c.23] Беда лишь в том, что как только этот превосходно отточенный план сталкивается с реальностью, он сразу рассыпается в прах. Но вместо того чтобы выбросить в мусорную корзину и сам план, и свой подход к нему, руководители делают вид, будто план работает… По сути, они платят людям за то, что те им лгут. [3, с.20]

Платят за то, что им лгут — вот в чем дело! Составление детального плана и сметы проекта (обобщенно называемых Сазерлендом «диаграммой Ганта») не только само по себе требует значительных трудозатрат, но и ведет к принятию огромного числа проектных решений на основе фантазий планировщиков. Будучи утвержденными заказчиком, эти фантазии оказываются обязательными к исполнению, поскольку на них теперь завязан авторитет начальства («у нас все идет по плану!»). Результат вполне предсказуем:

Как правило, руководство не в курсе, что проект катится в пропасть, по крайней мере до того момента, пока не будут растрачены впустую миллионы долларов и тысячи часов работы [3, с.23]

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

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

Хочешь быстрее — тормози! [9]

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

Почему так происходит? Что за проклятие тяготеет над проектированием новых вещей? Да все то же — сложность. Как только вместо борьбы с самой сложностью (упрощения) мы пытаемся взять ее под контроль с помощью другой сложности — вызванный демон набрасывается на нас с новой силой. Единственный способ справиться с проектом — это справиться со сложностью.

Предложенные в мировых бестселлерах способы сводятся именно к этому. Использовать гениальных проектировщиков, умеющих отсеять лишние требования и организовать оставшиеся в «собирающуюся» систему. Дать людям работать, минимизировав управляющие воздействия (то есть «политику»). Отказаться от избыточного планирования, направив сэкономленное время на саму работу. Простые по смыслу способы, единственный недостаток которых — отсутствие подробных инструкций, как это сделать. Борьба со сложностью ждет своего воплощения в развитую методологию управления, которая позволит наконец поменять неутешительную статистику успешности проектов.

Источник

LiveInternetLiveInternet

—Метки

—Рубрики

—Цитатник

Под вуалью тоски. Кубинский художник Orestes Bouzon По струнам дождя, под вуал.

Самые красивые автомобили Союза ГАЗ-12 ЗИМ Тех.характеристики В основе шест.

—Ссылки

—Новости

—Видео

—Музыка

—Статистика

А ларчик открывался просто. Имя Тамара буквами «Всеясветной Грамоты» пишется тремя буквами, которые имеют в наличии крест:

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

А.Ф Шубин-Абрамов, восстановший 147 букв «Всеясветной Грамоты», по-своему образно описал их. Букву «Та» он описывает как «звезду, сжигающую зло». К этой информации можно добавить, что «Звездой» называют матрицу «Бог», которая имеет «тысячу имён» и о ней существует определение:»Та, что в тысячу имён облачена».

Это и есть «Вифлеемская Звезда», познанием которой отличался от всех библейский царь Давид.

Мир ждёт МА как МАнны небесной.

«Евреи ждут «помазанника и мессию» МАшиаха, мусульмане ждут освободителя МАхди, те, кто обращает свои взгляды к Тибету, ждут будду текущего миропорядка МАйтрейю, Россия — в ожидании Богородичного пути и женских божественных образов МАрии, МАгдалины, МАкоши, МАдонны… Я много раз читала все эти предсказания и вдруг подумала: «А почему везде первый слог МА? Не есть ли МА — имя древнего Бога и мессии, которого все ждут с нетерпением, особенно, в связи с наступлением третьего тысячелетия и смены эры Рыб на эру Водолея?» (© Наталья Ярославова-Чистякова 26.02.2008 г www.yaroslavova.ru/main.mhtml )

«Поистине, лишь язык сердца может дать сущность Сущего».( Агни-Йога «Сердце» 228 )

Таким образом, в имени Тамара матрица «Бог», через слоговые понятия, являет Себя, Мысль и Мыслителя, обеспечивая таким образом САМОПОЗНАНИЕ.

«Понятие «Пища Ра», звучащее сегодня, как Пещера, изначально означало Духовную Пищу, хранилище Знания, необходимого для духовного роста и развития сознания людей». ( www.peshera.org/ )

Так давай споем на пару, про Тамару, про гитару
И про речку нашу Нару, что, как дЕвочка, бежит
Через рощи, через пущи, через нас с тобой, плывущих
По смешному океану под названьем «Наша жизнь».

Лучше нет для нас призванья, чем бесплодные скитанья,
Чем наивные желанья собеседника понять.
Но, весну предполагая, Томка веточкой играет,
Одновременно ругая невиновного меня.

Так давай споем на пару, про Тамару, про гитару
И про речку нашу Нару, что, как дЕвочка, бежит
Через рощи, через пущи, через нас с тобой, плывущих
По веселому проливу под названьем «Наша жизнь».

Из «Всеясветной Грамоты» А.Ф.Шубина-Абрамова

«Человечество, в положении явного исказителя законов космических, порождает те следствия, которые отражаются на всех событиях. Ведь уже столетия, как усовершенствование удалилось от человечества; и Дух, который насыщает множества, именно стремится к созданию тупика. Водоворот, в который человечество посеяло свои вожделения, создал то разобщение, которое нарушило космические законы. Свойства человеческие притягивают духов, которые воплощаются не имея никаких духовных устремлений «(«Мир Огненный» часть3, 328 )

Метки: откровение архангела михаила

Процитировано 3 раз
Понравилось: 2 пользователям

Источник