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

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

Ну то есть, вместо перечисления настроек вида «настройка А нужна чтобы сделать Б» будет перечисление задач вида «чтобы сделать Б воспользуйтесь настройкой А»

Так ли важно, в каком виде это сформулировано, если я ищу «как сделать Б?»

"ультимативное счастье" - хорошо сказано 👍

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

Обычно вопрос именно в зарплате. И сравнивают не с  инженерами вообще, а с разработчиками. У тестировщиков, например, тоже часто такие сравнения

Не всегда. Это зависит, в первую очередь от стиля изложения материала. linear или by-task. Некоторый софт предполагает работу только с первым linear. Там не освоив 1, не получится сделать 2.

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

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

Не всё, что user story, use case и т. п. — это маркетинг)) Точнее это не что-то уникальное именно для маркетинга.

Напомнило лекции по общей психологии  МГУ... Я сейчас вам буду давать информацию, если вы ее не понимаете, не расстраивайтесь, просто записывайте. Это будут ответы на вопросы, которые вы зададите себе в будущем😂

Допустим, я проанализировал и выяснил, что половина моих пользователей ищет «как мне сделать Б» а другая половина «для чего настройка А». Каким из двух предложенных способов описания правильнее будет воспользоваться?

Почему я написал про маркетинг и маркетологов. Когда я только начинал карьеру в техническом писательстве, мне было непонятно - как писать и о чем писать. Тогда я ещё был студентом, изучал маркетинг и рекламное дело. И мне попалась книга Marketing Management Филиппа Котлера. Что полезное я почерпнул там - “стоит помнить, что если человек покупает в магазине дрель, то он на самом деле нуждается лишь в некотором количестве отверстий“. Этот принцип с тех пор и использую в работе -  ваша дрель может выглядеть как угодно и сверлить в разных вариациях, но важно лишь то, что нужно пользователю на самом деле. Помним об отверстиях :)

я не понял про дрель. я могу сегодня сделать одно отверстие, завтра два и через год - три. А ещё я могу использовать дрель как шуруповерт.
Моя дрель всегда под рукой и я могу одолжить её симпатичной соседке.
Это факт.

Это будет пошаговая процедура (step-by-step instruction) , в которой вы расскажете пользователю, как выполнить его задачу. И где-нибудь на шаге четвёртом попутно расскажете о том, какие опции нужно выбрать. Рассказ о любых опциях и настройках стоит помещать в контекст задачи пользователя.

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

Помните фильм "Волк с Wall Street" и эпизод "продай мне эту ручку"? Вот так нужно писать Release Notes. Нужно попытаться "продать" каждую новую feature с точки зрения impact на бизнес-сценарии пользователя.

ИМХО, такие вопросы задают исключительно те, кто в конечном приближении видит себя как раз инженером.

То есть претензия к деньгам тут вторична; причина такой позиции как раз в том, что сам человек считает профессию техписателя второсортной по сравнению с инженерами, разработчиками и пр. И хочет занимать первосортную позицию (ну или активно продвигается к ней — переходит их техписательства в программирование и пр.)

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

но, повторюсь, это мое ситуативное мнение, не принимайте на свой счет вне зависимости от того, в каком вы лагере:)

(ну и в целом все споры на тему «столяр супротив плотника» априори холиварны и не имеют правильных ответов)

Чего ещё полезного стоит почитать техническому писателю, который пишет на английском. The Elements of Style. https://www.amazon.com/Elements-Style-Fourth-William-Strunk/dp/020530902X Этой книге уже сто лет, но она все ещё не теряет актуальности. Что мне в ней понравилось, запомнилось, и что я сейчас использую в работе - принцип "omit needless words". Сначала это может показаться сложным - пишешь свой текст, потом перечитываешь его в поисках слов, которые можно выкинуть. Потом это входит в привычку. В какой-то момент, если пишешь на английском, привычным становится писать сразу без лишних слов.