Продолжение темы про зоны ответственности Спасибо огромное за ответы! Особенно интересно было узнать про специфику отношений в командах в США (мы-то знаем, как у нас тут все устроено😏). Я согласна с ответами, добавлю чуть больше текста☺️ Худшее, что можно было сделать: 📍 Молча править или «подкручивать» решение за отсутствующего аналитика, даже из лучших побуждений - это почти гарантированно приведет к конфликтам и потере контекста. 📍 Брать на себя роль «спасателя релиза», когда аналитик фактически начинает принимать продуктовые решения без нужных для того полномочий. 📍 Коммуницировать проблему только с тестированием или разработкой, обходя руководителя - это замалчивание системной проблемы, которое точно «выйдет боком». 📍 Выпускать в релиз задачу с допущением, что «потом дочиним дефектами» (если и принимается такое решение, только с согласованием руководителя). С чем согласна: 👍 поставить руководителя в известность о несостыковках; 👍 перенести задачу в следующий релиз; 👍 дождаться ответственного аналитика. Что еще добавить можно из возможных шагов: 😇 Проверить существующее решение только на «своем участке» и об этом всех известить - этом случае появляются конкретные примеры. 😇 Как продолжение пункта выше, показать, какую часть общего решения покрывает «мой» участок, чтобы сложилась цельная картина масштабов изменений.