Конструктивное и деструктивное собрание

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

Погуглив выяснил, что выделяют следующие собрания исходя из целей:

  1. Определение проблем и путей их решения. Результат – список проблем и ответственных за их решения.
  2. Принятие решений по конкретному вопросу. Результат – решение принято, закреплен план выполнения.
  3. Информирование сотрудников. Результат – сотрудники поняли информацию, поведение сотрудников изменилось с учетом нововведений/изменений.

На неделе участвовал в 2 собраниях: одно очень понравилось, и я бы назвал его конструктивным, второе, наоборот не понравилось – его буду называть деструктивным. Каждое собрание в таблице ниже кратко расписано по категориям.

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

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

Попробую поразмышлять с точки зрения ролей… Должна возникнуть необходимость проведения собрания, т.е. кто-то должен встать в роль предпринимателя и понять, что есть необходимость в проведении собрания. Собрание кто-то организовывает и проводит – выполняет роль менеджера. На мой взгляд у роли предпринимателя и менеджера собрания в идеале должен быть один исполнитель, тогда менеджер четко понимает цель собрания и может ее заранее донести до остальных участников. Чаще всего участники собрания являются системой, которая генерирует продукт (например, протокол) и использует его. Участники собрания, на мой взгляд, чаще всего входят в роль инженера, чтобы получить мемо или протокол, который формирует секретарь (менеджер). Получается, что провальное собрание очень часто связано с низким качеством выполнения роли менеджера. Это видно на примере деструктивного собрания, где мне пришлось встать в роль лидера, чтобы мотивировать кого-то встать в роль менеджера для пояснения цели собрания. В итоге в эту роль вставали все по очереди и высказывали свое мнение о цели собрания. Менеджеров стало много, инженеров мало, время собрания увеличилось, и в итоге результат отрицательный.

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

  Конструктивное Деструктивное
Цель собрания Принятие решений по конкретному вопросу (согласовать с заказчиком дальнейшую работу по проекту) Скорее всего определение проблем и путей их решения Цель не указана до начала собрания, потребовался вопрос на собрании
Понимание цели Я точно знал зачем мне собрание и какой вопрос я на нем решу, что буду говорить и показывать Цель не понял
Тип Планирование/согласование работ Дискуссия, а должен быть информативный
Формат On-line Вживую
Подготовка к собранию Перед собранием был сформулирован вопрос, который будет обсуждаться, и предлагаемые варианты решения и отправлены участникам собрания Создана группа в Telegram для согласования начала собрания, материал получен на собрании
Число участников 5 6
Число активных участников 3 6
Результат Согласованы дальнейшие шаги по проекту Понял, что есть задача от руководителя
Затраченное время Запланировано 30 минут,
по факту – 10 минут
Запланировано 30 минут,
по факту - 1 час
Эмоции Положительные,
желание выполнять работу
Негативные,
желание уволиться с работы:)

Дима, спасибо! Очень хорошая памятка для всех, кто планирует проводить собрание. Читая, прям очень ясно как будто считала все твои мысли и чувства по этому поводу (и в памяти всплыли явные примеры и тех, и других собраний, которые были в моем опыте).

Дмитрий, спасибо за попытку разложить в ролях организацию собрания!
Немного уточню: “сотрудники” не являются системой, это команда, которая состоит из исполнителей определенных ролей. Команда при этом может создавать какую-то систему (продукт) или быть вписанной в систему “предприятие/ компания”, но сама по себе системой не является.

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

В принципе, исполнитель роли, который инициирует собрание, может не исполнять непосредственно роль организатора, если напишет повестку (цель собрания, кто нужен исходя из цели и тп). Орг детали вроде “во сколько поставим встречу, нужно ли бронировать переговорку и ставить воду, нужно разослать повестку не менее чем за 3 дня до встречи” может вполне “разрулить” и другой сотрудник, который исполнит роль организатора. Но только если у него есть повестка, список тех, кого надо пригласить, слоты времени на встречу, от которых можно отталкиваться + правила вроде “повестка должна быть на руках не менее чем за 3 дня”.
Ну и на самом совещании обычно нужен исполнитель роли “фасилитатора” или даже “лидера”, который будет помогать участникам придерживаться ролей. Например, переадресовывать инженерные вопросы инженерам, если исполнитель роли “менеджера” вдруг начал отвечать не по своему интересу.
Плюс по итогам встречи должны быть приняты решения о дальнейших шагах и ответственных за их исполнение, иначе это просто “собрались поговорить”))

Анна, спасибо за комментарий! Действительно сами люди в собрании не являются системой. Получается логика должна быть примерно такой: есть продукт, например, протокол на уровне собрания со сроками и ответственными - это система которую нужно создать команде на собрании. Сам протокол - это компонент системы более высокого уровня, например, результата проекта в рамках которого проводится собрание. Продуктом научного проекта может быть методическое руководство или программный продукт (ПО), тогда протокол собрания скорее даже - это система обеспечения итогового программного продукта?
В свою очередь программный продукт как система должен удовлетворять потребности всех заинтересованных ролей - тех, кто его создает, тех кто будет его использовать, тех кто будет его поддерживать.И протокол как подсистема ПО должен удовлетворять требования своих ролей. Также требования к конечному ПО, формируют требования к системе обеспечения (протоколу). Например, роли менеджера от заказчика и исполнителя важно чтобы ПО был сформирован в срок, тогда протокол должен учитывать сроки ПО (сроки выполнения всего проекта). Или роли инженера от исполнителя важно, чтобы итоговое ПО имело определенную функцию и задача по созданию этой функции может быть обозначена в протоколе.

Дима, отличный пост. Возьму себе на заметку некоторые моменты.
Что касается протоколов, то мы можем их официально оформлять и регистровать в Центре. Протоколировать собрания может Лена. Было бы полезно потом отслеживать выполнение сформулированных задач по итогам собраний, а также была бы видна работа по разным направлениям Центра.

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

Собрание проводится, чтобы принять решения / продвинуть ход реализации системы по одной из альф. Протокол как рабочий продукт – это описание “что нужно сделать”. Он может быть на бумаге, но в описании важна не физичность носителя, а то, что оно описывает. Описание системой не является.