Мы под каждую фичу формируем отдельную проектную команда из состава продуктовой: аналитик, разработчик и тестировщик.
Если можем распараллелить разработку/тестирование, то тогда таких людей несколько в проектной команде.

Нужен обязательно, причём он должен к разработке подключаться ещё на этапе постановки задачи.  Тестировщики начинают свою документацию вести сразу же вместе с продуктовой.

Как функциональные/продуктовые команды ложатся на штатное расписание? Взаимодействие между линейными руководителями, лидами/РП в командах и т.д.?

+1

Привет! Это чатик со строгими правилами.

* Спамеры караются мгновенно, автоматически и навсегда.
1. Первые три сообщения от вас в этом чатике не должны содержать ссылок или форвардов. Включен авто-бан и удаление первого сообщения нового пользователя, если оно содержит ссылку.
2. Нетехдирские темы или использованием икс-лексики приводят к санкциям.  Любой может ответом на ваше сообщение написать "!report" и после трёх таких жалоб вы уходите в молчанку на 30 минут.
3. Особо неадекватные могут заработать до 5 предупреждений от админов, после чего автоматически уходят в молчанку на сутки.
4. Все GIF и видео, аудио автоматически удаляются
5. Любые формы рекламы или объявления о вакансиях только по согласованию с основателем чатика.

Чтобы согласиться с правилами и общаться в чатике, нажми кнопку ниже этого текста!

Ребят такой вопрос ещё:
кто где ведёт базу багов?
Хочется получить примерно такую штуку:
1. Есть набор багов (со стороны пользователя)
2. Они привязываются к техническим багам
3. Мы видим, на каких именно версиях продукта эти баги были и понимаем, что n-багов пользовательских это например влияние одного технического бага
4. Видно, в какой версии решили эту проблему => решились все пользовательские баги

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

+ бывают баги, когда есть какая-то авария -> не работает довольно много. и мы можем в таком случае понимать, что все входящие запросы в support в эти 10 минут (точнее все, которые относятся к этому времени)  - следствие аварии и ничего править не нужно

jira очень удобная

введите понятие массовая жалоба

наверное там можно так сделать, но я пока не видел успешного кейса((  поэтому наверное и нет понимания, как там это устроить.
если пробовать по jira release делать, то получается что-то непонятное((

а как это правильно гуглить? пока нашёл только юр. жалобы

чтобы не путаться, внешние баги это тикеты, а не баги.
У нас тикеты свои, но систем таких много- zendesk там
отношение тикет-баг обычно много ко многим

там можно понять как-то что "этот баг отвечает за n-пользовательских багов" и мы его уже поправили => можно не тратить время разрабов?

в багах ссылки на тикеты, саппорт подписан

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

кто-то тикеты должен разбирать и привязывать (саппорт)

просто 1 агрегирующую сущность добавьте в какой-то из ваших систем в зависимости от структуры кастомер суппорт-л1-л2-л3 и т.д.

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

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