^_^

Какие люди))

техрайтерский мир тесен ;)

Всем привет!

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

Основных вопроса два.

1. Где можно поискать хорошие гайдлайны по составлению широкого скопа документации на большую компанию?

2. Есть ли какие-нибудь удобные инструменты для набросков схем документации? Пока основным вариантом вижу драфтовую страницу (юзаем xWiki, т.е. в ней же и создать) с категориями-подкатегориями-ссылками, но, возможно, есть какие-нибудь более наглдяные онлайн-сервисы.

Если есть какие-то релевантные советы\книги\лекции\презентации\etc., буду благодарен за любые ссылки

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

был доклад https://www.writethedocs.org/videos/prague/2018/how-to-tear-down-existing-documentation-and-rewrite-docs-that-actually-work-alexandra-white/
не суперполезный прям, но на мысли может натолкнёт

@SuckMyNuts спасибо :-)

Сорри, что так редко выходит какой-то ориджынал контент, совсем нет времени, но вот вам (довольно небрежный, если уж совсем на чистоту, но суть ясна) мой перевод статьи Тома Престона-Вернера, со-основателя GitHub, о важности написания README в самом начале разработки (чего-либо).

https://telegra.ph/Readme-Driven-Development-09-25

Спасибо!

Сплошные благодарности в чате )

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

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

СОЛДАТЫ И НАЁМНИКИ

Бизнес — это война, а все работники условно делятся на солдат и наёмников.

Эти два типа людей различаются примерно всем. Если вы с солдатами попробуете обращаться как с наёмниками, то быстро останетесь без бойцов. Если вы наёмник в роте солдат, то уютненько вам не будет.

Вот некоторые мои соображения по этому поводу:

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

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

Появилась программа Dita-OT
https://www.oxygenxml.com/events/2018/dita-ot_day.html#agenda
От себя. Какие вкусные темы. Просто очень вкусные.

Comparison between the DocBook and DITA publishing systems
Ох май гаш! Это тема!

a plugin which customizes the PDF processing in some way - милота!

Это сарказм? )

«Installing DITA-OT on macOS via Homebrew» — серьёзно, 50 минут доклада будет про brew install dita-ot?

ммм почему сарказм?