][akep был мой любимый журнал в начале 00-х, ещё были Компьютерра и Hard&Soft - по этим журналам собирал свой первый компьютер и изучал софт. Ностальгия... Удачи вам ребята и привет Дане Шаповалову, если он ещё с вами)
Да, мой путь сложился похожим образом, через бизнес- и системный анализ. Видел менеджера проекта, который «вырос» из технического писателя. Это уже кому что ближе, а «дорогу осилит идущий» (с).
Согласен на 100% и поступал точно так же те 5+ лет, которые работал в этой роли в прошлом. Отдельно отмечу шестую причину, по которой я вообще ушёл из этой специализации (и ни разу об этом не пожалел): Причина 6. Нет путей развития как специалиста.
В какой-то момент я познакомился с single sourcing в целом и DITA в частности. Тут есть где развернуться :) Но проектов, где это используется либо согласны это внедрять, — единицы.
Далее — если ты технический писатель и только технический писатель, у тебя действительно нет путей развития как специалиста. Спустя годы ты будешь всё легче находить работу, но по-прежнему будешь тем самым «ты кто такой и что тут делаешь?», пользоваться примитивными инструментами и иметь лишь поверхностные знания технологий, о которых пишешь. В лучшем случае ты будешь расти в лида/руководителя команды техписов, но это только в крупной компании и это уже вертикальное развитие, не всем такое нужно.
Если в продукте много интерфейсов взаимодействия с пользователем, можно расширить свою квалификацию в сторону UX — здесь тоже важна информационная архитектура, о которой имеет понятие хороший технический писатель, даже появились специалисты UX Writer. Ну и ценность юзабилити в индустрии в целом понимают больше, чем ценность документации.
И последняя «ложка дёгтя»: есть устойчивый глобальный тренд на автогенерацию документации и чат-ботов. Это не значит, что такие специалисты исчезнут, но спрос на них будет снижаться.
Очень хорошая статья, виден серьёзный опыт автора :)
Я бы добавил лишь одну мысль: технический писатель — это не человек, а роль. В зависимости от проекта эту роль может выполнять разработчик, менеджер проекта, аналитик, специалист по разработке документации, команда специалистов по разработке документации (примеры из реальных проектов, крупных и мелких, заказных и продуктовых). При этом все 5 тезисов абсолютно релевантны этой роли, особенно когда она выполняется отдельным специалистом и такой специалист один :)
Как раз использование «бигдатных» технологий не означает, что у вас Big Data :) Можно держать в Hadoop файловую помойку, можно поднять свою базу в AWS или GCP — но если данные не обладают характеристиками 3V, вряд ли это можно назвать Big Data.
Интересно, что статья одновременно указывает на несостоятельность тезисов Канемана и содержит описанные Канеманом же когнитивные искажения)
][akep был мой любимый журнал в начале 00-х, ещё были Компьютерра и Hard&Soft - по этим журналам собирал свой первый компьютер и изучал софт. Ностальгия... Удачи вам ребята и привет Дане Шаповалову, если он ещё с вами)
Причина 6. Нет путей развития как специалиста.
В какой-то момент я познакомился с single sourcing в целом и DITA в частности. Тут есть где развернуться :) Но проектов, где это используется либо согласны это внедрять, — единицы.
Далее — если ты технический писатель и только технический писатель, у тебя действительно нет путей развития как специалиста. Спустя годы ты будешь всё легче находить работу, но по-прежнему будешь тем самым «ты кто такой и что тут делаешь?», пользоваться примитивными инструментами и иметь лишь поверхностные знания технологий, о которых пишешь. В лучшем случае ты будешь расти в лида/руководителя команды техписов, но это только в крупной компании и это уже вертикальное развитие, не всем такое нужно.
Если в продукте много интерфейсов взаимодействия с пользователем, можно расширить свою квалификацию в сторону UX — здесь тоже важна информационная архитектура, о которой имеет понятие хороший технический писатель, даже появились специалисты UX Writer. Ну и ценность юзабилити в индустрии в целом понимают больше, чем ценность документации.
И последняя «ложка дёгтя»: есть устойчивый глобальный тренд на автогенерацию документации и чат-ботов. Это не значит, что такие специалисты исчезнут, но спрос на них будет снижаться.
Я бы добавил лишь одну мысль: технический писатель — это не человек, а роль. В зависимости от проекта эту роль может выполнять разработчик, менеджер проекта, аналитик, специалист по разработке документации, команда специалистов по разработке документации (примеры из реальных проектов, крупных и мелких, заказных и продуктовых). При этом все 5 тезисов абсолютно релевантны этой роли, особенно когда она выполняется отдельным специалистом и такой специалист один :)