Технический писатель
Важную роль в поддержке и продвижении ИТ-решений занимает качественная документация. Ее подготовка и разработка входят в круг обязанностей технического писателя. Именно от его знаний, опыта, умения представить в доступной для целевой аудитории форме информацию об ИТ-решении зависит то, какое мнение сложится у клиентов, как потенциальных, так и текущих. Мы попросили представителей компаний рассказать о знаниях, навыках, опыте, актуальных для технического писателя
1. Технический писатель: какими знаниями и навыками должен обладать?
2. Инструментарий технического писателя?
3. Каковы требования компании к уровню образования потенциальных сотрудников?
4. Какие требования предъявляются к опыту работы?
5. Есть ли особые требования, которые обусловлены спецификой деятельности компании?
Милена Чебыкина, руководитель отдела технической документации ИТ-компании «Нетрика»
1. Профессия находится на стыке наук, поэтому необходимы как хорошее знание русского языка и навыки работы с текстом, так и техническая «подкованность».
Знания технической части могут быть неглубокими – уметь программировать и паять не нужно, но от слов ПАК и Ubuntu технический писатель не должен вздрагивать.
Обязательно уметь работать с большими объемами информации и структурировать ее. Кроме того, необходимо иметь навыки верстки текста в соответствии с заданными требованиями.
Технический писатель должен понимать профессиональный сленг разработчиков и уметь формулировать простым понятным языком сложные технические термины и описывать процессы, обладать навыками деловой переписки и знать принципы работы с архивом, понимать и уметь трактовать нормативно-правовые документы.
2. Основным инструментом является Microsoft Office, но на хорошем профессиональном уровне. Однако есть и профессиональные инструменты, например, AutorIT, Help&Manual.
Имеет значение инструмент для снятия скриншотов (снимков экрана или выделенной области), например мы используем Clip2net.
Для учета трудозатрат на проект и поставленных задач, как правило, используются системы багтрекинга, мы применяем Atlassian Jira.
С ведением учета версий хорошо справляется Atlassian Confluence.
3. В нашей компании нет общих для всех кандидатов требований, кроме одного – высшего образования. Не очень важна и специализация по опыту.
У меня в отделе работают сотрудники как с гуманитарным, так и с техническим образованием – примерно поровну. В компании среди наших технических писателей есть экономист, филолог, педагог, математик, программист и инженер.
Сегодня техника и технологии настолько глубоко внедрены в нашу повседневную жизнь, что для ввода в профессию базовых навыков достаточно.
4. Требуемый опыт работы зависит от позиции. Меня на собеседовании в основном интересует несколько критериев:
- скорость «вникания» в новую предметную область;
- умение быстро переключаться между несколькими предметными областями;
- умение работать с большими объемами информации;
- внимательность (это очень важный критерий);
- умение работать с текстом;
- уровень владения русским языком;
- навыки описания программного обеспечения;
- ну и, конечно, умение работать в команде.
5. В связи с тем, что наша компания ориентирована на работу с государственными заказчиками, опыт работы с подобными проектами для нас является преимуществом.
Нам также важно умение кандидата работать с ГОСТ, РД и нормативно-правовыми актами.
Мы учитываем умение описывать программное обеспечение, а также знание принципов разработки, развития и сопровождения автоматизированных систем и программно-аппаратных комплексов.
Лично для меня при подборе кандидатов очень важно определить направление развития в профессиональном плане и понять, как кандидат представляет себе профессию и свое развитие – если, конечно, представляет.
Для меня на собеседовании очень важно получить от соискателя ответ на вопрос: от чего человек получает удовольствие в профессии? Одним важны интересные проекты, другим – социальная направленность, третьим – сфера информатизации, а четвертые просто хотят заработать – от этого зависит, как дальше строить работу с этим специалистом.
Анна Гаспарян, технический писатель в команде IntelliJ IDEA, компания JetBrains
1. В первую очередь технический писатель должен уметь быстро разобраться в новом продукте или технологии и уметь изложить сложные вещи простыми словами.
Нужно также уметь анализировать большие объемы информации и структурировать ее, выделять главное, видеть за отдельным функционалом конкретные сценарии использования.
Мы пишем для наших пользователей, а значит, должны встать на их место, посмотреть на продукт их глазами, увидеть проблемы, с которыми они могут столкнуться в своей работе, и показать им, как их можно эффективно решить с помощью наших продуктов.
Очень нужны навыки общения – часто разработчики являются единственным источником информации, поэтому необходимо уметь ее от них получить.
Так как всю документацию мы пишем на английском языке, конечно, технический писатель должен владеть им в совершенстве. Излишне говорить, что документация должна быть безупречной с точки зрения грамотности и презентации контента – ведь она является одним из факторов «доверия» к продукту.
Технический писатель должен быть проактивным. Нельзя ждать, что обо всех новых фичах тебе обязательно вовремя расскажут. Нужно уметь самому добывать информацию из разных источников, главным из которых, конечно, является сам продукт.
В нашей команде в этом смысле технические писатели находятся на особом положении – мы для нашей работы сами используем IDE, о которой пишем, поэтому часто сразу видим изменения функционала, а также в каком-то смысле тестируем его с точки зрения usability – ведь если интерфейс нуждается в сложных дополнительных пояснениях, значит, это неудачный интерфейс и стоит подумать о том, как его улучшить.
2. Как я уже сказала, мы пишем документацию в IDE IntelliJ IDEA, используя специальный плагин, разработанный нашей командой Internal Development. Мы пишем на языке XML, используя адаптированную под наши задачи схему. Весь исходный код хранится в системе контроля версий Git.
3. Это очень сложный вопрос. До сих пор в нашей стране, насколько я знаю, в вузах не учат, как писать документацию, и нельзя получить диплом по специальности «Технический писатель». Поэтому обучение происходит в основном уже в процессе работы.
Обычно техническими писателями становятся люди с филологическим образованием, так как они отлично умеют писать на английском языке, или «технари» с отличным знанием английского (но таких меньше).
За 15 лет работы техническим писателем я столкнулась с тем, что разные компании предъявляют очень разные требования к этой профессии. Поэтому для нас важен не диплом, а опыт работы.
4. Необходим опыт работы в серьезной ИТ-компании, желательно делающей программные продукты для разработчиков.
5. Так как наши конечные пользователи – программисты, а научить других тому, чего не умеешь сам, непросто, нужно иметь представление о том, из чего, собственно, состоит процесс разработки продукта.
Технический писатель должен:
- понимать, что такое компиляция кода, тестирование, отладка,
- понимать принципы работы с системами контроля версий, системами автоматической сборки, фреймворками и т.д.
В идеале, конечно, нужно иметь хотя бы базовые знания о языке программирования, для которого предназначена описываемая IDE.
Татьяна Гришина, технический писатель в Tutu.ru
1. Технический писатель, разумеется, должен быть грамотным и должен уметь представлять информацию любой сложности в понятном и доступном виде. Дополнительным плюсом для технического писателя является знание ГОСТов (например, 19-й или 34-й серий) – это помогает ему в структурировании документации.
2. Инструментарий технического писателя многообразен: это и стандартный офисный пакет, и Wiki-системы, и системы автодокументирования. В Туту.ру используется Atlassian Confluence. На мой взгляд, это очень удобная и прозрачная Wiki-система, позволяющая хранить большой объем документации в одном месте.
3. Высшее или незаконченное высшее техническое. Желательно ИТ-направления, т.к. происходит плотное общение с разработчиками, и лучше говорить с ними на одном языке.
4. Большой плюс, если человек ранее работал с Wiki-системами и занимался описанием программных продуктов.
5. Особых требований нет.
Дмитрий Шурупов, соучредитель компании АО «Флант»
1. Технический писатель – специалист, находящийся на стыке двух областей, поэтому он должен любить и знать язык, на котором пишет, и технологии, о которых пишет.
В случае легкой доступности технических специалистов, способных помогать по всем вопросам, познаниям писателя в области технологий можно сделать большую скидку.
Однако для создания качественных материалов увлеченность этими технологиями обязательно должна присутствовать, а слабое их понимание приведет к большим дополнительным затратам (на время привлечения других профессионалов и последующие осмысление, структурирование полученной информации).
2. Текстовый редактор, офисный пакет, а также любые средства создания схем/диаграмм и, возможно, презентаций.
3. В нашей компании пока нет такой отдельной должности среди штатных сотрудников. Если мы не берем на проект внештатного специалиста, то во многом такие функции выполняю я.
Обладая высшим техническим образованием, еще со школьного возраста пишу тексты технической направленности и имею большой опыт работы в качестве редактора.
Нанимая нового технического писателя, я бы обратил внимание на наличие у него высшего образования – желательно (но даже не обязательно) в области ИТ или журналистики, но более важным (решающим) фактором является опыт.
4. Необходима демонстрация уже созданных соискателем материалов, которыми могут оказаться:
- профессиональная техническая документация;
- обычные публикации/инструкции в блоге или на каком-то специализированном сайте;
- опыт практической работы с любыми из интересных технологий.
5. Поскольку основной текущей деятельностью нашей компании является DevOps, создаваемая техническая документация обычно относится как минимум сразу к двум ИТ-областям:
- системному администрированию (GNU/Linux);
- и разработке (Web).
В связи с этим к техническим компетенциям писателя предъявляются высокие требования в ИТ, необходимо иметь понимание:
- о техническом устройстве GNU/Linux и обслуживании таких систем (в частности, с подходом Инфраструктура-как-код, IaC);
- о полном цикле разработки;
- об основах взаимодействия разработчиков и DevOps-инженеров (с применением Agile, Scrum). eof
Подготовил Игорь Штомпель