#колонкаредактора
Всем привет! Продолжаем разговор об особенностях профессии. И сегодня наша тема:

Трамплин в IT или профессия?

Да, действительно, очень часто профессия технического писателя преподносится именно как лёгкий способ присоединиться к IT-сообществу. К техписателю не предъявляются такие требования, как, например, к разработчику или тестировщику: просто пиши и пиши себе текст.

И отчасти это так: знания языков программирования от техписателей требуют не везде.

😎 - Вот освою техписательство и уйду в разработчики!

Но есть ли границы у навыков технического писателя? Можно ли в какой-то момент времени сказать, что "освоил техписательство"?

Для удобства разделим навыки технического писателя на группы.

1️⃣ Язык

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

Вашим пользователям всё понятно? Документация помогает использовать продукт? Все процессы доступно зафиксированы? Отлично!

2️⃣ Инструменты

Документация не витает в воздухе — команды передают её заказчику в каком-то виде. Например, в виде страниц в корпоративной вики или в виде распечатанных страниц Word.

Можете ли вы одним махом форматировать все таблицы на 300 страницах текста? Сами создаёте макросы? А может ещё и схемы чертите? Супер!

*3️⃣ Управление*

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

Вы можете выстроить стратегию документации, рассчитать трудозатраты на её реализацию и разработать подробный план? Великолепно!

🧐 - Уже всё? Уже можно уходить в разработчики?

Мы ответим, что уйти можно в любой момент, и вы уйдёте, так и не узнав... Что это ещё не всё)

4️⃣ DocOps

Целый пласт навыков на стыке техписательства, фронтенд-, бэкенд-разработки и DevOps.

*5️⃣ Локализация и интернационализация*

Мастерство адаптации документации для другой страны или целого мира. Да-а, это всё ещё возможно) Подробнее об этих направлениях напишем в отдельных постах.

😏 — Оу, здесь уже и платят неплохо, и код писать могу, и зачем мне тогда в разработчики?

Техписатель — не просто трамплин в IT, а самая настоящая профессия. И, если для вас это важно, у неё есть свой госстандарт. Оставайтесь с нами❤️

#такбывает
Всем привет!
Иногда полезно делиться своими ошибками, даже самыми глупыми, чтобы больше никто их не совершал. А ещё такие истории помогают коллегам избавиться от синдрома самозванца — люди ошибаются, так бывает)

Самая полезная (нет) запись встречи

Для техписателя важно записывать все встречи. Какой бы ни была надёжной память, но в самый ответственный момент и она может подвести. Запись же позволяет сохранить информацию и лишний раз не беспокоить носителя знаний.

Поэтому я (Лида) и решила записать очередную встречу с разработчиком. Но по какой-то причине мой микрофон был программно отключен. И запись получилась такая:

Я: ...
Разработчик: Привет, давай.
Я: ...
Разработчик: Да, верно.
Я: ...
Разработчик: Да.
Я: ...
Разработчик: Да, сейчас это так работает.
Я: ...
Разработчик: Верно.
Я: ...
Разработчик: Хорошо, давай тогда договоримся - во вторник дедлайн.

Конец записи

Проверяйте настройки перед записью)

Привет!

Наверняка вы слышали ироничную фразу «технических писателей не существует». Как говорится, в каждой шутке — доля шутки. Давайте поговорим о том, как повысить свою видимость, когда вы только вышли на новую работу.

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

С непониманием, что вы за покемон, можно столкнуться, например, если вы первый технический писатель в компании. Пришли со стороны или «доросли» — это уже не имеет значения.

Давайте разбираться, как можно повысить свою «видимость» в компании.

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

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

Далее выбирайте наиболее «безболезненный» для вас вариант и действуйте:

?Идите ко всем, с кем в теории будете общаться, в личку и напишите пару строк о себе и будущей работе. Можете сделать сообщение-костяк (или шаблонное, но это не очень) и отправлять его. Этот вариант подразумевает, что вы очень общительный и активный человек, который сразу выстраивает рабочие отношения. Подходит, естественно, не всем :)
?Прийдите к лидам продуктов или команд, с которыми вы будете работать. Познакомьтесь с ними и попросите познакомить себя с командой. Либо в общем чате, на командной встрече — буквально забежать на пару минут, например, на дейлик, планирование спринтов или ретро.
?Напишите сами в общекомандный чат о себе и чем можете быть полезны. Это самый простой вариант и не всегда действующий — вас увидят и забудут. А если вас представит лид или вы ворвётесь в личку к каждому — тут впечатлений будет побольше.

Про впечатления: однажды я пришла в новую компанию и меня представили в общем чате. После этого ко мне в личку пришёл лид одной из команд, чтобы познакомиться. Запомнила ли я такое поведение? Конечно! Сталкивалась ли я с этим лидом по работе? Нет! Зато его точно запомнила ☕️

Наша профессия и так часто «невидима», поэтому не стесняйтесь ~~заходить с ноги~~ сразу обозначать себя и вашу работу. Легко не будет, но некоторый положительный эффект всё же возможен.

А если у вас есть какие-то лайфхаки о том, как повышать свою видимость, когда вы только устроились в новую компанию — пишите в комментариях

#Выпуск 13

#колонкаредактора
Чем сеньор отличается от джуна?

Как и в любой профессии, у технических писателей есть свои уровни квалификации — грейды. Грейды техписателей называются так же, как и грейды разработчиков: джун, мидл, сеньор. В разных компаниях эти основные грейды дополняются промежуточными вроде pre-junior или middle+.

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

Споры об этих различиях в профессиональном сообществе продолжаются до сих пор и примерно сводятся к тому, что джун-мидл-сеньор — это градация самостоятельности человека в компании. Например, сеньор может самостоятельно поднять документацию с нуля.

Хорошая мысль, я её уважаю, но считаю неполной. А где-то даже немного неверной.

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

Видеть свой участок в общем бизнес-процессе, осознавать и управлять его влиянием на метрики, выбирать путь развития, планировать его и воплощать. Умеете? Вы сеньор.