Ты слишком много думаешь: как менеджеру понять, что на проекте нужен аналитик

Привет, это Максим Павлов, управляющий партнер KTS.

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

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

• #1 Менеджер не успевает выполнять задачи за полчаса
• #2 Задачи в таск-трекере идут в работу без описания
• #3 Менеджер долго отвечает на вопросы, потому что ходит консультироваться с заказчиком
  
• #4 Разработчики сами утвердили интеграции со сторонними командами, а результат не совпал с ожиданиям заказчика
  
• #5 Смежные команды выдают неработоспособный API или срывают сроки по его предоставлению
  
• #6 Дизайнеры рисуют макеты, по которым у фронтендеров возникает много блокирующих вопросов
  
• #7 На проекте не хватает документации
  
• Если обобщить

Главная задача менеджера — в моменте направлять команду в правильную сторону. Чтобы с этой задачей справляться, он должен быстро реагировать на меняющуюся обстановку. Если на менеджере повиснет крупная задача, он либо будет плохо ее делать, отвлекаясь на возникающие вопросы, либо сфокусируется на задаче и не сможет оперативно реагировать на происходящие изменения.

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

Этот срок мы вывели по опыту нашей компании, и для других компаний оно может отличаться. Главное, чтобы это время можно было легко найти между встречами и отложить на него решение большинства входящих вопросов.

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

Чем детальнее поставлена задача, тем меньше будет вопросов при реализации и тем точнее можно оценить и спланировать работу. Но если уже который раз разработчику надо начинать работу, а у менеджера нет лишнего времени чтобы сейчас сесть и детально что-то описать – самое время звать аналитика.

В такие моменты проблемы накапливаются как снежный ком:

• Менеджеру не хватило времени, и он не описал задачу детально
• Разработчики или дизайнеры начали ее реализовывать так, как сами поняли
  
• У них возникло много вопросов, которыми они стали отвлекать менеджера
  
• Задачу реализовали не так, как планировал менеджер – нужно планировать переделки
  
• У менеджера становится еще меньше времени на описание дальнейших задач
  

В таких случаях аналитик – это палочка-выручалочка. Он может заранее подумать за разработчика, снять большинство его возможных вопросов и поставить детально описанную задачу в таск-трекер.

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

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

Аналитик сможет отвечать на большинство вопросов сам, если правильно распределить зоны ответственности менеджера и аналитика. Главное поставить перед ним задачу – погружаться в проблемы заказчика. Это экономит время заказчику, менеджеру и команде разработки.

Если продукт или создающая его компания большие – задачи бывают связаны с интеграцией систем друг с другом. В отличие от стандартных функций, в которых нет никаких дополнительных ограничений, при проектировании интеграций на итоговую реализацию влияют ограничения интегрируемой системы.

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

Переделывать интеграции сложнее, чем обычные функции, поэтому влияние таких проблем на планы может быть сильно выше, чем обычные переделки.

Эта проблема – продолжение предыдущей. Если в команде нет отдельного человека, который отвечает за взаимодействие с другими командами по интеграции, то некорректно работающие методы API сторонних систем могут заблокировать работу команды. В таком случае, команде придется либо срочно менять планы, либо простаивать.

В этом случае аналитик – входной фильтр перед командой разработки. Он передает в разработку только задачи, по которым все внешние элементы работоспособны. Аналитик проверит, что формат API сторонней команды соответствует договоренностям, а также убедится в том, что все методы работают.

Обычно вопросы сроков – это зона ответственности менеджера. Но управлять чем-то можно только имея более глубокое понимание задач, чем просто – сделаны они или нет. Чтобы погружаться глубже – нужно ощутимо больше времени и поэтому эту комплексную задачу по предоставлению внешнего API может эффективно решить аналитик.

Задача для аналитика звучит не как «сделать API», а разделяется на составляющие, например: «сделать каждый конкретный метод», «обработать определенные кейсы». Следовательно, он может тестировать частично сделанную задачу и раньше давать фидбек сторонней команде, а также передавать своей команде работоспособные куски и быть уверенным, что работа команды не будет заблокирована.

Даже если дизайнер находится в одной команде с разработчиками, для них он все равно является внешним человеком – примерно как и сторонняя команда, которая делает API.

Вывод здесь аналогичный: аналитик нужен команде для того, чтобы проверить все, что поступает в разработку и доработать, если с макетами что-то будет не так. Аналитик может уменьшить количество переключений и блокировок команды.

Ощутить именно нехватку документации на проекте менеджеру позволяет достаточный опыт. Как правило, она точно нужна, если:

• В команду постоянно приходят новые сотрудники
• Над проектом работает большая команда
• Работа над проектом циклична или ставится на паузу

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

В идеальном мире документацию пишет технический писатель. Но если задача звучит как «на проекте не хватает документации», а не «наш аналитик не успевает писать документацию», то скорее всего эффект от привлечения аналитика будет гораздо больше.

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

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

Хороший аналитик разгружает менеджера от всего большого, долгого и вдумчивого. При таком симбиозе менеджер может сфокусироваться на выполнении именно менеджерских задач: планирование, контроль, частые переключения и адаптация планов под меняющуюся ситуацию.

Читайте также:

6 ошибок, из-за которых менеджеры-джуны остаются джунами