Роль и польза техписателей в Plesk.

Мы всей компанией готовимся к Кодфесту. Я сегодня написал несколько абзацев про команду техписателей для нашей общей статьи про компанию. Постарался объяснить, зачем мы вообще нужны и в чём польза. Хочу узнать ваше мнение о том, что получилось.

Технические писатели в Plesk отвечают за технические коммуникации компании с пользователями: документацию, release notes, тексты в интерфейсе и блоги.

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

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

А ещё мы рассказываем про обновления продуктов в release notes. Их главная задача — мотивировать пользователей скорее обновляться к новой версии, в которой есть нужные им фичи и исправлены затронувшие их баги. Чем быстрее пользователи обновляются, тем меньше у них проблем и лучше впечатление от наших продуктов.

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

Что здесь понятно, что непонятно? С чем вы хотели бы поспорить? Напишите мне на @nickvolynkin или в чат @docsascode.

​​Программа KnowledgeConf готова!

Программа конференции по управлению знаниями KnowledgeConf готова. Мы выбрали 24 лучших доклада из 83 заявок. Прямо сейчас докладчики активно работают над своими докладами, а мы будем вам о них рассказывать.

Лана Новикова написала статью-анонс: KnowledgeConf: нам нужно серьезно поговорить о докладах. Читайте, ставьте плюсы и, конечно, приходите на конференцию.

На фото мы с Ланой общаемся с участником TeamLeadConf на стендe нашей конференции.

Кто-нибудь выгружает описания API в OpenAPI (swagger) из кода на Java? У вас есть тесты на полноту javadoc'ов? Поделитесь опытом в @docsascode, пожалуйста.

Если вы сегодня на CodeFest — приходите к нам на квартирники. Первый будет в 10:50, тема — «Почему технический писатель — не аналитик».

https://2019.codefest.ru/lecture/1512

Второй квартирник на CodeFest: «Можно ли превратить создание и поддержку документации в процесс, или что такое DocOps».

14:10, то есть прямо сейчас.

https://2019.codefest.ru/lecture/1511

Через час (17 по Новосибирску, 13 по Москве) мы с Семёном Факторовичем и Татьяной Фокиной будем рассказывать про документацию и DocOps на радио ЦФТ. Трансляция тут: https://team.cft.ru/radio

Командный и персональный рост в продукте: уроки, навыки и процессы.

А вот и первый конспект с Кодфеста!

Анна Бояркина из Miro (ex-RealtimeBoard) рассказывает, что компания может расти экспоненциально, а сотрудники — только линейно, и как помочь сотрудникам успевать за быстрорастущей компанией.

​​Эволюция цифрового общения.

Виктор Иванов из ВК рассказывает, как 23 года назад появилось цифровое общение, как оно менялось и меняло весь мир коммуникаций.

https://github.com/plesk/codefest19/blob/master/source/digital-communication.md

Уже пару конспектов прервал на середине: трансляция не позволяет нормально досмотреть доклад.

К сожалению, на сегодня всё. Ждите продолжения конспектов на Highload.

Если вы сейчас на CodeFest — приходите в 17:00 на доклад Сергея Быстрых:«Как ускорить тесты в 10 раз и вернуть к ним доверие». Там реальная история оптимизации тестов, которую я наблюдал своими глазами в Plesk (хоть и со стороны).

https://2019.codefest.ru/lecture/1419

Технические задания как исполняемый код.

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

Если вам это интересно — почитайте статью Никиты Соболева про то, как писать требования: Engineering guide to writing correct User Stories.

​​На честном слове и на одном ядре.
Генератор статических сайтов Jekyll — однопоточный. Даже если на машине прекрасные 8 или 16 ядер, Jekyll всё равно использует одно ядро для сборки доки. Поэтому у меня сейчас этап сборки на Jekyll длится по 15-20 минут.

Если у вас в документации тысячи страниц — берите сразу многопоточный генератор.

Jekyll → Hugo.

Читатель подсказывает, что с Jekyll надо переходить на Hugo, у которого всё хорошо со скоростью. Вот инструкция:Migrating from Jekyll+Github Pages to Hugo+Netlify.

Объединить конспекты всех конференций в один репозиторий или каждую писать в новом? Как вы считаете, что будет лучше?

Раньше писал в разных:
— Highload 2018
— TeamLeadConf 2018
— CodeFest X

Аргументы за разные: проще структура, не смешивается в кучу.
Аргументы за один: всё в одном месте, легче сделать сайт.

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

Репозиторий ждёт ваших звездочек, а я иду писать первый конспект. :)

https://github.com/docops-hq/conf

Эволюция Python в Яндексе.

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

1. Приложения в deb-пакетах прямо на железном сервере
2. Приложения вместе с виртуальным окружением (venv), запакованные в deb-пакеты, точно так же на сервере.
3. Контейнеры в собственном Docker-совместимом облаке
4. Бинарная сборка.

https://github.com/docops-hq/conf/blob/master/moscowpython/19/yandex-python.md

Для меня Python — <del>язык, который я знаю наименее плохо</del> основной язык разработки, и я где-то возле второй эпохи. А где ваша компания (или вы лично)?

Go против Python.

Очередной конспект с #MoscowPythonConf2019. Виталий Левченко мастерски набрасывает на Python, буквально на все больные точки надавил.

https://github.com/docops-hq/conf/blob/master/moscowpython/19/go-vs-python.md

Не могу удержаться от ещё одного опроса.

Ещё CodeFest X.

Тем временем, моя коллега из Плеска Надя Мануйлова закинула пуллреквест с ещё 4 конспектами CodeFest:

— Додо в LeSS: как не заблудиться
— Основные ошибки при проведении экспериментов
— Moneyball. Как построить команду продактов, когда на рынке их нет
— Сколько нужно энергии для работы Scrum Master, Product Owner и Agile Coach?

И там ещё конспекты добавятся. А потом будет второй, секретный этап. Я вам про него позже расскажу. А пока что спасибо Наде!

Непрерывная локализация.

Слышали про принцип «сдвига влево» (shift left)? Непрерывная локализация (continuous localization) реализует этот принцип для перевода документации, интерфейса и других текстов.

Раньше было так: сначала разработка, потом пишем тексты, потом их переводим и наконец можем выпустить релиз. А теперь мы пишем тексты на этапе проектирования, а робот забирает их и отдаёт переводчикам. А готовые переводы сам коммитит обратно в ветку разработки. Тексты и переводы перестают блокировать релиз, и это уменьшает time to market всего продукта. Угадайте, как это влияет на прибыль и риски компании?

Техписатели из Xsolla рассказали на Хабре, как у них выстроен процесс непрерывной локализации. Они там переводят 20 проектов на 20 языков, сроки сжатые, всё автоматизировано. Xsolla крутые, спасибо им за статьи.

— 20 проектов, 20 языков, срок вчера
— 20 проектов, 20 языков, срок вчера. Часть 2