На информационном ресурсе применяются рекомендательные технологии (информационные технологии предоставления информации на основе сбора, систематизации и анализа сведений, относящихся к предпочтениям пользователей сети "Интернет", находящихся на территории Российской Федерации)

Свежие комментарии

  • vg avanesov
    Юля, а вот схемку, интересно, сюда никак не выложить?Г.П.Щедровицкий. ...

Г.П.Щедровицкий. Проблемы и проблематизация в контексте программирования процессов решения задач 2

 

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

 

И это, простое на первый взгляд, соображение сразу же заставляет нас развертывать эту кооперативно-коммуникативную схему и вводить в нее еще дополнительные позиции: 1) исследователя (или исследователей); 2) оргпроектировщика, расставляющего исполнителей по определенным местам; 3) технологов, создающих технологии разработки программ и технологии использования программ, и, наконец, 4) методологов, разрабатывающих средства и методы этой работы.

В результате, схема 10 развертывается в более сложную многопозиционную схему (см. схему 11).

Схема 11

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

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

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

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

 

Схема 12

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

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

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

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

После того, как тема достаточно проанализирована и развернута и мы получили ряд тематизмов, начинается совсем иной тип работы целеобразование (см. схему 13).

Схема 13

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

Схема 14

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

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

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

Те из вас, кто следит за новой литературой по системному анализу, наверное, уже догадались, что я здесь использую новое понятие системы и новые методы системного анализа, созданные в рамках Московского методологического кружка примерно 10 лет назад. Это понятие и соответствующие ему методы анализа предполагают, что всякая схема, претендующая на системное использование, должна интерпретироваться в пяти разных планах: 1) как изображение процессов, 2) как изображение структур связей, 3) как изображение функций и функциональных характеристик выделенных элементов, 4) как изображение организованностей материала и 5) как указание на сам материал (или субстрат). В дальнейшем каждый из этих планов интерпретации должен получить свое особое изображение в специфических для него схематизмах и языках. Но все это требует специального обсуждения, а пока что я отметил это лишь мимоходом, чтобы предотвратить возможные неадекватные интерпретации и неправильные вопросы.

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

Если попытка достичь целей этим путем, т.е. в форме решания задач, оканчивается неудачей, то, как правило, делается вторая такая попытка, потом третья, четвертая и т.д. (см. схему 15).

Схема 15

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

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

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

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

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

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

Схема 16

В этой схеме нужно обратить особое внимание на два обстоятельства.

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

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

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

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

 

Схема 17

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

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

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

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

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

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

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

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

На этом я закончил следующую смысловую часть доклада и могу ответить на вопросы.

И.С.Алексеев: Сначала вы говорили о решании задач, потом стали говорить одновременно и параллельно о решании и решениях, а сейчас только что сказали о решении задачи как таковом.

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

8.

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

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

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

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

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

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

В этом же контексте и плане мы можем говорить о продуктивных выходах программирования.

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

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

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

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

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

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

Я не знаю, Игорь Серафимович, сумел ли я ответить на ваш вопрос достаточно точно?

И.С.Алексеев: Да! Благодарю вас.

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

На этом я закончил эту смысловую часть и теперь могу ответить на вопросы.

Нередко мы не имеем темы-задания, но при этом у нас могут быть цели.

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

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

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

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

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

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

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

Но разве не в ходе самого исследования наука выясняет, что она может и чего она, наоборот, не может решить?

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

Мне так студенты второго курса обычно отвечают. Я их спрашиваю, что у вас там будет в конце вашего курсового исследования? А они в ответ: так мы же его еще не проводили; вот проведем, выясним, тогда вам и скажем. Я их в таком случае выпихиваю за дверь аудитории и говорю: наблюдайте, через 15 минут расскажете. Но уже минут через 7-10 возвращаются и спрашивают: а что наблюдать? Тогда я сажаю их на месте и говорю: программируйте ваше исследование, определите, что вы хотите получить, сформулируйте цели, определите ограничения на ваши продукты, условия их практического использования и т.д. Запомните: если вы не знаете целей вашего исследования, не представляете себе продукта, который вы должны получить, то вы не ученый-исследователь, а рыболов.

А разве не бывают мнимые проблемы и мнимые цели?

 У слова «мнимые» два совершенно разных смысла.

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

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

А когда заканчивается вся эта цепочка программирования?

 Она заканчивается тогда, когда мы получаем полный ряд задач. В этом плане программирование бесконечно, а то, что из него «вываливаются» задачи, это факультативный продукт и результат. Но обратите внимание объективность тем, целей и проблем определяется совсем не тем, доходим мы до конца цепочки или не доходим; она определяется самой этой процедурой, тем, что темы, цели и проблемы прошли через эту процедуру. И если их формулировки при этом сохранились, то значит они «правильные», социокультурно значимые.

Чем изложенные вами идеи отличаются от известных идей сетевого планирования?

 По сути дела, ваш вопрос о том, чем программа отличается от плана.

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

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

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

А что вы делаете в тех случаях, если вы изложили программу, а вас не поняли?

 Я излагаю еще раз и стараюсь так трансформировать текст этого изложения, чтобы меня поняли. При этом я все время руководствуюсь замечательным принципом В.И.Ленина: говорить надо не так, чтобы было понятно, а так, чтобы нельзя было не понять.

Что такое проблематизация?

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

9.

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

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

Это относится к первой или к последней цели из вашей схемы?

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

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

 Да, конечно. Но я хотел бы сейчас уклониться от обсуждения этих аспектов все это принадлежит уже деятельностным механизмам целеобразования. Здесь важную роль могут играть: 1) разрывы в деятельности, 2) проекты желаемых состояний, 3) директивные и другие организационные документы, 4) социокультурные и личностные цели, 5) стандарты профессиональных задач, 6) система философских или научных знаний и т.д., и т.п.

Для примера приведу некоторые темы-задания, выступающие в роли целевых установок, над решением которых мне приходилось работать: обеспечить функционально оптимальную оргструктуру ГКНТ СССР; создать тренажер для прыгунов в длину, обеспечивающий занятие призовых мест на Олимпиаде-80, и т.п.

Так это что указание на продукт?

 Да, причем типичное.

А какого рода цели вы при этом преследуете, разрабатывая эти программы?

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

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

Теперь я перехожу к обсуждению проблематизации и проблем.

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

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

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

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

Но если, наоборот, человек склонен к размышлениям и если ему не удается достичь цели путем представления ее в виде стандартной, уже известной ему задачи, то тогда может произойти и происходит качественный переход в процессах мышления и деятельности, своего рода «ага-эффект», но наоборот. Такой человек может вдруг сказать: «Я понял! Меня обманули, точнее, я сам обманулся: у меня не задача, а, наверное, проблема!»

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

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

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

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

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

Именно здесь появляется понятие опыта, которое противостоит понятию объекта. «Опыт» это то, что мы выделяем в нашей деятельности и в нашем мышлении, когда начинаем их рефлексировать.

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

Этот момент начали обсуждать еще древние греки. Они задавали вопрос: а существует ли то, чего нет? И поскольку обсуждалось все это в плоскости единого и унифицированного мира-знания, у них возникла апория. Сейчас, работая в схемах многих разнотипных знаний, мы хорошо понимаем, что у этого вопроса будет разный смысл в зависимости от того, к какому пространству мышления-деятельности мы его будем относить. И соответственно этому будут разные ответы.

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

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

1 2 4 5 6 8 9 10 11 12 ...

и спрошу, чего здесь нет, то, наверное, многие из вас ответят, что нет тройки и семерки. Но как вы это определили? Я отвечаю, что вы определили это за счет того, что в натуральном ряду чисел все морфологически незаполненные места существуют точно так же, как и заполненные. И то же самое имеет место во всякой функциональной структуре: «дырки» в ней существуют в одном ряду со всеми морфологически заполненными элементами.

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

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

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

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

Если мы рассматриваем процессы решания задач, то в роли такой функциональной структуры будет выступать представление о способе решения задач. Это представление включает четыре основных блока: 1) представление о продукте процесса решения, 2) представление об исходном материале, 3) представление о средствах мышления и деятельности, 4) представление о методе решения. Все эти блоки должны быть связаны друг с другом соответственно процессам и механизмам мышления и деятельности.

Если решатель задач после своего «ага-просветления» введет подобную схему способа решения задач обратите внимание: не способ, а схему способа, то он затем, руководствуясь этой схемой может задавать себе вопросы: какие из элементов этой схемы он знает и имеет, а каких не имеет и не знает? Таким образом решатель задач актуализирует свой прошлый опыт, делая его материалом рефлексивного анализа: «Чего не было в моей деятельности? Из-за чего, собственно, у меня не получается? Правильно ли я представляю себе продукты моей работы, или здесь у меня какие-то разрывы, неточности, ошибки?»

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

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

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

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

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

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

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

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

Таким образом, я попробовал здесь ответить на вопрос, как я представляю себе проблемы и процессы проблематизации в контексте программирования.

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

А чем определяется число проблем, которые вы формулируете в одной тупиковой или разрывной ситуации?

 Это достаточно сложный вопрос, и я сейчас отвечу на него лишь частично.

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

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

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

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

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

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

Картина дня

наверх