#вопросвлоб

Всем привет! В рубрике "Вопрос в лоб" мы обычно разбираем частые вопросы на собеседованиях, но на этот раз поговорим немного о другом, не отходя от темы.

Как изменился наём техписателей за последние годы?

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

📌 Легко вкатиться в IT — всё

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

📌 Техписатель — известная сущность

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

📌 Без джунов

Компании ищут не специалиста, а решение проблем. Поэтому чаще нужны самостоятельные единицы, которые готовы предложить своё решение, внедрить новые процессы. А это грейд middle и выше. Место джунов чаще всего замещают стажёры: они дешевле обходятся компании, и после стажировки работодатель получает самостоятельных junior plus или pre-middle, которые стоят дешевле обычных мидлов со стороны и уже могут приносить пользу бизнесу.

📌 Управленческие скиллы

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

📌 Смещение компетенций

Общий тренд на пресловутый ИИ привёл к изменению ландшафта компетенций (ух, как мы завернули!). Сейчас мало писать текст, важно уметь использовать все доступные инструменты для достижения цели.

А какие вы наблюдаете изменения?

#средаразработки

Всем привет! В сообществе техписателей часто звучат разговоры о docs as code и о том, что мы используем методы и инструменты разработчиков. Допустим, мы используем Git. Но задумывались ли вы о том, как именно мы работаем с ветками? Какой тип ветвления нам подходит? Предлагаем вместе обсудить эту важную тему:

Что выбрать: Central Workflow, TBD или GitFlow?

Поясним для новичков: эти три основных подхода к работе с ветками. Конечно, они не включают бессмертного варианта: "Ребята, какая у нас ветка актуальная?" 😉

Итак, коротко:

1️⃣ Central Workflow. Одна ветка основная, рабочая. Все изменения — это коммиты в эту ветку. Удобно, если вы работаете в одиночку в очень маленькой команде разработки и точно знаете, что все изменения в продукте идут последовательно.

👉 Например, один фронтендер создаёт модальные окна, а вы описываете заполнение полей в них и публикуете эти инструкции.

2️⃣ TBD (Trunk-Based Development). Три типа ветки: основная (master или main), feature-ветки и релизная ветка. Одно изменение — одна ветка. Здесь важно: ветка отводится для конкретного изменения, а не для всей функциональности целиком, и сливается в основную ветку как можно быстрее.

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

TBD в разработке имеет ещё одну особенность — разработчики могут использовать feature-toggle (флаги), которые включают или выключают какую-то недоработанную часть фичи в базе данных. Поскольку техписатели почти никогда не используют базу данных для сборки документации, нам не нужны флаги, но мы можем закомментировать часть текста.

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

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

3️⃣ GitFlow. Большой процесс со всеми типами веток. Классический GitFlow включает ветки main, develop, release-*, hotfix-* и feature-*. В отличие от TBD, в GitFlow каждая feature-ветка — это отдельная полноценная функциональность. Плюс в том, что пока фича не опубликована, ваши черновики по ней в основной ветке не маячат перед глазами других техписов.

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

Это лишь общее описание подходов, которое умещается в одном посте.

Расскажите, как вы работаете с ветками: придерживаетесь одной методологии или комбинируете их?