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

Передача знаний о системе

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

И вот перед ним появляется задача передать часть своих знаний другому человеку или некоторой аудитории (группе людей). Опишем особенности соответствующего психического состояния профессионала.

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

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

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

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

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

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

Кто же в IT-индустрии может выступать в роли такого профессионала, заинтересованного в передаче тех или иных знаний? Вот примеры:

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

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

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

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

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

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

Цикл SADT/IDEF читатель/автор

Опишем одну интересную и крайне полезную технику использования визуального моделирования при изучении какой-либо области знаний. Она называется цикл читатель/автор (Reader/Author Cycle review process) и может применяться при работе как с UML, так и с любым другим языком визуального моделирования. Эта техника была определена в рамках методологии SADT (Structured Analysis and Design Technique) [5.2].

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

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

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

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

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

Кроме автора, эксперта и читателя в цикле "читатель/автор" имеются также следующие роли:

• библиотекарь (librarian) - это главный координатор процесса моделирования; он следит за тем, чтобы все участники процесса вовремя получали свежие копии моделей, чтобы эти копии не терялись и вовремя попадали в архив, а последний был бы доступен; в его компетенцию входит также отслеживать, что все замечания экспертов и читателей обработаны автором, не оставлены без внимания; раньше, когда метод SADT только появился, роль библиотекаря была велика - модели строились на бумаге; теперь же для этого используют разные графические пакеты, а для хранения разных версий модели - программные средства управления версиями;

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

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

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

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

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