Как менеджеру понять, что на проекте нужен аналитик
Привет, это Максим Павлов, управляющий партнер KTS.
Типовая ситуация — разработка проекта шла хорошо, а потом тебе либо увеличили команду, либо накинули работы, либо дали дополнительный проект, либо появился ещё один заказчик, интересы которого надо учитывать. И постепенно радость от работы сменяется на грусть от того, что всё начинает ухудшаться.
В статье я расписал, какие маркеры могут указать, что в команду нужно звать аналитика.
#1 Менеджер не успевает выполнять задачи за полчаса
Главная задача менеджера — в моменте направлять команду в правильную сторону. Чтобы с этой задачей справляться, он должен быстро реагировать на меняющуюся обстановку. Если на менеджере повиснет крупная задача, он либо будет плохо её делать, отвлекаясь на возникающие вопросы, либо сфокусируется на задаче и не сможет оперативно реагировать на происходящие изменения.
Полчаса — максимальное время, в которое должно укладываться решение большинства задач менеджера. Частое превышение этого срока говорит о том, что менеджеру в помощь необходим аналитик.
Этот срок мы вывели по опыту нашей компании, и для других компаний оно может отличаться. Главное, чтобы это время можно было легко найти между встречами и отложить на него решение большинства входящих вопросов.
Но есть и исключения. Такое правило хорошо подходит для крупных команд, в которых на менеджера падает много задач. Если команда состоит из двух-трёх человек, а заказчик всего один, то вопросов прилетает не так много, чтобы привлекать аналитика.
Задачи часто занимают больше получаса, а параллельно сыпятся срочные и важные вопросы? В команду нужен аналитик.
#2 Задачи в таск-трекере идут в работу без описания
Чем детальнее поставлена задача, тем меньше будет вопросов при реализации, и тем точнее можно оценить и спланировать работу. Но если уже который раз разработчику надо начинать работу, а у менеджера нет лишнего времени чтобы сейчас сесть и детально что-то описать — самое время звать аналитика.
В такие моменты проблемы накапливаются как снежный ком:
Менеджеру не хватило времени, и он не описал задачу детально
Разработчики или дизайнеры начали ее реализовывать так, как сами поняли
У них возникло много вопросов, которыми они стали отвлекать менеджера
Задачу реализовали не так, как планировал менеджер, и нужно планировать переделки
У менеджера становится еще меньше времени на описание дальнейших задач
В таких случаях аналитик — это палочка-выручалочка. Он может заранее подумать за разработчика, снять большинство его возможных вопросов и поставить детально описанную задачу в таск-трекер.
Не успеваешь детально описывать задачи? Зови аналитика.
#3 Менеджер долго отвечает на вопросы, потому что ходит консультироваться с заказчиком
В идеальном мире опытный менеджер полностью понимает потребности заказчика и на большинство вопросов разработки может ответить сам. Но не потому, что заказчик уже отвечал ему на такой вопрос, а потому что менеджер знает, какие проблемы заказчика решает команда.
Если времени у менеджера становится меньше, он не так глубоко погружается в боли и проблемы заказчика. Ему становится тяжелее принимать решения и все чаще он ходит уточнять какие-то вопросы к заказчику. Следствие — частое переключение команды между задачами из-за вопросов, блокирующих разработку.
Аналитик сможет отвечать на большинство вопросов сам, если правильно распределить зоны ответственности менеджера и аналитика. Главное поставить перед ним задачу — погружаться в проблемы заказчика. Это экономит время заказчику, менеджеру и команде разработки.
Уже который раз не можешь предсказать, что бы ответил на твоём месте заказчик? Зови аналитика, который погрузится в его проблемы.
#4 Разработчики сами утвердили интеграции со сторонними командами, а результат не совпал с ожиданиям заказчика
Если продукт или создающая его компания большие, задачи бывают связаны с интеграцией систем друг с другом. В отличие от стандартных функций, в которых нет никаких дополнительных ограничений, при проектировании интеграций на итоговую реализацию влияют ограничения интегрируемой системы.
Если разработчики самостоятельно проектируют детали реализации, то обычно они не учитывают контекст решаемой задачи. В итоге может интеграция может быть выполнена в соответствии с поставленной задачей, но верхнеуровневой цели она может не удовлетворять.
Переделывать интеграции сложнее, чем обычные функции, поэтому влияние таких проблем на планы может быть сильно выше, чем обычные переделки.
Второй раз переделываете интеграцию? Возможно, пора привлечь аналитика.
#5 Смежные команды выдают неработоспособный API или срывают сроки по его предоставлению
Эта проблема — продолжение предыдущей. Если в команде нет отдельного человека, который отвечает за взаимодействие с другими командами по интеграции, то некорректно работающие методы API сторонних систем могут заблокировать работу команды. В таком случае, команде придется либо срочно менять планы, либо простаивать.
В этом случае аналитик — входной фильтр перед командой разработки. Он передаёт в разработку только задачи, по которым все внешние элементы работоспособны. Аналитик проверит, что формат API сторонней команды соответствует договоренностям, а также убедится в том, что все методы работают.
Обычно вопросы сроков — это зона ответственности менеджера. Но управлять чем-то можно только имея более глубокое понимание задач, чем просто — сделаны они или нет. Чтобы погружаться глубже, нужно ощутимо больше времени, поэтому эту комплексную задачу по предоставлению внешнего API может эффективно решить аналитик.
Задача для аналитика звучит не как «сделать API», а разделяется на составляющие, например: «сделать каждый конкретный метод», «обработать определенные кейсы». Следовательно, он может тестировать частично сделанную задачу и раньше давать фидбек сторонней команде, а также передавать своей команде работоспособные куски и быть уверенным, что работа команды не будет заблокирована.
Смежники очередной раз выдали нерабочее API? Подключай аналитика.
#6 Дизайнеры рисуют макеты, по которым у фронтендеров возникает много блокирующих вопросов
Даже если дизайнер находится в одной команде с разработчиками, для них он всё равно является внешним человеком — примерно как и сторонняя команда, которая делает API.
Вывод здесь аналогичный: аналитик нужен команде для того, чтобы проверить всё, что поступает в разработку и доработать, если с макетами что-то будет не так. Аналитик может уменьшить количество переключений и блокировок команды.
Фронтендеры жалуются на непродуманные макеты? Пропускай макеты через аналитика.
#7 На проекте не хватает документации
Ощутить именно нехватку документации на проекте менеджеру позволяет достаточный опыт. Как правило, она точно нужна, если:
В команду постоянно приходят новые сотрудники
Над проектом работает большая команда
Работа над проектом циклична или ставится на паузу
Вопрос «нужна ли на проекте документация» и каждую из таких ситуаций я подробно разберу в отдельной статье. Но если эти ситуации — не про ваш проект, но всё равно кажется, что документации не хватает, скорее всего, вам поможет аналитик.
В идеальном мире документацию пишет технический писатель. Но если задача звучит как «на проекте не хватает документации», а не «наш аналитик не успевает писать документацию», то скорее всего, эффект от привлечения аналитика будет гораздо больше.
Аналитик сможет закрывать и другие задачи и решать другие проблемы, указанные в этой статье. Когда эти проблемы будут решены, и у аналитика не будет хватать времени именно на документирование, можно постепенно двигаться к специализации и брать в команду технического писателя.
Если обобщить
Аналитики делают из непонятного понятное и уберегают команду от задач, которые из-за недостаточной детализации могут сильно нарушить процесс и сдвинуть сдачу проекта на более поздний срок.
Хороший аналитик разгружает менеджера от всего большого, долгого и вдумчивого. При таком симбиозе менеджер может сфокусироваться на выполнении именно менеджерских задач: планирование, контроль, частые переключения и адаптация планов под меняющуюся ситуацию.
Аналитик позволяет менеджеру погружаться ровно на столько, на сколько это нужно для эффективного управления.
