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