Большую часть дня, исключая беседы и различные семинары, технический писатель посвящает себя работе за компьютером. О том, как устроена работа технического писателя в сфере заказной разработки, рассказывает Сергей Кузьмишкин, руководитель подразделения в компании Notamedia. найм технических директоров, что бизнес ждёт от человека на позиции директора и какими глазами смотрит на соискателя. TechWriter Days прошла 5-6 апреля 2024 в енция организована с целью собрать и объединить специалистов, занимающихся технической документацией. Станислав, вы описали самый отличный день технического писателя.
Работа технического писателя в IT-компании: цели, зоны роста, кому подходит
На сайте в рубрике «Наука и техника» всегда свежие новости за день и неделю. Актуальные и свежие новости в стране и мире, эксклюзивные материалы и мнения экспертов. Технический писатель рассказывает о своём рабочем дне, объясняет, что это за профессия, какие инструменты применяются и какие навыки нужны. Станислав, вы описали самый отличный день технического писателя. В свою очередь, технический писатель вносит исправления и проверяет, чтобы они соответствовали остальному тексту.
Открылась выставка «С красной строки» к 100-летию со дня рождения писателя Анатолия Митяева
Положила учебник на коленки :grin: Учитель заметил, конечно, и влепил двойку. А ещё один раз я написала сочинение по какому-то произведению и получила 2 за то, что поняла его не так, как учитель". Уже не помню, почему так случилось, помню только как мне было страшно и стыдно рассказывать об этом дома :scream: Когда приходила исправлять, учительница всё приговаривала: ну как же так, ты же умная девочка, неужели не вспомнила вот это правило? Часто писала по 6-7 страниц текста, а не сделать ошибок в таких длинных текстах сложно".
Ориентировочно мероприятие займёт 2 часа. Тема: «Инструменты технического писателя». Анастасия подготовила доклад «Создаём документацию с удовольствием в MadCap Flare», в котором она поделится своим многолетним опытом работы в MadCap Flare, а вы сможете задать ей любые вопросы. Кстати, недавно в нашем блоге была статья Анастасии на эту тему. Далее технический директор компании «ПроТекст» Валерий Ледовской расскажет о средствах нашей работы: «Инструменты компании ПроТекст при выполнении задач технического перевода и локализации на аутсорсинге». Затем нам хотелось бы послушать рассказы самих участников об использовании разных инструментов, кроме самого распространённого варианта — Microsoft Word.
Хотя если вы используете его каким-то необычным образом, мы тоже с удовольствием узнаем и о вашей практике! Готовьте рассказы, придумывайте вопросы для обсуждения, ибо круглый стол — это место для общения. Приходите рассказывать и спрашивать, говорить и спорить, а не только слушать! Если вы подготовите презентацию, присылайте файл до начала встречи, и мы сможем оперативно подгрузить его в вебинар. Планы на будущее Также просим вас подумать, чего бы вы хотели от таких встреч — пишите свои предложения нам на адрес info protext.
Я уверен, что в ближайшие десятилетия профессия технического писателя не только останется нужной и востребованной, но будет обретать всё большую популярность и ценность на рынке. Текста больше, чем кода — Кто за сутки до отправки заказчику во всей инструкции заменил manual на manul?! Давайте окинем взглядом весь процесс разработки программного обеспечения. Его главный результат — это, конечно, программный код.
А его главными действующими лицами всегда были и будут программисты, что бы там ни говорили другие его участники. Но сам этот процесс попутно порождает большое количество текстовых артефактов. Тут и функциональные требования заказчика, и техническое задание, и многочисленные протоколы совещаний, и переписки в чатах, и комментарии к запросам в системе планирования задач, и, наконец, описание реализации. А ведь есть ещё многочисленные комментарии в коде, которые тоже содержат много нужной информации. В общем, текстов хватает. Так зачем же тогда в самом конце разработки нужен ещё и технический писатель? Почему всех этих документов недостаточно для того, чтобы дать ответы на основные вопросы заказчика и пользователя: как работает система и как её настроить? Будем разбираться. Разработчики должны писать код, а не текст «Условие, что поле PART должно быть не пустым, обеспечивается целостностью процесса, заполняющего это поле, и не обеспечивается отдельным ограничением Oracle типа NOT NULL для обеспечения максимального быстродействия при изменении данных таблицы».
Из внутренней документации проекта Бывает так, что программисты прекрасно разбираются в программе, досконально понимают все тонкости работы системы, но не могут красиво изложить всё это в текстовом виде. Лично я убеждён, что в этом нет ничего плохого. Согласитесь, что даже текст, написанный с орфографическими и стилистическими ошибками, может быть понятным и успешно выполнять свою функцию — доносить до читателя мысль автора. А ошибки — это дело поправимое, коррекцию и правку текста при необходимости может выполнить редактор или тот же технический писатель. Главное — не допускать ошибок фактических. Каждый должен заниматься своим делом. Например, математику или физику часто проще написать формулу, чем объяснить словами какой-то закон. Программисту проще выражать свои мысли в виде кода и алгоритмических конструкций. Когда же дело доходит до формулирования чётких и понятных текстов на русском или другом языке, в дело вступает технический писатель.
Это тот самый специалист, который переводит информацию с языка разработчиков на язык пользователей. Не было бы технических писателей, и программистам пришлось бы самим напрягаться, пытаясь объяснить такие понятные и очевидные для них вещи обычным пользователям системы. Стройная система подпорок и противовесов Хогвартс напоминает любой IT-проект, который разрабатывается долгое время. Древние баги, нигде не прописанные фичи, несовместимости, куча сдерживающих этот ужас костылей и несколько программистов, которые даже не хотят лезть в неведомые глубины и гордо называют их «школьными традициями».
Здесь пройдет занятие «С книгой назначена встреча…». Детям расскажут интересные факты из жизни русских писателей Александра Пушкина, Ивана К рылова, Аркад ия Гайдара, чьи ю билейные даты пришлись на текущий год. А еще библиотекари помогут гостям найти ответы на вопросы о том, кто такие писатели и в чем состоит их труд. Еще для ребят проведут конкурсы, в которых они смогут проявить свою эрудицию, начитанность и смекалку. Начало в 11:00. Здесь будет организована праздничная программа, которая начнется в 14:00. Помимо этого, школьники расскажут о своем любимом авторе и произведениях, которые их впечатлили больше всего. Халтуринская, д. Он будет посвящен 220-летию со дня рождения писательницы и историка Александры Ишимовой. Гостей познакомят с биографией автора детских произведений XIX века. Еще на занятии расскажут о самой знаменитой книге Ишимовой «История России в рассказах для детей». Затем участники вместе прочтут рассказ писательницы «Как славяне хозяйничали». А еще им предложат поучаствовать в игре «Преданья старины глубокой», которая поможет вспомнить героев российской истории и их роль в истории страны. День писателя отмечается 3 марта во всем мире на протяжении последних 37 лет. Это значимый праздник для профессионального сообщества и учреждений культуры. В День писателя организуют концерты, семинары, встречи авторов с читателями, посвящают мероприятия знаменитым литераторам и их произведениям.
Наука и техника
Только так получится хорошая и качественная документация. Процесс работы технического писателя. Чаще всего у документации есть заказчик. Это может быть менеджер, разработчик, дизайнер — любой человек, осознавший, что есть какая-то проблема в понимании происходящего. Задача технического писателя — определить, реальна ли проблема и в каком формате её нужно решать. Вот как строится процесс работы: Определение главных задач документации и ее аудиторию. Составление плана технической документации и согласование его с заказчиком. Здесь скорее всего, будут изменения, поэтому важнее понять какие вопросы хочет решить заказчик.
Изучение как работает программа или устройство. На этом этапе важно найти экспертов, кому можно будет задавать уточняющие вопросы и договориться о формате работы с ними. Обязательно уточнить что непонятно у инженеров. Поиск и подготовка иллюстрации к тексту. Наполнение документа текстами и отправка его на проверку экспертам. Внесение правок от разработчиков и экспертов. Презентация документации заказчику.
Передача документации команде. Этапы не должны затягиваться. Если пошёл уже пятый круг обсуждения структуры документа, который ещё даже не начали наполнять — что-то пошло не по плану. Финальное согласование с окончательной заморозкой структуры и текста происходит только тогда, когда уже всё написано и проверено. Своих технических писателей я учу: при постановке задачи важно, чтобы заказчик не пытался переписать ваш текст согласно своему субъективному взгляду. Факты и термины — да, тут он эксперт, но вкусовщину надо учиться фильтровать, иначе процесс может затянуться». Елена, технический директор IT-компании Что должен знать и уметь технический писатель.
Профессии технического писателя в российских вузах не учат. Есть курсы, где можно научиться писать технические тексты, но их немного. Поэтому осваивать такую профессию часто приходится по статьям в интернете, ориентируясь на примеры других. Это хорошая профессия для людей, желающих работать на стыке технического и гуманитарного направлений. В отличие от копирайтинга, здесь меньше творчества и больше регламентов. Soft skills и Hard skills технического писателя в концепции Модели компетенций команды цифровой трансформации в системе государственного управления подробно описаны в Профиле роли. Технический писатель должен сочетать в себе свойства технаря и гуманитария.
Интерес к технике и программированию, усидчивость и внимательность должны в нём сочетаться с желанием осваивать новое и делиться своими знаниями. Очень важно знать предметную область, в которой ведется работа. Например, если вакансия открыта в ИТ-компании, потребуется знать языки программирования и разбираться в процессах разработки софта. Список ПО зависит от отрасли, в которой трудится специалист. Нужно уметь работать в команде, общаться с разработчиками и понимать пользователей, которые будут использовать продукт. Часто работа идет в стандартных текстовых редакторах и программах для работы с изображениями. В некоторых IT-компаниях требуется, чтобы технический писатель знал языки разметки текста или один из языков программирования на уровне чтения кода, другим важны навыки работы с базами данных или в системах управления запросами.
То, что пригодится точно — интерес к той сфере, о которой технический писатель работает.
Так и новый роман автора — "Позови меня, Ветлуга" о зове Родины, на который откликаются герои — пусть даже неосознанно. Так, по мнению Олега Рябова, хороший писатель должен, в первую очередь, писать. Во-вторых, писать надо правдиво. И еще один важный момент — автор должен быть в курсе литературного процесса, знать мастеров прошлого и будущего. В таком случае текст получится достойным.
Еще один важный момент — технический писатель должен не только предоставить заказчику комплект отчетной документации, но и согласовать ее с ним. Если клиенту что-то не нравится — выяснить, что именно, и понять, как это исправить. Куда расти техническому писателю Представим ситуацию, что человек приходит на позицию технического писателя, перерастает грейд Junior и в какой-то момент начинает думать: «А куда дальше развиваться?
Буду ли я до конца карьеры писать технические документы, такие как руководство пользователя? У технического писателя есть конкретные зоны роста — как горизонтального, так и вертикального. Поговорим о горизонтальном росте подробнее. Хороший технический писатель должен знать, какие шаги нужно пройти для успешной сдачи проекта. Это шаги, которые находятся не только в его компетенции, но и которые должны пройти другие участники команды: дизайнеры — нарисовать макеты, разработчики — написать код, аналитики — описать бизнес-процессы. И контроль выполнения работ другими участниками команды тоже может быть в числе обязанностей техписа. Также техпис должен уметь оценивать затраты на разработку той или иной документации: Сначала сформулировать требования к другим участникам команды — в каком виде и в какие сроки ему должны предоставить исходные данные для формирования комплекта отчетной документации. С учетом качества и количества исходных данных прикинуть свои трудозатраты на формирование отчетной документации. Уложить это все на план-график исполнения контракта, понять, сколько нужно людей, какой трек согласования документации, и как вообще при этом выжить.
То есть это процессное и ресурсное управление, которым он должен владеть. И это схожие процессы с теми, которые есть у руководителя проекта. Что из этого следует: техпис может быть правой или левой рукой руководителя проекта и, соответственно, в этом направлении развиваться. Так что хороший техпис может вырасти до РП. Иногда это классическая аналитика при ведении проектов, когда сначала есть общие верхнеуровневые требования, а затем надо проговорить с заказчиком, что сделать — декомпозировать эти требования, провести трассировку, управлять ими. Бывают и неклассические аспекты аналитики. Например, мы берем проект, которым ранее занимался другой подрядчик. И теперь нам надо его развивать. Стартовая задача технического писателя — это разобраться в этом проекте, провести Reverse engineering технической части проекта: что написано, как это работает.
Вторая задача — посмотреть на документы, какие были договоры и технические задания. И понять, что реально представляет собой проект или конкретный продукт, и соотнести с тем, что написано в документах. То есть это Reverse engineering с прицелом на формальную часть. Сергей Кузьмишкин, руководитель подразделения Nota. Docs Нетипичный случай аналитики также возникает, когда нужно обосновать заказчику стоимость работ в ходе формальных процедур по подготовке к конкурсу. И тут надо понять детали реализации — сходить к разработчикам, понять, что они реализовали, и каким образом эта функциональность работает. Если разработчики еще не реализовали, то идти к продактам, которые развивают данную часть продукта, и узнавать, что они задумывали и сделали. Все это нужно оформить и защитить перед заказчиком, иногда вплоть до демонстрации кода продукта. Поэтому технический писатель может вырасти в аналитика.
В крупных контрактах, как коммерческих, так и государственных, есть правила привлечения генподрядчиком субподрядчиков: на какие работы их можно привлечь, на какие нет, на какие работы нужно привлечь обязательно. Типичный пример — если на проекте выполняются работы по информационной безопасности, то они требуют наличия лицензий, которых у генподрядчика может не быть.
У нас есть специальный тип задач с префиксом DOC. Обычно они связаны с задачами на разработку или с запросами заказчиков. Задачи на документирование создают менеджеры, которые ведут проект, тестировщики, сотрудники службы поддержки. Заказчик тоже может инициировать изменение документации, задав вопрос, высказав пожелание или жалобу. Team Lead нашей команды планирует деятельность каждого писателя, распределяет задачи, следит за их выполнением и отгрузкой документов. Для всех участников процесса разработки главное — не забыть создать задачу, ведь писатели должны откуда-то узнать о том, что что-то нужно задокументировать. К сожалению, у нас всё ещё бывают такие ситуации, когда подходит срок отгрузки новой системы, а заявка на документирование этой системы не создана.
В этом случае чуда не произойдёт — документация не появится моментально. Внутренняя «кухня» — источники вдохновения Начиная работать над очередной задачей, писатель изучает многочисленные источники информации и преобразует полученные оттуда данные в пользовательскую документацию. Источников у нас много. Самый главный — это технический проект ТП , которые пишут бизнес-аналитики ещё до начала разработки. ТП — это закон для разработчиков, тестировщиков и технических писателей. В идеале всё должно быть реализовано именно так, как написано в ТП. На деле же оказывается, что итоговая реализация отличается от ТП. Вы знаете, как это бывает: что-то не учли, что-то поняли неправильно, что-то оптимизировали… Для того, чтобы узнать, как на самом деле всё было реализовано, мы используем техническое описание ТО , которое пишут разработчики. Там есть больше технических подробностей, описаны изменения конкретных типов данных и таблиц в БД, приведены алгоритмы работы процедур серверного кода, приведены скриншоты добавленных или изменённых окон в клиентских приложениях.
Без ТО нам было бы очень трудно написать полноценную документацию. К сожалению, разработчики иногда откладывают написание ТО на самый последний момент. Есть ещё один важный источник — описание настроек интеграционного тестирования. Там подробно описаны все настройки, которые нужно сделать в системах, чтобы пройти все тестовые сценарии тест-кейсы. Этот источник незаменим для написания руководств по настройке. ТП, ТО и описание настроек — это основные источники, из которых писатель получает информацию. Но есть ещё множество дополнительных: исходный код серверных процедур и клиентских приложений, XML-описания параметров, страницы в базе знаний Wiki, наконец — вопросы разработчикам и тестировщикам в мессенджерах. Ну и, конечно, сами системы — их web-интерфейс, клиентские и серверные приложения. Задача писателя — объединить всю полученную информацию и написать простую, понятную и хорошо структурированную документацию о системе или решении.
Тут нужно быть очень внимательным — ничего не перепутать, не забыть, описать именно то, что было реализовано. Писатель должен самостоятельно разобраться во всех особенностях реализации, понять все алгоритмы и принципы работы системы от начала и до конца. Только так получится хорошая и качественная документация. Один в поле не воин Часто думают, что технический писатель — это профессия, не требующая особых коммуникативных навыков. На практике оказывается, что для написания документации каждый день приходится консультироваться со множеством коллег: бизнес-аналитиками, разработчиками, тестировщиками. Бывает так, что в исходных документах авторы что-то опускают, что-то недоговаривают. Работа писателя — быть профессиональным занудой: уточнять, переспрашивать, перепроверять информацию много раз, чтобы правильно всё описать и не допустить ошибку в документе.
Наука и техника
Технический писатель: Новые тенденции и требования в документации '23 from Vlad Orlikov. Выходит, что технические писатели в пользовательской документации исправляют все недостатки, ошибки и неточности, допущенные во внутренней документации и метаданных в процессе проектирования и разработки системы. Последние события в режиме онлайн: главные новости российского бизнеса и политики, международные события, криминальные происшествия, обзоры прессы, движения фондового рынка, лента спортивных новостей, автомобильные новости.
TechWriter Days
Лично я убеждён, что в этом нет ничего плохого. Согласитесь, что даже текст, написанный с орфографическими и стилистическими ошибками, может быть понятным и успешно выполнять свою функцию — доносить до читателя мысль автора. А ошибки — это дело поправимое, коррекцию и правку текста при необходимости может выполнить редактор или тот же технический писатель. Главное — не допускать ошибок фактических. Каждый должен заниматься своим делом. Например, математику или физику часто проще написать формулу, чем объяснить словами какой-то закон. Программисту проще выражать свои мысли в виде кода и алгоритмических конструкций. Когда же дело доходит до формулирования чётких и понятных текстов на русском или другом языке, в дело вступает технический писатель. Это тот самый специалист, который переводит информацию с языка разработчиков на язык пользователей. Не было бы технических писателей, и программистам пришлось бы самим напрягаться, пытаясь объяснить такие понятные и очевидные для них вещи обычным пользователям системы. Стройная система подпорок и противовесов Хогвартс напоминает любой IT-проект, который разрабатывается долгое время.
Древние баги, нигде не прописанные фичи, несовместимости, куча сдерживающих этот ужас костылей и несколько программистов, которые даже не хотят лезть в неведомые глубины и гордо называют их «школьными традициями». Мы уже привыкли и считаем нормальным, что у наших программ есть много недокументированных возможностей. Если система живёт и развивается уже несколько лет, то в ней с каждым годом появляется всё больше исключений из правил. В неё добавляются новые функциональные возможности, старые отмирают или видоизменяются. Настройка системы становится всё сложнее, в интерфейсе появляется всё больше параметров, которые взаимодействуют друг с другом неочевидным и зачастую непредсказуемым образом. Постоянная гонка за быстрой реализацией новых бизнес-возможностей приводит к тому, что сокращается время на рефакторинг старого кода и устаревших интерфейсов. Так и остаются в системе старые и недействующие параметры и настройки. Представьте, каково пользователям работать в такой «пожилой» системе без сопроводительной документации, которую пишут технические писатели. Это всё равно, что управлять атомным реактором, не прочитав предварительно многотомное руководство по интерфейсу пульта управления. Как говорил Гомер Симпсон: «На такую-то кнопку так сразу и не нажмёшь».
Внутренние документы по системе, порождённые в процессе разработки, представляют для пользователя неразрешимую головоломку. Без пользовательской документации он просто «утонет» в многочисленных описаниях итерационных изменений, выполненных в различных местах системы. Задача технического писателя — всё это объединить, систематизировать, структурировать и изложить понятным пользователю стандартизированным языком. Кстати, бывает, что аналитики, разработчики и тестировщики сами с трудом ориентируются во внутренней документации. Чтобы быстро найти ответ на свой вопрос они часто пользуются документацией, написанной техническими писателями.
А в другом проекте я пишу небольшую часть документации по функциональности продукта для обычных пользователей. Здесь тексты простые, информативные и доступные. Моя основная задача — сделать так, чтобы и системный администратор, и обычный пользователь нашли в инструкции то что ищут и этот поиск не занял много ресурсов». Приступая к написанию любой инструкции, технический писатель анализирует многочисленные источники информации и преобразует полученные оттуда данные в пользовательскую документацию.
Самый главный источник — это технический проект ТП , которые пишут бизнес-аналитики ещё до начала разработки. Технический проект — это закон для разработчиков, тестировщиков и технических писателей. В идеале всё должно быть реализовано именно так, как написано в ТП. На деле же оказывается, что итоговая реализация отличается от ТП: что-то не учли, что-то поняли неправильно, что-то оптимизировали. Для того, чтобы узнать, как на самом деле всё было реализовано, используется техническое описание ТО , которое пишут разработчики. Там есть больше технических подробностей, описаны изменения конкретных типов данных и таблиц в БД, приведены алгоритмы работы процедур серверного кода, приведены скриншоты добавленных или изменённых окон в клиентских приложениях. Есть ещё один важный источник — описание настроек интеграционного тестирования. Там подробно описаны все настройки, которые нужно сделать в системах, чтобы пройти все тестовые сценарии тест-кейсы. Этот источник незаменим для написания руководств по настройке.
Технический проект, техническое описание и описание настроек — это основные источники, из которых писатель получает информацию. Но есть ещё множество дополнительных: исходный код серверных процедур и клиентских приложений, XML-описания параметров, страницы в базе знаний Wiki, наконец — вопросы разработчикам и тестировщикам в мессенджерах. Ну и, конечно, сами системы — их web-интерфейс, клиентские и серверные приложения. Задача писателя — объединить всю полученную информацию и написать простую, понятную и хорошо структурированную документацию о системе или решении. Тут нужно быть очень внимательным — ничего не перепутать, не забыть, описать именно то, что было реализовано. Писатель должен самостоятельно разобраться во всех особенностях реализации, понять все алгоритмы и принципы работы системы от начала и до конца. Только так получится хорошая и качественная документация. Процесс работы технического писателя. Чаще всего у документации есть заказчик.
Это может быть менеджер, разработчик, дизайнер — любой человек, осознавший, что есть какая-то проблема в понимании происходящего. Задача технического писателя — определить, реальна ли проблема и в каком формате её нужно решать. Вот как строится процесс работы: Определение главных задач документации и ее аудиторию. Составление плана технической документации и согласование его с заказчиком. Здесь скорее всего, будут изменения, поэтому важнее понять какие вопросы хочет решить заказчик. Изучение как работает программа или устройство. На этом этапе важно найти экспертов, кому можно будет задавать уточняющие вопросы и договориться о формате работы с ними. Обязательно уточнить что непонятно у инженеров. Поиск и подготовка иллюстрации к тексту.
Наполнение документа текстами и отправка его на проверку экспертам. Внесение правок от разработчиков и экспертов. Презентация документации заказчику. Передача документации команде. Этапы не должны затягиваться. Если пошёл уже пятый круг обсуждения структуры документа, который ещё даже не начали наполнять — что-то пошло не по плану.
Показать описание вакансии Обязанности: Разработка сетевых графиков проектов, конструкторской и эксплуатационной документации, схем, маршрутных карт и другой технической документации, внесение изменений в техническую документацию в связи с корректировкой; Разработка конструкторской и эксплуатационной документации; Ведение переписки с заказчиком и исполнителями составной части опытно-конструкторской работы, документооборот; контроль сроков выполнения работ по договорам; участие в ведении архива документации учёт, регистрация, выдача, копирование, актуализация ; участие в совещаниях по направлениям разработки и сопровождения инфраструктуры; Отчётность по договорной работе. Умение вести документооборот, знание в области ведения контрактной работы; умение быстро включаться в работу, адекватно воспринимать задачи и выполнять их в указанные сроки; Знание нормативной докуметации по ГОСТ 19, 34 желательно с применением на практике. Знание серии докуметов ГОСТ 2 желательно с применением на практике.
Гофман, Т. Панченко, Б. Новгород: «Эльдорадо», 224 с. Нижний Новгород: изд-во «Книги», 2009. Новгород, 1999. Ночные костры; Ю. Странноприимный дом. Новгород, 2002. Новгород, 2006. Новгород, 2001. Дом-корабль: рассказы детям о взрослых и взрослым о детях. Новгород: Фонд «Народный памятник», 2006.
День технического специалиста на PulpFor 2023
Технические писатели. Опыт работы в должности бизнес-аналитика или технического писателя от 1 года. Презентация писателей – педагогов, внесших большой вклад в образование, подготовила библиотекарь ТТВТС Шевердяева И. В. Историю празднования Дня писателя узнают те, кто придет в библиотеку №107 (Перовское шоссе, д. 16/2). Самые свежие новости России и мира, новости политики, шоу-бизнеса. девушка при исполнении, а в свободное время - поэт.
#Кем стать: Техническим писателем
Над отдельным проектом обычно работает не один человек, а несколько. Поэтому нужно, чтобы каждый был в курсе дел и смог вовремя получить необходимую информацию. После летучки возвращаюсь на рабочее место. Сегодня мне нужно описать работу новой программы. Список отбираемых работ берется не наобум. Ежедневно никто не станет напоминать, что тебе нужно описать. Процессом планирования занимается сам технический писатель: пересматривает документы отделов разработки что сделали, как это работает , открывает тестовые разработанные программы смотрит и вручную проверяет их работу. И из всей полученной информации выбирает только то, что влияет на документацию.
Теперь я создаю документ, в котором буду разрабатывать описание программы. Перед началом описания необходимо изучить функционал. То, как вы поймете его изначально, повлияет на качество текста в целом. Чтобы посмотреть, как работает программа, запрашиваю ее в отделе разработки. Для начала в документе создаем примерную структуру — в какой книге будет располагаться новый текст, какие разделы появятся, что они будут в себя включать. Книги обычно подразделяются на руководства для пользователя, администратора и разработчика. В зависимости от этого, описание выполняется на языке, понятном представителю одной из ролей.
Например, для пользователя нужно писать «простым» языком, давать подробный порядок действий, для разработчика, напротив, нужны четкие формулировки с терминами, описание рабочих примеров кода. Вам сложно понять, что нужно писать, с чего начинать, как писать?
И будут неправы. Но они должны много знать и доходчиво излагать свои мысли, уметь писать и одновременно разбираться в технике и технологиях, чтобы сложные вещи объяснить простым и понятным языком». Технический писатель изучает существующее оборудование или программу и, вникнув в них до уровня разработчика, пишет инструкции различного уровня, в том числе для пользователей, по которым со сложной программой или устройством без проблем сможет разобраться даже новичок.
Таким образом, технический писатель — это профессиональный писатель, который разрабатывает, составляет, поддерживает и обновляет все виды технической документации, онлайн-помощи, руководств пользователя, инструкций, различных «мануалов» и «гайдов», разнообразных спецификаций и т. Сферы деятельности, где могут понадобиться услуги технического писателя, — машиностроение, приборостроение, медицинское оборудование и др.
ЦА продукта может быть разная, начиная от пользователей сайта или мобильного приложения и заканчивая разработчиками. Документация бывает как для внешних пользователей пользователей сервиса , так и внутренних сотрудников компании. Техническая документация позволяет пользователям быстрее понимать и эффективно использовать функциональность продукта. С кем взаимодействует технический писатель Над разработкой продукта в IT-компании работает проектная команда. И для подготовки документации технический писатель взаимодействует со всеми ее участниками: Разработчики. Технический писатель переводит понятные и прописные истины программиста на удобный для пользователя язык.
Для этого он идет к разработчику и задает вопросы о том, как работает система. Для оплаты услуг субподрядчика или оплаты услуг компании нужны сопутствующие документы. Технический писатель вместе с финансовым отделом участвует в разработке этих документов для заказчика и их приемке от субподрядчика. С ними технический писатель обсуждает логику создания продукта, которую те придумали для разработчиков. Иногда совместно с аналитиками технический писатель может создавать документацию для команды разработки. Взаимодействие с дизайнерами нужно для того, чтобы задокументировать те или иные решения по дизайну. Руководители проектов. С РП технический писатель взаимодействует для координации и контроля над соблюдением всех необходимых формальностей со стороны участников проекта.
Обеспечивает консистентность формальной части проекта. Цели работы технического писателя Работа в сфере заказной разработки — это командный вид спорта, поэтому цель работы технического писателя — это успех всей команды, всего проекта. Антицель — написать красивый документ по ГОСТу, по которому невозможно провести испытания демонстрацию продукта заказчику , либо который не коррелируется с разработанной функциональностью продукта. Поэтому технический писатель разрабатывает документацию для целей, которые должны совпадать с целями компании. Если он пишет отчетную документацию по конкретному проекту, то он должен тесно взаимодействовать с проектной командой и осознавать, что разработанная функциональность будет приниматься заказчиком именно на основе написанной им отчетной документации. А ошибки в отчетной документации приводят к провалу испытаний или вовсе к отказу в приемке работ. Для технического писателя важно не зацикливаться на самом тексте, а смотреть в суть. Прийти к разработчику и спросить: «Все ли я правильно понял и написал?
Еще один важный момент — технический писатель должен не только предоставить заказчику комплект отчетной документации, но и согласовать ее с ним. Если клиенту что-то не нравится — выяснить, что именно, и понять, как это исправить. Куда расти техническому писателю Представим ситуацию, что человек приходит на позицию технического писателя, перерастает грейд Junior и в какой-то момент начинает думать: «А куда дальше развиваться? Буду ли я до конца карьеры писать технические документы, такие как руководство пользователя? У технического писателя есть конкретные зоны роста — как горизонтального, так и вертикального. Поговорим о горизонтальном росте подробнее. Хороший технический писатель должен знать, какие шаги нужно пройти для успешной сдачи проекта. Это шаги, которые находятся не только в его компетенции, но и которые должны пройти другие участники команды: дизайнеры — нарисовать макеты, разработчики — написать код, аналитики — описать бизнес-процессы.
И контроль выполнения работ другими участниками команды тоже может быть в числе обязанностей техписа. Также техпис должен уметь оценивать затраты на разработку той или иной документации: Сначала сформулировать требования к другим участникам команды — в каком виде и в какие сроки ему должны предоставить исходные данные для формирования комплекта отчетной документации.
Теперь о вашем опыте и навыках, которые мы считаем ключевыми для вашей успешной работы. Требования: - Опыт подготовки технической документации ГОСТ 19, ГОСТ 34 ; - Хороший уровень владения русским языком, грамотная письменная речь; - Умение структурировать и систематизировать информацию; - Уверенное владение пакетом офисных приложений Word, Excel ; - Базовое понимание процессов разработки программного обеспечения.
#Кем стать: Техническим писателем
девушка при исполнении, а в свободное время - поэт. Сталин и писатели. Поэтому какое-то время мечтала стать писателем. Меня зовут Елена, мне 23 года, я живу в Москве, работаю техническим писателем. Представляю свой будний день 10 июля 2012 года. Регламент работы технического писателя группы документирования (далее – Регламент) описывает схему процесса документирования и определяет порядок работы технического писателя при создании документации.
Газета.Ру в соцсетях
Специальность технический писатель появилась не так давно, однако уже является востребованной. Роль технического писателя Технический писатель переводит «от разработчика – клиенту». Меня зовут Елена, мне 23 года, я живу в Москве, работаю техническим писателем. Представляю свой будний день 10 июля 2012 года.