#опросHR

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

Почему мы увольняемся? Результаты опроса

Часть 3. Топ-10 причин увольнения

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

Итак, почему же техписатели принимали решение уволиться по собственному желанию?

В тройке лидеров:
1. Не устраивают процессы в компании — 56,4%
2. Низкая заработная плата — 53,1%. Здесь содержится как невозможность роста оплаты труда, так и появившиеся интересные предложения.
3. Выгорел(а) — 32,5%

Далее места распределились следующим образом:
4. Неуютно в команде — 30,8%
5. Неинтересный стек — 29,9%
6. Не сложились отношения с руководителем — 29,1%
7. Увольнение связано с обстоятельствами в личной жизни — 9,4%
8. Документация не ценится, развивать невозможно — 5,4%
9. Не одобряю деятельность компании — 4,3%
10. Чувствую, что не справляюсь с обязанностями — 3,4%.

Отличаются ли эти ответы в целом по рынку труда в IT? Скорее нет. Мы не нашли современных масштабных исследований (если у вас есть, поделитесь, пожалуйста), но фрагменты оспросов 10-летней давности подтвердили наши результаты.

Мы попросили поделиться своими наблюдениями IT-рекрутера Татьяну Сабитову.

- По рынку все очень подвижно. Где-то финансирование заканчивается и проекты схлопываются — компании экономят. Поэтому люди сами выходят на рынок из-за отсутствия перспектив. Бывает, что не совпадают ожидание и реальность: недостаточно подробно обсуждают предстоящие задачи на этапе собеседования и офера. Среди причин также называют желание роста в должности, переход в другую сферу, например от внутренней разработки в продуктовую команду. Из банков часто уходят из-за бюрократии, а кто-то, наоборот, хочет больше структурности и уходит в банк.
Может поменяться руководство, а с ним и процессы.
В последнее время появились новые причины: неготовность к релокации, возвращение в РФ или желание работать в аккредитованной IT-компании.

В следующем посте мы расскажем об отношениях с руководителями и проблемах в компании.

#вопросвлоб

Всем привет! В рубрике "Вопрос в лоб" мы рассказываем о частых вопросах на собеседованиях. А сегодня поговорим об одном из приёмов: лайфдокинге.
Впервые мы встретили этот термин в одном из профессиональных чатов, так что слово не наше, а приём знакомый)

Лайфдокинг. Анализ статьи

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

В первую очередь постарайтесь успокоиться. Не стесняйтесь рассуждать вслух.

1️⃣ Попытайтесь выяснить или предположить, для какой аудитории написана статья.
2️⃣ Уточните или предположите, какова её цель: описать интерфейс, описать возможности или дать конкретную инструкцию.

Далее смотрите на статью, учитывая ответы на эти два вопроса.

3️⃣ Есть ли в статье внятная структура: заголовок и связанные между собой подзаголовки.
4️⃣ Чаще всего показывают инструкцию: убедитесь, что в ней есть предварительные требования, информация о правах и доступах, пошаговое описание действий, ожидаемый результат, а также информация о решении проблем или ссылка на нужный раздел.

Обязательно скажите, что это то, что вы можете сказать быстро. Попросите ещё время, чтобы выполнить анализ содержания статьи. Дополнительное время - это нормально.

5️⃣ Проверьте, соответствует ли содержание статьи её цели, выполняет ли нужные задачи. Например, достаточно ли информации, чтобы пользователь выполнил нужную настройку.
6️⃣ Проверьте, нет ли в статье опечаток или ошибок, и прост ли язык изложения. Учтите, что статья может быть написана по правилам, установленным в компании.

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

А вы сталкивались с лайфдокингом? Расскажите о своём опыте.

#мемница
Как рассказать зумерам о типах статей в документации

#twd3
Всем привет!
Друзья, мы снова в информационных спонсорах профессиональной конференции техписателей TechWriterDays#3. И мы готовы рассказывать о ней, о докладах и спикерах и отвечать на ваши вопросы. Позже мы разыграем среди наших подписчиков один офлайн-билет на конференцию. Следите за новостями🤗

А пока напоминаем, что доклады принимаются до 1 сентября 2025 года.

🤔 — Можно ли будет подать доклад позже?

Такая возможность есть, но не гарантирована. Программный комитет может открыть приём докладов с 20 ноября по 1 декабря, но на те тематики, которые решит обогатить.

Чтобы подать доклад, перейдите на официальный сайт конференции и нажмите кнопку Подать доклад.

🧐 — А если я сомневаюсь в теме?

Подавайте ту тему, которую считаете нужной и важной. С вами свяжется куратор, побеседует и поможет доработать тему или сместить фокус, если это будет нужно.

Больше информации для спикеров читайте здесь.

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

#выпуск 19
Всем привет! Продолжаем сопровождать новичков в мир документирования в IT.
Сегодня мы поговорим о том, что важно не только новичкам, но и тем техписателям, кто переходит из смежных сфер.

Цикл разработки ПО. Введение

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

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

🔸 Планирование
🔸 Анализ
🔸 Дизайн
🔸 Разработка
🔸 Тестирование
🔸 Внедрение и использование

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

Для чего техписателю эта информация?
Чтобы проектировать и создавать документацию, планировать свою занятость в проекте и знать, кто будет носителем знаний на определённом этапе.

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

#анонс
Всем привет!

Конец лета — время, когда новые знания, кажется, так и витают в воздухе... Постарайтесь не упустить возможность прокачать профессиональные навыки и обменяться опытом с коллегами из других компаний) Да-да, речь о WriteConf — конференции по созданию контента в IT!

На мероприятии будут:

🔘 Доклады по внутренним и внешним текстам
🔘 Мастер-классы
🔘 Круглый стол
🔥 И даже «прожарка» кейсов!

Конференция будет проходить офлайн и онлайн. Подробности, программу и билеты ищите на сайте мероприятия.

#циталити

Екатерина Ушакова
Канал Ушакова — директор буковок @ringova

#выпуск 20 #практика

Всем привет! Сегодня несём новичкам (и не только!) два отличных курса от наших коллег.

1️⃣ Docs as code для самых маленьких

Автор канала Parawriter Антон Гафаров рассказывает о парадигме docs as code и объясняет, как с нуля развернуть свою документацию.

2️⃣ Курс по проектированию и документированию API для технических писателей

Техписатель Денис Ребенок (канал @pro_techwriting) разъясняет, как описывать API и как затем опубликовывать API-документацию.

Давайте качать харды вместе! 😎

#анонс

Всем привет!
Нас попросили рассказать об одной конференции, и мы с радостью это делаем. И вот почему:

1. Это содержательная и полезная конференция для техписателей.
2. Много технины — то, по чему соскучились опытные коллеги. Ух, давно такое не анонсировали!
3. Это бесплатно. И можно подключиться онлайн — отличная возможность для техписателей из регионов. Если вы из Москвы или можете приехать в столицу, отлично — побываете в офисе СберТеха и позадаёте вопросы лично. Нетворкинг — наше всё)

А теперь конкретика (цитируем):

Doc Config 2025: как ИИ, скрипты и автоматизация меняют документацию

🗓26 сентября СберТех зовет на Doc Config 2025 — конференцию по технологичному документированию для разработчиков и технических писателей.

➡️О чем поговорим:

• Инструменты — скрипты для генерации контента с нуля, валидаторы, линтеры и многое другое;
• Автоматизация — от структурной миграции тысяч файлов до генерации готовых документов;
• ИИ в документировании — практические инструменты для проверки стиля, качества или интеллектуального поиска;
• Суровые кейсы — опыт разработки сложнейшей документации от экспертов СберТеха и ведущих ИТ-компаний.

Вас ждут очно и онлайн!

🔗Посмотреть программу и зарегистрироваться

#мемница

То самое ощущение, когда что-то делаешь, но результата (пока что) нет…

#мемница
POV: когда окнули статью после тысячи этапов ревью

#писалитирекомендует
Всем привет!
Как найти работу, если нет опыта?

Да, намекаем на стажировки)

Мы уже рассказывали о стажировках в Озоне и Лаборатории Касперского. А теперь знакомим новичков с PTЛабс — это те самые Госуслуги)

Почитать о всей программе стажировок можно вот здесь. В этом году РТЛабс открыл набор и стажёров-техписателей.

С вопросами и резюме можно приходить к лиду техписателей в РТЛабс Марии Киселёвой @fintiplushka.

#какэтоработает
Всем привет! Сегодня у нас маленькая, но очень важная тема:

Три правила хороших Release Notes

Release Notes — это описание изменений в продукте, которые появились после выпуска новой версии. Его называют релизнотами, а по-русски — описание релиза или список изменений (и ещё пара десятков названий на любой вкус).

Собирать релизноты — это целое искусство, но поделимся только 3 правилами, которых мы рекомендуем придерживаться.

1️⃣ Структурируйте информацию. Вы можете разделить текст на три условных части:
- Что нового
- Что доработано
- Что исправлено/удалено.

2️⃣ Пишите в мире пользователя: поясняйте, что для него изменится в продукте. Не рассказывайте, что сделала команда — говорите, что теперь сможет сделать пользователь. Например, вместо "доработали механизм группировки задач" поясните, что пользователь теперь может группировать задачи по важному для него признаку.

3️⃣ Не перегружайте release notes информацией. Оставьте только самое важное. Пользователю не обязательно знать, на сколько градусов изменилось закругление рамки вокруг блока.

И, конечно, публиковать Release Notes нужно вовремя, вместе с обновлением продукта. Но это уже совсем другая история)

Эти правила — взгляд админов Техписалити! и касаются только пользовательской документации. Не соглашайтесь и делитесь своим опытом в комментариях)