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