Хм, я занималась документацией для партнеров и клиентов. Так сказать была и владельцем, и разработчиком ее: определяла и архитектуру, и структуру, и внешний вид, и сами буковки писала. Этим полностью снимала с начальника головную боль относительно документации. Использовали не MadCap Flare, а другой платный инструмент. Но зарплата была в разы меньше озвученной тут в чатике (( Правда, писала на русском, на английский мой коллега переводил

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

и потом, не всегда дело только в зарплате, тут можно только гадать, почему не можете найти нужного спеца...

привет, а кто пользуется трекерами, можете подсказать какие статусы задач и другие айтемы для документирования вам помогают?

я не нахожу в списке ничего подходящего когда работу "сделал"
всегда говорили ставь "ready to test" и отдавай автору

а сейчас началось, а чего автору, а не qa? кто тестирует? но в некоторой документации qa как бы и не привлекают (не знаю почему,мне было бы легче, но в общем нет времени вроде как. то сам все и проверяешь)

и еще не сильно понимаю вот этой разницы между
Ценность - нужно, важно и на будущее,
и Важность - обычная, средняя, высокая.
мне кажется это одно и тоже и просто приоритет, а не severity (масштаб, степень влияния)

https://monosnap.com/file/9Z5gKhHm8uPlio6nRemZgXIDl4Mid6

Привет. Кажется, что названия — вопрос внутренних договорённостей и процесса.

Ценность (также иногда severity, а не business value или customer value) — рейтинг задачи в планах менеджера продукта.
Важность — приоритет выполнения задачи. Задачи одной ценности выполняются с разным приоритетом.

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

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

Попробуйте построить свою схему рабочего процесса, и обсудите её с менеджером проекта.

Если команда небольшая — хороший вопрос для ретроспективы, если процесс гибкий.

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

Лучше с тем, который используется в задачах других специалистов. Если у всех Done, то и у вас Done, а не Published или Issued.

Так проще отследить, что происходит. Например, с помощью плагинов-аналогов плагина Structure в Atlassian Jira.

как видели службу технической документации в 1989 году

с лёгким налётом автоматизации

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

Nowadays: 80% нижнего уровня - в одной лицо DocOps (максимум два/три)

Спасибо!

Ух ты, ГОСТовский чертежный шрифт, прям няшно.

я ещё успел в школе застать уроки черчения - там этому шрифту учили

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

Я когда-то умел им писать, правда, не очень быстро) оформление чертежей в течение нескольких 5 лет универа располагает к тому, чтоб научиться.
Но потом все это дело перешло на электронные рельсы (б-же, храни Автокад! сколько он мне нервов сэкономил!)