СХЕМА ТЕХНОЛОГИИ ПРОГРАММИРОВАНИЯ
Первое представление о технологии программирования было оформлено в ММК в 1975—76 г. В предыстории работ, позволивших сделать такое оформление, можно выделить две линии разработок: разработки по методологии организации НИР и по теме -Проблемы и проблематизация». *
В 1975—76 г., читая курс лекций по педагогике для студентов МОГИФК, Г. П. Щедровицкий вынужден был дать студентам достаточно простое средство для составления программы курсового исследования, когда обнаружил, что студенты, получив тему курсовой работы, испытывают большие трудности в определении содержания работы. Отметим, что ситуация подобных затруднений знакома, вероятно, не только студентам, но и практически каждому научному сотруднику, когда при составлении программы или ТЗ на НИР он должен до выполнения исследования ответить на вопрос о том, какие именно результаты он собирается получить.
Мы специально подчеркиваем этот аспект простоты и даже технологичности необходимого представления: его освоение и использование не должно было требовать от студента большой методологической подготовки, оно должно было годиться для освоения при минимальном обучении. Оформленная методика требовала от студента соотнести тему исследования, с одной стороны,— с целями и проблемами, ас другой,— с представлением об объекте (объективном содержании) предстоящего исследования. Примерно в это же время (1975—76 гг.) в ММК было оформлено представление об искусственной, технической работе с проблемами. Толчок к такому оформлению дала подготовка к Всесоюзному симпозиуму -Логика научного поиска» (Свердловск, 1977 г.).
Для работ по истории и методологии науки термин -проблема» является широко используемым, прежде всего, для фиксации достижений в определенной области науки. Истории науки в таком анализе движется как бы в -обратном» направлении относительно «хода событий»: сначала он обнаруживает появление новых направлений исследований, затем он определяет, какими новообразованиями, открытиями были обеспечены эти новые направления, и уже затем пытается оформить всю предыдущую работу исследователей как целенаправленное решение «проблемы». Установка методологии на искусственное и целенаправленное развитие предметно-профессиональных областей, в том числе научных, выдвигала вопрос о механизмах такого развития. Использование проблем и проблематизации как механизма развития требует такого изменения содержания понятия «проблема», чтобы оно могло из средства ретроспективной фиксации опыта превратиться в средство перспективной (прожективной) организации работ по развитию, Деятельностная точка зрения в этом вопросе предполагает определение того, в какой деятельности (не исторической, а прожективной) существуют проблемы. Мы уже отмечали, что такой деятельностью (или таким мышлением) не может быть проектирование (только проектирование)— это потребовало бы отказа от «основных принципов и методов проектной работы, в частности, отказа от принципа однородности действительности проектирования. Возможность работы проектировщика с неоднородными, конфликтными, разрывными ситуациями требует создания вокруг него целого комплекса обеспечивающих работ (а частности, комплекса технических и организационно-технических исследований /а/), в ряду которых проектирование становится лишь частным процессом. а вся « проблемная» нагрузка падает на ситуативную coopганизацию такого комплекса. Момент ситуативное™ и большой неопределенности работ при решении проблем неустраним: если бы мы знали, как двигаться к решению проблемы и в чем состоит оно — не было бы и «проблемы», мы имели бы дело с «задачей».
В стратегии ограничения области применения проектирования был дан другой ответ: такой прожективной деятельностью может оказаться программирование. Этот ответ с точки зрения ситуации в области формирования программирования означал, что наряду с требованиями-заказами на программирование со стороны сферы ОРУ, появляется новое, дополнительное требование со стороны сферы методологии: программирование должно обеспечивать работу развития за счет искусственной, технической работы с проблемами.
Выделим некоторые принципиальные результаты, полученные в работах по технологии программирования /II/. Во-первых, программирование было представлено как процесс определенного типа. Во-вторых, были выделены пять типов технологических единиц, входящих в состав технологии программирования: (1) анализ ситуации, (2) тематизация, (3) целеполагание, (4) постановка и решение задач, (5) проблематизация. В-третьих, был поставлен вопрос о средствах программирования как о средствах реализации каждой из выделенных технологических единиц. В-четвертых, были выделены основные типы организованностей материала, которые оформляются и преобразуются в процессе программирования: описания ситуаций, темы, цели, задачи, проблемы. В-пятых, были оформлены представления о процессах движения и трансформации организованностей материала при программировании («цель как процесс», «задача как процесс»,… «программа как процесс»). В-шестых, была предложена типология программ — на основании того, какие результаты программирования в них оформляются: программы целей, программы тематические, программы задач, программы проблем. «Полная» программа была представлена как состоящая из подпрограмм всех этих типов.
Не анализируя более подробно все эти результаты, остановимся на вопросе о представлении программирования как процесса определенного типа: не линейного, разворачивающегося по одной оси времени, а как бы «двумерного», разворачивающегося «разу по двум осям времени: горизонтальной и вертикальной. (см. сх. 4). На уровне простого технологического образа можно представить, что в горизонтальном направлении происходит параллельное движение пяти конвейерных лент, выделенных по типам организованностей материала: лента описаний ситуации, лента целей и т. п. На каждой ленте, по отношению к попадающему на нее материалу, применяются технологические операции соответствующего типа: производится преобразование одних тем в другие, производится изменение целей, переформулируются и решаются задачи и т. п. А по вертикальной оси происходит как бы переброс обрабатываемого материала с ленты на ленту: цели переводятся в задачи или проблемы, описания ситуации — в формулировки целей и т. п.
В чем состоит принципиальное отличие «двумерного» процесса программирования от линейного? На основе линейного принципа организации мы могли бы получить два варианта технологий. Первый соответствует пяти параллельным независимым процессам преобразования целей, тем, задач и т.д. (сх. 5а). По такому принципу организованы технологии построения «деревьев целей», «иерархии задач» и т. п. в «целевом программировании» /1/. Независимость этих процессов означает, в частности, что в каждом из них мы имеем однородную действительность: действительность целевую, тематическую и т. п. Линейность этих процессов означает отсутствие «обратных связей», т. е. последующие этапы работы и их результаты не влияют на предыдущие. Идеи «обратных связей», «возвратов», «циклов» требуют уже двумерного представления.
Отметим один момент, важный для сопоставления программирования и проектирования: задание однородных действительностей позволяет нам использовать в организации каждого в отдельности линейного процесса проектный подход. С этой точки зрения, существующие методы «целевого программирования» правильнее было бы называть «целевым проектированием». Но для того, чтобы остаться в рамках только проектного подхода, необходимо выбрать одну из этих действительностей (что и делается, по-видимому, в «целевом программировании»). Введение разнородности действительности, охватывающей одновременно все пять процессов -~ требует применения новых средств. По-видимому, этот момент является одним из наиболее принципиальных при сопоставлении проектирования и программирования: программирование работает с принципиально разнородными действительностями. Везде, где нам удается «гомогенизировать» действительность — мы можем рассчитывать на применение проектного подхода (в стратегиях «среднесрочного» или «перманентного» проектирования). Как показывает опыт программирования в орг-деятельностных играх, разрывные, конфликтные, комплексные и т. п. ситуации не могут быть адекватно представлены в однородной действительности («в плоских схемах»).
Второй вариант линейной технологии мог бы быть представлен как последовательность технологических этапов, соответствующих типам технологических единиц (сх. 6). Как показали попытки осуществления программирования в ОДИ. реальный процесс программирования не удается организовать при таком жестком членении технологических этапов (по крайней мере, при имеющихся сегодня средствах): осуществляя анализ ситуации, например, нам приходится обращаться и к определению целей, и к проблематизации, и т. п.,— т. е. забегать вперед; в свою очередь, занимаясь постановкой и решением задач нам приходится возвращаться и к анализу ситуации, и к тематизации — изменяя ранее полученные в этой работе результаты. А это значит, что представлять такой процесс линейно — значит вводить очень неадекватную идеализацию. Отметим, что на уровне общих целей и даже практики работы подобные требования к характеру процесса программирования осознаны, безусловно, не только в ММК (см., например, /13/). В методологии сделано другое: найдены средства представления этого процесса как объекта теоретического мышления.
Двумерное представление процесса программирования позволяет нам, во-первых, избежать проблемы «линеаризации», а во-вторых, оно задает принципиальную действительность программирования. Идея двумерного процесса намного богаче и сложнее, чем это было представлено в нашем простом технологическом образе. Чтобы избежать чрезмерно упрощенного понимания этого образа, при котором может потеряться одна из основных, базовых идей программного подхода ММК, мы выделим еще несколько принципиальных моментов. В двумерном представлении иначе, чем в линейном, задается операциональные содержание технологической единицы. Технологическая единица «целеполагание» содержит и «горизонтальные» операции преобразования одних целей в другие, и «вертикальные— преобразование целей в задачи, целей в проблемы, целей в описание ситуации и т. п. Суммарное преобразование при описании технологической единицы должно выглядеть как «диагональное» движение, имеющее две компоненты (сх. 6а).
Эта идея выглядит на абстрактном уровне понятной, если мы применим аналогию о представлении в механике движения в двумерной системе координат. Но эта простая картина резко усложняется, если мы попытаемся представить, что при таком диагональном движении происходит с преобразуемым материалом. Что это означает, что цель одновременно преобразуется и в другую цель, и в задачу? Чем является суммарный результат такого преобразования? Потому что механика не описывает процесс преобразований материала: перемещающееся в евклидовом (ньютоновом) пространстве тело не подвергается преобразованию. В эйнштейновской механике картины движения резко усложняются в связи с тем, что масса тела (всего один параметр!) зависит от скорости его движения. Представить эти процессы на уровне обыденного сознания уже невозможно. Парадоксы, в которые попадает обыденное сознание в мире двумерных процессов — мире программирования, намного сложнее. Методологический подход к анализу подобных парадоксов заставляет нас искать основания парадокса не в самой картине движения, а в средствах изображения. В данном случае парадоксальность ситуации может быть снята за счет использования средств системного представления объектов. Используя результаты разработок в ММК по категории системы /б/, можно сказать, что действительность программирования, представленная системно, должна был» многослойной: нам приходится представлять отдельно, но состыковано слои процессов, функциональных структур организованностей материала (морфологии), материала и т. д. При этом изображение объекта в каждом слое будет отличаться от изображений в других слоях. Приведенное нами «диагональное» изображение технологической единицы должно быть отнесено к слою процессов. Следы преобразования организованностей материала следует искать в слое морфологии. В этом слое мы не обнаружим «диагонального» следа, потому что умеем оформлять материал программирования именно как цели. проблемы, задачи и т. п. Поэтому следы преобразования материала в технологической единице мы «увидим» только по вертикальным и горизонтальным составляющим: в виде двух разных следов (сх. 66). А в слое материала мы при этом наблюдали бы процесс «удвоения» (-раздвоения-) материала,— для двух разных преобразований в слое морфологии (сх. 6в).
Таким образом, двумерные схемы программирования обязательно предполагают использование средств системного подхода. Безусловный интерес представляет вопрос о различии техник системной проработки проектной и программной действительности.
Выделим еще один принципиальный, на наш взгляд, результат. В двумерном программировании принципиально новое — процессуальное — содержание приобретают понятия -цель», «задача», «проблема» и даже «программа». В целевом программировании /1/ процедура разбиения целей на «подцели» позволяет дать структурное (точнее структурно-составное) представление цели. Это представление статично: несмотря на возможность продолжения процедуры разбиения, содержание целей верхних уровней логически не зависит от этого продолжения. В двумерном программировании все организованности материала подвергаются преобразованию, а разных технологических единицах, их содержание непрерывно трансформируется («горизонтальные» сдвижки) и перефункционализируется (вертикальные сдвижки). Здесь перевод «цели 1» в «цель 2» означает изменение исходной цели. а не процедуру разбиения на компоненты. Здесь перевод цели в задачу может сопровождаться кардинальным изменением описания ситуации и т. п. Сборка результатов процесса программирования, остановленного в разные моменты времени даст разные программы. Мы вынуждены говорить о процессах (точнее, использовать категорию процесса), если хотим сделать фокусировку на целевом или проблемном содержании программирования, «цель как процесс», «проблема как процесс» и т. ч.
Уместны вопросы: когда следует прекращать, останавливать процессы программирования? Когда следует считать, что цель определена? В каждой игре по программированию эти вопросы очень остро ставятся участниками при определении результатов игры. С деятельностной точки зрения, эти вопросы некорректны: не указано, в какой деятельности и с какими функциями будет употребляться результат программирования. Программирование должно дать программу (и отдельные ее составляющие, .например, цели) как средство ситуативной организации. Поэтому вопрос об остановке процесса программирования должен иметь ответ не обобщенный, а ориентированный на конкретную ситуацию употребления программы. Программа в своих средствах, своей специфической действительности (через определение целей, задач и т. п.) должна так прорисовать эту ситуацию, чтобы в ней можно было продолжать движение, остановленное из-за чрезмерной неопределенности ситуации. Эта прорисовка не должна быть, вместе с тем, избыточно конкретной, детальной. Степень конкретности должна, очевидно, соответствовать степени статичности ситуации. Чем динамичнее ситуация, тем менее определенными должны быть средства организации.
Отметим еще одно обстоятельство: ситуации — это всегда чьи-то ситуации (персонально), поэтому программы — это всегда чьи-то программы. Понимание этого обстоятельства позволило уже для программирования в ОДИ-1 избрать стратегию самопрограммирования: программу НИР разрабатывал коллектив, который должен был по ней работать. Можно ли разрабатывать программу для других? Можно ли за других определять их цели? В каждой игре по программированию точки зрения участников на этот вопрос разделяются. Если программу можно разрабатывать только для себя (программирование есть самопрограммирование), то может ли программирование существовать как профессия? В чем могут состоять функции такого профессионала относительно работ по самопрограммированию?
От бытового термина – к понятию.
Опыт формирования сферы проектирования
Первые сопоставления программ и проектов
Схема технологии программирования
Программирование и методологизация
(С. Наумов. Представления о программах и программировании в контексте методологической работы. — Журнал «Кентавр» №1 –1991)
__________
Для философствующих конфликтологов
Конфликтология и конфликты