Size: a a a

2019 November 12

R

Roht in technicalwriters
Зато как гордо звучит — профессиональный писатель!
источник

MS

Maxim Shabanov in technicalwriters
Алексей Москвин
Поделюсь своими мыслями: третий год работаю техническим писателем и чувствую полное опустошение от профессии.

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

Техническую документацию, как устроена архитектура системы, напишет быстрее и правильнее архитектор, который ПО и разрабатывал.

Чтобы писать документацию разработчика, нужно понимать стэк, который зависит от компании и может быть узким.

Чем заняться техническому писателю? Собрать информацию, переписать «красиво», отправить на ревью.

Не исключаю, что техпис разбирается в стэке, но зачем имея знания разработчика, не перейти туда, где гораздо шире возможности для карьерного роста и больше платят? Если только энтузиазм/нравится писать.

Еще и на рынке бОльшая часть вакансий – ГОСТы и сертификация, и, если это сертификация ФСТЭК – нужно детально разбираться в их требованиях и знать продукт. Опять техпис выполняет роль, по большей части, оформителя.

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

В самом начале пути я вдохновлялся миру IT, мне нравилось то, чем я занимаюсь. Но спустя время у меня пришло разочарование от профессии «красиво переписывать чужой текст».

Готов к камням.
Техпис может быть больше, чем оформитель.

Задача не "писать текст", как скажут, а доносить полезную информацию до пользователей. А путей для этого целая уйма.

Решение конкретных проблем (FAQ, How To) — тут интерес самому разобраться, что к чему.
Схемы, графики, картинки — тут надо любить систематизировать информацию и уменьшать энтропию вселенной, да. Но тоже многим нравится процесс)
Видеоролики — очень модно. (а ещё популярные каналы рубят деньги на рекламе).

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

Да даже нанесение пользы отделу саппорта — очень важное дело. Сколько времени экономит суммарно саппорт, если под рукой всегда есть документация? А сколько времени экономит разработчик, который не отвечает на "дурацкие" вопросы от саппорта?
источник

R

Roht in technicalwriters
Daria
я бы осторожно предложила поучиться, но это, понятно дело, непрошенный совет
Не возникало такой необходимости, 7 лет в профессии уже
источник

D

Daria in technicalwriters
Roht
Не возникало такой необходимости, 7 лет в профессии уже
саморозвитие например
расширение зоны ответственности вотэтовсё
источник

FM

Fox Mulder in technicalwriters
Алексей Москвин
Поделюсь своими мыслями: третий год работаю техническим писателем и чувствую полное опустошение от профессии.

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

Техническую документацию, как устроена архитектура системы, напишет быстрее и правильнее архитектор, который ПО и разрабатывал.

Чтобы писать документацию разработчика, нужно понимать стэк, который зависит от компании и может быть узким.

Чем заняться техническому писателю? Собрать информацию, переписать «красиво», отправить на ревью.

Не исключаю, что техпис разбирается в стэке, но зачем имея знания разработчика, не перейти туда, где гораздо шире возможности для карьерного роста и больше платят? Если только энтузиазм/нравится писать.

Еще и на рынке бОльшая часть вакансий – ГОСТы и сертификация, и, если это сертификация ФСТЭК – нужно детально разбираться в их требованиях и знать продукт. Опять техпис выполняет роль, по большей части, оформителя.

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

В самом начале пути я вдохновлялся миру IT, мне нравилось то, чем я занимаюсь. Но спустя время у меня пришло разочарование от профессии «красиво переписывать чужой текст».

Готов к камням.
Напишу по своему опыту про техписа и его видение в современных реалиях :
1. Да, документацию никто не читает. Её не читали и 30 лет назад. И не только в СНГ.
2. Да. на рынке России одна гостуха, вакансий не гостового направления катастрофически мало. К ГОСТ прибавляется знание ФСТЭК. От этого нику не деться.
3. Да, очень часто, проработав в одной организации достаточно долго, техпис становится узкоспециализирован.
4. Да, системную архитектуру, ПМИ и и прочее напишут лучше специализированне люди.
5. Пути движения - уход от гост как самая первая мера; движение в концепцию docsasacode; овладение навыками кодинга на уровне джуна минимум; английский язык на среднем уровне минимум; умение быть и devops_ом, и саппортом, и аналитиком, и UX-редактором.
6. Работа в компаниях, в которых документация излагается в виде сайте, а не отдельных докуменотв аля docx.
источник

R

Roht in technicalwriters
Ну, я уже выше писал про видеоролики — в прошлом году я их не делал, а теперь почти только их и делаю, так что моё замечание про неумение в другие вещи следует воспринимать с долей иронии :)
источник

MS

Maxim Shabanov in technicalwriters
Как-то чат быстро переквалифицировался в чат моральной поддержки технических писателей)
источник

D

Daria in technicalwriters
а где ещё её брать
источник

MS

Maxim Shabanov in technicalwriters
о даааа
источник

S

Sara in technicalwriters
А я, как оказалось через 5 лет после окончания не самого любимого филфака, полюбила текст - это же целый мир, такое полотно красивое можно сделать, не хуже кода :) плюс хорошее ощущение от того, что помогаешь, такой пассивный диалог с пользователем. И это у меня писательских задач на самом деле не очень много - и это самые любимые. А разработчики... Ну вот третий день редактирую доку, написанную тестировщиком и разрабами - не их это работа, у всех разные таланты)
источник

АХ

Алексей Хорьков in technicalwriters
Fox Mulder
Напишу по своему опыту про техписа и его видение в современных реалиях :
1. Да, документацию никто не читает. Её не читали и 30 лет назад. И не только в СНГ.
2. Да. на рынке России одна гостуха, вакансий не гостового направления катастрофически мало. К ГОСТ прибавляется знание ФСТЭК. От этого нику не деться.
3. Да, очень часто, проработав в одной организации достаточно долго, техпис становится узкоспециализирован.
4. Да, системную архитектуру, ПМИ и и прочее напишут лучше специализированне люди.
5. Пути движения - уход от гост как самая первая мера; движение в концепцию docsasacode; овладение навыками кодинга на уровне джуна минимум; английский язык на среднем уровне минимум; умение быть и devops_ом, и саппортом, и аналитиком, и UX-редактором.
6. Работа в компаниях, в которых документация излагается в виде сайте, а не отдельных докуменотв аля docx.
4. Да, системную архитектуру, ПМИ и и прочее напишут лучше специализированне люди.

Вот категорически не согласен! Разработчик никогда не напишет хорошую документацию. Также как и тестер, архитектор и тд и тп (есть исключения, но они только подтверждают правило).
Это не их основная работа и не ключевой навык. А наш ключевой. Для этого мы и нужны, их полёт мысли понять, переварить, зафиксировать в нужную форму и разместить в нужное место
источник

MS

Maxim Shabanov in technicalwriters
Sara
А я, как оказалось через 5 лет после окончания не самого любимого филфака, полюбила текст - это же целый мир, такое полотно красивое можно сделать, не хуже кода :) плюс хорошее ощущение от того, что помогаешь, такой пассивный диалог с пользователем. И это у меня писательских задач на самом деле не очень много - и это самые любимые. А разработчики... Ну вот третий день редактирую доку, написанную тестировщиком и разрабами - не их это работа, у всех разные таланты)
Я просто обожаю находить вопросы по фиче, которые ставят в тупик даже разработчика. А иногда и отправляют фичу на доделки)
А вот для пользователя такой кейс покажется вполне очевидным. У разработчиков совсем иное видение мира и пользователя.
источник

СФ

Семён Факторович in technicalwriters
Мы тут последние месяц-полтора копаем тему расширения навыков технического писателя в сторону DocOps, и пока наблюдения следующие:

1. Базовые навыки работы с инструментарием вокруг легковесных языков разметки (Pandoc, Sphinx и прочее) полезны (т.к. здорово расширяют кругозор) и приобретаются довольно быстро.

2. Тем не менее, объем знаний и навыков, необходимый для решения комплексных DocOps-задач (например, выстроить пайплайн переводов и публикации в разные таргеты) ОЧЕНЬ велик. Путь от «техписатель с базовым знанием командной строки и несложного скриптинга» до «инженер, в одиночку решающий сложные DocOps-задачи» может занять год и более.
источник

СФ

Семён Факторович in technicalwriters
это я к тому, что вектор «техписатель → эксперт по docs-as-code» верный, но длинный и сложный
источник

СФ

Семён Факторович in technicalwriters
и усложняется тем, что четкого понимания, как этот путь пройти, пока ни у кого нет
источник

СФ

Семён Факторович in technicalwriters
(нет ни учебных программ, ни курсов, вот этого вот всего)
источник

A

Angela in technicalwriters
DocOps на отечественном рынке мало востребован, если двигаться в эту сторону, надо параллельно серьёзно повышать уровень английского и искать вакансии удалённого сотрудничества с иностранными компаниями
источник

СФ

Семён Факторович in technicalwriters
> DocOps на отечественном рынке мало востребован

Ситуация стремительно меняется в лучшую сторону
источник

АМ

Алексей Москвин in technicalwriters
Просто работа по итогу заключается убрать из текста англицизмы вроде «фича», «помержить» и прочее, почистить от ошибок и красиво и чётко переписать текст. А вот сам техпис очень врядли разберётся как микросервисы работают.
Из-за отсутствия хардскиллс, потому как на работе надо работать. Развитие, самообучение — это все хорошо. Но оно будет медленное в отрыве от сферы и без ментора.
источник

DS

Daria Savina in technicalwriters
Алексей Хорьков
4. Да, системную архитектуру, ПМИ и и прочее напишут лучше специализированне люди.

Вот категорически не согласен! Разработчик никогда не напишет хорошую документацию. Также как и тестер, архитектор и тд и тп (есть исключения, но они только подтверждают правило).
Это не их основная работа и не ключевой навык. А наш ключевой. Для этого мы и нужны, их полёт мысли понять, переварить, зафиксировать в нужную форму и разместить в нужное место
Ну уж. Архитекторы и какие-нибудь аналитики обычно хорошо пишут. Это такой же их хлеб. Да и тестеры пишут по шаблону и справляются :)
источник