Требуется технический коммуникатор

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

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

Специалиста, ответственного за взаимопонимание между людьми, задействованными в проекте, в международной практике принято называть «техническим коммуникатором», а сферу его деятельности — «донесением полезной информации, относящейся к определенной области, до соответствующей целевой аудитории» (en.wikipedia.org/wiki/Technical_communication).

В практике западных компаний технические коммуникаторы являются равноправным сообществом среди ИТ-профессионалов.

Работа технического коммуникатора не сводится лишь к обязанностям «технического писателя», хотя исторически с ней тесно связана (www.stc.org/PDF_Files/caseTC.pdf ). Создаваемый им информационный продукт, даже если это руководство или пособие, должен быть интерактивным, гипертекстовым, сетевым; должен включать в себя иллюстрации, схемы, каталоги, классификаторы. Таким образом, в сферу деятельности коммуникаторов в программных проектах входят многообразные обязанности, в том числе: технического писателя, редактора, иллюстратора, архитектора информационных систем, эксперта по «юзабилити», дизайнера пользовательского интерфейса, инструктора. Современный «технический» читатель требует, чтобы организация информации допускала возможность фрагментарного ознакомления (нужны перекрестные списки терминов, ссылки), должны быть предусмотрены визуальные формы акцентирования внимания на основных положениях вместе с альтернативной возможностью углубления. Нужны многообразные возможности поиска. Еще более технологически «продвинутым» должно быть справочное обеспечение, не говоря уже про пользовательский интерфейс, на котором до последнего времени и ограничивались усилия разработчиков по достижению эффективности взаимодействия.

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

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

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

Особенности коммуникаций в программных проектах

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

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

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

Очевидно, что спектр решаемых техническими коммуникаторами проблем существенным образом зависит от перечисленных вариантов коммуникации.

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

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

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

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

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

Гуманитарные аспекты технической коммуникации

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

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

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

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

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

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

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

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

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

Информация, циркулирующая в программном проекте, и, в том числе, предоставляемая пользователю, все более походит на ризому. Для наглядности приведем пример организации систем помощи в прикладной программе, в которой задача технического коммуникатора — автора систем помощи поисковой программы — в том, чтобы у пользователя не было проблем при работе. Пусть с помощью конструктора отчетов в среде Microsoft Business Intelligence Development Studio пользователь разрабатывает отчет, в котором хочет вывести дату в определенном формате. Предположим, что он даже знает, что нужно воспользоваться функцией Format. Где искать описание ее параметров? Функция Format не входит в компоненты отчета, она (как и подавляющее большинство других элементов) наследуется из смежных сред (может быть, из Visual Basic, но пользователь не должен про это знать). Очевидно, что ее используют и многие другие инструменты. Слово «Format» столь распространено, что текстовой поиск в help программы ничего не даст. Взаимное проникновение, интегрированность инструментов приводят к тому, что, работая с одной программой, пользователь одновременно обращается к десятку других, что и приводит к сложному переплетению, которое невозможно отразить не только линейным текстом, но и деревом.

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

Какие практические выводы можно сделать из всего этого?

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

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

Умберто Эко в Записках на полях «Имени Розы» сравнил ризому с лабиринтом, имеющим бесконечное число входов, выходов, тупиков и коридоров, каждый из которых может пересечься с любым другим. Метафора лабиринта — одна из основных символических моделей, используемая сообществом технических коммуникаторов. Осознание масштаба своих задач, невозможности разрешения их в рамках строгого формального подхода должно способствовать привлечению неточных, но значительно более емких гуманитарных подходов. Обилие изобразительного материала, используемого сегодня как в интерфейсе, так и в документации, — тому свидетельство. Другой, возможно, неосознанный подход, — использование метафор, например, «дерево», «окно», «очередь» и т.д. Однако не все метафоры переносимы в другие культуры. Так, перевод на русский язык термина cash не состоялся по причине неразвитости в стране банковской системы. Метафора наличных денег, позволяющих оперативно решить какие-то проблемы, для отечественного сознания прошлого века была не понятна. Так мы и произносим «кэш» и, по сравнению с widows-окно метафора не состоялась.

***

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

Наталья Маркова (nmarkova@ipiran.ru ) — ведущий научный сотрудник Института проблем информатики РАН (Москва).