Нужные люди без профессии
Для меня, студента, а потом выпускника московского технического вуза по специальности «Прикладная математика», середина 1990-х годов выглядела дивным новым миром и взрывом возможностей. Появлялись новые российские компании, новые продукты, приходили в Россию иностранные компьютерные и софтверные компании. И всё это было окружено многочисленными выставками, всевозможными семинарами, презентациями, журналами и еженедельниками.
«Войти в айти» тогда было сравнительно просто: бери и делай то, что можешь и умеешь или хочешь, хотя и не очень умеешь, но знаешь, что так бывает, и можешь убедить окружающих, что ты — как раз тот, кто так может.
В начале 1990-х был такой еженедельник «Софт Маркет» — первое (по крайней мере, так говорят) специализированное компьютерное издание в России. Меня взяли туда внештатным корреспондентом. Я прислал им книгу своих стихов и предложение: давайте сделаем у вас новую рубрику, литературное творчество программистов, я буду ее вести.
Они сказали: стихов не надо, а вот корреспондент нам сейчас нужен. Так я стал компьютерным журналистом.
Но оказалось, что для журналиста я недостаточно язвителен, а для автора рекламных статей слишком правдив. Пришлось перейти к крупной форме.
В одно прекрасное утро я выкинул со своего личного сайта всё, кроме объявления о том, что я готов писать техническую документацию. Дальше случилось удивительное: посыпались заказы. Оказалось, что это вообще кому-то нужно. Что я технический писатель, мне потом кто-то из этих заказчиков и рассказал.
Эта история довольно типична для первого поколения технических писателей. Многие из нас не получили специального техписовского образования, не учились под руководством мастеров. Мы просто увидели, что документация кому-то нужна, за ее разработку готовы платить. А как это делать — каждый определял в меру собственного понимания, полученного образования, опыта и вкуса.
Холивары и первые руководства
Мы в основном писали руководства по программным продуктам, которые одни небольшие и средние коммерческие предприятия выпускали для других таких же.
Отсутствие общей базы часто приводило к конфликтам между разными поколениями, традициями и подходами.
Специалисты старой советской закалки возмущались: «Техническую документацию разрабатывают инженеры по ГОСТам, какие писатели?» Люди из ИТ-бизнеса отмахивались: «Вашим ГОСТам место на свалке вместе со всем советским хламом. Посмотрите, как написана документация у нормальных людей: у Borland, у Apple…» Кто-то вообще шел от средств разработки: «У меня есть такой инструмент, лучший в мире, и делать надо так, как получается на нем».
В целом же мы скорее скептически относились к ГОСТам. Если наши тексты будет читать продажник, бухгалтер, сметчик, ответственный за пожарно-охранную сигнализацию в каком-нибудь офисном здании, — какая им разница, по ГОСТу ли написано руководство? Им важно понять, как с помощью программы решаются поставленные перед ними практические задачи.
Значит, думали мы, надо действовать по системе Станиславского: вживаемся в образ, говорим с читателем на его языке, осваиваем его систему понятий, а не пытаемся погрузить его в собственную.
А с другой стороны, в каких-то случаях надо и объяснять азы компьютерной грамотности. Юрий Кагарлицкий, ученый-филолог, мой коллега и давний соавтор, написал «Метагайд» — книгу, которая объясняла, как объяснять.
Постепенно стараниями таких неравнодушных людей были выпущены первые (в постсоветское время) учебники для технических писателей. Тут я хотел бы вспомнить ушедших старших коллег, Вадима Глаголева, который написал книгу о применении ГОСТов, и Владимира Головача, энтузиаста-редактора Adobe FrameMaker и автора книги по этому инструменту.
Эпоха госзаказа и обмена опытом
На мой взгляд, вторая волна популярности профессии возникла в период расцвета государственных ИТ-контрактов. Этот период начался с программы «Электронное правительство» и продолжался примерно до 2016 года.
Чтобы успешно сдать программы и автоматизированные системы заказчику-государству, на каждом этапе проекта нужно было предоставлять много формализованных документов. Причем значительная их часть была адресована не инженерам, а специалистам из предметных областей: от госслужащих среднего звена, ответственных за заказ и внедрение ИТ-решений, до многочисленных операторов и пользователей этих систем.
Во-первых, для этой работы сразу потребовалось много технических писателей. Во-вторых, появилась объективная необходимость сделать так, чтобы документация соответствовала ГОСТу и при этом была понятна и доступна целевой аудитории.
К тому времени холивары между «гостофилами» и «гуманитариями» (в какой-то период сильно напоминавшие полемику славянофилов с западниками) прекратились.
Постепенно выработался единый, более или менее сбалансированный подход к выбору стандартов, языковых и стилистических средств, инструментов разработки.
А главное — появилось достаточно много специалистов, которые считали документирование своей основной профессиональной деятельностью и работали примерно в одном стиле.
Наставлять эту «паству» или «проповедовать» ей что-то уже не имело смысла. Пришла пора собирать и систематизировать ее практику, выделять лучшие решения, описывать и распространять их. Этому очень способствовали конференции.
Замечательную серию конференций под названием «Гипербатон» сделала Светлана Каюшина со своей командой в Яндексе. Несколько хороших конференций провел Семён Факторович в новосибирском Академгородке. Интересные конференции были в Лаборатории Касперского, хотя они были целиком посвящены достижениям именно этой организации. Кроме того, было много разных небольших митапов.
От подрядчиков — к командным игрокам
Госструктуры остаются одним из основных потребителей на ИТ-рынке. Но исполнители госзаказов перестали быть основным потребителем и кузницей кадров. Это место заняли производители всевозможных электронных сервисов: банковских, потребительских, развлекательных, различные B2B. Сыграли свою роль кадровые «сверхпылесосы»: Яндекс, Сбер, ВТБ. Сложно найти специалиста, который хотя бы раз не ходил к ним на собеседования или не участвовал в работах по их подрядам.
В отличие от госзаказа, процессы в котором почти всегда однонаправленные — подписано, и с плеч долой, — там идет продуктовая разработка.
Это другая история: там требуется не только вовремя (то есть быстро) сделать и сдать заказчику приемлемый комплект документации, а и поддерживать и развивать его годами, повышать его качество, адаптировать к различным изменениям в продукте, учитывать его изменчивость по разным осям: версиям, конфигурациям, тарифам, уровням доступа.
Эта перемена потребовала от технических писателей осознать себя не столько авторами технических текстов, сколько инженерами, для которых текст или, обобщенно, контент — материал для изготовления продукта с определенными заранее заданными свойствами. К обязательным стилистическим и методическим скилам технических писателей добавились инженерные и технические. Они связаны как с необходимостью автоматизировать собственную деятельность, так и с намного более глубокой интеграцией технических писателей в процессы и команды разработчиков. Стали популярными подходы DocOps (по аналогии с DevOps) и Docs-as-Code.
Рынок создает стандарт
Одновременно в стране началась кампания по разработке профессиональных стандартов. Было сделано несколько попыток заменить унаследованную от Советского Союза систему специальностей и должностей чем-то более рыночным и актуальным. «Что это мы учим людей непонятно чему, давайте сначала работодатели выразят свои реальные требования к специалистам в виде профстандартов, а потом учебные заведения, вузы в том числе, адаптируют к ним свои образовательные стандарты и программы» — такая была идея.
Работу поручали разным ведомствам, потом она ушла к Министерству труда и там при определенном административном давлении сверху была реализована.
За профстандарты в ИТ отвечала Ассоциация предприятий компьютерных и информационных технологий (АПКиТ). Насколько я понимаю, никакой желаемой изначально рыночности из этого не вышло. Но многие современные профессии, отсутствовавшие в старых классификаторах, получили официальное признание. Требования к специалистам этих профессий были четко сформулированы и зафиксированы. Технический писатель был в их числе.
Чем полезен профессиональный стандарт?
Это официальный, утвержденный на государственном уровне документ, который описывает функции представителя определенной профессии и требования к его знаниям и умениям на разных уровнях квалификации.
Работодатели ориентируются на него, когда размещают вакансии, а учебные центры и их клиенты — когда составляют и выбирают программы повышения квалификации и дополнительного профессионального образования.
Ну а для самого специалиста заложенная в нем система уровней квалификации — что‑то вроде карьерной перспективы: помогает понять, как и куда расти.
Стандарт отражает изменения, которые произошли в профессии, ее зрелость. Сейчас от техписа требуется не просто создавать ясные и понятные технические тексты. Ему нужны глубокие технические знания, хорошее владение выбранной предметной областью, умение участвовать в процессах, присущих системной и программной инженерии.
Например, если вы отвечаете за документирование корпоративной системы для организации грузовых перевозок, вы должны:
хорошо разбираться не только в логистике, но и в том, как логистические процессы реализованы в системе с использованием микросервисов;
уметь взаимодействовать с разработчиками, быть частью их команды;
писать тексты, которые понятны и экспедиторам, и заказчикам перевозок, и водителям грузовых автомобилей;
описывать внутреннее устройство системы и ее программные интерфейсы так, чтобы разработчики могли получить всю необходимую информацию для их работы;
уметь автоматизировать свою деятельность, чтобы избежать рутинной работы с копированием и вставкой текста.
Куда и как расти специалисту
Действующая версия стандарта подготовлена авторским коллективом, состоящим из руководителей отделов документирования крупных организаций и специализированных компаний по разработке технической документации. Так что все, что там изложено, опирается на практику.
Стандарт предусматривает четыре уровня квалификации.
Первые два отведены начинающим специалистам. Они должны освоить основные инструменты и методы работы, их основная задача — написание качественного технического текста по предложенным им ограниченным темам и под руководством старших коллег.
Третий уровень отведен зрелым профессионалам, которые уже выбрали и приобрели определенную специализацию. Тут есть ветвление, что нетипично для профстандартов, и мы, авторы, долго убеждали методистов из Минтруда, что для технических писателей оно оправдано. Таких специализаций мы выделили три: специалист по техническим базам знаний, специалист по созданию документации для инженеров и руководитель рабочей группы технических писателей.
Самый высокий уровень отведен специалистам на руководящих должностях: руководителям отделов документирования или более крупных подразделений, ответственных за все поддерживаемые в организации формы технической коммуникации: документирование, локализацию и др.
Но осваивать профессию, опираясь только на стандарт, довольно сложно. Это объемный документ, по существу состоящий из прямых и косвенных ссылок на различные практики, инструменты и технологии, применяемые при разработке технической документации. Однако он не похож на учебную программу. Он не ведет читателя от одной ступени к другой, не дает ему пояснений — что конкретно имели в виду авторы в том или ином случае. К тому же его авторы были обязаны соблюдать строгие требования к нейтральности: не называть прямо никаких конкретных продуктов, источников и технологий, чтобы не рекламировать их.
И вот в помощь пользователям профстандарта мы с коллегами создали проект «Гостопедия». Это обширный справочник по различным вопросам, важным для разработчика технической документации: стандарты, жанры документов, язык и стиль, инструментарий. При этом в нем сделана привязка статей к требованиям профессионального стандарта «Технический писатель». Пользователь может читать стандарт и по ссылкам сразу переходить к статьям, проясняющим, что конкретно стоит за тем или иным требованием. Проект постоянно развивается, пополняется статьями. Проект работает по принципу Википедии. Мы приглашаем коллег пользоваться им и включаться в его развитие в качестве соавторов
