Эффективные встречи команды

Я руководитель группы из 8 программистов в компании из 20 технических специалистов. Они работают над целым рядом проектов, в этих проектах также участвуют люди из других команд, которые находятся вне моего контроля. Моя организация не занимается надлежащей гибкой разработкой, и они несколько устойчивы к изменениям, но я проводил ежедневные встречи в своей команде, и мы все находили их полезными, и все были вовлечены, и мы закончили 10-15 минут У меня также есть еженедельные индивидуальные беседы с каждым членом команды, где мы более подробно обсуждаем различные общие темы (как технические, так и нетехнические), а также различные специальные тематические встречи.

Однако с чем я боролся, так это с моей еженедельной встречей команды. Он теряет пар, и я не смог заинтересовать людей.

Я все еще хочу провести более продолжительную встречу, даже если она будет проводиться раз в две недели или ежемесячно. Цель состояла в том, чтобы обсудить различные темы, которые нельзя сделать во время фуршета, поскольку они требуют больше времени. Мои обновления включают в себя сводку по каждому текущему проекту, над которым они работают (будь то по графику, различным задержкам и т. Д.), Любые изменения в направлении, будущие проекты, изменения в процессе разработки и т. Д. лекция от меня, и, по крайней мере, 2 человека, очевидно, разделены на зоны, а остальные, по крайней мере, немного заинтересованы.

Я пытался заставить людей быть более вовлеченными, заставляя их говорить о своей неделе, но у 8 человек это занимает много времени и (отчасти потому, что большая часть их работы не пересекает все это), большая часть команды отдыха делает не волнует, над чем работали их коллеги более подробно (они получают обзор высокого уровня во время стоянок).

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

Любой совет, что я могу сделать, чтобы люди были более вовлечены и более заинтересованы? И как я могу заставить их представлять свои вещи или начинать дискуссии, в которых участвуют все, а не монолог с моей стороны?

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

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

В retros , где я работаю, мы будем иметь три колонки на доске, как правило , поставив смайлик, Мех и печальное лицо в верхней части, например :), :|и :(. Затем члены команды могут разместить на доске все, что они хотели бы обсудить со всей группой.

В счастливой колонке вы можете отметить успехи (например, поздравить Алису и Боба с выпуском проекта, над которым они работали вместе), и вы можете объявить победу с новыми процессами, которые вы пробуете (например, новый баг-трекер гораздо лучше, чем Старый).

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

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

После того, как все напишут свои предложенные темы на доске, я хотел бы кратко просмотреть каждую тему и попросить ее автора дать 10-30 секундное объяснение темы. Этот раздел собрания легко сорвать, поэтому вам нужно быть осторожным, чтобы держать людей в теме - например, кто-то скажет, что X был проблемой, а кто-то еще начнет говорить о решении проблемы; решения не должны обсуждаться до окончания голосования. Представляя темы, вы можете найти способы сгруппировать несколько тесно связанных тем.

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

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

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

Добро пожаловать в мир среднего звена!

Вы обнаружите, что этот тип проблемы происходит много!

У вас есть 3 варианта:

Big Stick Сделай это, или ты уволен - никогда не работает. Не делай этого.

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

Говорите невысказанное Из того, что вы сказали, всем скучно - тогда почему бы не спросить их об этом? Вам скучно ? / Это пустая трата времени и т. Д. Почему мы слышим? Какова ценность в этом?

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

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

• короткие демонстрации, показывающие новые функции, разработанные в недавнем спринте. (представлено всеми)
• дискуссия на основе извлеченных уроков, в которой у них есть возможность изменить способ работы и улучшения команды (дискуссия привела вашу правую руку в команду, и вы пришли к обоснованию своих управленческих решений. Похоже на сессию 1: 1 но больше)
• лекция о новом проекте с открытым исходным кодом, который может быть релевантным или о другом языке кодирования, таком как функциональные Lang или Golang или зеленые потоки в Python (возможно, представленный одним из молодых разработчиков или в виде онлайн-видео)
• дискуссия под руководством инженера по продажам, рассказывающая об очень сложной инженерной проблеме, которую пытается решить его клиент. (то же самое касается менеджера службы поддержки / обслуживания, который пытается снизить затраты на поддержку за счет повышения удобства использования продукта)
• менеджер, раскрывающий различные стратегические альтернативы, которые компания могла бы использовать, и то, как это повлияло бы на проектирование, учитывая конкурентную среду.
• внешний консультант, который дает консультационные сессии по технологиям, которые вы уже используете, но не по максимуму (обычно nosql, cep, RDBMS, сети, безопасность, мониторинг ...)
• обзор кода, в котором каждый может изучить новые советы по производительности в области кодирования, отладки или тестирования (у этого разработчика, который имеет 10-кратную производительность).
• сеанс кодирования, где мышь не разрешена. Изучите ярлыки IDE чтоли.
• разговоры бухгалтера о деньгах 101 связанные вопросы пенсия, инвестиции
• поговорить о социальных программах и карьере (обмен стеками, твиттер, github, личные блоги, LinkedIn, встречи в вашем регионе)

Может встреча или проводить ее гораздо реже. Напишите свои лекции в обычной электронной почте и разошлите их всем.

Проводите собрания только в том случае, если у них есть основания участвовать в них. В противном случае вы действительно тратите время людей.

Не проводите долгих встреч и не используйте программное обеспечение для управления проектами. Если вы хотите, чтобы люди интересовались, тогда сконцентрируйтесь и выделите то, что важно, и сохраните остальное для журналов проектов и отчетов. Сконцентрируйтесь на этапах, поставках, основных моментах и ​​целях, и, если это применимо только к 1/3 людей, подготовьте их для обсуждения в рамках проекта.

• Сделайте ваши встречи короткими
• Использование программного обеспечения для управления проектами
• Держите это личным, целеустремленным и связанным с эмоциями и целями
• Решение проблемы в фокус-группах, а не на форумах
• Получите обратную связь от ваших коллег

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

Примите директиву о подходе к управлению вашими проектами и поощряйте хорошие практики разработки, приводя пример.