3. Простота и единообразие языка техписа и обширный словарный запас литератора. Технический писатель может использовать в документации только литературные слова. Разговорные, просторечные выражения, присказки, транслитерация и всё остальное — для него табу. Также любую описываемую сущность он всегда должен называть одинаково, не оглядываясь на повторы (о том, как их избежать — мы расскажем позднее), например: папки это папки, а не каталоги, папки и директории одновременно. Также если корпоративный стиль документов подразумевает шаблонные заготовки для вступлений или описаний определённых действий — необходимо использовать их, не изобретая велосипеды и ничего не меняя в этих шаблонах. Писатель же может использовать в описаниях и речи героев абсолютно всё, вплоть до матерной ругани (хоть она и не украшает текст, да и автору особой чести не делает), а также подбирать синонимы к любому слову и по-разному описывать одно и то же повторяющееся событие или действие. Например, трёхкратный процесс открывания двери и посадки человека в машину в течение книги техпис и писатель должны описывать по-разному: первый вставит три совершенно одинаковых алгоритма, а второй обыграет это действие так, как ему будет угодно.
4. Техпис пишет для конкретных людей, писатель — для всех. Техпис всегда ориентируется только на пользователей описываемого продукта или конкретную целевую аудиторию (далее ЦА), для которой предназначен материал. Ему не нужно заботиться об общей эрудированности читателей, он должен оценить только степень их грамотности в том вопросе, которого он касается. Например, при написании инструкции пользователя к ПО, техписа будет волновать только уровень компьютерных навыков пользователя и ничего больше. Писатель же должен излагать мысли так, чтобы знаний любого читателя хватало для усвоения его текста. Если это правило не соблюдается, значит у товарища проблемы со способностями к творчеству — их просто нет.
5. Техпису принципиально, чтобы его текст был ясен всем пользователям. Все пользователи документации в рамках целевой аудитории должны легко понимать написанный техническим писателем материал. Если это правило не соблюдается — значит, автор сделал работу плохо, и текст надо переписывать. Писатель же может утверждать, что его тексты рассчитаны на некую «элиту» или «бомонд», тем самым перекладывая ответственность за плохое качество текста на читателей (увы, как правило, это касается бездарей, неспособных донести мысли понятным языком).
6. Писатель сочиняет, а техпис констатирует. Выдумки в нашем деле не очень востребованы, когда дело касается документирования — что видим, то и описываем. Для аналитика же доля воображения и находчивости, напротив, может быть весьма полезной, чтобы правильно подобрать аспекты для оценки того или иного процесса или продукта, а также в подборе методов и принципов анализа.
4. Почему навыки работы с текстами нужны всем?
О специалистах, работающих непосредственно с текстами, мы сказали уже достаточно много. Может сложиться впечатление, что перечисленные выше профессии представляют собой полный список тех, кому по работе вообще требуются навыки работы с текстами, но это в корне неверно. Положение дел в IT-отрасли и любом высокотехнологичном производстве таково, что уметь создавать качественные тексты необходимо практически всем сотрудникам, независимо от занимаемой ими должности.
Создавая документацию и тексты для внешних пользователей и потенциальных клиентов, техписы очень слабо втянуты в процесс непосредственной разработки продукции (кроме разработки технических заданий, да и то не всегда). Как правило, их подключают уже на завершающем этапе, чтобы выдать материалы для документирования и дать задачи по комплектности документации. И вот здесь начинается самое интересное — даже постановка задачи техническому писателю — это текст, это изложение мыслей руководителя проекта или руководителя отдела документирования. И если второму формулировка задачи даётся легко, то первому — не всегда.
Если рассматривать очень грубо, то процесс разработки любого изделия (программы, оборудования, чего угодно) выглядит примерно так: кто-то разработал идею, облёк её в форму, разработав Техническое задание (в идеале — с привлечением техписа или аналитика), после чего отдал готовое ТЗ программистам. Те, общаясь между собой, разрабатывают программу, попутно консультируя маркетологов и продвиженцев, чтобы они могли начинать кампанию по продвижению продукта (если продукт делается под заказ — этой проблемы нет). После того как продукт создан — начинается тестирование, полевые испытание и прочие краш-тесты. По их результатам проводится доработка, после чего к делу подключаются технические писатели (если их не привлекли ещё на этапе разработки ТЗ или тестирования), которые делают комплекты документов, набираются или обучаются инженеры поддержки, которые будут буфером между пользователями и разработкой. Разумеется, на каждом этапе, начиная с разработки ТЗ, идут постоянные отчёты о работе, которые рассылаются руководству проекта, отдела и компании в целом, иногда — ещё и заказчику, если тот требует держать его в курсе дела.