Читаем Как написать понятную инструкцию. Опыт инженера онлайн бесплатно

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

Данную небольшую работу можете считать этаким криком души. И далее немного вам поясню, что я имею в виду. Но для начала, как принято в приличном обществе, представлюсь и расскажу немного о себе.

Я — инженер. Когда-то окончил машиностроительный факультет Саратовского государственного технического университета (ныне имени Ю.А. Гагарина). По многим причинам мне не довелось реализоваться по своей специальности, но вот уже почти 15 лет (на момент написания этой книги) я успешно работаю в сфере информационных технологий.

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

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

Теперь вернемся к причинам выбора темы.

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

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

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

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

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

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

Вот лишь несколько простых примеров, которые сходу вспоминаются:

— достаточно часто в рамках одного документа использовались разные термины, обозначающие одни и те же сущности;

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

— отсутствовала привязка функциональности продукта к конкретным сценариям его использования, то есть в инструкциях просто показывались и описывались какие-то элементы интерфейсов — кнопки, диалоговые окна и т. д.

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

Словом, инженеры разучились писать инструкции…

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

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

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

Возможно, принципов создания инструкций великое множество, но моему мнению, основных всего три:

1. Решение конкретной задачи

2. Последовательность

3. Краткость и аккуратность

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

Пересечение всех этих кругов как раз и является той самой «понятностью» в инструкции.

Рисунок 1. Основные принципы создания понятной инструкции

Принцип 1 — Решение конкретной задачи

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

Принцип 2 — Последовательность

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

Принцип 3 — Краткость и аккуратность

Используйте знакомые и понятные пользователю слова и термины. Формулируйте мысли короткими предложениями. При этом немаловажным фактором является аккуратное оформление материала.

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

Во-первых, ответьте себе на вопрос — для кого вы пишите инструкцию?

Во-вторых, каким уровнем знаний или осведомленности об объекте документирования (продукте) обладают те, для кого вы пишите инструкцию?

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

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

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

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

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

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

Рисунок 2. Уровень знания о предмете документирования

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

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

— инструментальный;

— функциональный.

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

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

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

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

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

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

Правильный выбор подхода составления инструкций всегда зависит от конкретных условий, в которых находится автор (инженер).

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

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

Вы должны (и даже обязаны) осмыслить весь подготовленный материал для того, чтобы суметь его структурировать.

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

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

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

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

Рисунок 3. Дедуктивный метод структурирования материала для инструкции

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

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

Также обратим внимание на требование стандарта по эксплуатационным документам1 в части изложения указаний:

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

Для этого взял у сына прекрасный школьный учебник по русскому языку под редакцией В.В. Бабайцевой2 (как бы это смешно ни казалось). Вот что там написано: