Техписалити!

#колонкаредактора
Всем привет! "Где учиться на техписателя?" — самый частый вопрос от новичков. Это важный вопрос, но мы предлагаем начать с другого: как учиться на техписателя?

Самообразование, курсы, менторы — три уровня образования

Почему мы рекомендуем выстроить обучение именно так? Рассказываем.

1️⃣ Самообразование

Новички всегда в поисках курсов. Кажется, что появится школа, которая всему научит. Но техническая документация — очень широкое понятие. Ни одни курсы не принесут вам пользы, если не знать, что именно вы хотите изучить.

Поэтому, прежде чем искать курсы, мы советуем поучиться самостоятельно. Это позволит вам точно понимать, что искать дальше.

Всем новичкам мы предлагаем:
*️⃣Посмотреть курс на ютуб от Документата,
*️⃣Почитать редполитики, например, редполитику Госуслуг,
*️⃣Почитать книгу Кагарлицкого (ссылку дали как пример, что-то цена там неконкурентная),
*️⃣Подписаться на нас и почитать посты с начала 😊

2️⃣ Курсы

Курсы, которые испытаны нами лично, посоветовать не получится, потому что они не вынесли испытание временем, хотя были очень хороши.

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

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

3️⃣ Менторы

Кто такие менторы? Это опытные технические писатели, которые за деньги (от 2 000 рублей за час) помогут вам решить конкретные задачи в обучении. Например, они могут выстроить индивидуальный план обучения, исходя их ваших знаний, либо поделиться знаниями в конкретной области.

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

И тут мы снова возвращаемся к пункту 1 😉
Самообразование — основа всего обучения.

🔆 Если вы уже прошли какой-то хороший курс или нашли хорошую публикацию, поделитесь, пожалуйста, ссылкой на них в комментариях.

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

Давайте соберем для новичков полезную информацию.

#мемница

#мемница

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

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

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

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

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

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

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

1️⃣ Язык

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

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

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

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

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

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

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

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

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

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

4️⃣ DocOps

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

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

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

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

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

#мемница

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

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

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

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

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

*Конец записи*

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

Всем привет!

В этот четверг, 3 октября, в 19:00 по московскому времени пройдёт митап для технических писателей, организованный коллегами из X5 Tech.

О чём пойдёт речь?

0️⃣ Лютикова Александра из X5 Tech расскажет, как выжить в режиме аврала.
0️⃣ Александр Мачулин из Gram.ax поделится опытом, как они пытались автоматизировать проверки по стайлгайдам.
0️⃣ Акимова Юлия из Яндекс Маркета расскажет, почему дизайнер, UX-редактор и исследователь — единый организм.

1️⃣ Круглый стол «UX-исследования справки и интерфейсов» с коллегами из X5, Cloud.ru, Авито, Яндекс Маркета и Ozon.

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

#анонс

#мемница

#какэтоработает
Всем привет! В прошлом посте мы поговорили о том, что же такое docs-as-code и почему команды выбирают именно его для создания документации.

Как создавать документацию с docs-as-code?

Допустим, мы уже переняли инструменты разработчиков: пишем документацию в markdown, используя VS Code, храним в гите, собираем генератором и поставляем в виде веб-ресурса. Но как использовать практики разработки?

Работа с документацией организована по аналогии с разработкой: одна функциональность – одна ветка в гите.

➕ Для каждой задачи, в которой предполагается обновление документации, создаётся отдельная ветка, в имя которой мы добавляем номер задачи.

➕ Для всего релиза тоже существует отдельная, релизная ветка, в которую мы сливаем все ветки-задачи, не удаляя исходные.

➕ Как только релиз сформирован у разработчиков, технический писатель уточняет, все ли задачи попали в релизную ветку документации. Если всё корректно, сливает ветку в основную.

❗️ Если по какой-то причине техписатель поспешил и залил в релизную ветку лишнюю задачу, некорректная релизная ветка удаляется и собирается новая из веток-задач, которые мы предусмотрительно не удаляем.

🔆 Готово. К релизу продукта мы получаем релизную ветку, в которой содержатся описания всех фичей и доработок.

Это только одна из возможных схем работы. Каждая команда выбирает удобный для себя путь.

#мемница

#какэтоработает

Всем привет! Сегодня поговорим об одном из самых популярных терминов в речи техписателей – docs-as-code.

Что такое docs-as-code?

🔆 Это подход к созданию документации, когда техписатели используют инструменты и практики разработки. По мнению documentat.io, docs-as-code подразумевает, что технические писатели выполняют хотя бы часть из указанных процессов:
– Пишут документацию в редакторах кода вроде VS Code и подобных.
– Используют языки разметки, например, Markdown или reStructureText.
– Хранят исходники в гите и используют его для совместной работы с файлами.
– Используют программные решения для “компиляции” документации – преобразования исходников в html-страницы. Такие инструменты называются SSG (Static Site Generator), чаще используется термин “генератор” или “сборщик”.
– Разворачивают документацию как приложения – с помощью так называемой технологии непрерывной интеграции и развёртывания (CI/CD).

Почему команды выбирают такое решение?

Аргументов “за” docs-as-code много. Рассмотрим три основных.

1️⃣ Первый, но не самый очевидный, – единый мир с продуктовой командой. Технические писатели, которые обычно отвечают за буквы и считаются гуманитариями, в этой парадигме полностью интегрируются в команду. Они неизбежно начинают разбираться в процессах разработки, лучше понимают разработчиков, а разработчики лучше понимают их.

2️⃣ Второй аргумент, самый веский – подход docs-as-code помогает создавать актуальную и полную документации за счёт самого процесса. Документация развивается и обновляется одновременно с продуктами.


3️⃣ Третий аргумент – гибкость решений и разгрузка команды, если используются генераторы. SSG, как правило, — это опенсорсные продукты с хорошей документацией и обширным сообществом. Благодаря этому технические писатели могут освоить инструмент самостоятельно и наладить сборку документации.

Если с инструментами разработки всё понятно, то что же значит “использовать практики разработки”? Об этом мы поговорим в следующем посте.

А пока давайте вспомним, какие же ещё плюсы у docs-as-code и какие недостатки?

#мемница

#мемница

#анонс
Всем привет!
Соскучились по полезным докладам и крутым спикерам? Несём вам классную новость:

Завтра, 5 сентября, стартует DevFest 2024, и доклады в треке Documentation можно посмотреть онлайн бесплатно!

🔥Кто спикеры:
*️⃣Екатерина Чинкова, Ozon
*️⃣Ольга Каныгина, X5 Tech
*️⃣Татьяна Цикунова, МойСклад
и
*️⃣Семён Факторович😎

Присоединяйтесь к чату конференции, ссылку на трансляцию сбросят туда)

#мемница

Привет! 👋

Если вы работаете свою лучшую работу, но иногда вас настигает чувство, что вы делаете что-то не так или плохо — этот пост для вас.

Поговорим про «рабочую самооценку» — не синдром самозванца, хотя, наверное, он тут тоже затесался. Что делать, если вы вдруг почувствовали неуверенность в своих силах? Это может случиться на сложном проекте, после отпуска, от отсутствия отпуска, или просто потому, что так сложились звезды.

Что может помочь поднять «рабочую самоуверенность»?

📌 Обратная связь от коллег
Это могут быть как коллеги по цеху, если вы работаете в команде, так и коллеги-заказчики, если вы работаете один. Не стесняйтесь спрашивать ОС! Так вы узнаете, правда ли вы так плохи, как успели себе надумать (спойлер: нет).

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

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

Но где же найти друзей-техписателей?
📎 в сообществе техписателей или во флудилке — инвайты туда периодически кидают в чате;
📎 в тематических чатах для техписов;
📎 в каналах, которые ведут техписы, например, Катя Ушакова из Ozon тщательно собрала такие каналы в отдельной папке;
📎 на митапах и конференциях;
📎на работе! Да-да, коллеги тоже могут стать отличными друзьями, знаем не понаслышке 😏

Но что делать, если я интроверт?

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

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

Поделитесь в комментариях своими методами, которые помогают поднять рабочую самооценку 🙈

#выпуск 16

#мемница

#мемница

Привет!

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

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

Как себя «прорекламировать»? Можно напомнить о себе или мозолить глаза! 😏

📌Напишите небольшую страничку о том, кто вы, чем можете быть полезны, как к вам обратиться и поставить задачу
📌Пишите о своей работе в командные чаты. Готовите релиз ноты? Напишите об этом! Выпустили документацию? Похвастайтесь! Заведите еженедельный/ежемесячный/ежеквартальный дайджест о своей работе. Пусть видят, чем вы занимаетесь, может, каждый для себя найдет какую-то пользу.
📌Если пишете пользовательскую документацию — дайджесты тоже помогут, но уже не разработчикам, а техподдержке или даже самим пользователям. Сделайте страницу с ежемесячными обновлениями документации.
📌И способ «со звездочкой» — начните ходить на командные встречи.
Что хорошего: вы будете больше погружены в продукт, знать, что делает команда, можете сразу всем задать вопросы о проектах. А ещё будете маячить у них перед глазами, напоминая о себе и документации.
Что плохого: если вы один техпис на несколько продуктов или команд, есть вероятность, что вы будете только и делать, что ходить на встречи. Но это тоже решаемо: выбираете один приоритетный/проблемный продукт/команду и начинаете внедряться только к ним. И так начинаете кочевать от команды к команде.

И ещё несколько способов из комментариев к прошлому посту!
📌 Залетайте на демо, если они есть в вашей компании. Там можно рассказать, кто вы и чем полезны.
Кстати, как вариант: если у вас есть коллеги-друзья, можно попросить их на таких встречах попиарить вас и вашу документацию.
📌 Если работаете в офисе — проставьтесь по окончанию испытательного срока. На пиццу могут слететься разные люди, заодно познакомитесь и расскажете о себе.
📌 Участвуйте во внутренних митапах! Тоже повышает видимость вас, техписателей в целом и документации.

В итоге о вашей работе будут знать, возможно, кто-то даже скажет «спасибо», но это неточно 😁

Расскажите в комментариях, как вы популяризируете документацию или пытались это делать 🙂

#Выпуск 15