Ошибка #4 также касается коммуникации с вашими партнёрами по счастью (проекту, ага) — нечеткие зоны ответственности, что приводит либо к дублированию работы (причём с непонятным уровнем компетентности в ряде случаев), либо к пробелам в ней. Первое часто вызывает переделки друг за другом и конфликтные ситуации, а второе — пробелы в (спасибо, кэп) проделанной работе и последующее хаотичное тыкание пальцем "Отныне, Вася, этим будешь заниматься ты." 

Давайте вспомним, на чем фокусируется сферический аналитик в вакууме. На требованиях. Поняв, что такое требования в идеальном измерении, вполне несложно дедуцировать, где должна начинаться и заканчиваться ваша работа. Но есть пара нюансов: 1) под требованиями и 2) под границами работы аналитика в компаниях/отделах/командах могут понимать и принимать всякое. Те, кто проходил курс от ITMINE, вероятно помнят, что с требованиями пересекается (создавая при этом "серые" области) ряд иной проектной информации: проектно-менеджерские штуки; то, "как" реализовать требования (design specifics); UI и пр. И раз ряд информации может иметь разных авторов в плане проработки, то и налицо потенциальные непонятки, кому и чем заниматься.

Часто встречающиеся кейсы и как с ними жить:
- Бизнес-аналитик прорабатывает структуру базы данных — либо потому, что так исторически сложилось, либо потому что команда или ПМ считают, что это натурально его компетенция. А девелоперы потом допиливают, ибо без слез на БД от БА смотреть нельзя.
Решение:
Если вы СА, то, вероятно, все в норме. Если же БА, то а) проговорите команде/автору процессов (ПМ, тим лид, etc.), что есть требования и что именно они — вотчина аналитиков. Например, "я как аналитик буду ограничиваться логической моделью данных, как и должен; я научу команду её правильно интерпретировать; в трансформацию же её в физическую реализацию лезть не буду, дабы не навредить криворукостью".

- Схожая по причинам ситуация: аналитик прорабатывает работу с внешним API, причём даже в таких вопросах, как "какой технически способ интеграции выбрать" и "в каких временных точках обращаться к эндпойнтам". Метод решения ситуации аналогичен предыдущему (если вы не СА и естественным образом не принимаете это за свой спектр деятельности): "я девочка, я хочу платье я аналитик, я отвечаю за требования ("что" вложить в систему, а не" как" это реализовать). Мы точно эффективно используем ресурсы? Я точно тот человек, который это лучше всех продумает? А вам точно кайф потом за мной все переделывать? Может, я остановлюсь вот тут и тут (использование API в контексте требований), а дальше уже вы подхватите (технические нюансы его использования)? Или же давайте вместе сядем и по ходу процесса каждый будет давать инпут в том ключе, где он компетентен. "

- Аналитик и дизайнер/юиксер делают одну и ту же работу или спорят, кому что делать. UI и UX—  это также часто серая область. Кто-то где-то относит это к требованиям, иные же — к деталям реализации. Есть вполне простое решение: если помимо аналитика есть люди, умеющие проработать UI/UX лучше, то считаем это не-требованиями и везде в артефактах БА не касаемся UI от слова совсем (не считая внешних ограничений, когда, например, заказчику нужен именно такой вот UI и никак иначе). Пусть будет полная свобода действий у дизайнера и им подобных ролей (и не будет пересечений в работе, не считая совместных коммуникаций с заказчиком). Если таких людей нет, то а) если для вас UI — cornerstone продукта, успехов вашей команде :), б) аналитику стоит считать это требованиями и включить в разных соприкосновениях в свои требования.

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