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

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

Оценка задач

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

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

Статус

Я имею в виду статусную встречу с заказчиком. Заказчик может быть из компании-клиента в случае заказной или бизнес-подразделения, если мы говорим о продуктовой разработке. Крайне желательно, чтобы вы знали оперативную обстановку так, чтобы могли проводить эту встречу без привлечения разрабов и тимлида. Рассказываете заказчику, как обстоят дела с задачами, какие консёрны, какие блоки с его стороны или со стороны других продуктов, не двигаются ли сроки. 

Планирование спринта

Эта встреча нужна только какое-то первое время, когда вы только знакомитесь с заказчиком и приоритеты не вполне ясны. При достижении определённого уровня взаимопонимания с заказчиком и сотрудниками, эту встречу можно отменить. Планируете в одно лицо, засылаете результат заказчику и тимлиду, вносите правки, утверждаете. 

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

Ретроспектива

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

Демо

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

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

Дейлики

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

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

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

Контроль статуса работ над проектом.
Ответственные сотрудники могут отчитаться о том, в каком состоянии находятся работы на их участках. Заинтересованные лица могут задать им контрольные вопросы.

Облегчение уведомлений
Предположим, нам нужно уведомить всю проектную группу о важном известии. Если сделать это в корпоративном чате или переписке, есть вероятность, что информация до кого-то не дойдёт или дойдёт в искажённом виде. На совещании все всё поймут правильно, в крайнем случае — зададут вопросы. К сожалению, в варианте удалённой работы эта цель недостижима, придётся пользоваться электронными средствами коммуникации.

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

Надёжная фиксация поручений
Поручения, выданные в ходе совещания, заносятся в протокол (об этом ниже) при свидетелях. Саботировать такое поручение будет намного сложнее, чем если бы оно было выдано в устной форме или даже в трекере задач (исполнитель может сказать, что ему не упало уведомление).

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

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

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

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

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

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

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

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

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

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

Отсутствует председатель
На совещании должен в явном виде присутствовать руководитель. Оглашать пункты повестки, следить за временем, распоряжаться фиксированием решений, подводить итог.

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

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