"Человеческие" аспекты применения визуального моделирования

О тематике

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

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

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

Базовые функции

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

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

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

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

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

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

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

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

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

Проектирование уникальной системы

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

Проектировщик может вести себя, например, так. Он размышляет, задумчиво глядя в окно, отрешенно пьет кофе^{1Отдельные детали здесь несущественны - кто и что пьет при поиске решения и т. д. Комиссар Мегрэ у Жоржа Семенона в таких ситуациях пил, например, пиво, но в целом вел себя очень похоже. В данном случае важен не отдельный сценарий, а психическое состояние человека, которое узнается и сопереживается, а не детально описывается и точно классифицируется.}. Он погружен в море информации, она внутри него. Однако он не тасует ее отдельные аспекты, а созерцает их все вместе. При этом он может заниматься любой деятельностью, углубляющей его созерцание. Проектировщик внешне может выглядеть рассеянным и беспорядочным, но внутренне он настойчив и интенсивен. Он сосредоточен, и его нелегко вывести из этого состояния каким-либо внешним способом. Ему нужно что-то узнать и уточнить, но его вопросы могут показаться странными и нелепыми для окружающих.

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

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

Для продуктивного творческого поиска не нужно множества пресс-конференций, большого количества разнообразной информации, интенсивного общения. Самое главное, как правило, происходит внутри самого проектировщика - в его воображении, уме и т. д. Его созерцательность, терпеливость и настойчивость являются хорошим залогом успешности - но не гарантией^{2Я предвижу, что, читая это место, менеджеры могут с досадой отложить эту книгу. Их стандартной реакцией на отсутствие гарантий является раздражение, стремление во что бы то ни стало эти гарантии получить. Однако опытные менеджеры знают, что успех - это еще и удача, случай. Поэтому, если участвуешь в проекте по созданию новой уникальной системы, то нужно быть готовым к неожиданностям и непредвиденным поворотам событий.}

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

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