«Языковой барьер» - риск крупных проектов
автор ТАЛАНОВ Виктор Александрович

Введение.
В этой статье постараюсь обобщить собственный опыт участия в крупных проектах. Я предлагаю обсудить проблему непонимания внутри проектной команды на лингвистическом уровне. Сразу поясню, почему словосочетание “языковой барьер” написано в кавычках. Речь пойдет о проблеме перевода с русского на русский язык, а не с английского (немецкого, французского и т.д.) на русский, как многие могли бы подумать. На практике, бывали моменты, когда взаимопонимание с англоговорящими коллегами было выше, чем с русскими. Основная причина такого недопонимания состоит в том, что члены проектной команды владеют разными предметными областями. При этом они вносят свой профессиональный сленг в проект. Безусловно, если бы все проекты велись согласно общепринятым методологиям и ГОСТ, то этой статьи, скорее всего, не было бы, т.к. каждый документ проекта содержал глоссарий, а проектная команда чётко следовала той терминологии, которая определена в документах. Но в реальной жизни все гораздо сложнее.
Перед руководителем крупного проекта, в котором задействованы одновременно специалисты ИТ, финансисты и бухгалтеры, специалисты по логистике и др., стоит довольно сложная задача договориться о терминологии, которая будет использоваться в проекте. Этот вопрос на начальных стадиях, как правило, упускается из вида, и как следствие, непонимание со временем нарастает как снежный ком.

Неформальное общение.
Неформальное общение - это устное общение, которое никак не документируется, но зачастую решения, принятые в результате такого общения, носят стратегический характер.
Перейдем к конкретным примерам. Так, под термином “остаток’ бухгалтеры понимают одно, складские работники другое, а ИТ-специалисты вообще могут ничего не понимать, но зачастую додумывают сами. Это случай, когда желательно всегда употреблять расширенное написание термина, например: “остаток по счетам”, “складские остатки” и тп. Это пример того, как один и тот же термин используется для разных физических сущностей. Подобные ситуации, как правило, встречаются при интеграции приложений. В приведенном примере это интеграция бухгалтерской и складской систем. Подобная интеграция может проходить при создании биллинговой системы, хранилища данных или внедрении ЕАР-системы.
Бывают ситуации, когда масса терминов в голове несведущего человека сливается в одни и он не может понять различия между физическими сущностями. Например, была ситуация, когда систем- ному аналитику пришлось долго объяснять, чем отличаются “зоны”, “области”, “места”, “ячейки”, “типы мест”, “типы транспортных единиц’. Те. то, что для работника склада очевидно, для аналитика может оказаться далеко не так.
Хорошо, если это непонимание обнаружится сразу. А если аналитик решит, что он всё понял, передаст задание на разработку программисту, программист додумает и внесет свои домыслы в разработку.
Рассмотрим реальный случай ‘домысла”. Нужно отразить в складской системе исключительный случай, когда клиенту по документам отгрузили 100 коробок, но реально в грузовик положили 99 коробок. Разработчику говорят, что нужно сделать возврат одной коробки на склад. Что делает разработчик - он реализует интерфейс, где оператор может в складской системе подправить фактическое количество товара на складе. Но с точки зрения бизнес-процесса так делать категорически нельзя. Возврат товара в такой ситуации - это сложный процесс. В товарных накладных, в бухгалтерских документах и в системах клиента фигурирует 100 коробок, соответственно, нужно генерировать массу документов, чтобы исправить эту ошибку при отгрузке. Вывод: “возврат” с точки зрения разработчика, юриста, бухгалтера, склад- ских и транспортных работников - это совсем разные понятия. Все они смотрят на одну и ту же проблему под разными углами.
Бывает так, что два специалиста привыкли употреблять разные термины для обозначения одного и того же. На совещаниях по проекту разгораются нешуточные дискуссии (споры) из-за того что одно и то же называют разными терминами. Т.е. суть спора зачастую состоит в том, как назвать ту или иную сущность. достаточно простой пример - “сервер” и ‘база данных” часто может обозначать одно и то же в рамках дискуссии по проектному решению.

Формальное общение.
Под формальным общением я подразумеваю общение через документы, т.е. технические задания, протоколы встреч, акты и другая техническая проектная информация.
На первый взгляд может показаться, что аккуратное документирование всей проектной деятельности избавит от проблемы “языкового барьера” на 100%. Но я готов утверждать, что это далеко не так, хотя, конечно, очень большой процент непонимания и рисков, связанных с “языковым барьером”, снимется. Именно ради уменьшения этого риска в ГОСТе 34.602 и других прописываются требования к оформлению документации и этапам ведения проекта. То же самое, но другими словами, прописано в международных стандартах и рекомендациях. Одна из основных целей любого документа в проекте - это избежать двоякого прочтения утверждений и терминов, чтобы всем участникам проекта были понятны цели проекта или отдельного этапа, методы достижения целей и критерии успеха.
Перейдем к конкретным примерам. Первое, что приходит на ум - это аббревиатура “ИС”. В глоссари вы увидите: “ИС - информационная система”. С формальной точки зрения требование выполнено, термин описан. Но если спросить программиста, архитектора ИС, бухгалтера или финансового директора, что они понимают под информационной системой, то скорее всего вы получите разные ответы, и все люди будут по-своему правы. Вот еще один яркий пример - ‘ИТ - инфраструктура”. Специалист по базам данным, ЕАР-системам и специалист по СКС(структурированные кабельные системы), специалист по IР-маршрутизации видят инфраструктуру в разных ее проявлениях. Был реальный случай, когда разделение ИТ - инфраструктур поручили специалистам по СКО. Они просто затеяли замену всей СКС здания. Изначально ставилась задача жёстко разделить доступ к информационным ресурсам (базам данных, файлам, принтерам и т.п.) из-за разделения компании на две независимые фирмы. Уверен, что если бы эту задачу поручили специалистам по активному оборудованию, то они просто бы переконфигурировали коммутацию. А если бы эту задачу поручили специалистам по администрированию серверов и баз данных, то они сделали бы это на уровне прав доступа к ресурсам.
Таким образом, к формальному общению в рамках проекта нужно тоже относиться аккуратно. Во многих случаях в глоссарий вставлять максимально расширенное описание терминов и, возможно, это описание будет немного отличаться от общепринятого академического описания, но будет более понятным для участников проекта.

Выводы.
Руководитель проекта должен быть подкован во всех предметных областях, которые охватывает проект и хорошо ориентироваться в их терминологии. Как минимум, в проектной команде должны быть аналитики, архитекторы, которые знают два или более “языков”.
При старте проекта, в момент формирования команды и на первых встречах, нужно внимательно следить за терминологией, пытаться понять уровень владения терминологией каждого человека, т.е. на сколько глубоко бухгалтер владеет ИТ терминологией и наоборот ИТ специалист понимает бухгалтера. Если непонимание существенное, то стоит приглашать “переводчика”.
Язык общения желательно максимально упростить и ориентировать его на человека, который хуже всех ориентируется (разбирается) в предметной области проекта или его части. Т.е. разделы документов финансового характера должен уметь понять ИТ специалист, пусть даже время от времени заглядывая в глоссарий. .

 

На  первую страницу.