Заказать звонок

Технический писатель, направления для развития

Внимание! У нас сбои с почтовым сервером! Если не пришло письмо о регистрации или смене пароля напишите нам на info@techwriters.ru! 
@twriters
 obmen_soobsheniyami.pngчат для технических писателей в Telegram

 Зарегистрируйтесь
   RSS
Технический писатель, направления для развития, Обсуждаем какие профессиональные направления развития есть у технического писателя
 
Тут задался вопросом, в каких направлениях развиваться? Вижу, от тех. писателя требуется либо знание ГОСТ, либо технический английский, редко сразу оба. Часто поощряется Linux, DocBook, LaTeX, DITA. Как вы видите для себя развитие в области?
Страницы: Пред. 1 2 3 4 5 След.
Ответы
 
Цитата
techwriter пишет:
Цитата
ADVANCED пишет:
Вопрос не в том, что нравится или не нравится. Должен и нравится - разные вещи.
Конкретно у вас кто занимается дизайном разрабатываемых справок?
На текущем месте работы я. На предыдущем мне дали набор картинок и сайт в качестве эталона, сказали подгонять дизайн под него, т.е. писатель+CSS
 
http://www.apkit.ru/committees/education/meetings/standarts.php - здесь можно скачать проф. стандарт "Технический писатель (Специалист по технической документации в области ИТ)". Не понятно, принят ли он уже, но вряд ли есть что-то более новое на эту тему.

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

"Оформление и компоновка документов" - самый низкий уровень квалификации, "оформление документа в соответствии с заданным стандартом" - первый пункт трудовых функций. Не понятно, почему технический писатель не должен это делать или должен только на каких-то особых условиях.
 
Цитата
Марина пишет:
ТЗ в виде сайта, да ещё и красочного, делать не приходилось, потому что заказчикам не приходило в голову требовать. Когда-то делала юзабилити-аудиты интерфейсов, тоже никто не предъявлял каких-то особых требований к формам отчетов, всем хватало документа в ворде или pdf, конвертированного из ворда. С заказчиком обсуждались содержание и доступность изложения, форма - только в начале работы, с непосредственным начальством, на уровне "сделайте титульный лист по нашим корпоративным стандартам".

Разбить текст ТЗ на смысловые блоки, соответствующие вебстраницам, смогу без проблем. Сверстать каждую в HTML, наверно, тоже (но это ведь уже работа верстальщика)? Смогу внятно нарисовать прототипы карандашом на бумаге или в Visio (в Axura - это к проектировщику интерфейсов). Собрать из этого готовый сайт и разместить на хостинге - это к веб-программисту. Чтобы сайт был ещё и красочный - к веб-дизайнеру.
Угу.
А можно просто в Confluence написать все требования, проставив ссылки на корпоративный глоссарий, на связанные задачи в Jira, на описание процесса приемки, тестирования и прочие особенности.

Confluence это или иная вики-система не важно, главное, что над текстом может работать несколько участников, видно кто что внес или изменил, прикрепляются макеты и файлы в разных форматах, архивы и т.п. Например, таблица из Excel, сертификат для сервера, архив с картинками, набор необходимых библиотек, которые недоступны никому и прочее. В итоге вся достоверная информация есть в ТЗ и оно доступно всем, кому надо одновременно из разных мест планеты с любого устройства с инетом..  
К нему всегда удобно обратиться программисту и отметить ход работ, что он выполнил (тут же заказчик может контролировать ход работ), тестировщику, писателю и прочим участникам. Есть целый системы планирования, постановки задач, управления проектами. технические задания ставятся там.
Изменено: ADVANCED - 07.10.2014 16:04:16
 
Цитата
Виктор Фигурнов пишет:
Во многих западных фирмах нет печатей, тем более гербовых. Да и в России печати скоро сделают необязательными.
Дополню...
Более того, в России уже есть электронные подписи и они активно используются. Ранее они назывались ЭЦП (электронно-цифровая подпись).
На сайтах некоторых бюджетных учреждений без ЭП ничего нельзя ни заказать, ни получить. Внести изменения в личном кабинете, что-либо продать/купить на бирже, документы по сделкам депозитария или брокера, оплата в банках, заказ автомобилей и покупка недвижимости...

Миллион примеров еще - все сопровождается ЭП или 3d-secure.  Авторизация и аутентификация с мобильного устройства с помощью IMSI-кода, Мобильный штрих-код и тому подобное. В это направлении надо смотреть, столько интересного впереди.
 
Верю, что для большой распределенной команды и достаточно продвинутого заказчика это круто. Для небольшой команды, сидящей в одной комнате, с единственным аналитиком-техписателем, и заказчиками, использующими интернет только для чтения почты и новостей с рабочего компьютера, это не имеет смысла. Польза не окупит вложенных усилий.
 
Цитата
Марина пишет:
Верю, что для большой распределенной команды и достаточно продвинутого заказчика это круто. Для небольшой команды, сидящей в одной комнате, с единственным аналитиком-техписателем, и заказчиками, использующими интернет только для чтения почты и новостей с рабочего компьютера, это не имеет смысла. Польза не окупит вложенных усилий.
Тогда надо вместе с fs444 задаться вопросом в каком направлении развиваться и развиваться, чтобы уйти к более продвинутому начальнику.
Чего высиживать то?  
 
Цитата
Марина пишет:
"оформление документа в соответствии с заданным стандартом" - первый пункт трудовых функций. Не понятно, почему технический писатель не должен это делать или должен только на каких-то особых условиях.
Он может это делать если его попросят или если это его обязанность.  
Могу привести пример с DITA, просто пример. Есть компания в которой используют диту. Она настроена, стили есть, все хорошо. Есть группа писателей. Им сказано описывать некую систему. Сказано примерно так: Открыл редактор XML - написал абзац - вставил картинку - сохранил, написал абзац - вставил картинку - сохранил.  Писатель пишет, о стилях и стандартах не думает. Картинки принимают размер как надо, стили сами применяются, как выглядит конечный документ - они могут и не знать  :D .  

Другой писатель в другой компании пишет текст на сайте с движком Битрикс или WordPress, загружает картинки. Также ни о каких стилях и стандартах он не думает. Часть текста попадает в релиз, в описание изменений, остальное в подсказки, страницы помощи и т.п.  
 
А я работаю, а не высиживаю. Разрабатываю программные продукты для энергетических объектов, нужные и востребованные. Просто развитие не меряю навороченностью инструментов и моделями айфонов.
 
Цитата
ADVANCED пишет:
Заказчик на встрече с аналитиком ставит требование "чтобы адрес можно было выбрать из списка". Аналитик отправляет программисту СМС "надо сделать справочник КЛАДР, подробности в письме". Пишет письмо в электричке пока не забыл, или прикладывает аудиозапись с диктофона. Когда аналитик приезжает на свое рабочее место со встречи, прикладывает переписку из почты в JIRA. Программист в это время уже заканчивает справочник и передает на тестирование. Тестировщик читает весь ход мыслей от появления идеи, до завершения разработки и тестирует, писатель документирует. Доработка сдается заказчику патчем или в следующем обновлении.
Вообще так редко бывает, если честно, но бывает. Пример из опыта работы с госзаказчиком. Срок разработки сокращен до минимума, все все выполнили, заказчик доволен. Никто не растягивает договоры, печати, ТЗ по ГОСТ и т.п.
Плохой принцип разработки требований.
От проектирования до разработки того же сайта выполняется много работы, как например, анализ существующих аналогов, изучение разработок конкурентов, изучение недостатков и достоинств существующих решений, описание бизнес-процессов "как есть - как будет", разработка концепции, описание возможностей развития в дальнейшем, проектирование самой системы как на уровне архитектуры, так и на уровне интерфейса и функционала и пр., и пр.
Приведенный пример - типичный пример разработки "на коленке". Заинтересованный заказчик к тому варианту редко склоняется. И ежу понятно, что JIRA для нормального управления требованиями недостаточно, она подходит только на этапе разработки системы.
techwriter.ru.com
 
Цитата
ADVANCED пишет:
Цитата
Марина пишет:
"оформление документа в соответствии с заданным стандартом" - первый пункт трудовых функций. Не понятно, почему технический писатель не должен это делать или должен только на каких-то особых условиях.
Он может это делать если его попросят или если это его обязанность.
Конечно, но это вполне естественная для него обязанность. Вы же выше писали, что это почти тоже самое, что заставить его мыть полы и заправлять кондиционер.
 
Цитата
techwriter пишет:
анализ существующих аналогов,
изучение разработок конкурентов,
изучение недостатков и достоинств существующих решений,
описание бизнес-процессов "как есть - как будет",
разработка концепции,
описание возможностей развития в дальнейшем,
проектирование самой системы как на уровне архитектуры, так и на уровне интерфейса и функционала и пр., и пр.
Эта деятельность входит в компетенцию аналитика.

Если этим занимается писатель, может означать, что:
а) ему не правильно назвали должность на которую он трудоустроен;
б) он достаточно продвинут в знаниях и имеет аналитический склад ума и проходит испытательный срок на должность аналитика;
в) аналитик заболел, а писатель из пункта "б" не знает чем заняться;
г) маленькая контора, где разработчик сам себя же тестирует, руководитель проекта контролирует время прихода и ухода сотрудников, техподдержка пишет инструкцию "как перезагрузить сервер" и происходит другая путаница в работе.
д) еще что-либо
 
Цитата
techwriter пишет:
Плохой принцип разработки требований.
Ты спросила пример, я привел пример. Я не говорю, что так правильно или не правильно, такое возможно. Всякое бывает.

Хороший принцип или плохой - определяется результатом деятельности той компании, в которой так делается, а не аналитиком или пользователем форума TW ;)

Всегда хороши принципы того работодателя, к которому недавно устроился работать. Как только взгляды поменялись, в мозгу проскакивает мысль о смене места работы :)
 
Цитата
ADVANCED пишет:
Эта деятельность входит в компетенцию аналитика.

Если этим занимается писатель, может означать, что:
а) ему не правильно назвали должность на которую он трудоустроен;
б) он достаточно продвинут в знаниях и имеет аналитический склад ума и проходит испытательный срок на должность аналитика;
в) аналитик заболел, а писатель из пункта "б" не знает чем заняться;
г) маленькая контора, где разработчик сам себя же тестирует, руководитель проекта контролирует время прихода и ухода сотрудников, техподдержка пишет инструкцию "как перезагрузить сервер" и происходит другая путаница в работе.
д) еще что-либо
А ТЗ и пишет аналитик, а не технический писатель.
techwriter.ru.com
 
Цитата
techwriter пишет:

И ежу понятно, что JIRA для нормального управления требованиями недостаточно, она подходит только на этапе разработки системы.

У каждого "ежа" свои критерии нормального  8)

Кому-то JIRA не по зубам в финансовом плане, кому-то она вообще не нужна, т.к. небольшой стартап и все проектируется на доске маркером. кому-то жиры мало.


Jira подходит и на этапе тестирования и документирования системы.
 
Цитата
ADVANCED пишет:
Цитата
techwriter пишет:
Цитата
ADVANCED пишет:
Вы зациклились на Ворде.
ТЗ необязательно писать в ворде, оно не обязательно должно быть распечатано на принтере. Оно не обязательно должно быть по ГОСТ и тд.
При упоминании ТЗ, почему-то ассоциация о печатном документе. Оно может быть в HTML и им пользуются разработчики как им удобно. Один на планшете, другой на компе, третьему достаточно прочитать.

Книги тоже не обязательно должны быть на бумаге. Есть e-book со своими форматами. И в них тоже можно писать и ТЗ и другую документацию и ГОСТ можно забыть.
Предложи свой вариант ТЗ так, чтобы при этом печатного и электронного документа не существовало в природе. При этом ТЗ содержало все обоснования решений, ограничения и условия.
Заказчик на встрече с аналитиком ставит требование "чтобы адрес можно было выбрать из списка". Аналитик отправляет программисту СМС "надо сделать справочник КЛАДР, подробности в письме". Пишет письмо в электричке пока не забыл, или прикладывает аудиозапись с диктофона. Когда аналитик приезжает на свое рабочее место со встречи, прикладывает переписку из почты в JIRA. Программист в это время уже заканчивает справочник и передает на тестирование. Тестировщик читает весь ход мыслей от появления идеи, до завершения разработки и тестирует, писатель документирует. Доработка сдается заказчику патчем или в следующем обновлении.
Вообще так редко бывает, если честно, но бывает. Пример из опыта работы с госзаказчиком. Срок разработки сокращен до минимума, все все выполнили, заказчик доволен. Никто не растягивает договоры, печати, ТЗ по ГОСТ и т.п.
Вероятное развитие событий:

Все всё выполнили, но заказчик недоволен. Ему не нужен КЛАДР, а нужно чтобы в систему был забит его список адресов с пояснениями "пройти 10 метров от угла дома, свернуть в подворотню, постучать в дверь с красной вывеской 3 раза". Сейчас этот список написан нечитаемым подчерком в нескольких бумажных тетрадях. Те деньги, за которые компания готова за это взяться, заказчик платить не готов. Получили по половине человекодня программиста, тестировщика и техписателя, потраченных впустую, и недовольного заказчика. Этого можно было бы избежать, если бы аналитик не поленился перевести устное пожелание заказчика "хочу выбирать из списка" в требование "У пользователя должна быть возможность выбрать адрес из справочника КЛАДР" и отправить его на утверждение заказчику.  
На самом деле всё зависит от масштаба задач. Пожелание адекватного заказчика, которое может быть реализовано за полчаса, можно выполнить и без бюрократической волокиты. Но это именно выполнение мелкого пожелания, а не "разработка ТЗ без создания печатного или электронного документа".
Изменено: Марина - 07.10.2014 17:49:55
 
У нас тут каша получилась и от темы отклонились ) На тему ТЗ и ГОСТ далее не охота рассуждать  8) .

Никто никому ничего не должен. Писатель может или "обязан, согласно должностной инструкции на конкретной должности в конкретной компании", но по каким стандартам или шаблонам - зависит не от него. Если есть выбор, я бы выбрал не ГОСТ.  ;)

И направление развития я бы выбрал не в сторону госстандартов и бюрократии, а передовых технологий ПО и хелпа для этого ПО, в частности онлайн-справки, а также HTML5, CSS3, JS, верстка. Инструментарий для разработки документации независимо от платформы и устройств, переносимые источники, без привязки к какому-либо формату или системам хранения.
 
Цитата
ADVANCED пишет:
И направление развития я бы выбрал не в сторону госстандартов и бюрократии, а передовых технологий ПО и хелпа для этого ПО, в частности онлайн-справки, а также HTML5, CSS3, JS, верстка. Инструментарий для разработки документации независимо от платформы и устройств, переносимые источники, без привязки к какому-либо формату или системам хранения.
Думаю, очевидно: недостаточно владеть инструментарием. Да и овладеть им не так сложно. HTML5 и CSS3 не те вещи, которыми имеет смысл хвалиться, т.к. в них чего-то мегасложного нет. Любой может научиться за месяц.
techwriter.ru.com
 
Цитата
techwriter пишет:  HTML5 и CSS3 не те вещи, которыми имеет смысл хвалиться, т.к. в них чего-то мегасложного нет. Любой может научиться за месяц.
Ну попробуйте за месяц выучить HTML5 и CSS3, сдать экзамен и получить майкрософтовский сертификат "Programming in HTML5 with CSS3".

Тогда и будете говорить, что это несложно.
Изменено: Виктор Фигурнов - 21.10.2014 10:18:58
 
Коллеги! Напоминаю тему: Какие направления для развития технического писателя вы знаете!  ;)
 
Цитата
Виктор Фигурнов пишет:
Цитата
techwriter пишет: HTML5 и CSS3 не те вещи, которыми имеет смысл хвалиться, т.к. в них чего-то мегасложного нет. Любой может научиться за месяц.
Ну попробуйте за месяц выучить HTML5 и CSS3, сдать экзамен и получить майкрософтовский сертификат "Programming in HTML5 with CSS3".

Тогда и будете говорить, что это несложно.
А для написания технической документации их нужно знать на таком уровне?
 
Цитата
Марина пишет: А для написания технической документации их нужно знать на таком уровне?
Для написания может и нет, а для сдачи онлайн-документации заказчику очень может быть что да.

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

Если хочется активного развития и роста, довольно быстро уйдёте в какую-то смежную область. Вот и выбирайте вначале область, куда хочется развиваться (технический переводчик, аналитик, верстальщик и т.д.), от этого и пляшите.  
 
Цитата
Виктор Фигурнов пишет:
Цитата
Марина пишет: А для написания технической документации их нужно знать на таком уровне?
Для написания может и нет, а для сдачи онлайн-документации заказчику очень может быть что да.

Заказчик говорит, что онлайн-документация ему в принципе нравится, но эта кнопочка должна быть с закругленными углами, этот ярлычок вкладки другой высоты, промежуток между панелями должен быть узкий, должны быть такие-то кнопки, которые то-то делают, и т. д. Будете отвечать, что ничего этого делать не умеете?
Если я - техписатель, знающий инструментарий на начальном уровне, говорю, что попробую разобраться, как это сделать, но возможно потребуется помощь и сроки надо сдвигать. Так в процессе работы и научусь.

Если я - менеджер, работающий с заказчиком, вежливо доношу до него мысль "любой каприз за ваши деньги". Пожелания про форму кнопок скорее всего сразу отвалятся. То, что действительно необходимо, будем осваивать, может быть, наняв верстальщика или оплачивая обучение верстке своих техписателей.  
 
Цитата
Виктор Фигурнов пишет:
Ну попробуйте за месяц выучить HTML5 и CSS3, сдать экзамен и получить майкрософтовский сертификат "Programming in HTML5 with CSS3".

Тогда и будете говорить, что это несложно.
А что конкретно для вас сложно в этой связке?
techwriter.ru.com
 
Цитата
Виктор Фигурнов пишет:
Заказчик говорит, что онлайн-документация ему в принципе нравится, но эта кнопочка должна быть с закругленными углами, этот ярлычок вкладки другой высоты, промежуток между панелями должен быть узкий, должны быть такие-то кнопки, которые то-то делают, и т. д. Будете отвечать, что ничего этого делать не умеете?
Виктор, а что сложного в закруглении углов, изменении высоты и проставлении промежутков между панелями?
techwriter.ru.com
Страницы: Пред. 1 2 3 4 5 След.
Читают тему

Рейтинг@Mail.ru