Правильная ссылка на эту страницу
http://az-design.ru/Support/SoftWare/l/GlassRob/04h1084.shtml

8.4. О понимании, согласии... и формальных методах

       Прошлой зимой на компьютерной конференции я свалял дурака. Я стал спорить с докладчиком. То есть сделал то, что терпеть не могу в других.
       Что случилось? Что меня так задело?
       Докладчик излагал некую концепцию. Воодушевясь представлением этой концепции, он, на волне возбуждения, выразил неудовольствие тем, что не все соглашались с его мыслями, и фактически стал осуждать несогласных. Поскольку я был с его идеями не согласен, во мне росло возмущение. Наконец, я не выдержал. Я выступил и постарался объяснить, что хотя мысль докладчика понятна, многие могут с ней не согласиться.
       Чем больше я говорил, тем старательней докладчик объяснял свою идею, и чем больше он объяснял, тем сильнее я выражал несогласие с ней. Мы увязли в безвыходной ситуации, в конце концов придя в ярость. Другие участники и докладчики замолкли. Воцарилась атмосфера неловкости. По окончании заседания я крадучись покинул зал, жалея, что вообще в нем оказался.
       Размышляя впоследствии о случившемся, я пришел к выводу, что мы с докладчиком действовали каждый в рамках своей модели общения.
       В его модели достаточно было, чтобы я понял идею, которую он излагал. Если я не соглашался с его идеей, значит, я ее не понял. Если я не понял, следовало еще раз объяснить идею. Если и после этого я ее не понял, то потому что я глуп или невнимательно слушал.
       В моей же модели общения было два разных компонента. Первая — это понимание, над чем и трудился докладчик. А вторая, совершенно независимая от понимания, — согласие. Мне была понятна излагаемая им концепция — просто я не соглашался с ней.
       Размышляя над этой проблемой, я усмотрел ее связь с более глубоким социальным смыслом и пришел к выводу, что она представляет более общий интерес. (Этим я оправдываю описание на этих страницах перебранки, случившейся на какой-то конференции.) В начале жизни, когда наше развитие определяют авторитетные фигуры, “понять” и “согласиться” фактически синонимы. Кто-либо из родителей или учитель излагает идею, а ребенок или ученик соглашается с ней. Но по мере взросления ученика или ребенка разрыв между пониманием и согласием постепенно увеличивается. Родителю подростка или преподавателю студента уже недостаточно просто добиться понимания идеи. Они должны стремиться к ее принятию, а это гораздо более сложная и утомительная задача. Это связано с тем, что понимание достигается просто усвоением теоретического материала, а принятие связано с адаптацией идеи к имеющимся представлениям. И чем богаче система уже имеющихся у слушателя представлений, тем сложнее задача восприятия новой идеи.
       (Типичная реакция авторитетной фигуры на раздвоение понимания и принятия во взрослеющем человеке, это, пожалуй, жалкий вопль всех родителей — “да потому что я твоя мать, вот почему!”)
       Помню момент, когда во мне впервые проявилась эта разница. Я прочел -много десятилетий назад — “Взлет и падение Третьего рейха” Ширера. Размышляя над прочитанным, я вдруг осознал, что мне понятны представленные Ширером причины, по которым Гитлер уничтожал евреев и организовал холокост.
       И я пришел в ужас. Потому что до того момента в моем личном опыте не было различия между пониманием и принятием, как и должно быть у ребенка или школьника. Принимал ли я данные Гитлером обоснования холокоста? Конечно, нет — я противился им всем своим существом. И в то же время я понимал их. В тот момент было совершенно необходимо разделить эти два понятия.
       Теперь я хотел бы вернуться к некоторым недавним своим размышлениям и попробовать перевести этот разговор на системы и программы. В компьютерной литературе я часто наталкиваюсь на обсуждение каких-то новых идей (например, формальных методов), сопровождаемое сердитым замечанием, что в области практики эта идея не принята, поскольку совершенно неизвестна.
       Полагаю, что достаточно хорошо разбираюсь в практике программирования, и по моим представлениям важно не столько то, известны какие-то идеи практикам или нет, сколько согласны ли они с ними. И часто случается — формальные методы служат здесь особенно хорошим примером, -что действительной причиной неприятия каких-то идей в мире практики оказывается не их непонимание, а их неодобрение.
       Что происходит, когда теоретик осознает, что его новой идеей не пользуются? Он начинает усиленно разъяснять ее. Он хочет, чтобы ее поняли. А добившись понимания и обнаружив, что идеей все равно не пользуются, приходит в раздражение и начинает обвинять практиков в том, что они глупы или не умеют слушать, — знакомая картина? Разве в мире, где правят авторитеты, “понять” не значит “принять”?
       Смысл, который я хотел передать, таков. Необходимо, чтобы авторитетные личности, так же как студенты и дети, отделяли понимание от согласия. Мера, в которой авторитетная личность позволяет студенту или школьнику разъединять эти два понятия, свидетельствует о степени уважения к созреванию этих студентов и школьников и достигнутой степени ее собственной зрелости.
       Достигнув такого разделения, авторитетная личность может приступить к решению двух важных задач, которые на нее возлагаются:
       1. Объяснить свою идею так, чтобы это было понятно.
       2. Дополнительно изложить причины, по которым она должна быть принята.
       Мне кажется, что в большинстве нынешних исследований в области программирования отсутствует такой компонент, как проверка. С моей точки зрения, для современных исследований характерно обилие определений, обилие объяснений, обилие пропаганды и крайний недостаток фактов в поддержку этой пропаганды. Оценочные исследования, направленные на поиск таких фактов, традиционно проводятся нашими более учеными собратьями, но в нашей области почти отсутствуют.
       (Одно оценочное исследование по формальным методам, с которым я знаком, демонстрирует 9-процентный выигрыш в “общей стоимости разработки”, достигаемый в результате применения языка формальных спецификаций Z [Ralston 1991]. В более широком мире поиска компромисса между стоимостью и выгодой, где формальным методам пришлось бы конкурировать с языками 4GL, и CASE-инструментами, и методологиями, и разукрупнением, чтобы привлечь внимание менеджеров и финансирование, технология, сулящая 9% прибыли и большие затраты на освоение, в списке перспективных технологий заняла бы не самое высокое место.)
       Возможно, почти полное отсутствие оценочных исследований частично обусловлено отсутствием разделения понимания и принятия у наших авторитетных личностей. Наверное, дело в плохо понятом и явно не сформулированном общем ощущении того, что задача исследователя ограничивается пониманием. Возможно, это связано с тем, что исследователь — авторитетная личность — еще не усвоил, что зрелость практика-программиста растет. Из-за этого он не видит необходимости снабжать свое объяснение обоснованием.
       О различиях между академическим миром и производством я размышлял на протяжении многих лет. Например, я считаю, что в академическом мире хуже умеют слушать (обычные условия лекционного зала не способствуют развитию у лектора умения слушать) и менее ориентированы на цель (здесь работают, чтобы учиться, а не учатся, чтобы работать). А сейчас я добавил бы к этому свое убеждение, что практики более успешно справляются с разделением понимания и принятия, чем теоретики. (Ваша первая попытка заинтересовать высшее руководство новой идеей на основе одного лишь понимания станет также последней!)
       Ладно, хватит уходить в сторону. Спрашиваете, каков итог того спора на конференции? Что ж, я действительно поставил себя в глупое положение, но не очень жалею, что так поступил!

Ссылки
       Ralston 1991 — “Formal Methods: History, Practice, Trends and Prognosis”, American Programmer, May 1991; T.J. Ralston and S.L. Gerhart.




<<< Пред. Оглавление
Начало раздела
След. >>>

Дата последнего изменения:
Thursday, 21-Aug-2014 09:10:55 MSK


Постоянный адрес статьи:
http://az-design.ru/Support/SoftWare/l/GlassRob/04h1084.shtml