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

По моему опыту, ежедневные "пятиминутки" (aka scrum-митинги) в известном формате "что сделал вчера, что будешь делать сегодня, какая нужна помощь" очень здорово помогают в установлении взаимодействия. Но внедрить и удержать эту практику не так-то просто.

Соблюдение сроков и приоритезация

Если при планировании не учтены поправочные коэффициенты, то срыв сроков будет всегда.

Как вообще соотносятся ПМы и аналитики? У ПМа — по аналитику, у ПМа — по несколько аналитиков, на одного аналитика бывает несколько ПМов?
Если несколько ПМов — то понятно, что «ошибки» в приоритезации будут всегда, потому что «мой проект самый важный».

У нас ПМ и аналитик это один и тот же человек. Т.е. с момента как нам передается клиент на поддержку какому то из аналитиков, он становится его ПМ-ом, ну и аналитика никуда не девается..

По моему опыту, ежедневные "пятиминутки" (aka scrum-митинги) в известном формате "что сделал вчера, что будешь делать сегодня, какая нужна помощь" очень здорово помогают в установлении взаимодействия. Но внедрить и удержать эту практику не так-то просто.

Насчет пятиминуток полностью согласна, но только для установления взаимодействия. В плане какой-то помощи отделу в целом - пользы пока не увидела (именной той, что ожидаема).

Насчет пятиминуток полностью согласна, но только для установления взаимодействия. В плане какой-то помощи отделу в целом - пользы пока не увидела (именной той, что ожидаема).

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

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

Очень хороший метод - работа в паре. Это очень продуктивно не только в программировании, но и в тестировании, и в проектировании, и в подготовке документов. Но есть обратная сторона у продуктивности: это здорово выматывает.

Мне, например, до сих пор не удалось преодолеть сопротивление людей, не привыкших к такой практике. Руководство не понимает, почему два человека занимаются одной задачей, когда другие задачи стоят, а сами разработчики не любят нарушения своих собственных ритмов и дополнительного контроля за своими действиями. Использую только в авральных случаях, не больше чем на несколько часов.

1. более прозрачно увидеть все задачи в соответствии с их приоритетами и сроками реализации.
3. иметь представление о том, кто чем занимается в текущий момент времени.

Посмотрите в сторону систем управления задачами (JIRA, etc.).

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

Не понятно, что понимается под словом "уметь". Иметь физическую возможность, иметь требуемые навыки и квалификацию, иметь возможность "не забыть" про эту задачу или еще что-то?

4. в случае появления неожиданных задач в середине итерации не сильно сбиваться с запланированных сроков.

Как уже сказали выше, можно закладывать резервы на риски, можно привлекать внешних подрядчиков, можно работать по 10-12 часов в день (а вдруг?), можно придумать еще какие-то варианты. Но вначале надо понять имеющиеся на данный момент проблемы срыва сроков и отталкиваться уже от них.

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

По-моему до сих пор нет однозначного ответа на вопрос: "Как измерить качество работы аналитика?". Хотя разговоры по этому поводу периодически возникают то тут, то там. В том числе и на этом форуме есть несколько топиков, посвященных данной теме.

Посмотрите в сторону систем управления задачами (JIRA, etc.).
Не понятно, что понимается под словом "уметь". Иметь физическую возможность, иметь требуемые навыки и квалификацию, иметь возможность "не забыть" про эту задачу или еще что-то?
Как уже сказали выше, можно закладывать резервы на риски, можно привлекать внешних подрядчиков, можно работать по 10-12 часов в день (а вдруг?), можно придумать еще какие-то варианты. Но вначале надо понять имеющиеся на данный момент проблемы срыва сроков и отталкиваться уже от них.
По-моему до сих пор нет однозначного ответа на вопрос: "Как измерить качество работы аналитика?". Хотя разговоры по этому поводу периодически возникают то тут, то там. В том числе и на этом форуме есть несколько топиков, посвященных данной теме.

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

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

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

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

В любом случае надо проанализировать плюсы и минусы обоих подходов применительно к вашей ситуации.

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

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

Возможно, будет интересно, если я расскажу, как устроено у нас. Правда, оно сильно по-другому, потому что основная масса аналитиков - погружена в проектную (sсrum)команду. Внутри команды аналитикой занимается руководитель проекта (он же PO, и у нас он внутри), и один из инженеров (это те, кто на поддержке и контактах с заказчиком). Плюс, по ситуации, аналитические задачи берет кто-то еще, из инженеров или разработчиков (если много техники). А еще есть группа сильных аналитиков, курирующих проекты. Они обычно занимаются новыми проектами, которые на стадии начального проектирования и разработки, но при этом приглядывают за проектными решениями внутри проектной группы. "Приглядывание" организовано по принципу прошлого участия в проектировании, так что человек в целом в контексте. В таких условиях в случае болезни или отпуска текучку всегда есть кому подхватить с приемлемым качеством. Что касается новых проектов, то там тоже выработка основных проектных решений обычно коллективная, а не индивидуальная и на начальных стадиях идет аудит. То есть по сути имеем ту же проектную команду, только с более сильным аналитическим составом (и некоторые - совместители). Примерно так.

Внедряем\поддерживаем заказчику систему ".. и управления запросами". Решили заточить ее под себя -  для управления запросами на доработку этой самой системы. В системе заказчик регистрирует заявку (бизнес требование\требование пользователя), которое в дальнейшем согласовывается в разных подразделениях и "обрастает" ТЗ, планом тестирования, переносов.. В любой момент времени можно выяснить на каком этапе заявка, кто ответственный, просмотреть документы, плановые даты реализации  и прочее.. Полная прозрачность!
В результате если кто-то уходит в отпуск или увольняются все задачи сотрудника легко перекидываются на коллег..
Как не говорится Сапожник с сапогами )