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

Мое нежелание тратить время впустую или неэффективно, вылилось в то, что в департаменте разработки программного обеспечения мы тщательно следим за временем, которое наши разработчики тратят на совещания. В среднем, на разработчика приходится всего 2 часа 15 минут обязательных совещаний в неделю, включая четыре стендапа по 15 минут, встречу 1 на 1 с руководителем на 30 минут каждые две недели и 60 минут на различные совещания, такие как планирование и демонстрации. Остальное время, примерно 5 часов 45 минут, уходит на прочие активности в MS Teams, включая чаты и единичные созвоны. Хотя мы считаем, что и это время следует оптимизировать, основное внимание мы уделяем именно ключевым совещаниям, чтобы убедиться, что каждая минута проведенного времени имеет ценность.

Для сравнения, по данным исследования компании Atlassian, средний работник тратит до 31 часа в месяц на непродуктивные совещания. Это примерно 8 часов в неделю, что равносильно полной рабочей неделе одного сотрудника из команды из пяти человек каждый месяц. Если мы переведем это в рабочие дни, то получается, что в среднем четыре человека работают, а один постоянно находится на совещаниях. Это не учитывает дополнительное время, потраченное на неформальные обсуждения и ad-hoc встречи, которые еще больше сокращают время, доступное для непосредственной работы над созданием продукта. Таким образом, разработчики фактически проводят менее половины своего рабочего дня на прямую разработку, что является тревожным сигналом для любой организации.

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

Много встреч - это не нормально

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

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

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

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

Конечно, иногда встречи необходимы, но они склонны к бесконтрольному разрастанию. Это напоминает борьбу с лишним весом: сначала ты допускаешь одну маленькую слабость, затем другую, и вроде бы ничего страшного. Но со временем эти "маленькие слабости" превращаются в серьезную проблему. Так и с совещаниями: кажется, что это всего лишь короткие созвоны, но когда начинаешь подводить итоги, выясняется, что они занимают огромное количество времени.

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

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

Совещания обходятся дорого, затраты незаметны и склонны к увеличению.

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

Избавляемся от непродуктивных совещаний

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

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

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

В нашей полностью распределенной команде мы научились эффективно отслеживать активность в MS Teams. Я настаиваю на том, чтобы анализировать не только время, затраченное на плановые совещания, но и на любые отвлечения. Если кто-то тратит более 20% своего времени на коммуникации в чате или созвоны, мы видим в этом потенциал для оптимизации. Это относится как к разработчикам, так и к менеджерам. Решение может не всегда заключаться в сокращении количества встреч, но мы всегда ищем способы уменьшить необходимость в излишних взаимодействиях.

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

Всегда существуют совещания, которые можно отменить.

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

Инициатива 'День тишины' стала еще одним шагом в оптимизации нашего рабочего процесса. Учитывая гибкий график работы нашей команды, мы заметили, что многие коллеги усердно трудятся в течение первых четырех дней недели, иногда работая сверх обычных восьми часов. Это приводило к тому, что к пятнице у них оставалось всего четыре часа рабочего времени. Если в этот день добавлять совещания, то он рисковал стать практически непродуктивным.

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

Отменить нельзя, заменить

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

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

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

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

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

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

Если отменить совещание нельзя, то его можно заменить чем-то другим.

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

Если не отменить, то регламентировать

Когда отмена совещаний невозможна, важно ввести четкие рамки и подготовиться к встрече. Следует разделить совещания на типы и ввести для каждого из них определенный регламент:

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

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

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

У нас строгие временные рамки: статус-митинг не дольше 15 минут, стандартная длительность совещаний не более 30 минут, а вебинары на уровне компании не превышают одного часа.

Из недавнего опыта. Была встреча на 70 человек. CEO и руководители рассказывали о месячном апдейте. Каждая минута такой встречи — это больше человеко-часа. Я мог долго вещать о технологических достижениях нашего отдела, но это было бы непонятно и неинтересно большинству. Вместо этого, мы сфокусировались на том, чтобы все понимали общее направление движения компании, её цели и принимаемые решения. Формат встречи был переработан и уточнен на основе внутренних опросов и обратной связи. Целью каждого департамента было не похвастаться своими успехами, а ясно и понятно изложить суть происходящего, чтобы каждое подразделение понимало, как их работа влияет на общий результат.

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

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

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

Заключение

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

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

Здравствуйте! Меня зовут Леонид Нетребский. Я руковожу разработкой и проектами с 2013 года. У меня есть опыт управления командами разработчиков до нескольких десятков человек. Есть опыт управления разработкой в компаниях с полной анархией, пропитанной пилением бюджетов, до адептов метрик производительности. Я тот руководитель, кто выстраивает процесс комплексно, включая CI/CD, автоматизацию тестирования, архитектуру, SRE. При необходимости я также могу написать код, чтобы продемонстрировать пример или что-то попробовать.

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

Добавляйтесь ко мне в LinkedIn, где я делюсь своими идеями и опытом чаще: @netleon