Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
В технической и пользовательской документации часто встречаются фразы с использованием страдательного залога. Параметры там «задаются», файлы «сохраняются», а программа «запускается». Ох, опасная эта форма для строгих и однозначных описаний!
Почему же страдательный залог заставляет читателей страдать? Давайте разбираться.
Теория изложена
Сначала небольшой ликбез для тех, кто подзабыл эту тему. Страдательный залог показывает, что подлежащее (лицо или предмет) не производит действие, а наоборот испытывает на себе чьё-либо действие. Иначе говоря, подлежащее выступает не субъектом, а объектом действия.
Деньги потрачены, документ прочитан, программа протестирована, а бутерброд хищно съеден.
Что же такого плохого в страдательном залоге? А то, что из текста не всегда понятно, кто или что именно выполняет действие. Иногда это не важно: съеден бутерброд — и ладно. Но представим, что это был ваш собственный бутерброд из холодильника в офисе — заманчивый и аппетитный, но, к сожалению, уже съеденный не вами. Тут уже вопрос о субъекте действия становится принципиальным.
Хорошо, если по контексту читатель может определить, кто или что именно выполняет действие. Например: «Параметр задаётся». Значение параметра может задать как система, так и пользователь. По контексту и окружающим предложениям можно понять, кто именно это делает.
Но заставлять читателя о чём-то догадываться — это не дело. Во-первых, это, хоть и небольшая, но всё же когнитивная нагрузка. Ресурсы мозга лучше бы поберечь для изучения самого предмета описания. Во-вторых, существует вероятность, что читатель догадается неправильно. А это уже будет совсем нехорошо.
В документации всё должно быть кристально ясно, понятно и однозначно, без других вариантов толкования. Поэтому лучше избегать страдательного залога — так надёжнее. Тем более, что это не сложно: достаточно использовать одну из следующих конструкций:
Конкретные рекомендации по настройке, обращённые к читателю:
«задайте параметр», «сохраните файл», «запустите программу».Однозначное указание того, кто выполняет действие:
«система задает параметр», «пользователь сохраняет файл», «администратор запускает программу».
Примеры разобраны
Предлагаю разобрать несколько показательных примеров.
Пример 1
«После нажатия на кнопку выполняется сжатие базы данных».
Этот пример может означать следующее:
После нажатия на кнопку пользователь должен запустить сжатие базы данных.
После нажатия на кнопку система выполнит сжатие базы данных.
Пример 2
«После этого переключатель „Методы“ устанавливается в положение „Расширенный“».
Тут тоже непонятно, что же именно описано — процесс или инструкция пользователю:
Система сама поменяет положение переключателя.
Положение переключателя должен изменить пользователь.
Если речь всё же идёт о пользователе, то можно придумать следующие варианты замены:
«После этого установите переключатель „Методы“ в положение „Расширенный“».
«Пользователь устанавливает переключатель „Методы“ в положение „Расширенный“».
«Следует установить переключатель „Методы“ в положение „Расширенный“».
Мне больше нравится первый вариант с прямым обращением к читателю. Во втором варианте автор как будто разделяет читателя и пользователя. Если это документ, который адресован, например, администратору системы, который не выполняет действия с ролью обычного пользователя, то такая форма вполне подойдёт. Если же читатель — это и есть пользователь системы, то у него вполне может возникнуть вопрос: «А какой именно пользователь? Это нужно сделать мне или это сделает какой-то другой пользователь?». Третий вариант тоже вызывает вопросы: кому именно следует установить переключатель?
Пример 3
«Перед обработкой файла создается его резервная копия».
Без контекста совершенно непонятно, кто же создаёт резервную копию файла: система или пользователь.
Опять же это предложение можно перефразировать вполне однозначно:
«Перед обработкой файла система создает его резервную копию».
«Перед обработкой файла создайте его резервную копию».
Представьте себя на месте пользователя, который понял исходное предложение в первом варианте и понадеялся на то, что система сама создаст резервную копию. Так недолго и важные данные потерять! А ведь бывают предметы описания, где неоднозначность в документации может привести к непредсказуемым последствиям.
Варианты улучшены
Иногда встречаются варианты, в которых возвратные формы глагола вроде бы не мешают пониманию:
«В зависимости от настроек, либо резервное копирование выполняется системой автоматически, либо его при необходимости выполняет пользователь».
«После этого в программе автоматически выполняется обработка данных».
«Процесс завершается, как только все папки будут проверены на наличие инфицированных файлов».
На первый взгляд тут всё понятно и однозначно — чётко указано, кто и что делает. Однако такие фразы звучат тяжеловесно. Читателю гораздо проще воспринимать прямой порядок слов. Лучше переформулировать эти примеры так:
«Система автоматически выполняет резервное копирование, если это задано настройками. Иначе пользователь самостоятельно выполняет резервное копирование при необходимости».
«После этого программа автоматически обрабатывает данные».
«Приложение завершает процесс после проверки всех папок на наличие инфицированных файлов».
Кстати, присоединение к глаголу возвратной частицы «-ся» не всегда приводит к образованию страдательного залога. Например, в предложении «Приложение обновляется с заданной периодичностью» слово «обновляется» может иметь два толкования:
приложение обновляется самостоятельно — возвратная форма глагола;
приложение обновляется кем-то, например, администратором — страдательный залог.
Ещё один повод к неоднозначности трактовок там, где всё должно быть ясно и понятно.
Исключение сделано
Есть и исключения, куда же без них. Возьмём, например, словосочетания, которые выглядят как название статуса объекта в какой-то системе: «Платёж отклонён». Или: «Система обновлена». Тут, конечно, не указано, кто именно отклонил платёж и обновил систему. Но так ли уж это важно в данном случае? Я не просто так использовал слово «статус» — он описывает текущее состояние объектов, когда не важно кто, когда и как привёл объект в это состояние.
Преобразование в действительный залог в данном случае не только не добавит ясности, но и, пожалуй, только запутает дело. Например, если мы напишем «Система обновлена администратором» или «Администратор обновил систему», то у читателя непременно возникнет подозрение, что администратора добавили сюда не просто так. Возможно, есть какой-то другой статус, например: «Приложение обновило систему»?
Этот пример показывает, что с описанием состояний объектов автору нужно быть очень аккуратным — в стремлении упростить материал можно сделать только хуже.
Ещё почитать:
Манулы и мануалы. Как избавиться от опечаток в технических текстах
Уж послала, так послала: 10 словосочетаний-паразитов в технических текстах
