История развития методологий проектирования (программной инженерии). Основные методологии для проектирования ис

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

Традиционная (Каскадная) методология управления проектами

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

1. Определение требований
2. Проектирование
3. Реализация (строительство, производство…)
4. Внедрение
5. Тестирование и отладка
6. Установка
7. Эксплуатация и сопровождение

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

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

Методология управления проектами PRINCE 2

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

Принципы методологии PRINCE2:

1. Постоянная оценка экономической необходимости — остается ли неизменной экономическая выгода от проекта на протяжении всего жизненного цикла проекта
2. Обучение на опыте – команда проекта должна постоянно искать и изучать опыт предыдущих проектов
3. Определение ролевой модели – команда проекта должна иметь ясную организационную структуру и вовлекать подходящих людей для решения нужных задач
4. Управление по этапам – необходимо, чтобы проекты были спланированы, а также подвергались мониторингу и контролю на каждом этапе выполнения;
5. Управление по отклонениям – следует четко обозначить допустимые границы отклонений в проекте, чтобы установить границы ответственности
6. Фокус на продуктах – необходимо концентрироваться на определении и достижении качества продуктов (результатах проекта)
7. Адаптация к проектной среде – следует адаптировать процессы и инструменты управления проектом к требованиям проектной среды, а также к масштабу работ, их сложности, важности, квалификационным требованиям и степени риска

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

Аспекты методологии управления проектами PRINCE2 :

1. Обоснование проекта: какую ценность проект принесёт организации?
2. Организация : каким образом необходимо распределить роли и ответственность между членами проектной команды для того, чтобы эффективно управлять проектом
3. Качество : какие имеются требования и критерии к качеству и каким образом можно их обеспечить
4. Планы : шаги, требуемые для разработки плана, и инструменты PRINCE2, необходимые к использованию
5. Риски : каким образом менеджмент проекта будет разрешать проблему наличия неопределённостей в плане проекта и во внешней среде
6. Изменение : как руководство проекта будет оценивать влияние непредвиденных задач и изменений и реагировать на них
7. Прогресс : реализуемость проекта, выполнение планов и дальнейшее развитие проекта

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

PRINCE2 подразумевает следующие процессы управления проектом:

1. запуск проекта
2. руководство проектом
3. инициация проекта
4. контроль этапов
5. управление созданием продукта
6. управление границами этапов
7. закрытие проекта

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

Гибкая методология управления проектом (Agile Project Management)

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

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

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

Методология Agile является гибкой и позволяет легко изменить параметры проекта, что является значимым для таких сервисно-ориентированных проектов, как разработка программного обеспечения или графический дизайн. Но это методология не подходит для проектов со строго заданными параметрами и требованиями.

Методология быстрой разработки приложений (Rapid Application Development — RAD)

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

• Планирование
• Пользовательское проектирование
• Быстрое конструирование
• Переключение

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

• Не существует универсальной «наилучшей» методологии управления проектом – выбор определяется типом проекта и спецификой окружающей среды
• Если вы работаете над проектом с возможными небольшими изменениями содержания работ, например, в области строительства, выбирайте каскадную модель
• Для разработки программного обеспечения, графического дизайна и других сервисно-ориентированных проектов выбирайте Agile методологию
• Используйте методологию быстрой разработки приложений для небольших IT проектов с сжатыми сроками
• Если вам необходимо минимизировать риски и требуются структурированный подход в исполнении крупного или среднего масштаба проекта, выбирайте PRINCE2
• Не бойтесь использовать другие, менее популярные методологии, если они в большей степени подходят к вашему проекту

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

С чего все начиналось

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

В античные времена проектирование связывали с «наукой архитектора» и связывали данную науку не только с возведением зданий, но и созданием строительных и военных машин.Римский инженер и архитектор Марк Витрувий в 1 в. до нашей эры в своем трактате «10 книг об архитектуре» дал проектированию следующее определение:
В теории - показать и обосновать исполнение в соответствии с требованиями искусства и целесообразности.
В практическом смысле - выполнение руками человека работ из любого материала по данному чертежу.

Однако, история развития проектного менеджмента как дисциплины относительно молода: ее относят к 30-м годам XX века и связывают с разработкой специальных методов координации инжиниринга крупных проектов в США - авиационных в «US Air Corporation» и нефтегазовых в фирме «Exon». В СССР в этот же период начала развиваться теория и практика поточной организации работ по реализации крупных строительных проектов.

Появление новой дисциплины

Предпосылки для внедрения принципов проект-менеджмента в процесс разработки ПО зародились в конце 60х - начале 70-х годов прошлого века, когда произошло событие, которое вошло в историю как первый кризис программирования. Событие состояло в том, что стоимость ПО стала приближаться к стоимости аппаратуры («железа»), а динамика роста этих стоимостей позволяла прогнозировать, что к середине 90-х годов все человечество будет заниматься разработкой ПО для компьютера. Развитие микроэлектроники привело к резкому увеличению производительности ЭВМ при значительном снижении стоимости. Начали уходить ограничения для аппаратных средств, оставшиеся ограничения приходятся на долю ПО. Это приводило к тому, что умение строить новые программы отставало от требований к новым программам.
Другая тенденция развития зародилась внутри самой отрасли и была основана на усилении взгляда на разработку программ, как на более чем простое «кодирование». Вместо этого программное обеспечение рассматривается как имеющее полный жизненный цикл, начинающийся с появления концепции и проходящий стадии проектирования, разработки, ввода в действие, сопровождения и развития. Смещение фокуса внимания с кодирования породил разработку методологий и развитого инструментария, вооруживших команды инженеров, занятых на всех этапах жизненного цикла программного обеспечения.
Тогда и заговорили о программной инженерии(технологии промышленного программирования) как о некоторой дисциплине, целью которой является сокращение стоимости программ. Такая проблема должна решаться более грамотной организацией процесса разработки. Это и привело к развитию методологий проектирования ПО и возведения его в главенствующие составляющие разработки.

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

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

Методологии в программной инженерии

С этого момента программирование «обрастает» различными дополнительными видами деятельности: разработкой требований, планированием, тестированием, конфигурационным управлением, проектным менеджментом, созданием различной документации (проектной, пользовательской и пр.). Разработка программного кода предваряется анализом и проектированием (первое означает создание функциональной модели будущей системы без учета реализации, для осознания программистами требований и ожиданий заказчика; второе означает предварительный макет, эскиз, план системы на бумаге).
Все эти и другие дополнительные виды деятельности, выполняемые в процессе промышленного программирования и необходимые для успешного выполнения заказов и будем называть программной инженерией. Получается, что так мы обозначаем, во-первых, некоторую практическую деятельность, а во-вторых, специальную область знания. Или другими словами, научную дисциплину. Ведь для облегчения выполнения каждого отдельного проекта, для возможности использовать разнообразный положительный опыт, достигнутый другими командами и разработчиками, этот самый опыт подвергается осмыслению, обобщению и надлежащему оформлению. Так появляются различные методы и практики (best practices) – тестирования, проектирования, работы над требованиями и пр., архитектурных шаблонов и пр. А также стандарты и методологии, касающиеся всего процесса в целом. Вот эти-то обобщения и входят в программную инженерию как в область знания.
Таким образом методологии в программной инженерии являются одной из самых динамично развивающихся составляющих области знаний, т.к. несут в себе практическую составляющую.
Современная классификация методологий управление проектом или моделей жизненного цикла проекта согласно SWEBOK выглядит следующим образом.
Методологии управления проектами:

• традиционная(каскадная, водопадная) модель;
• cпиральная модель;
• итеративная и инкрементная модель(эволюционный подход).

Подробнее о методологиях

Как видно из названия традиционные методологии построены на последовательном выполнении всех фаз проекта и конечный продукт будет получен только после выполнения всех этапов. Возвращение на предыдущий этап не предусмотрено и при появлении критических ошибок весь проект начинается сначала. Основным примером таких методологий разработки является каскадная модель или модель Водопад. Источником данной модели принято считать статью Уинстона Ройса вышедшею в 1970 году. Однако, сам Ройс описывал эту модель как пример противопоставленный итеративной модели, применимый только для очень простых проектов и сам пользовался итеративными методологиями. Так же Ройс писал, что в особо сложных местах проекта и при применении новых, ранее не используемых технологий, промежуточные этапы можно повторить дважды и заказчик по окончанию проекта получает вторую версию продукта. Такой подход нельзя назвать итеративным, но и однозначно последовательным тоже. На начальном периоде она сыграла ведущую роль как метод регулярной разработки сложного ПО. В 70x - 80x годах XX века модель была принята как стандарт министерства обороны США.
По мере развития методологий каскадная модель подвергалась жесткой критики со стороны всех исследователей, предлагавших свои методологии. Последовательное выполнение этапов разработки не дает изменить требования к программному продукту до самого релиза. Чем больше проект тем больше накапливается проблем в процессе проектирования. И реализация изменений в следующей версии продукта иногда становится не целесообразной. Продукт необходимо писать с 0 . Таким образом стоимость работоспособной версии не оправдано сильно растет. А процент успешно завершенных проектов ничтожно мал. Однако, можно ли назвать традиционные методологии разработки отжившими свой век? Не совсем. Для проектов затрагивающих безопасность жизнедеятельности строго поставленные требования и высокая степень формализации является основополагающим и необходимым фактором.
Кроме того, несмотря, на модную сейчас критику традиционной модели, она играет важную роль, потому что налагает на процесс разработки требование крайне необходимой для него дисциплинированности, с помощью которой удается благополучно обходить неструктурированные процессы типа «пишем и правим». Данная модель внесла фундаментальный вклад в понимание процессов разработки ПО следующими утверждениями:

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

Спиральная модель ЖЦ стала следующим (после водопадной) этапом развития методологий разработки, поскольку она решает основную проблему каскадной модели. Каждая фаза водопадного процесса разработки в спиральной методологии завершается этапом прототипирования и управления рисками. Этап прототипирования после каждой фазы проекта позволяет определить, насколько текущее состояние проекта соответствует первоначальному плану. По итогам прототипирования выполняется либо переход к следующей фазе, либо возвращение на одну из предыдущих фаз. Однако фазы и последовательность фаз остаются линейными. Автором данной модели является Барри Боэм, опубликовавший в 1988 году статью «A Spiral Model of Software Development and Enhancement». Не смотря на то, что в SWEBOK данная модель выделена отдельно от итеративной, при описании моделей напрашивается вывод об отнесении спиральной методологии к семейству итеративных. Это обуславливается и возможностью изменения требований между этапами и выпуска прототипов продукта после каждого цикла. Возможно такое разделение связано с авторской принадлежностью методологий.

Итеративная модель предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает “мини-проект”, включая все фазы жизненного цикла в применении к созданию меньших фрагментов функциональности, по сравнению с проектом, в целом. Упоминания о данной методологии начали появляться задолго до статьи У. Ройса и появления самой программной инженерии. Истоки концепции итеративной разработки прослеживаются в относящихся к 30-м годам работах эксперта по проблемам качества продукции Уолтера Шеварта из Bell Labs. Важной вехой в истории является осуществленный в 50-е годы проект по разработке сверхзвукового реактивного самолета X-15. По мнению участников этих работ, применение данной методологии в значительной степени определило успех проекта.
Наиболее обсуждаемые сейчас гибкие методологии разработки (Agile методологии) относятся именно к итеративным моделям ЖЦ. При описании любой из гибких методологий упоминается принцип разделения на итерации. Однако, особенность данных методологий это упор на человеческий фактор, а не на документацию проекта, что никак не обозначается в описании итеративной и инкрементной методологии.

Гибкие методологии разработки начали появляться на фоне быстрорастущего усложнения технологий и всеобщей информатизации. Теперь заказчиком в большинстве случаев является лицо далекое от информационных технологий. Для такого заказчика главным является готовый продукт, а не фолианты документации. При экспоненциально растущем темпе развития информационных технологий сроки на разработку ПО сократились и стали жестче. Теперь нет времени на долгое планирование, написание документации и полновесное тестирование. Программный продукт может устареть еще до релиза. В противовес традиционным методологиям разработки итеративные методологии делят выполнение проекта на короткие итерации, ограниченные по времени. После каждой итерации заказчику продукта предоставляется результат. Предусмотрен откат на предыдущие итерации. Появление гибких методологий не привязано к конкретной дате, так как начиная с середины 90х годов начали появляться и внедряться практически параллельно. Это были методологии разработки такие как: Scrum (1995), экстремальное программирование (1996), Crystal Clear, Lean, Kanban и другие. Созданный в феврале 2001 года, Agile-манифест, провозгласил философию гибких методологий разработки и задал вектор развития данных методологий.

Современный этап развития методологий

Сейчас выбор методологии проектирования как никогда подвержен влиянию маркетинга. Все больше появляется консультантов по внедрению agile, коучеров, проводящих бесконечные тренинги, семинары, вэбинары, бесконечные встречи, конференции, круглые столы. Все эти мероприятия направлены на продажу внедрения в ИТ-компаниях за большие деньги приглашенными специалистами или повышения рейтинга компаний, которые уже внедрили гибкие методологии.
Гибкие методологии сейчас - это в большей степени свод знаний по организации работы людей с психологической точки зрения. Такие методологии помогают команде проявлять творческую составляющую, умение работать в команде, навыки коммуникации и прочее. Техническая сторона организации работ все больше уходит на второй план. Только ХР(Экстремальное программирование) имеет в своем арсенале такие инженерные практики как разработка через тестирование, метафоры и рефакторинг. Эти практики с успехом применяются в сочетании с другими методологиями. При некачественном внедрении Agile мы получаем то, что сейчас происходит на рынке IT продуктов. Рынок перенасыщен некачественными, нестабильными продуктами, не отвечающими требованиям не к функционалу, ни к интерфейсу. При этом, что скорость выпуска таких продуктов, благодаря пропагандируемому Agile принципу непрерывной интеграции, постоянно растет.

С набирающим обороты снижением качества выпускаемых IT продуктов стали появляться методологии, стремящиеся это качество повысить. Такой методологией стал DEvOps.
Термин «devops» был популяризирован на конференции «Дни DevOps» («DevOps Days») в 2009 году в Бельгии. С тех пор такая методология все больше набирает популярность.Это отчасти связано с тем, что принципы DevOPs пропагандируют не отказ от действующей в организации методологии, а сочетание с ней. Общая концепция DevOps заключается в усилении кооперации между группами разработки(DEVelopments) и эксплуатации(OPerations) в рамках одной организации, несущими ответственность за разработку ПО. Данная методология это без преувеличения новый виток эволюции методологий разработки поскольку ориентирована не только на удовлетворение требований заказчика в жестко определенные сроки, но и повышение качества и стабильности продукта.

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

Источники

Управление проектами разработки ПО. Дисциплина «Гибкие технологии разработки программного обеспечения» автор: Д.Г. Шопырин

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

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

Рассмотрим некоторые основные методологии и средства, которые их используют.

SADT - методология структурного анализа и проектирования (Structured Analysis and Design Technique). Основана на понятиях функционального моделирования. Является методологией, отражающей такие системные характеристики, как управление, обратная связь и исполнители.

IDEF0 - методология функционального моделирования (INTEGRATION DEFINITION FOR FUNCTION MODELING). Применяется для описания рабочих процессов (Work Flow). Разработана на основе SADT. По сути одно и тоже.

DFD - методология моделирования потоков данных. Применяется для описания обмена данными между рабочими процессами.

IDEF3 - методология моделирования потоков работ. Является более детальной по отношению к IDEF0 и DFD. Позволяет рассмотреть конкретный процесс с учетом последовательности выполняемых операций.

IDEF1X - методология описания данных. Применяется для построения баз данных.

IDEF4 - объектно-ориентированная методология. Отражает взаимодействие объектов. Удобна для создания программных продуктов на объектно-ориентированных языках (например С++). Пока широкого распространения не нашла. Более широко сейчас используется UML.

UML - (Unified Modeling Language) язык визуального моделирования, основанный на объектно-ориентированном подходе. UML включает в себя двенадцать типов диаграмм, которые позволяют описать статическую структуру системы и ее динамическое поведение.

В настоящий момент к семейству IDEF можно отнести следующие стандарты:

IDEF0 - Function Modeling - методология функционального моделирования. С помощью наглядного графического языка IDEF0, изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков - в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы. Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique);

IDEF1 - Information Modeling - методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;

IDEF1X (IDEF1 Extended) - Data Modeling - методология построения реляционных структур (баз данных), относится к типу методологий «Сущность-взаимосвязь» (ER - Entity-Relationship) как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

IDEF2 - Simulation Model Design - методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. В настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN - Color Petri Nets);

IDEF3 - Process Description Capture - Документирование технологических процессов, IDEF3 - методология документирования процессов, происходящих в системе (например, на предприятии), описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 - каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3;

IDEF4 - Object-Oriented Design - методология построения объектно-ориентированных систем, позволяют отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;

IDEF5 - Ontology Description Capture - Стандарт онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация;

IDEF6 - Design Rationale Capture - Обоснование проектных действий. Назначение IDEF6 состоит в облегчении получения "знаний о способе" моделирования, их представления и использования при разработке систем управления предприятиями. Под "знаниями о способе" понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, "знания о способе" интерпритируются как ответ на вопрос: "почему модель получилась такой, какой получилась?" Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF6 акцентирует внимание именно на процессе создания модели;

IDEF7 - Information System Auditing – Аудит информационных систем. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF8 - User Interface Modeling - Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интефейсов в большей степени создают внешний вид интефейса. IDFE8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интефеса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфес для выполнения операции);

IDEF9 - Scenario-Driven IS Design (Business Constraint Discovery method) - Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие. Обычно, при построении моделей описанию ограничений, оказывающих влияние на протекание процессов на предприятии уделяется недостаточное внимание. Знания об основных ограничениях и характере их влияния, закладываемые в модели, в лучшем случае остаются неполными, несогласованными, распределенными нерационально, но часто их вовсе нет. Это не обязательно приводит к тому, что построенные модели нежизнеспособны, просто их реализация столкнется с непредвиденными трудностями, в результате чего их потенциал будет не реализован. Тем не менее в случаях, когда речь идет именно о совершенствовании структур или адаптации к предсказываемым изменениям, знания о существующих ограничениях имеют критическое значение;

IDEF10 - Implementation Architecture Modeling - Моделирование архитектуры выполнения. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF11 - Information Artifact Modeling. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF12 - Organization Modeling - Организационное моделирование. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF13 - Three Schema Mapping Design - Трёхсхемное проектирование преобразования данных. Этот метод определён как востребованный, однако так и не был полностью разработан;

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

Похожая информация.

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

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

Проектирование как основа формирования любой деятельности

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

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

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

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

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

• автоматизированное проектирование, основанное на взаимодействии ЭВМ и человека,
• автоматическое проектирование, выполняемое на промежуточных этапах без участия человека,
• ручное.

Подавляющее большинство проектов пока осуществляется по автоматизированному типу, а автоматическое проектирование применимо к относительно несложным объектам. Но и в этом соотношении доля участия компьютера постоянно растёт.

Подходы к проектированию

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

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

Конкретизация и интерпретация исходных идей системного подхода находит своё отражение в других производных подходах к проектированию:

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

В социальном проектировании все подходы к процессу принято разделять по критерию их ориентированности на 3 типа:

• с ориентацией на объект (объектно-ориентированные),
• с ориентацией на субъект (субъектно-ориентированные, или тезариусные),
• с ориентацией на проблему (проблемно-ориентированные).

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

Методы проектирования

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

• Графический метод .

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

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

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

• Макетно-графический метод .

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

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

• Автоматизированный метод (с применением электронной техники) .

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

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

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

Структура проектирования

Проектирование делится на процедуры, этапы и стадии. Проектирование сложных объектов включает стадии:

• научно-исследовательских работ,
• опытно-конструкторских работ,
• технического проекта,
• рабочего проекта,
• стадию испытания опытного образца.

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

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

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

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

При некоторых видах договора подряда функцию взаимодействия с проектными организациями берёт на себя генеральный подрядчик. Международные стандарты инжиниринга предусматривают несколько вариантов, среди которых самые распространённые соглашения – это договоры в стандарте EPC (Engineering Procurement Construction) и в стандарте EPCM (+Management). В первом случае контрактор предоставляет заказчику услуги по проектированию (а также по закупке оборудования и строительству) «под ключ». Во втором случае, контрактор занимается менеджментом этих процессов (в том числе, и менеджментом проектирования).

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

Глазычев В.Л.: Несколько слов, чтобы вам было немножко понятнее, с кем вы имеете дело. В команде, которая разворачивала работы в области проектирования и в области методологии, народ был с самого начала достаточно пёстрый. Мой древний приятель, (я надеюсь, вы с ним встретитесь) вышел из физики. Я когда-то кончал Московский архитектурный институт. Среди нас есть географы по происхождению. Единственное, кого почти совсем нет, это тех, кто по диплому называются философами. И Петр Георгиевич Щедровицкий кончал вовсе даже педагогический институт.

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

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

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

В школьных учебниках написано обычно много разных легенд про то, как Египет строил пирамиды. Гораздо правильнее перевернуть это сочетание слов и сказать: «Это пирамиды построили Египет». Система организации деятельности на формирование этих грандиозных сооружений, система организации труда, очень тщательно, очень тонко разведенного по разным специализациям, выступает как некий образец, в известном смысле, на все времена. И в выражении «пирамиды построили Египет» нет серьёзного преувеличения. Вот не далее, как в прошлом году, наконец раскопали некрополь, кладбище строителей пирамид. Реальное, не воображаемое. И одна из первых гробниц, уже сейчас в Интернете она предъявлена, можно посмотреть: очень трогательно, это гробница столяра, в которой одновременно представлены три его портретных изображения. Очень грубые, очень примитивные, но настоящие: где он маленький, где он юноша с пробивающимися усиками и где он зрелый муж. Как вы понимаете, если в гробнице представлена такого рода история персонажа, то все греческие байки про рабов, которые создавали пирамиды, наверное, разлетаются в пыль. Никакими рабами пирамиды построить было нельзя. Это было ясно и раньше, но сейчас просто появилось дополнительное подтверждение.

Знаете ли вы, что в организации процесса создания этих изумительных сооружений была впервые записана технология. Была сформирована система поощрения высоко производительного дофеодального труда, поэтому существовала система премий, которые выдавались лепешками, пивом, и прочим (денег же в Египте не было), была система расчленения на рабочие роты. Слово «роты» здесь наиболее точно отвечает делу. Каждой роте был придан не только врач, но и заклинатель змей от укусов. Иными словами, когда мы, не только оглядывая эти замечательные сооружения (мне это довелось делать, это достаточно сильно), но влезая под кожу процесса их создания, впервые мы сталкиваемся с тем, что некий выброшенный вперед как якорь, к которому можно притягиваться, мощный образ, имидж. В этом отношении имидж всегда является частью проекта, не обязательно основанием, но частью непременно, потянул за собой соорганизацию чрезвычайно сложной машины, составленной из десятков тысяч людей, в расчете на 10-15-20 лет непрерывного совместного производства. По крайней мере получается, что в этом отношении принципиальная проектная ориентация имеет, хочешь не хочешь, хороших пять с лишним тысяч лет истории.

Тем не менее, как ни странно, очень трудно найти книгу, которая бы называлась «История проектирования». У нас с вами бесконечное число томов посвящено истории науки, литературы, изобразительного искусства, философии, всего, чего угодно, а книг по реконструктивной истории проектирования по пальцам можно перечесть, а по-русски ещё пока нет ни одной. Почему? Почему не опознается особый тип организации мыслительной работы, которому уже пять с лишним тысяч лет? Сам по себе этот вопрос достаточно существенный, потому что, в конце концов, только к середине недавно завершенного века, само понятие «проект» оказалось вдруг опознано, вычленено, увидено как какая-то особая структура организации. Вопрос «почему» длинный.

Меня сейчас интересует другое. Бог с ними с пятью тысячами лет. Вот совсем недавно, в середине и конце 99-го года я был вовлечён в сооружение проекта, который был достаточно любопытен по структуре своей, поэтому я его постараюсь пошагово вам описать, тем более, что я был просто прямым носителем оного.

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

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

И вот тогда, сначала (по-русски нет точно такого слова, inspiration), была сформирована первая чёрточка, которая была способна или перерасти в проект, или не перерасти. И вот здесь я прошу вас на это обратить внимание. Когда говорят «проект», очень часто смешивают с ним то, что является просто ситуативной творческой находкой, увидел — сделал. В своё время мне приходилось отрабатывать долги за кооперативную квартиру, иллюстрируя журнал «Знание — сила », я с удовольствием делал его макет и картинки в него. Формирование таких картинок — классический предмет такого мгновенно вспыхивающего решения. Мгновенно, потому что времени нет, и вы не можете себе позволить месяцами думать, как положено говорить, выхаживать образ, и прочее. Картинка должна быть послезавтра, или ты «горишь» как профессионал. Возникали картинки, и некоторые из них были достаточно любопытные, и хотя общие черты, используемые в проектировании и в такого рода импровизационном художественном творчестве есть, но в действительности это совершенно разное. Такие картинки проектами не являются, и замысел этих картинок проектом тоже не является. А вот когда возникла такого рода вспышка, связанная с конкретной политической ситуацией, возникло то, что могло вырасти в проект, и выросло.

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

Было решено так: необходимо осуществить замещение задач. Задача, макро-задача, была вам знакома по недавней практике — прорыв в парламент силы, у которой не было ясно выраженной опоры. Практически не было денег, вернее, их было очень мало. Вам это тоже знакомо, тем, кто участвовал в недавней здесь политической компании, это хорошо ясно. Не было, собственно, когорты, не было ядра организаторов. Было только одно — понимание того, что необходимо заявить себя достаточно жёстко и сильно. И вот тогда возникла идея, способная превратиться в проект.

Идея заключалась в том, что выставим-ка мы конкурента Юрию Михайловичу Лужкову на выборах мэра города Москвы. Это был забавный ход, парадоксальный. И вот здесь я ввожу очень важную оппозицию. В логике традиционного научно-аналитического мышления затея была абсурдна и заведомо бессмысленна. Абсолютно жёстко схваченная конструкция, контролирующая огромные средства и пользующаяся очень широкой популистской поддержкой, реальной, невыдуманной. Юрий Михайлович Лужков — человек талантливый, кепку свою носит с достоинством, умеет играть в разные игры, обладает реальной человеческой, политической популярностью.

В этом, собственно, и был резон. Если бы это была никакая фигура, проходная фигура, какое-нибудь серое ничтожество вроде питерского губернатора Яковлева, то и игра против, «игра с» не имела бы существенного политического и культурного смысла. Как раз выбор сильного противника, к тому же не ожидающего вообще, что кто-то дерзнет выставить напротив его абсолютной доминантности некоторую альтернативу, в этом был весь секрет. И проект получил сразу название, точнее, сначала было только название — «Московская альтернатива ».

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

Слово есть: «Московская альтернатива». Есть несколько человек, готовые сыграть в эту игру, по разным соображениям. Сергей Владиленович Кириенко, по молодости лет, по разозленности на свои неполные 100 дней премьерства, понимающий опасность провалиться «в никуда» и быть забытым, ведь прошло уже достаточно много времени, — один из этих людей. Мой старый приятель Глеб Павловский — второй. Кстати, с Павловским мы когда-то начинали проект под названием «Мемориал», общество «Мемориал». Вот, и это тоже был проект достаточно интересный, драматический и просто часть моей жизни. И ещё несколько человек. Но ведь сказать слова — не значит ничего. Плюс средств заведомо ничтожно мало, и добыть их можно мало. Каким образом выражение «московская альтернатива» сделать не слоганом, не лозунгом, не выражением «вот, вы такие, а мы — альтернатива», а альтернатива — это что? Это означило соорганизовать иксы и игреки, потому что они были неизвестны заранее.

Проект и заключается в том, что расставляет не живых персонажей, которые есть здесь, сидят в зале, есть наши знакомые, родственники и все прочие, а функциональные иксы, игреки и зеты в определённую конструкцию, которая позволила бы выстроить действительный образ «московской альтернативы». Альтернативы чему? Альтернативы пирамиде власти. Альтернативы системе организации ценностей, развешивания приоритетов, ну, скажем, поставить здоровенного Петра І, да, но не делать ничего, чтобы люди не падали в обморок в метро во время перегрузки, потому что там плохая система вентиляции, и люди просто задыхаются.

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

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

Да, у нас нет средств на самостоятельное издание, нет средств на покупку эфира. Но у нас есть средства на создание интернет-сайта «Московская альтернатива». Много ли людей лазают на сайт такого рода добровольно? Конечно, немного. Но по должности, по обязанности туда лазают редакции изданий, и туда залезают те, кого вы атакуете. И вся проектная затея базировалась на одном абсолютно художественном допущении, это прилагательное здесь очень важно, художественном, отнюдь не научном. Голиаф, а московская конструкция власти — это Голиаф, опасается или может опасаться только юного тоненького Давила, который во-время залепит ему в лоб камнем из пращи.

Сам факт появления в виртуальном пространстве Интернета площадки, на которой начинается анализ действительного существования дел за вывеской под названием «Москва», должен был вызвать неадекватную реакцию. Реакцию возмущения и иронии. Если бы наши противники, наши оппоненты были мудрее, они бы могли переиграть этот проект. Они бы могли его просто не заметить. Если бы они его проигнорировали, мы бы проиграли. Но точный расчёт был на психологию, на художественное восприятие действительности, а мэр Москвы, Юрия Михайлович Лужков — художник в душе, поэтому и возникают все эти художества в городе. Власти не могли этого стерпеть. И что начали? Начали отвечать, начали огрызаться. С этого момента они попали в ловушку. По одной простой причине. Голиаф тяжел и мощен. Бюрократическая система означает проведение сигнала, любого сигнала в течение нескольких дней, правда? Он не может сработать в секунду. По определению, сложная бюрократия должна провести сигнал снизу вверх, сверху вниз, промежуточные уровни должны его фильтровать. А маленький Давид, в виде группы проектантов, обладает мгновенной реакцией, и поэтому как только выходит статья или радиовысказывание с их стороны, ровно через 45 минут появлялся ответ. Соответственно, большая машина начинала все время стрелять по тени, по хвосту, а юркая машинка уже давно убежала вперед.

Возникла система, которая должна была породить постоянно действующую, подогреваемую интригу. При малых деньгах вы можете работать только на интриге. Более того, соединив интернет-сайт с горячей линией по телефону, а это небольшие деньги, мы получили шанс выходить на действительные источники информации, что входило изначально в проектную схему. Наш доклад по проблемам лужковской Москвы публиковался частями каждую неделю, что также было просчитано: очень важно было порционирование информации, что позволяло проводить еженедельный же брифинг для СМИ. Я опускаю множество деталей, вроде того, что мы верно сориентировались на силу неприязни ельцинской России к Москве, и потому анализ хостинга показывал: региональные и местные пользователи залезали на наш сайт чаще и больше, чем московские. Так или иначе, хотя официально мы набрали чуть более 12% голосов (по нескольким округам, где велся настоящий контроль, было было 30%), СПС прошел в парламент. Более того, в последующие полтора года московские власти более-менее верно отреагировали на дюжину ключевых претензий, содержавшихся в нашей программе.

Выйдем за рамки актуальности и собственные горизонты.

Всем известны американские автомобили «Форд». В 50-е годы у Форда начали падать продажи. Для выхода из сложившейся ситуации понадобилось внешнее отношение, видение этой компании в совокупном контексте культуры. Совершенно конкретный человек по имени Джорж Нельсон, не имеющий отношение к Форду, предложил вещь, которая сначала вызвала полный шок. Вся его идея заключалась в следующем. Почему вы не можете продать свои автомобили? Потому, что они надоели тому слою, кто покупал Форд. Люди, так сказать, средне-нижних доходов, в основном молодые профессионалы, младшие квалифицированные работники. Вы им надоели! Нужно то, что даст им ощущение свежести и новизны. Что было тогда ощущением свежести и новизны в начале 60-х годов? Начали выходить фильмы серии об агенте 007, Джеймсе Бонде. Он ездил в первых сериях на роскошной, специально сделанной машине с совершенно драгоценными спортивными колесами. Джорж Нельсон нарисовал молдинг, изображающий спицы на штампованных дисках. Он перестроил образ типового фордовского автомобиля, психологически опознаваемый как родственник машины Джеймса Бонда. Продажи форда «Мустанг» подскочили на 750, а потом на миллион автомобилей.

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

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

Вопрос: Есть ли какие-то этапы разворачивания, осуществления проекта?

Глазычев В.Л.: Это очень хороший вопрос. Почему? Потому что есть опасность спутать собственно проектную парадигму, которая предполагает живую машину. Живая машина состоит из живых людей. Если вы будете воображать себе их как отливки, вы мгновенно соскочите из проектной модальности в классическую схему линейного управления, где все выстраиваются по уставу. Поэтому «все предусмотреть» противоречит самой логике проектной ориентации. Это как в слаломе. Вы можете обойти под таким углом, под таким, с большим радиусом, с меньшим радиусом, но вам надо обойти эту вешку. Способ обхода этих вешек, это вопрос живого наполнения традиций. В этом есть принципиальное отличие от классически научной, прагматической парадигмы. Если вы ставите проектно-ориентированную задачу, вас будут интересовать не коэффициенты, вас будут интересовать правила поведения поля ценностей. Вы залезаете в совершенно чужой карман и начинаете шарить в нем для того, чтобы найти тот инструмент, с помощью которого вы имеете шанс, управляя чем-то, выстроить проектную машину изменения ситуации. Прогноз жесток, хотя и вариативен. Проект жесток по организации, но абсолютно мягок по отношению к взаимодействию и с контекстом, и с человеческой машиной, соответственно, он выстраивает план собственной реализации, тогда как сам скорее вырастает как деревце.

Есть ещё вопросы?

Я бы вернулся к тому, что повесил в самом начале. Как же так? Почему проектная деятельность, легко прослеживаемая на огромной толще человеческой истории, не обозначена как равноценная, равноправная с искусством, с философией, с наукой. В значительной степени этот вопрос сам в себе и несет ответ. Потому что опознание не происходит само. Даже если вы его вывесите, но не созрела культурная ситуация для его восприятия, оно не схватывается. Если занять чисто методологическую позицию, и задаться вопросом, а есть ли какой-то порядок в движении того, что можно назвать ключевыми словами. Не те key words, которые машина распознает автоматически, а те, на которых выстраивались гигантские здания человеческой культуры. Это страшная вульгаризация, но для понимания она мне необходима.

Смотрите. Великая античная культура. Ключевое слово в этой культуре — рок, судьба. Это не та судьба, которая трагедия, которая фортуна. Это рок, который одолеть нельзя. Затем возникают мощные монистические культуры: христианство, ислам. И слово Бог выходит на ту позицию, которую занимало слово рок. Судьба осталась, но теперь все крутилось вокруг слова Бог. Все центрировалось на этом ключе.

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

Как только возникло слово «общество», возник шанс для появления слова «культура». Не как признак: культурный или некультурный человек, есть такой бытовой термин. А понимание культуры как сложной машины, производящей, воспроизводящей, передающей и реализующей ценности. Это уже абстракция достаточно высокого порядка. Значит, сначала должно было возникнуть слово «общество», чтобы возник шанс на опознание проектирования, которое осуществляется в обществе и в материале культуры. Обскакать историю невозможно, и только в ретроспективе вы можете обнаружить мощные проектные ходы, проектные способы замышления движения к результату.

Обнаруживать, что крестовые походы могут быть описаны как проект. Это не значит, чтобы они были проектом. Но в ретроописании вы можете получить чрезвычайно интересную схему. Станьте в позицию Господа Бога или его земного воплощения, и захотите придать новый облик застывшей, не имеющей шансов на качественный скачок абсолютно мужественной культуре раннего средневековья. Вы бы захотели радикально переструктурировать всю систему ценностных рядов. Вам понадобилось бы внешнее основание. Крестовые походы описываются как подобный проект. Пусть эти олухи идут завоевывать Гроб Господень. И пока эта вся шпана уйдет из Европы, женщины, которые остались на хозяйстве, реструктурируют всю культуру. Что и произошло. Возникла готика, культ Девы Марии и т.д.

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

А что такое США? Их декларация о независимости — как проект, созданный абсолютно конкретными людьми. Адамс и Джеферсон монтировали свой образ, свой продукт из того, что было под рукой. А что было под рукой? Классические античные тексты, опыт уже нарывавшей французской революции, стремление опереться на живое чувство народа, а в ход могло идти все что угодно, вплоть до абсолютных фальшивок, вроде т.н. Бостонского чаепития. Значит, проекты уже выстраивались.

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

Чтобы было понятней. Сейчас я играю с несколькими своими друзьями в занятный тип деятельности. Формально это называется Центр стратегических исследований Приволжского Федерального Округа . Почему Приволжского совершенно понятно. Уже пройдя некий путь вместе с Сергеем Кириенко, как-то глупо бросать все на пол-дороги. Судьба поставила его в очень любопытную позицию рамки, не имеющей содержания. Идея округов, кроме того, что немного нагнуть губернаторов, никакого содержание не имела. Это ситуация для включения проектной работы.

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

Что такое новая граница. Она есть, её нет. Она есть, но в сознании людей её нет. Как с ней работать? Если мы зададим этот вопрос профессионалам в фуражках, которые называются пограничникам, они пробубнят статью закона или устава, по которая границей является линия не имеющая толщины… В логике военно-инженерного мышления граница есть некая линия, отмаркированная в натуре — а она у нас не отмаркирована… каковую охраняют и т.д. Охраняют где? В каких точках? По всей линии что ли?

Схема линейного управления, а любая военная схема управления является линейной, то есть по уставу, по предписанию, по долженствованию. Что это означает? Есть понятие застава. Застава вроде бы где? На границе. Но физически она же не на границе. Может находится за 26 км от границы. Я видел такие. Совершенно параноидальная ситуация. Это примитивное видение.

Второе видение, что предполагает? Если удерживать само понятие, которое «живет» только в логике линейного управления, вообще ни о каком проектировании речь идти не может. По одной простой причине: линейное управление отторгает любую попытку изменения процедур. Подчинение сверху вниз. В единичных случаях обратный сигнал. Это не предполагает какое-либо изменение.

Значит, правило номер один в методологически окрашенном проектном сознании — взвесьте, оцените на зуб ключевое слово. Усомните ключевое слово. За этим усомневанием может последовать иная операция. Операция замещения другим ключевым словом, вашим ключевым словом, которое входит в тело вашего будущего проекта. В моем случае, смотрите, лёгкая подтасовка, вместо слова «граница», появляется слово «приграничье». Другое даже по роду. Граница — женский род, приграничье — средний. То есть, что-то, что около границы. Это некое понятие, приграничье, обладающее чувственной очевидностью. Любой человек мгновенно реагирует на содержание этого понятия. Понятно о чем речь.

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

Что происходит дальше? Пространство приграничья не имеет пределов, пока вы их не задали. Если мы с вами тянули, даже на уровне понятия, нечто, что вовлекает в себя взаимодействие живых людей, а значит, и живых оргструктур, соорганизованностей? Как только вы ввели новое, объемлющее понятие, вы получаете шанс работать с этими соорганизованностями. Смотрите, я же не могу сформулировать такую понятийную конструкцию — развитие границы. Меня не поймут. Я и сам себя не пойму. А развитие приграничья — запросто. Значит, понятийные конструкции здесь оказываться теми вешками слаломного спуска, о которых я говорил раньше. Заместить понятие необходимо. Если не заместили, проиграли заранее. Потому что существующие линейные конструкции управления сильнее вас. Переиграть их можно, только вклиниваясь между ними. Проектное сознание работает на том, что врезается в трещины больших массивов, а они всегда имеют трещины.

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

Проектная деятельность работает с человеческими машинами. Значит, сильная проектная конструкция может иметь шанс на воплощение, хотя бы только номинально встраиваясь в готовую линейную систему управления. Это один из вспомогательных конструктов. Следующее — это живые люди, деятельность которых зациклена на реальных проблемах приграничья. Эти проблемы являются питательным узором, на котором вы можете встраивать в проектную конструкцию совершенно другие ценностные структуры. Сама мембрана, само взаимодействие, само соседство, само взаимопроникновение является ценностью, которая несет рефлективность обмена, операций. Это должно быть переосмыслено. Каркас пространства должен быть реорганизован так, чтобы служить по возможности плотным забором для нежелательных проникновений и свободной мембраной для желательных. Грубо говоря, если зерно из Казахстана везут менять на «левое» горючее это хорошо, а если везут наркотики — плохо. Это простенькие вещи, но как только они схвачены как живое движение, следующий шаг вашей работы будет вопросом — что может стать каркасом новой границы? Специалисты в фуражках вам не ответят на него. Это не по их части. Кто может ответить на этот вопрос? Нет такой отрасли знаний, которая бы ответила на этот вопрос. Действительность, складывающаяся лишь несколько лет по определению не может быть предметом научного познания. Предмет меняется быстрее, чем вы его опишете. Почему социологи беспомощны? Потому, что жизнь меняется быстрее, чем они успеют оформить результаты.

Отсюда правило номер три. Ключевое. Собственно проектное мышление. Проектные конструкции. Методология проектного отношения имеет шанс возникнуть там, где есть принципиальный дефицит иных форм знаний . Знания такого нет. Можно сложить руки и ничего не делать. Можно заниматься сугубо спазматическими действиями по вдохновению. Можно выстраивать макропроектную действительность. Я начинаю сейчас новый тип проектно-аналитической работы. В чем она заключается? Только часть проектного замысла превращает эту работу в действительность. Я сейчас провожу семинары. Эти семинары показывают: 1) Произошла кадровая революция, неопознанная и неосмысленная. Уровень мышления руководителей низового звена подскочил на порядок. И тут возникает, как говорит Генисаретский , проектная готовность. Человек ещё не умеет проектировать, но он уже готов, чтобы его втягивали, у него уже достаточно широкий горизонт. 2) За два дня интенсивной работы можно получить 4-5 дееспособных, конкретных проектов, реализуемых, в принципе, здесь и сейчас. За этим следует принципиально важная вещь. Если в нескольких местах можно «наколоть» практику таким образом и получить результат, значит, мы получаем принципиально новую конструкцию для формулирования проектной идеологии. Если ещё недавно мы должны были рассчитывать исключительно на людей из столицы, если на самом деле мы можем рассчитывать на людей, относящихся к элите на районном уровне, это значит, что всю систему проектной работы надо переструктурировать. Она строится уже не на отдельных тренингах, а на создании сети, на сетевом принципе. На задействовании формирования человеческих машин, растянутых в огромном пространстве, взаимодействующих напрямую.

Как только вы вводите сетевую конструкцию в схему проектного метода, вы радикальнейшим образом меняете парадигму организации собственного мышления. Потому что классическая досетевая, проектная идеология тоже линейная, тоже диктаторская. Несколько умных, оснащённых людей способны реализовать свой проект, эксплуатируя разные интересы и устремления самого разного круга людей. Это классическая схема проектирования. Мы в ней вырастали. Описание пока существует только на нее. Как только вы вводите сетевую конструкцию в основание проекта, у вас меняется все. Сетью нельзя управлять — по определению. У сети нет якорной верхушки —по определению. В нее можно только вбросить импульс. Как этот импульс будет претворен, соорганизован, переосмыслен, мы увидим. Гигантская возможность, которая открылась только сейчас, но для того, чтобы этой возможностью воспользоваться, необходимо многое понять.

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

И последнее. Поскольку мы имеем дело с человеческой машиной, постольку мы должны научиться работать с пустыми рамками, только векторально связанными рамками, а не пытаться изображать предмет. Если я, вместо фермеров, сочиню проект как им организовать обслуживание их железок, которыми они пользуются, то я могу его сочинить, но шансы его врастания в жизнь нулевые. Если этот проект создан вместе с оценкой людей из местных сельсоветов и т.д., тогда у них возникает представления горизонтальной связанности, что у соседей может быть общий проект, не идущий сверху. Тогда вы создаёте рамку, в которой один обнаруживает, что у него тысячи здоровых мужиков уволенных из офицеров, которым нечего делать, а у другого давно вымерли последние механизаторы и некому чинить эти железки. Тогда вы создали рамку, в которой они это обнаружили и начинают нащупывать способ взаимодействия. Значит мои проекты становятся вовсе не железом, вовсе не способом борьбы с сельской беспризорностью, а превращаются в создание рамки, в создание цепи этого типа семинаров, способов их проведения так, чтобы вовлечённые в них люди перестанут стесняться мыслить и бояться говорить. Я должен спроектировать эту цепь, вовлечь новый тип чиновников в эту цепь. Есть у нас эти новые чиновники, которые надзирают на уровне округов, у них нет власти, но есть авторитет. Молодые и очень интересные люди. Часть моего проекта заключается в следующем. Я приглашаю на семинар федерального инспектора области, в которой проходил семинар, инспектора области, в которой проходит семинар, инспектора области, в которой будет семинар. Происходит скользящий процесс обучения этих новых чиновников, не встроенных в обычную систему управления и становящихся узлами нашей сети проектного способа мышления. Где здесь критерий успешности проекта? Вообще, где критерий успешности проекта, реализуемого в действительности? Только в одном. Если его автор становится невидимым. Если действительность выталкивает автора за ненадобностью, проект успешен. Если автору необходимо оставаться внутри, чтобы все скрипело и двигалось, значит, проект неудачен.

Вопрос — Вы говорили о проектной готовности. А что, если нет времени для зондирования и подходит момент, когда проект должен сработать, либо не сработать? Что в этом случае делать? Например, выборы.

Глазычев В.Л.: Я скажу жёстко, поскольку я переживал подобную операцию. В принципе, проект «Озимое поколение» имеет достаточно большие шансы на реализацию. Но он только сейчас их приобрел. Только сейчас. Потому что только дуриком можно было проскочить через систему просчета при неконтролируемых избирательных участках. Только совершенно нелепым фартом можно было бы одолеть. Независимо от того, какие бы вы усилия вкладывали, без 100 миллионов — и не гривен отнюдь, решить эту задачу невозможно. Но вы и ваши коллеги добились огромной победы. Потому что до того как формально произошел подсчёт голосов, абсолютное большинство традиционно мыслящих экспертов оценивало шансы на уровне социологической ошибки. Даже те 2,4%, которые формально пропустила здесь казённая машина, это на порядок выше, чем то, что давали эксперты. Это колоссальный прорыв. Сейчас время развертывания своего проекта. Такого рода проект не спазматический. Тот пример, который я вам приводил, он же был замещающий. Сосредоточение всех небольших сил на одной точке для того, чтобы внимание к этой точке потянуло за собой шлейф вокруг.

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

Под проектной готовностью я имею в виду достижение нескольких специфических качеств, разочарованности во всех шаблонных формах. Эта разочарованность должна быть полной. Возникает проектная готовность. Я встречал ситуацию, где со слезами на глазах страдали бывшие советские руководители говорили: «Госзаказ, госзаказ…». Они всё ещё верили, что будет госзаказ. Тогда ещё нет проектной готовности. Пока есть вера в то, что завтра кто-то даст госзаказ, зачем проектное мышление?

Проектная готовность — это некие формы образованности, которые не есть диплом. Образованность, которая рассеяна в воздухе, которая дана тем, что вся страна, будь то Россия или Украина, научились считать, считать деньги. Эмансипирующее значение этой процедуры грандиозно и недоосмыслено. Когда понятие семейного бюджета для миллионов людей стало не абстрактной категорией, а конкретной. Когда в этой процедуре происходит сравнение цена-качество. Когда слова-выручалочки уже перестали действовать, есть проектная готовность. Она есть независимо от вас. Её можно только проверить. Я ее проверяю, сознательно проводя свои семинары в точках, удаленных порядка 200 км от областного центра, на предельной периферии регионов.

Вопрос — Человек ничего не делает просто так. Какова ваша миссия пребывания на Украине? Это часть проекта?

Глазычев В.Л.: Я это делаю просто так, для удовольствия. А если говорить абсолютно серьёзно, то здесь есть две вещи. Первая причина. Меня об этом попросил мой друг и товарищ Петр Георгиевич Щедровицкий. Этого уже было бы достаточно. В нашем кругу единомышленников так принято. Я не буду долго допрашиваться: зачем. Надо — значит надо. А вторая причина более глубокая. Нет ничего более важного, чем понимание и выработка проектной модальности отношений России с Украиной. Украина это ваш вопрос, но и для России более существенного вопроса, чем Украина, нет. Все остальное — чепуха собачья. Это, к сожалению, недоосмыслено многими людьми в России.

Вопрос — Вы упомянули проект «Озимого поколения». Провальный проект. Есть ли смысл на месте проваленного проекта строить какой-то новый: с теми же людьми, с теми же знаками и т.д., или чаще приходиться ориентироваться на создание совершенно нового проекта? Насколько негатив проваленного проекта может повлиять на следующий проект?

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

Если посмотреть, сколько набрали «озимые», а это 700 тысяч голосов, то, господа, это безумно много. Если 70 тысяч, т.е. 1/10 из них сделать каркасом сетевого строительства, можно и горы свернуть. Как? Это уже не вопрос этой лекции.

Вопрос: Правильно ли я поняла, что для вас не существует провальных проектов? То есть любой проект можно переформулировать в поражение, которое будет рассматриваться двояко: для одних поражением, а для других достижением.

Глазычев В.Л.: Это очень хороший вопрос, на который разные персонажи дадут разные ответы. В моей позиции, да, провальных проектов не бывает. Потому что из каждого независимого формального результата извлекается материал для других. Но это моя точка зрения. Моя позиция дистанцированная. Проектно-методологическая. Разумеется, для того, кто ставит все на одну карту и играет прямо в игру под названием политика или бизнес, цена неудачи стремительно возрастает. Хотя плюс в этой неудаче тоже есть. Есть одна деталь. Вы знаете в чем была проектная идея Генри Форда? Очень многие по ошибке считают, что это была низкая цена машины. Это не верно. В том же Детройте было около двух десятков мастерских, которые изготовляли машины по меньшей цене, чем это делал Форд. Гениальность его заключалась в том, что он, не называя ещё того по имени, первым ввел в оборот понятие цена-качество, как число признаков предмета соотнесенных с ценой. Так же он увидел тип потребителя, который никто эмпирическим образом увидеть не мог, потому что тот не был проявлен. Он увидел в фермерах покупателей автомобилей, тогда как все остальные считали автомобиль предметом роскоши. От этого был только один шаг до признания собственных рабочих покупателями собственных автомобилей.

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