Что означает три креста
О трех крестах 42
Кресту Твоему поклоняемся, Христе,
И святое воскресение Твое поем и славим
Когда мы, паломники ко Гробу Господню, оказались на Голгофе, мы увидели место, где находился Крест Господень, а слева и справа от него были кресты двух разбойников. Всего три креста.
Когда мы спустились в одну из пещер за Голгофой, нам показали место, где царица Елена обрела кресты – Крест Христов, крест покаявшегося разбойника и крест нераскаянного разбойника. Всего три креста.
Дорогие мои братья, и сейчас существуют три креста, которые носят люди. Крест праведника, крест кающегося грешника и крест нераскаянного грешника. Какой из них легче?
Крест символизирует страдание. Страдание праведника, страдание кающегося грешника и страдание нераскаянного грешника. Какое из них легче?
Легче тот крест, который несешь с верой и надеждой. Легче то страдание, которое держится на крыльях веры и надежды.
Двое знают, за что страдали, а третий не знает. Праведник знает, что страдает по воле Божией ради блага других людей и ради собственного совершенства (так же как металл бросают в огонь, чтобы сделать из него закаленную сталь). Кающийся грешник знает, что страдает за свои грехи, страдает ради своего очищения (так же как полотно мнут и бьют, чтобы сделать его белым), страдает на этом свете, чтобы не страдать на том. А нераскаянный грешник не знает, за что страдает. Он обвиняет всех и вся, только не самого себя, и он страдает без веры и надежды, поэтому его страдание самое мучительное, а крест самый тяжкий.
Вы знаете слова Господа Иисуса – Иго Мое легко и бремя Мое благо ( Мф. 11:30 ). Поистине, вера в Бога легче, чем неверие. Пост легче объядения, а трезвость – пьянства. Жизнь легче с молитвой, чем без нее, прощение легче сутяжничества, давать милостыню легче, чем отнимать чужое. Поддерживать кого-то слаще, чем унижать. Взаимная любовь радостней, чем самолюбие и ненависть. Путь правды может кому-то показаться трудным, но каждому нужно знать, что путь неправды много труднее.
Посмотрите и увидите, как труден путь неправды. Неправедный ест и никак не насытится. Отнимает и похищает, и ему всегда мало. Мстит и не находит удовлетворения. Ненавидит Бога и людей и всегда несчастлив, а когда добьется в жизни всего, что хочет, пропадает и гибнет, а его дети оказываются нищими или попадают на каторгу или в тюрьму.
Нелегок и путь праведника, но он легче. Возьмите в пример праведного Иова. Он претерпел великие страдания за правду, но вера и надежда на милость Божию не оставили его, и он не посрамился. Господь вернул ему утраченное здоровье, потерю детей возместил новым потомством, вернул и потерянное имение и весьма умножил. А праведный Иов равно прославлял Бога, и когда Он отнимал, и когда давал.
Священное Писание Божие полно примеров страданий праведников, кающихся грешников и нераскаянных грешников, и во всех этих примерах видно, что страдание праведника венчается великой славой, страдание кающегося завершается прощением грехов и спасением, а страдание нераскаянного остается бессмысленным, тщетным и без награды от Господа.
Вот, братья. Три пути перед вами. По одному из них нужно пойти, вот вам три креста, один из них нужно нести по жизни. Или Крест Христов, или крест благоразумного разбойника, или крест нераскаявшегося разбойника. Всего три креста существует в человеческой жизни.
Движение богомольцев, возникшее в нашем народе, движение покаянное. Поэтому члены его не должны считать себя слишком праведными и еще меньше гордиться своей праведностью. Но пусть каждый возьмет крест покаяния и радостно идет с ним вперед к Царству Божию. Пусть вооружится терпением и исполняет Божии заповеди с верой и надеждой. «И заповеди Его не тяжки» ( 1Ин. 5:3 ). Взаимная любовь смягчит страдания каждого из вас. Держи одной рукой крест, а другой крест брата своего, и обоим будет легче. И оба смотрите на святой Христов Крест, и еще легче вам будет. Ибо от Креста Христова сойдет сила и благословение, и благословенны будете и на этом свете и на том, и с легкостью пройдете этот краткий путь земной жизни и войдете в Царство Жизни Вечной, в Царство бессмертное, в котором царит Отец ваш Небесный.
Богу нашему слава и хвала, а вам благодать и радость, и любовь, и здравие, и спасение. Аминь.
Откуда взялось выражение «Аллюр три креста»
С детства, по книгам и художественным кинофильмам, всем нам знакомо выражение «Аллюр три креста». Но ни в одной книге, а уж тем паче кинофильме не объяснялось, что именно означает этот приказ.
Быть может вы когда-нибудь уже слышали, что раньше, когда население Российской империи было поголовно неграмотным, вместо подписи в раздаточных ведомостях часто ставился крестик? Тем самым подписчик удостоверял свое присутствие и участие в деле, подтверждая это крестом. Крест у православного русского люда являлся мерилом подлинности, своеобразной клятвой. Крестом не разбрасывались (не упоминали всуе).
Крестьяне в Российской империи были в основном малограмотными. Источник изображения: en.35photo.pro
Позже, крест так и остался значимой, исключительной величиной, который использовали в редких, но очень важных случаях.
До появления автомобилей, мотоциклов (которые назывались самокатами), самолетов (аэролодок и аэропланов) самым мобильным способом передвижения по территории была кавалерия. Всадник на лошади опережал любого иного скорохода. В императорских войсках России именно кавалерийские части являлись самым быстрым родом войск. Связь между собой кавалеристы (да и прочие армейские команды) держали через нарочных.
Гусары легкой кавалерии русской императорской армии. Источник изображения: en.35photo.pro
Курьеры верхом на лошадях курсировали с донесениями, а срочность послания определяла его важность. В мировой практике военных действий бывали случаи, когда опоздания донесения грозило существенными неприятностями. Но и не было смысла загонять до пены лошадь, когда реляция была второстепенной, третьестепенной и не имела срочной важности.
Гонец. Художник Трошин С.Н. Источник изображения: en.35photo.pro
На пакетах с военными донесениями отправитель фиксировал скорость доставки. Скорость перемещения послания обозначали аллюром, то есть видом походки (бегом) лошади, а срочность символически отмечали крестом. Один крест (+) обозначал ход лошади шагом (с этим донесением можно было не торопиться), Два креста (++) обозначали движение лошади с всадником рысью (то есть быстро), а три креста требовали движение незамедлительным галопом (то есть очень быстрым темпом движения). Таким образом надпись на секретном пакете «Аллюр +++» предупреждала курьера о необходимости очень быстро доставить донесение в пункт назначения.
Уважаемые друзья! Приглашаю Вас подписаться на наш канал, посвященный истории нашей Родины. Спасибо!
АЛЛЮР ТРИ КРЕСТА
Смотреть что такое «АЛЛЮР ТРИ КРЕСТА» в других словарях:
Аллюр три креста! — бежим отсюда! уходим! Возм. из уг … Словарь русского арго
Аллюр в два (три) креста — 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]
Теперь мы гораздо лучше представляем себе, что означает «аллюр три креста» в управлении проектами. Привычные методы, которые мы применяем для улучшения ситуации, на деле ее ухудшают. Тщательный сбор требований «лишь бы не пропустить что-то важное» приводит к огромному числу функций, которые практически невозможно реализовать в разумные сроки. Привлечение большого числа разработчиков влечет за собой резкий рост управленческих расходов («на одного работающего десять менеджеров») и снижает общую продуктивность команды. Тщательное планирование с целью не потратить ни одного лишнего цента создает огромный объем лишней работы, из-за которой тратятся зря миллионы долларов.
Почему так происходит? Что за проклятие тяготеет над проектированием новых вещей? Да все то же — сложность. Как только вместо борьбы с самой сложностью (упрощения) мы пытаемся взять ее под контроль с помощью другой сложности — вызванный демон набрасывается на нас с новой силой. Единственный способ справиться с проектом — это справиться со сложностью.
Предложенные в мировых бестселлерах способы сводятся именно к этому. Использовать гениальных проектировщиков, умеющих отсеять лишние требования и организовать оставшиеся в «собирающуюся» систему. Дать людям работать, минимизировав управляющие воздействия (то есть «политику»). Отказаться от избыточного планирования, направив сэкономленное время на саму работу. Простые по смыслу способы, единственный недостаток которых — отсутствие подробных инструкций, как это сделать. Борьба со сложностью ждет своего воплощения в развитую методологию управления, которая позволит наконец поменять неутешительную статистику успешности проектов.