#опросHR
Всем привет! Продолжаем публиковать результаты опроса о том, что заставляет нас менять работу. В прошлом посте мы рассказали о вынужденном увольнении. И сегодня расскажем о случаях, когда техписатель уволился по действительно собственному желанию.
Почему мы увольняемся? Результаты опроса
Часть 2. Увольнение по собственному. Общее состояние
Для начала поделимся неожиданным открытием - 65% опрошенных периодически испытывали желание уволиться. Некоторых техписателей это желание преследовало от 2 до 6 месяцев.
Ещё около 14% опрошенных отметили, что решили уволиться спонтанно. Однако у большинства последующие ответы (низкая зарплата, недопонимание с руководством) говорят о том, что предпосылки для ухода с этого места работы были. 18% спонтанно уволившихся приняли такое решение из-за предложений с более высокими заработными платами.
В их число тоже входят люди, которые заранее знали, что будут работать в компании недолго, например хотели получить опыт.
Из всех опрошенных 13% пришли к решению уволиться из-за возникших проблем: конфликт с руководителем, проблемы с заказчиком, ситуации в личной жизни.
Мы предложили респондентам подробнее указать причины своего решения.
Подробнее о конкретных причинах мы расскажем в следующем посте.
Всем привет! Продолжаем публиковать результаты опроса о том, что заставляет нас менять работу. В прошлом посте мы рассказали о вынужденном увольнении. И сегодня расскажем о случаях, когда техписатель уволился по действительно собственному желанию.
Почему мы увольняемся? Результаты опроса
Часть 2. Увольнение по собственному. Общее состояние
Для начала поделимся неожиданным открытием - 65% опрошенных периодически испытывали желание уволиться. Некоторых техписателей это желание преследовало от 2 до 6 месяцев.
Ещё около 14% опрошенных отметили, что решили уволиться спонтанно. Однако у большинства последующие ответы (низкая зарплата, недопонимание с руководством) говорят о том, что предпосылки для ухода с этого места работы были. 18% спонтанно уволившихся приняли такое решение из-за предложений с более высокими заработными платами.
Иначе говоря, только 21% опрошенных до момента увольнения работали в условиях, которые их полностью устраивали.
В их число тоже входят люди, которые заранее знали, что будут работать в компании недолго, например хотели получить опыт.
Из всех опрошенных 13% пришли к решению уволиться из-за возникших проблем: конфликт с руководителем, проблемы с заказчиком, ситуации в личной жизни.
Мы предложили респондентам подробнее указать причины своего решения.
Почти каждый третий опрошенный технический писатель указывает профессиональное выгорание в качестве причины увольнения.
Подробнее о конкретных причинах мы расскажем в следующем посте.
👍17❤12🔥9
#колонкаредактора
Всем привет! Данные, собранные компанией documentat, говорят, что техписатели, работающие в парадигме docs as code зарабатывают больше тех, кто использует стандартные подходы с редакторами-wysiwyg ("что видишь, то и получишь"). Иногда хочется просто присоединиться к касте "продвинутых" и тоже перейти на DaC. Предлагаем сначала задать себе вопрос:
Нужен ли мне docs as code?
Для чего нужно задавать этот вопрос? Как мы уже говорили ранее, сеньора отличает его способность действовать в интересах бизнеса. И в этом смысле результат всегда важнее, чем технологии.
Любая смена инструментов и методологии ведёт к расходу ресурсов. А мы должны считать свои ресурсы и тратить их только обоснованно.
Итак, когда этот расход обоснован:
1️⃣ Процесс создания документации сложен. Например, вы описываете одновременно несколько функциальностей, причём над документами работают разные техписатели, перед публикацией нужно получить согласования лидов, а документы могут "заехать" в прод в разное время.
2️⃣ Большинство из тех, кто создаёт документацию, работает в git. Например, разработчики создают и документируют свой сервис.
3️⃣ Изучение инструментов и подходов разработчиков целесообразно для остальных. Ценность продакт-менеджера не в том, что он может писать в markdown, а том, что он видит место продукта на рынке и может направить его развитие в экономически обоснованное русло. А кроме такого менеджера есть ещё бизнес-аналитики, профильные ручные тестировщики и другие люди, чьё время тратить на обучение ненужного им инструментария неправильно.
4️⃣ Количество людей, которые создают документацию, кратно меньше тех, кто её потребляет. Этот пункт связан с использованием процесса CI/CD. В ситуации, когда разработчик написал документацию, которую читают и используют три команды, подход docs as code оправдан. Когда над документом работают продакт-менеджер, аналитик, дизайнер и заказчик, и этот документ нужен только им — не оправдан.
Что мы имеем:
В компании вполне могут уживаться разные методологии создания документации и разные инструменты.
Например, требования, обсуждения и обзоры можно фиксировать с помощью линейных процессов и обычного инструмента с wysiwyg-редактором. А для создания документации, которую вы поставляете пользователям, удобно использовать подход docs as code.
Напомним, что наши публикации — это отражение нашего опыта и знаний. Но вы всегда можете представить свою точку зрения в комментариях.
Всем привет! Данные, собранные компанией documentat, говорят, что техписатели, работающие в парадигме docs as code зарабатывают больше тех, кто использует стандартные подходы с редакторами-wysiwyg ("что видишь, то и получишь"). Иногда хочется просто присоединиться к касте "продвинутых" и тоже перейти на DaC. Предлагаем сначала задать себе вопрос:
Нужен ли мне docs as code?
Для чего нужно задавать этот вопрос? Как мы уже говорили ранее, сеньора отличает его способность действовать в интересах бизнеса. И в этом смысле результат всегда важнее, чем технологии.
Любая смена инструментов и методологии ведёт к расходу ресурсов. А мы должны считать свои ресурсы и тратить их только обоснованно.
Итак, когда этот расход обоснован:
1️⃣ Процесс создания документации сложен. Например, вы описываете одновременно несколько функциальностей, причём над документами работают разные техписатели, перед публикацией нужно получить согласования лидов, а документы могут "заехать" в прод в разное время.
2️⃣ Большинство из тех, кто создаёт документацию, работает в git. Например, разработчики создают и документируют свой сервис.
3️⃣ Изучение инструментов и подходов разработчиков целесообразно для остальных. Ценность продакт-менеджера не в том, что он может писать в markdown, а том, что он видит место продукта на рынке и может направить его развитие в экономически обоснованное русло. А кроме такого менеджера есть ещё бизнес-аналитики, профильные ручные тестировщики и другие люди, чьё время тратить на обучение ненужного им инструментария неправильно.
4️⃣ Количество людей, которые создают документацию, кратно меньше тех, кто её потребляет. Этот пункт связан с использованием процесса CI/CD. В ситуации, когда разработчик написал документацию, которую читают и используют три команды, подход docs as code оправдан. Когда над документом работают продакт-менеджер, аналитик, дизайнер и заказчик, и этот документ нужен только им — не оправдан.
Что мы имеем:
В компании вполне могут уживаться разные методологии создания документации и разные инструменты.
Например, требования, обсуждения и обзоры можно фиксировать с помощью линейных процессов и обычного инструмента с wysiwyg-редактором. А для создания документации, которую вы поставляете пользователям, удобно использовать подход docs as code.
Напомним, что наши публикации — это отражение нашего опыта и знаний. Но вы всегда можете представить свою точку зрения в комментариях.
❤21✍4
#опрос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-рекрутера Татьяну Сабитову.
В следующем посте мы расскажем об отношениях с руководителями и проблемах в компании.
Всем привет! Продолжаем публиковать результаты опроса о том, что заставляет нас менять работу. И сегодня расскажем о конкретных причинах увольнений.
Почему мы увольняемся? Результаты опроса
Часть 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-компании.
В следующем посте мы расскажем об отношениях с руководителями и проблемах в компании.
🔥18👍5❤2
#вопросвлоб
Всем привет! В рубрике "Вопрос в лоб" мы рассказываем о частых вопросах на собеседованиях. А сегодня поговорим об одном из приёмов: лайфдокинге.
Впервые мы встретили этот термин в одном из профессиональных чатов, так что слово не наше, а приём знакомый)
Лайфдокинг. Анализ статьи
Не все компании дают тестовое задание, посколько его легко можно выполнить с ИИ. Поэтому на собеседованиях могут попросить проанализировать статью.
Рассмотрим, как можно выполнить это задание.
В первую очередь постарайтесь успокоиться. Не стесняйтесь рассуждать вслух.
1️⃣ Попытайтесь выяснить или предположить, для какой аудитории написана статья.
2️⃣ Уточните или предположите, какова её цель: описать интерфейс, описать возможности или дать конкретную инструкцию.
Далее смотрите на статью, учитывая ответы на эти два вопроса.
3️⃣ Есть ли в статье внятная структура: заголовок и связанные между собой подзаголовки.
4️⃣ Чаще всего показывают инструкцию: убедитесь, что в ней есть предварительные требования, информация о правах и доступах, пошаговое описание действий, ожидаемый результат, а также информация о решении проблем или ссылка на нужный раздел.
Обязательно скажите, что это то, что вы можете сказать быстро. Попросите ещё время, чтобы выполнить анализ содержания статьи. Дополнительное время - это нормально.
5️⃣ Проверьте, соответствует ли содержание статьи её цели, выполняет ли нужные задачи. Например, достаточно ли информации, чтобы пользователь выполнил нужную настройку.
6️⃣ Проверьте, нет ли в статье опечаток или ошибок, и прост ли язык изложения. Учтите, что статья может быть написана по правилам, установленным в компании.
Вам могут показать не только плохую статью, но и удачную. Поэтому не смущайтесь, если вы не видите серьёзных недостатков. В этом случае можно отметить все плюсы и обосновать их. Плюсы искать можно по тому же алгоритму, что и минусы.
А вы сталкивались с лайфдокингом? Расскажите о своём опыте.
Всем привет! В рубрике "Вопрос в лоб" мы рассказываем о частых вопросах на собеседованиях. А сегодня поговорим об одном из приёмов: лайфдокинге.
Впервые мы встретили этот термин в одном из профессиональных чатов, так что слово не наше, а приём знакомый)
Лайфдокинг. Анализ статьи
Не все компании дают тестовое задание, посколько его легко можно выполнить с ИИ. Поэтому на собеседованиях могут попросить проанализировать статью.
Рассмотрим, как можно выполнить это задание.
В первую очередь постарайтесь успокоиться. Не стесняйтесь рассуждать вслух.
1️⃣ Попытайтесь выяснить или предположить, для какой аудитории написана статья.
2️⃣ Уточните или предположите, какова её цель: описать интерфейс, описать возможности или дать конкретную инструкцию.
Далее смотрите на статью, учитывая ответы на эти два вопроса.
3️⃣ Есть ли в статье внятная структура: заголовок и связанные между собой подзаголовки.
4️⃣ Чаще всего показывают инструкцию: убедитесь, что в ней есть предварительные требования, информация о правах и доступах, пошаговое описание действий, ожидаемый результат, а также информация о решении проблем или ссылка на нужный раздел.
Обязательно скажите, что это то, что вы можете сказать быстро. Попросите ещё время, чтобы выполнить анализ содержания статьи. Дополнительное время - это нормально.
5️⃣ Проверьте, соответствует ли содержание статьи её цели, выполняет ли нужные задачи. Например, достаточно ли информации, чтобы пользователь выполнил нужную настройку.
6️⃣ Проверьте, нет ли в статье опечаток или ошибок, и прост ли язык изложения. Учтите, что статья может быть написана по правилам, установленным в компании.
Вам могут показать не только плохую статью, но и удачную. Поэтому не смущайтесь, если вы не видите серьёзных недостатков. В этом случае можно отметить все плюсы и обосновать их. Плюсы искать можно по тому же алгоритму, что и минусы.
А вы сталкивались с лайфдокингом? Расскажите о своём опыте.
🔥28👍11
#twd3
Всем привет!
Друзья, мы снова в информационных спонсорах профессиональной конференции техписателей TechWriterDays#3. И мы готовы рассказывать о ней, о докладах и спикерах и отвечать на ваши вопросы. Позже мы разыграем среди наших подписчиков один офлайн-билет на конференцию. Следите за новостями🤗
А пока напоминаем, что доклады принимаются до 1 сентября 2025 года.
🤔 — Можно ли будет подать доклад позже?
Такая возможность есть, но не гарантирована. Программный комитет может открыть приём докладов с 20 ноября по 1 декабря, но на те тематики, которые решит обогатить.
Чтобы подать доклад, перейдите на официальный сайт конференции и нажмите кнопку Подать доклад.
🧐 — А если я сомневаюсь в теме?
Подавайте ту тему, которую считаете нужной и важной. С вами свяжется куратор, побеседует и поможет доработать тему или сместить фокус, если это будет нужно.
Больше информации для спикеров читайте здесь.
А если вы хотите посетить конференцию в качестве слушателя, напоминаем, что сегодня билеты стоят меньше, чем будут стоить потом.
Всем привет!
Друзья, мы снова в информационных спонсорах профессиональной конференции техписателей TechWriterDays#3. И мы готовы рассказывать о ней, о докладах и спикерах и отвечать на ваши вопросы. Позже мы разыграем среди наших подписчиков один офлайн-билет на конференцию. Следите за новостями🤗
А пока напоминаем, что доклады принимаются до 1 сентября 2025 года.
🤔 — Можно ли будет подать доклад позже?
Такая возможность есть, но не гарантирована. Программный комитет может открыть приём докладов с 20 ноября по 1 декабря, но на те тематики, которые решит обогатить.
Чтобы подать доклад, перейдите на официальный сайт конференции и нажмите кнопку Подать доклад.
🧐 — А если я сомневаюсь в теме?
Подавайте ту тему, которую считаете нужной и важной. С вами свяжется куратор, побеседует и поможет доработать тему или сместить фокус, если это будет нужно.
Больше информации для спикеров читайте здесь.
А если вы хотите посетить конференцию в качестве слушателя, напоминаем, что сегодня билеты стоят меньше, чем будут стоить потом.
🔥13❤2
#выпуск 19
Всем привет! Продолжаем сопровождать новичков в мир документирования в IT.
Сегодня мы поговорим о том, что важно не только новичкам, но и тем техписателям, кто переходит из смежных сфер.
Цикл разработки ПО. Введение
Это то, что необязательно знать на зубок, но важно понимать и представлять. Компании практикуют разные подходы. Мы расскажем вам о своём опыте и передадим своё видение.
Почему же говорят "цикл разработки"? Потому что это круг, закольцованная последовательность этапов, каждый вытекает из предыдущего и даёт жизнь следующему. Какие же это этапы?
🔸 Планирование
🔸 Анализ
🔸 Дизайн
🔸 Разработка
🔸 Тестирование
🔸 Внедрение и использование
Казалось бы, на внедрении можно и закончить, но нет. Пока продукт жив, команда собирает обратную связь, анализирует потребности, и процесс снова заворачивается на этап планирования и опять идёт по кругу. Всё заканчивается, только если продуктом перестают пользоваться, и замирает на стадии использования, если продукт не поддерживают.
Для чего техписателю эта информация?
Чтобы проектировать и создавать документацию, планировать свою занятость в проекте и знать, кто будет носителем знаний на определённом этапе.
В следующем посте в рубрике поговорим об этапе планирования: что делать техписателю и к кому обращаться за информацией.
Всем привет! Продолжаем сопровождать новичков в мир документирования в IT.
Сегодня мы поговорим о том, что важно не только новичкам, но и тем техписателям, кто переходит из смежных сфер.
Цикл разработки ПО. Введение
Это то, что необязательно знать на зубок, но важно понимать и представлять. Компании практикуют разные подходы. Мы расскажем вам о своём опыте и передадим своё видение.
Почему же говорят "цикл разработки"? Потому что это круг, закольцованная последовательность этапов, каждый вытекает из предыдущего и даёт жизнь следующему. Какие же это этапы?
🔸 Планирование
🔸 Анализ
🔸 Дизайн
🔸 Разработка
🔸 Тестирование
🔸 Внедрение и использование
Казалось бы, на внедрении можно и закончить, но нет. Пока продукт жив, команда собирает обратную связь, анализирует потребности, и процесс снова заворачивается на этап планирования и опять идёт по кругу. Всё заканчивается, только если продуктом перестают пользоваться, и замирает на стадии использования, если продукт не поддерживают.
Для чего техписателю эта информация?
Чтобы проектировать и создавать документацию, планировать свою занятость в проекте и знать, кто будет носителем знаний на определённом этапе.
В следующем посте в рубрике поговорим об этапе планирования: что делать техписателю и к кому обращаться за информацией.
❤26✍17👍2💯1
This media is not supported in your browser
VIEW IN TELEGRAM
😁49🤣40🔥10😭7💯4❤3
#анонс
Всем привет!
Конец лета — время, когда новые знания, кажется, так и витают в воздухе... Постарайтесь не упустить возможность прокачать профессиональные навыки и обменяться опытом с коллегами из других компаний) Да-да, речь о WriteConf — конференции по созданию контента в IT!
На мероприятии будут:
🔘 Доклады по внутренним и внешним текстам
🔘 Мастер-классы
🔘 Круглый стол
🔥 И даже «прожарка» кейсов!
Конференция будет проходить офлайн и онлайн. Подробности, программу и билеты ищите на сайте мероприятия.
Всем привет!
Конец лета — время, когда новые знания, кажется, так и витают в воздухе... Постарайтесь не упустить возможность прокачать профессиональные навыки и обменяться опытом с коллегами из других компаний) Да-да, речь о WriteConf — конференции по созданию контента в IT!
На мероприятии будут:
🔘 Доклады по внутренним и внешним текстам
🔘 Мастер-классы
🔘 Круглый стол
🔥 И даже «прожарка» кейсов!
Конференция будет проходить офлайн и онлайн. Подробности, программу и билеты ищите на сайте мероприятия.
❤🔥7