Когда ведущий аналитик превратился в мини-РП: признаки перегруза и как вернуть роль в норму
Я думаю, что при работе на большом количестве проектов и с разными руководителями сотрудники сталкиваются с ситуацией, которую я разберу в данной статье.
На старте проекта все выглядит вполне логично: ведущий аналитик хорошо знает предметную область, быстрее остальных понимает, где команда застряла, и поэтому ему проще уточнить у разработчика срок, собрать вопросы перед встречей с заказчиком или напомнить коллегам, что к пятнице нужно закончить согласование требований. Руководитель проекта видит, что человек надежный и не теряет детали, поэтому постепенно начинает опираться на него все сильнее.
При таком раскладе через несколько месяцев роли уже выглядят совсем иначе - аналитик по-прежнему отвечает за требования, сложные сценарии и качество аналитической части, но параллельно собирает статусы по задачам, контролирует сроки, готовит клиентские встречи, следит за загрузкой специалистов, разбирает, кто кому что не передал, и фактически держит в голове состояние проекта. При этом формально руководителем проекта он не стал, а значит полномочия, время и ожидания команды остались прежними.
На этом месте речь уже идет не о помощи РП, а о размывании роли, потому что ведущий аналитик начинает выполнять управленческую работу между делом, а собственные задачи вынужден переносить на вечер, сокращать по глубине проработки или отдавать младшим аналитикам раньше, чем те готовы их забрать.
Все начинается с полезной помощи
Откуда же растут ноги у данной проблемы? Я считаю, что все-таки это не из-за умышленной передачи своих обязательств руководителем проекта. Обязанности добавляются по одной, причем каждая выглядит разумно: ведущий аналитик лучше всех понимает задачу, значит пусть сам уточнит срок у разработчика; он будет на встрече с заказчиком, поэтому заодно соберет статус по команде; он знает, где зависло согласование, значит проще попросить его проконтролировать ответ.
Каждое отдельное действие занимает немного времени, поэтому первое время никто не воспринимает его как смену роли. Но когда таких действий становится десяток, аналитик начинает жить сразу в двух режимах: с одной стороны, от него ждут глубокой проработки требований, проверки решений и помощи другим аналитикам, а с другой — постоянного контроля того, что происходит вокруг.
Эти два режима плохо сочетаются, потому что аналитическая работа требует длинных отрезков концентрации, тогда как управление проектом постоянно дробит день: нужно ответить на сообщение, уточнить срок, подключиться к встрече, собрать статус, напомнить ответственному и снова вернуться к документу, который до этого уже два раза приходилось откладывать.
Первый признак — аналитик знает состояние проекта лучше РП
Сам по себе хороший кругозор ведущего аналитика проблемой не является, поскольку он и должен понимать, что происходит в смежных задачах и как изменения в одной части влияют на другую. Вопрос возникает тогда, когда за актуальным статусом команда начинает идти именно к нему.
Особенно показательно, когда аналитик вынужден заранее собирать информацию у всех участников, потому что понимает, что на встрече вопросы все равно придут к нему. В результате он не просто знает проект, а фактически выполняет работу по синхронизации команды, хотя эта обязанность нигде отдельно не зафиксирована.
Второй признак — он отвечает за сроки, которыми не управляет
Есть большая разница между тем, чтобы оценить аналитическую часть задачи и тем, чтобы отвечать за общий срок. Ведущий аналитик может сказать, сколько времени понадобится на уточнение требований или подготовку ТЗ, однако финальный срок зависит еще от разработки, тестирования, участия заказчика и других работ, которыми он напрямую не управляет.
Когда аналитик начинает обещать дату за весь блок, потому что заказчик спрашивает именно его, появляется неприятная конструкция: ответственность за результат у него уже есть, а полномочий для управления ресурсами нет. Он не может самостоятельно переставить разработчиков между задачами, изменить приоритет проекта или договориться о переносе части работ, но при этом именно от него ждут объяснений, если дата начинает ехать.
Такой перекос довольно быстро приводит к тому, что аналитик пытается компенсировать отсутствие полномочий личным контролем, поэтому начинает чаще писать коллегам, проверять прогресс и держать все задачи в голове, а это еще сильнее затягивает его в работу РП.
Третий признак — подготовка к встрече превращается в управление проектом
Ведущий аналитик обычно участвует во встречах с заказчиком, поэтому ему естественно готовить материалы по своей части, собирать вопросы и заранее проверять спорные требования. Но если перед каждым созвоном он дополнительно выясняет статус разработки, готовит общий план, собирает просроченные вопросы, напоминает коллегам о договоренностях и решает, что нужно вынести на обсуждение, то речь уже идет не только об аналитической подготовке.
Еще заметнее это становится после встречи, когда тот же человек рассылает итоги, распределяет действия, контролирует выполнение и через несколько дней возвращается к коллегам с вопросом, почему договоренность не закрыта. По сути он начинает вести цикл управления встречей целиком, хотя изначально должен был отвечать только за содержание аналитического блока.
Здесь важно четко разделить две вещи: аналитик вполне может подготовить вопросы по требованиям и зафиксировать содержательные договоренности, но контроль общего списка действий, сроков и ответственных - обязанность РП, и нельзя передавать управление решениями аналитику только потому, что он лучше всех готовит протокол встреч.
Четвертый признак — команда приносит ему любые проблемы
Когда роль ведущего аналитика постепенно расширяется, команда быстро к этому привыкает, потому что обратиться к одному надежному человеку проще, чем разбираться, кто именно должен решить вопрос. В результате ему начинают приносить не только проблемы требований, но и задержки разработки, сложности с доступами, вопросы приоритетов, нехватку ресурсов и даже организационные конфликты.
Пока аналитик отвечает «я уточню», схема закрепляется, а через некоторое время он становится универсальной точкой эскалации. На первый взгляд это удобно, потому что вопросы действительно не теряются, однако у проекта появляется серьезная зависимость от одного человека, который постепенно превращается в диспетчера.
При этом часть проблем до РП может доходить уже в переработанном виде, когда ведущий аналитик сам поговорил с участниками, предложил решение и фактически снял вопрос. Руководителю проекта остается ощущение, что управленческой нагрузки немного, хотя значительную ее часть просто незаметно забрал другой сотрудник.
Аналитическая работа начинает делаться «когда никто не пишет»
Для меня это один из самых показательных признаков перегруза, и я сама сталкивалась с таким форматом работы. Если аналитик в течение дня почти все время отвечает на вопросы, участвует во встречах и контролирует чужие задачи, а требования начинает спокойно разбирать только вечером, значит его основная работа уже вытеснена обслуживанием проекта.
Это особенно опасно тем, что внешне сотрудник может продолжать хорошо справляться, поэтому проблема долго остается незаметной: документы подготовлены, встречи проведены, заказчик получает ответы, команда не простаивает. Цена становится видна позже, когда аналитик начинает работать дольше, быстрее устает, сокращает глубину проработки или перестает нормально проверять работу менее опытных коллег.
Иногда в этот момент возникает ошибочный вывод, что аналитику просто нужно лучше планировать время, хотя планирование не решает ситуацию, в которой человеку фактически назначили две полноценные роли и ожидают, что он уместит их в один рабочий день.
Почему такая схема вообще держится
Обычно потому, что в краткосрочной перспективе она действительно удобна. Заказчик получает человека, который знает почти все; РП может опираться на сильного специалиста; команда быстро получает ответы; младшие аналитики понимают, к кому идти с вопросом. Пока проект не слишком большой, ведущий аналитик способен удерживать эту конструкцию за счет собственного опыта и дополнительного времени.
Проблемы начинаются с ростом проекта, потому что количество связей увеличивается быстрее, чем человек успевает их контролировать и если ничего не менять, организация обычно приходит к одной из двух крайностей: либо аналитик окончательно становится фактическим РП и почти перестает заниматься аналитикой, либо начинает пропускать управленческие вопросы, после чего возникает ощущение, что раньше он справлялся лучше.
Не каждое участие в управлении нужно убирать
Вернуть роль в норму не означает запретить ведущему аналитику участвовать в обсуждении сроков, рисков или приоритетов, потому что на сложном проекте это было бы искусственным разделением. Его экспертиза как раз нужна РП, чтобы понимать последствия изменений и принимать нормальные решения.
Нужно четко провести границу по ответственности за результат. Ведущий аналитик может сообщить, что изменение требований добавит неделю аналитической работы, но решение о новой дате проекта должно оставаться у РП. Он может заметить, что задача зависла, но не обязан ежедневно контролировать исполнителя. Он может подготовить аналитическую часть клиентской встречи, но не должен автоматически становиться ответственным за весь список проектных действий после нее.
Сначала стоит разложить текущую работу, а не спорить о должностях
Если ведущий аналитик уже давно выполняет часть функций РП, разговор в стиле «это не твоя обязанность» мало что даст, потому что после него проектные задачи никуда не исчезнут. Намного полезнее взять его обычную рабочую неделю и посмотреть, на что реально уходит время.
Чаще всего довольно быстро обнаруживается несколько повторяющихся блоков: сбор общего статуса, напоминания по срокам, подготовка неаналитической части встреч, распределение действий после созвонов, контроль загрузки и ответы на вопросы, которые не требуют аналитической экспертизы.
После этого уже можно обсуждать каждую группу отдельно: что возвращается РП, что остается ведущему аналитику, а что вообще стоит автоматизировать или передать другому участнику. Такой разговор намного практичнее спора о том, где заканчивается одна должностная инструкция и начинается другая.
Статусы лучше вернуть тому, кто отвечает за общий срок
Если ведущий аналитик каждую неделю собирает состояние всех задач, потому что «ему все равно нужно знать», это не означает, что именно он должен готовить общий статус проекта. Знать зависимости действительно полезно, но собирать информацию со всей команды и отвечать за ее актуальность логичнее тому, кто отвечает за общий срок.
Клиент тоже должен понимать границу
Если заказчик привык задавать ведущему аналитику любые вопросы, вернуть роль только внутренними договоренностями будет сложно, потому что внешняя коммуникация продолжит затягивать его обратно. Особенно быстро это происходит, когда на встрече звучит вопрос о сроке, аналитик знает приблизительный ответ и из желания помочь сразу его называет.
Мне кажется полезным заранее договориться, какие вопросы он может подтверждать самостоятельно, а какие переводит РП. Это не должно выглядеть как бюрократия или отказ отвечать клиенту; вполне достаточно нормальной формулировки вроде «по объему работ я сейчас прокомментирую, а финальную дату лучше подтвердит РП после сверки общей загрузки».
Как понять, что роль вернулась в норму
Как и с оценкой результатов автоматизации, так и здесь, лучше всего смотреть на практику - т.е. как по факту изменился рабочий день аналитика. Если он снова может несколько часов подряд заниматься сложным требованием, не переключаясь каждые десять минут на статусы и напоминания, значит разгрузка действительно сработала.
Еще один хороший признак - команда перестает использовать его как универсальную точку входа, потому что вопросы по срокам идут к РП, вопросы по загрузке решаются там же, а к ведущему аналитику приходят прежде всего за экспертным решением. При этом он не выпадает из общего управления и по-прежнему видит риски, зависимости и состояние аналитической части, но уже не обязан лично проталкивать каждую задачу по проекту.
Сильный аналитик не обязан становиться вторым руководителем проекта
Самая неприятная часть такой ситуации заключается в том, что перегруз часто маскируется под признание компетентности: человеку доверяют больше, его подключают ко всему важному, спрашивают мнение и считают незаменимым. Снаружи это выглядит как рост, хотя внутри роль постепенно расползается настолько, что собственная аналитическая работа превращается в одну из многих задач.
Если проект действительно требует отдельного человека, который вместе с РП держит управление, это лучше оформить осознанно — с понятными полномочиями, загрузкой и изменением роли. Но если ведущий аналитик нужен именно как сильный аналитик, то превращать его в скрытого мини-РП обычно слишком дорого, потому что проект получает часть управленческой мощности, одновременно теряя человека, который должен разбирать самые сложные требования и удерживать качество аналитики.
Поэтому я бы периодически задавала довольно простой вопрос: если завтра ведущий аналитик перестанет собирать статусы, напоминать о сроках и координировать всю команду, кто должен делать эту работу? Если ответ — «вообще-то РП», значит границу роли уже стоит возвращать.
Вступайте в нашу телеграмм-группу Инфостарт