Да, у меня такое же мнение — в большинстве случаев инициатива должна исходить не от менеджера. Менеджер может инициировать организационные встречи для разрешения каких-то форс-мажоров (конфликт в команде, начинается отклонение от плана-графика без видимых причин и пр.)
А в обычном режиме к менеджеру поступают вопросы, а он уже принимает решение, как лучше найти ответ. Вопросы могут быть от разработчика (разработчик усомнился: не погорячились ли пользователи, когда написали такое ТЗ или есть разные варианты реализации и нужно выбрать), от эксперта (что-то нужно изменить, передумали, вспомнили редкий случай, про которых изначально не упоминали) или от аналитика (дополнения, изменения, уточнение деталей и пр.).
Чаще встречи требуются на этапе проработки идеи, когда необходимо присутствие аналитиков и экспертов, принимающих решения. На этапе реализации, когда все идет по плану, собираться смысла нет. Хватает утреннего стендапа с командой разработки.
если можно сотрудника не приглашать, а решить вопрос в личном порядке — не приглашаю
если обсуждается несколько вопросов, а он нужен только на одном — договариваемся, что я позвоню и приглашу его, когда дойдем до обсуждения
когда в процессе обсуждения он начинает "съезжать" в истории, детали и пр. там может быть несколько вариантов:
был затронут действительно важный вопрос, но он не относится к теме текущей встрече — говорю, что записываем это в повестку следующей встречи или обсуждаем в мини-группе (с ним и другими заинтересованными лицами) и не отнимаем время у всех остальных сейчас. Но это важно обязательно сделать впоследствии, а не просто сказать на словах. Иначе второй и третий раз прием уже не сработает.
если человек просто не может сформулировать мысль и ему нужно рассказать какой-то пример/историю, чтобы всем стало понятнее, то помогаю наводящими вопросами
если это просто жажда высказаться на абстрактные темы, то останавливаю. В зависимости от состава участников это можно сделать просто официально: "К сожалению, данные детали нам сейчас не помогают, поэтому спасибо, но мы возвращаемся к вопросу < ...>, на котором остановились". Или в виде шутки "Вечерело… Рассказ захватывающий, но пока совершенно не понятно, к чему ты клонишь?" Тогда человек либо перейдет к кульминации и изложит суть, либо остановится.
Кстати, если всегда останавливать любого говорящего на отвлеченные темы (вне зависимости от роли в команде, должности, авторитета и пр.), то через 2-3 встречи вся команда будет поддерживать это правило и сами участники начнут пресекать "говоруна". Никто не любит тратить время впустую.
Поделитесь, пожалуйста, своими материалами по данному вопросу? Судя по комментарию, Вы давно практикуете, а рекомендации более опытного коллеги лишними не будут.
А какие Вы аргументы приводили, чтобы переубедить собственника? Желание держать все под контролем может говорить о повышенном уровне тревожности из-за неумения делегировать и опасения, что команда не справляется. Один из вариантов в таких случаях: техника маленьких побед. Показывать регулярно небольшие завершенные блоки работ, а также перечень мероприятий, намеченных на ближайшее время. Собственник будет видеть, что процесс идет.
Да, у меня такое же мнение — в большинстве случаев инициатива должна исходить не от менеджера. Менеджер может инициировать организационные встречи для разрешения каких-то форс-мажоров (конфликт в команде, начинается отклонение от плана-графика без видимых причин и пр.)
А в обычном режиме к менеджеру поступают вопросы, а он уже принимает решение, как лучше найти ответ. Вопросы могут быть от разработчика (разработчик усомнился: не погорячились ли пользователи, когда написали такое ТЗ или есть разные варианты реализации и нужно выбрать), от эксперта (что-то нужно изменить, передумали, вспомнили редкий случай, про которых изначально не упоминали) или от аналитика (дополнения, изменения, уточнение деталей и пр.).
Чаще встречи требуются на этапе проработки идеи, когда необходимо присутствие аналитиков и экспертов, принимающих решения. На этапе реализации, когда все идет по плану, собираться смысла нет. Хватает утреннего стендапа с командой разработки.
я обычно действую так:
Кстати, если всегда останавливать любого говорящего на отвлеченные темы (вне зависимости от роли в команде, должности, авторитета и пр.), то через 2-3 встречи вся команда будет поддерживать это правило и сами участники начнут пресекать "говоруна". Никто не любит тратить время впустую.
Поделитесь, пожалуйста, своими материалами по данному вопросу? Судя по комментарию, Вы давно практикуете, а рекомендации более опытного коллеги лишними не будут.
А какие Вы аргументы приводили, чтобы переубедить собственника? Желание держать все под контролем может говорить о повышенном уровне тревожности из-за неумения делегировать и опасения, что команда не справляется. Один из вариантов в таких случаях: техника маленьких побед. Показывать регулярно небольшие завершенные блоки работ, а также перечень мероприятий, намеченных на ближайшее время. Собственник будет видеть, что процесс идет.