Возможно, это не навыки, а разновидности нашей профессии. Еще бывает единственный техпис в компании. По-моему, это еще один отдельный класс.

Всем добрый день! Есть задача по переводу книги в электронный формат. Рукопись немного устарела, авторы её обновлять не могут. Поэтому возникал идея сделать её народной в цифровом виде. При этом, хотелось бы это сделать технологично, красиво, с возможностью дополнять и обновлять. Какие технологии посоветуете? Книга техническая, написана в ворде, есть формулы, иллюстрации растровые и векторные.

Мой ответ на пост Anna
Я считаю, что хороший TW должен априори уметь пользоваться семантическими языками разметки, гитом, иметь джунские навыки во фронте и т.п..
Развитие TW должно основываться не просто на написание доков в ворде по ГОСТ, а на современных подходах к разработке кода (именно кода, т.к. код и контент должны быть взаимосвязаны), да  к life cycle разработки ПО в том числе.
Понятно, что документация на программу должна быть неотъемлемой частью как и кода, так и продукта, и документация в отрыве от процессов разработки, выполненная, например, в ворде, безусловна не является идеалом, точнее, стремлением к идеалу для техписа.
Кто такой TW в компании, которая выпускает код как продукт?
По мне, это человек, который замыкает на себе как раз многие процессы в данной компании. Должен замыкать. И плохо когда технический писатель со своей документацией остаётся в стороне от процессов. Почему плохо?
- Полнота. Если TW не коммуницирует с командами ,если не добывает сведения, то продукт в документации не будет описан полно. А для этого надо уметь/хотеть быть частью команды, в том числе и выполнять роль менеджера, если придётся
- Обновление. нет ничего хуже, если меняется какая-либо функциональность продукта, а документация не обновлена. Плохо, если сие действие влияет критически (пример - документация на полётный блок ПО в Боингах). А значит надо снова ходить, общаться, понимать и знать источники информации. Знать и roadmap по продукту компании.
- Доступность. Если документация содержится локально на компе TW, значит её, документации, нет совсем. Если документация лежит в word и эти ворд-доки множатся через re:re1:re2, значит этой документации нет. А значит техническому писателю надо уметь делать так, чтобы любой сотрудник компании могу получить доступ к одной и той же версии документа в любой момент. Значит техпис должен знать простейшие механизмы соответствующих технологий, чтобы смочь.
- Правдивость. Нет ничего хуже, когда документация написана неправильно. Когда неправильно описаны классы, библиотеки, шаги, действия, параметры и т.д. Ужасно, когда последовательность шагов по установке программы или настройке этой же самой программы, написаны с ошибками, которые не не приведут к success. А значит TW надо разбираться в продукте, в технологиях, на которых разрабатывается эта программа. Не падать в обморок от чистого кода.
——
А для этого, техпису надо расти.

- Расти в код, чтобы понимать то, чем является продукт. Код бывает разным - frontend / backend. Твоя компания пишет на java - Учи джаву, Если webapp - библиотеку react, например.
Никто не требует от TW уровня мидла практикующего, но стремиться к этому надо. Сл-но, вот цель: растём в сторону чистого разраба. Узнать зарплаты разработчиков можно узнать на ресурсах, которые я уже приводил, например, sql.ru.
Даже в России реально зарабатывать 400к-500к будучи лидом разработчиков.
====
- Расти в сторону Devops. Настраивать сложные логические процессы не требуется, но выполнять простейшие вещи, быть в курсе ансибла, кубика, ci/cd и т.п., Знать основы json и yaml-разметок. Оплата рук хорошего devops_а может легко уходить за 300к. Сл-но, если техпис хочет уйти в эту стезю, то ему надо и развиваться в этой области: уметь писать ansible-конфигурации, разворачивать кубик, знать yaml и прочее.
====
- Расти в сторону менеджментских позиций. Менеджер (lead, head), с хорошим знанием технологий очень сильно ценится. В цикле разработки не хватает людей, которые на менеджерских позициях могут и с кодом помочь команде, и написать читаемый контент, и провести переговоры с клиентом. Техпису, чтобы стать хорошим управленцем стоит не только глубоко погружаться в сам продукт, но и уметь презентовать продукт, организовать команды, мотивировать команды, объяснить, рассказать и многое другое. Сл-но, руководитель, менеджер, который вырос из TW есть прекрасная возможность взойти на данную карьерную речь. Ведь технический писатель всегда общается с коллегами, иногда заказчиками. Кто, как ни техпис, знает как устроено ПО, его недостатки и достоинства. Потолок развития  для менеджерских позиций неограничен и можно дойти до CEO. Что же касается зарплат, то при хорошем грейде в некоторых компаниях (корпорациях) руководитель может получать свыше 500к.
====
Что я хотел сказать этой вышеприведённой писаниной? То, что стоит развиваться. Можно действительно уметь и любить писать техническую документацию, но современные реалии таковы, что без знания ИТ, технический писатель будет плохо выполнять свою роль - проводника знаний о продукте. А значит, некое лицемерие.
——
Всё написанное - ИМХО.
(и неправда)

УПС! Сорри, я не ожидал что так много будет. Написал, пока пил кофе. Если надо, удалю.

Мб выложить как статью/пост где-то? И дать ссылку.

У мну есть блог на Я.дзене, Но у меня перерыв закончился, надо работать. Да я и сомневаюсь, что это стоит отдельного поста в блоге.

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

вообще стоит расширить области применения техписательства. в ИТ их куча, а за пределами ИТ еще больше

Молодца, норм расписал

Как автор канала про документацию, считаю, что канал ортогонален навыкам писателя.

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

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

Везде нужен опыт. А как войти в айти, если нет опыта и образования :))) По фильтру "нет опыта" на хх.ру вываливается описание "от года"

*понимаю, что в очередной раз поднимаю волну дискуссий

Прастити

Мне много где отвечали, что типа можно притянуть за уши свой текущий функционал, похожий на техписательский, и он будет считаться условным годом 🙄

НО

Я лично не считаю это уместным. Вот как, например, Николай пишет выше, что техноблог и техписательство не одно и то же.

Ну как будто сомнительно, да? И так могут советовать, кто уже вошел

Я 100 лет уже пишу о технологиях, но как копирайтер же.

Вот да.