4. Для разработчиков не требуется ни скриншотов, ни картинок. При этом графики в документах для них может быть достаточно много — это и структурные схемы баз данных, и схемы алгоритмов (иногда имеют просто огромный размер и распечатать их очень затруднительно, картинка может иметь размер 2×5 метров в масштабе распечатки 100%). Какие именно схемы и блок-схемы изображать — нужно согласовывать с консультантами, которых выделит вам отдел разработки. Это связано с тем, что только сами разработчики могут сказать, какие графические пояснения будут полезны их коллегам, а какие будут ненужным отчётом Капитана Очевидности.
В описанном в начале темы примере удобно использовать второму варианту.
Шестым шагом будет определение последовательности описания элементов программы и действий с ними.
Далее, важно подавать информацию структурировано. Вы должны описывать компоненты программы в той последовательности, в которой с ними будет знакомиться пользователь в ходе работы. Для этого необходимо вникнуть в программу и понять, с каких функций человек будет начинать, а до каких доберётся в последнюю очередь. Это своего рода высший пилотаж, поэтому есть более простой вариант структурирования: по визуальной очерёдности компонентов. Например, в меню программы 10 пунктов, расположенных слева направо. Вот с самого левого до самого правого вы их описать и должны. Всё дополнительные настройки и не вынесенные на переднюю панель функции описываются после этого.
Седьмым шагом... Нет, стоп, пришли. Теперь вы можете собрать все полученные сведения, ещё раз проверить свой выбор по каждому пункту и перейти непосредственно к написанию текста. Естественно, мы подразумеваем, что подготовительную исследовательскую работу вы уже провели, и описываемый продукт знаете, как свои пять пальцев левой руки (не забываем, что точность крайне важна!).
Но перед этим стоит обратить внимание на ещё один важный момент. Во время написания технического документа, ваш девиз должен быть таким: «Максимум данных в минимуме текста». Подробнее о приёмах минимализма мы поговорим чуть позже, сейчас же важно уяснить основные моменты.
Технический текст ценен краткостью и содержательностью, как говорилось в сравнении классического и технического писателей. Многие сильные стороны русского языка в документации неуместны, наша задача — высказать всю информацию в максимально кратком виде, при этом сохранив смысл и достаточно подробный (в зависимости от ЦА) уровень и глубину изложения. При этом в тексте не должно быть двоякого смысла, если что-то требуется уточнить — уточните, несколько поясняющих слов лучше, чем потенциально непонятный пользователем фрагмент инструкции.
