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