Овнер фичи или тимлид или продюсер. Зависит от команды и сферы.

Все кому с ним работать.

Тз- бизнес аналитик в связке с заказчиком Фтт - архитектор ФС - системный аналитик

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

Баба Маша ёбаный случий, тз устаревшая история. Исполнитель это специалист, заказчик желающий найти Решение. Какие нахуй тз?

Переговорили быстро, если сходитесь запцстили работу, время ценная штука, пока душные тз дрочите, Решение не приходит. С ТЗ как правило разного рода Аферы мутят боломутят, если заебись своё дело знаете, вам пары слов достаточно с Аудитом будет для поиска Решения. Но это если опытный исполнитель, если по проще ТЗ имеет место быть, но это Ёбань как и Рефференсы. Умение слышать и прямо говорить по Эффективнее

Тэзолог

Что такое Техническое Задание?)

Исполнитель

Заказчик, под чем то "сильнодействующим".

Аналитик

Я

В идеально мире - пишет заказчик. Передает. Мы уточняем и т.д. В реальности пишем мы… пишут аналитики. Проводят экспресс ППО и вперед

Мне кажется ТЗ должно формироваться заказчиком, и согласовываться с исполнителем на этапе планирования. В моём мире это просто документ, в котором вполне однозначными формулировками закреплено о чём заказчик с исполнителем договорились.

Остальное это скорее внутренняя документация. В том числе к этому я отношу и канбаны всякие. Это просто инструменты для управления командой, а не какие-то юридические документы.

Если речь про задачки которые предназначены для таскания по доске, то обычно они не пишутся для конкретного исполнителя. Это по сути как книга жалоб и предложений - пишут те, кому есть что написать. А потом кто-то ответственный решает как и кто это будет делать (и надо ли вообще это делать)

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

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

Отдел автоматизации

Вы лучше спросите, в скольких компаниях вообще знают это словосочетание. Я работаю в компании где за 13 лет двое программтстов написали в общем-то неплохую программу, но ТЗ там никогда небыло. В итоге там туча недоработок и несколько взаимоисключающих инструмента. Чего при наличии ТЗ было бы невозможно, но... Если бы люди знали что такое ТЗ и понимали бы его значимость, то системные аналитики были гораздо менее востребованы.

Системный аналитик

Менеджер проекта.

Всегда по разному. Расскажу про ТЗ для программистов, в своей компании. Если задача не сложная и не требует построения сложной архитектуры (Какие-то мелкие правки например) . То ТЗ может расписать Project Manager. Если же задача большая, требует построения сложной логики и расписания всех элементов в ТЗ. То ТЗ пишет старший программист, который занимается данным проектом, но перед этим его обязательно ставят в контекст задачи, чтоб он понимал, где? Зачем? И почему это надо.

Человек