КомпанияУслугиОбучениеСервисы

Кто такие технические писатели?

Версия для печати

Михаил Острогорский, 2006

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

Термин «технический писатель» представляет собой далекую от изящества кальку, буквальный перевод английского названия профессии “technical writer”. За неимением лучшего будем пользоваться им, ибо все остальное, как сказал поэт, «еще хуже, еще неуклюже». Документатор? Разработчик технической документации? Инженер по документированию? Красавчики, правда? Пусть уж будет технический писатель. Или нет: пускай специальность будет называться технический писатель, а должность — разработчик технической документации. Так логично, да. Тем более что в официальных классификаторах специальностей и должностей ничего отдаленно похожего не наблюдается.

Что такое техническая документация, на бытовом уровне наверно понятно всякому. Если вы покупаете в магазине программный продукт, допустим, домашнюю бухгалтерию или компьютерную игру, то, открыв коробку, вместе с дисками и какими-то мелкими рекламными бумажками достаете толстую или не очень толстую, а может быть совсем тонкую книгу, озаглавленную «Руководство пользователя». В ней сказано, как установить программу на компьютер, как запустить ее, и, наконец, как добиться от нее толку, например, посчитать ваши среднемесячные затраты на покупку провизии. Кто эту книгу сочинил? Программист? Нет, хорошо, если на человеческом языке он в состоянии написать что-нибудь более пространное, чем «Я пашол запивом». Может быть рекламист или так называемый копирайтер? Опять нет, он пишет о том, что программа наша самая лучшая в мире, и что ее обязательно всем надо купить, причем срочно. Сочиняет ее технический писатель. Он пишет: «Данная программа предназначена для решения таких-то и таких-то задач. Для того чтобы установить программу на компьютер, сделайте то-то и то-то. Для того чтобы запустить программу, щелкните мышью по такому-то значку. Для того чтобы сформировать вашу налоговую декларацию за прошедший год, выберите в меню “Налоговая декларация” и т.д.». Каждую задачу, которую решает пользователь с помощью программы, технический писатель должен изложить очень подробно, по шагам, ничего не пропуская. Всякому пользователю после прочтения такой документации должно быть понятно, что он может сделать, и как это сделать делать. Скажем прямо, сей идеал достигается не всегда, да и не всегда в полной мере достижим, но добросовестный технический писатель к нему стремится.

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

Все это не так уж сложно, если речь идет чем-то более-менее очевидном, о той же домашней бухгалтерии. Но ведь бывают и совсем другие программы. Они адресованы не частным лицам, а организациям, с ними работают профессионалы в разных предметных областях: финансисты, инженеры, геологи, врачи, авиадиспетчеры, криминалисты да мало ли кто еще. Тогда техническому писателю приходится осваивать соответствующую предметную область. Конечно, он не становится в ней настоящим специалистом, но узнает о ней очень много. Вы Артура Хейли никогда не читали? «Аэропорт», пожалуй, самая известная его вещь. Примерно на таком уровне. Разумеется, я говорю о добросовестном техническом писателе. Недобросовестный ведет себя, как хитрый студент на экзамене по невыученному предмету.

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

Документирование автоматизированной системы не сводится к созданию эксплуатационной документации. Много разных документов выпускается до того, как программистами будет написана хоть строчка кода (а может быть, они вообще ничего писать не будут, а построят систему из готовых программ, скомплектовав и соединив их нужным образом). Разрабатывается концепция системы, техническое задание на нее. Техническое задание (ТЗ) — очень важный документ, потому что в нем содержатся требования к системе. Сравнивая готовую систему с требованиями ТЗ, заказчик будет решать, можно ли заплатить исполнителю деньги и отпустить его с миром, или необходимо что-то доделывать. Устройство системы должно быть описано в документах технического проекта (ТП). Документом программа и методика испытаний (ПМИ) руководствуются при приемке системы. И это еще далеко не все. В принципе эти документы должны создавать разработчики системы (аналитики, архитекторы, ведущие специалисты), однако, на практике значительная часть рутинной работы по их подготовке перекладывается на технического писателя. Последний, как правило, лучше умеет обращаться и с текстом как таковым, и с инструментальными средствами для его набора и оформления: текстовыми процессорами, графическими пакетами и некоторыми другими более специальными программами, автоматизирующими деятельность автора. Я забыл сказать, что все документы помимо всего прочего должны быть составлены и оформлены в соответствии с требованиями каких-нибудь стандартов, в нашей стране это обычно ГОСТы серий 34 и 19. Иначе заказчик их не поймет и не утвердит, тогда проект пойдет прахом. Тут особая кухня, технический писатель должен в ней хорошо разбираться. Крупные коммерческие структуры от министерств не отстают, они тоже требуют, чтобы им все сделали, как положено. И это еще полбеды, потому что у военных заказчиков есть свои секретные стандарты.

Выходит, технический писатель занимается только документированием тиражируемых или заказных разработок? Снова нет. В каждой крупной и во многих средних организациях есть подразделения, которые отвечают за информационные технологии. Они могут называться по-разному, но мы будем для определенности использовать термин ИТ-департамент. Не мне вам объяснять, что сегодня в каждом офисе полно компьютеров, а все секретари, клерки и прочие эффективные менеджеры сидят за мониторами, их работа в большей или меньшей степени автоматизирована. Документооборот, планирование, маркетинг, производство, продажи, логистика, управление персоналом, учет — все, даже простая переписка, теперь происходит в электронной корпоративной информационной среде. Звучит красиво, хотя на самом деле все не так гладко, но в целом ситуация идет к этому. Следовательно, кто-то должен закупать и настраивать компьютеры, приобретать и устанавливать на них программы, заказывать или самостоятельно разрабатывать автоматизированные системы. Еще нужно обучать сотрудников, решать возникающие у них проблемы с техникой, заботиться о сохранности конфиденциальных данных и т.д. Все это забота ИТ-департамента. В ИТ-департаменте у технического писателя тоже может быть много дел. Как минимум, необходимо документировать разработки, которые ИТ-департамент ведет собственными силами, да и вся ИТ-инфраструктура в целом должна быть документирована, иначе ее будет очень сложно обслуживать, тем более развивать, адаптировать к потребностям бизнеса.

В зависимости от особенностей организационной структуры компании технический писатель может быть включен в профильное структурное подразделение либо непосредственно в команду разработчиков, занятых каким-то проектом или продуктом. Отдел документирования (как бы его ни называли в конкретной фирме) обычно невелик, сегодня мы редко встречаем отделы численностью более десяти человек. Некоторые компании комплектуют отдел документирования не только техническими писателями, но и литературным редактором, корректором, верстальщиком. В компаниях с достаточно большим количеством уровней иерархии сам отдел может относиться к более крупному структурному подразделению, осуществляющему или разработку, или обеспечение качества (“Quality Assurance”, QA). До самого последнего времени были распространены объединенные отделы документирования и тестирования, но эта практика постепенно изживает себя. Руководителем отдела документирования, как правило, назначают наиболее квалифицированного технического писателя. В разных компаниях ему могут присваивать разные функции, но в любом случае потребуют обеспечить соблюдение сроков подготовки технической документации и достаточный уровень ее качества. Надо сказать, что руководителю подчас приходится туго, он вынужден проявлять то дипломатичность, то жесткость, чтобы не перессориться с руководителями смежных подразделений, но и не позволить им завалить отдел нереальным объемом работы, в срыве которой его же потом будут обвинять. И все-таки даже при умелом управлении отдел документирования, как всякий общий ресурс, постоянно перегружен.

Вот где и чем бывает занят технический писатель. Но кто он такой? Поскольку еще не родился ребенок, который мечтал бы стать техническим писателем, ни один вуз сегодня не предлагает абитуриентам получить подобную специальность. По крайней мере, у нас в стране дело обстоит именно так, хотя за границей дипломированный technical writer вовсе не редкость. Но мы говорим про нашу страну и наше время. В армии офицер получает сначала должность, а после звание. Примерно то же самое происходит с техническими писателями. Человеку, который в ладу с письменным словом, поручают разработку технической документации, а необходимые для этого знания, умения и навыки он приобретает в процессе работы. Небезболезненная процедура, но выручают более опытные коллеги, книги, публикации в периодике, профессиональные форумы, специализированные курсы (http://www.philosoft.ru). Было бы желание. Высшее образование необходимо или, во всяком случае, очень желательно, но характер его принципиального значения не имеет. Хороший технический писатель может выйти из программиста, математика, филолога, педагога, географа, военного. Только одно обстоятельство портит благостную картину: если вы никогда не сами программировали, вы не сможете писать документацию, адресованную программисту. Это особая разновидность документации, которая обычно касается либо средств разработки (языки программирования, компиляторы, отладчики), либо технических интерфейсов для интеграции между программами. Правда, такие задачи возникают далеко не во всех компаниях.

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

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

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

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

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

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

  • представление о системной и программной инженерии как о суперсистеме для документирования;
  • системное видение документирования как инженерной дисциплины, понимание процессов документирования и их взаимосвязей с другими процессами в разных ситуациях;
  • международные стандарты, касающиеся жизненных циклов программ и систем и их документирования (ISO, IEEE);
  • отечественные стандарты, касающиеся программ и систем и их документирования (ГОСТ, ГОСТ Р);
  • отечественные стандарты на конструкторскую и технологическую документацию (ЕСКД, ЕСТД);
  • методологии и практики ведущих компаний (RUP, MSF);
  • инструментальные средства для разработки электронной справки (Microsoft HTML Help Workshop, Help&Manual, RoboHELP);
  • технологии и средства для автоматизации документирования, в том числе для работы с единым источником (AuthorIT, DocBook/XML, DITA, SiberSafe);
  • текстовые процессоры и специализированные пакеты для подготовки технических публикаций (Adobe FrameMaker, Microsoft Word, OpenOffice);
  • языки разметки (HTML, XML и его приложения) и средства для работы с ними;
  • языки программирования, позволяющие автоматизировать разработку технической документации (VBA, XSLT);
  • понимание основ современных информационных технологий, основных идей, таких, как реляционные (и нереляционные) базы данных, локальные и глобальные сети, клиент-серверные технологии, объектно-ориентированное программирование и т.п.
  • методологии и языки моделирования (IDEF0, DFD-диаграммы, ER-диаграммы, UML) на уровне, который позволяет читать модели;
  • владение лингвистическим понятийным аппаратом и терминологией на уровне, который позволяет вести обсуждение текста при формулировании требований к его стилю, при его критике и редактировании;
  • умение пользоваться нормативно-справочной литературой по естественному языку, на котором технический писатель пишет.

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

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

Что касается зарплаты технического писателя в России, то среднее значение чисто арифметически вычислить можно, но смысла в нем не будет, потому что существует много «точек сгущения», и в каждой свое среднее. Есть крупные города (Москва, Санкт-Петербург), а есть регионы, есть малые, средние и крупные организации, есть отечественные и есть зарубежные фирмы, есть те, кто пишет по-английски и те, кто пишет по-русски, наконец, есть простые писатели, а есть начальники отделов документирования. Какое уж тут среднее, средняя температура по больнице. Проще говорить о максимуме и пути приближения к нему. Зарплатного потолка достигает руководитель отдела документирования, пишущий по-английски в крупной российской или иностранной компании в Москве (про заграницу, еще раз повторяю, не говорим, это вообще другая планета). Две-три тысячи долларов «белыми» при самом хорошем соцпакете такой сотрудник будет получать. На схожий компенсационный пакет можно рассчитывать и в средних российских компаниях, занятых внедрением ERP-систем (SAP, Axapta). Правда, дело тут совсем не в особой ценности технического писателя как такового; это средний уровень для руководителя небольшого структурного подразделения в организациях такого рода. Но причины не важны, главное, что такие вакансии есть, и, перепрыгивая из фирмы похуже в фирму получше, до них можно добраться. Дорогу осилит идущий.

© «Философт», 2008–2017

+7 (499) 500-44-77

mail@philosoft.ru

SpyLOG