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

А если не расширение команды, то что?

не, альтернативы расширению команды нету, но зачастую к нему подходят формально. "мы дали вам человека, что ещё вам надо? отстаньте от инженеров, им работать надо")

в ответ на вопрос “если не расширение, то что?” у меня есть несколько вариантов (некоторые вне команды):
- оптимизация процессов в команде
- уменьшение числа новых фич
- удаление ненужных фич

кажется, что в большинстве случаев у документационной команды нет достаточного количества рычагов, чтобы сделать всё это:(

(если под оптимизацией процессов вы имеете в виду процессы в команде разработки или в других, внешних к техписательской, командах)

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

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

вот это, кажется, очень правильное направление мысли

ведь если цель общая — сделать хорошо понимаемый пользователями функционал — то, кажется, в эффективной документации заинтересованы все

например, компания не может быстро найти нескольких техписов. мы успешно брали в роли джуниор техписа qa из этой же команды

красиво. Я тоже пропагандирую идею поиска внутренних ресурсов и последующей помощи в росте и развитии им

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

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

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

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

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

> к руководителю документационной команды приходит кто-то и заставляет его против воли нанимать новых людей

У нас такого не происходит )

Обычно происходит наоборот.
Как мне кажется, весь разговор исходит из того факта, что большинство компаний до сих пор не понимаю, кто такие техпесы. Отсюда или неверно выставленные требования к должности или попытка заставить непричастных (тех же разрабов) писать документацию.
Я очень люблю разрабов, админов, но если бы в прод шла документация написанная ими...
Туши свет, я ухожу. (хотя именно такое я и встречал).
Что же касается онбординга и нежелание проводить/тратиться.
То мне всегда в этом случае вспоминается мем (примерно)

>  попытка заставить непричастных (тех же разрабов) писать документацию.

У нас разрабы часто пишут, причём по смыслу и структуре очень хорошо пишут. Помогаем только язык и оформление поправить.

можно ж писать эротические рассказы :D

В целом мысль про отрицательную эффективность очень интересная, есть над чем подумать. Спасибо )

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