Ловим проблемы в море созвонов: автоматизация менеджмента с AI

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

Если вы не знакомы с системами транскрибации (расшифровки), рекомендуем посмотреть подробную статью про это. А ниже мы поговорим про то, зачем и как обрабатывать транскрипты с помощью AI и встраивать результаты обработки в рабочие процессы компании.

Встречи как препятствие продуктивности

Для определенности возьмем компанию, разрабатывающую программный продукт.

По мере увеличения размера продукта, затраты на его разработку растут нелинейно — быстрее, чем сам продукт. Это происходит из-за роста сложности координации и коммуникации между людьми. В предельном случае, если каждому нужно поговорить с каждым, то количество коммуникаций — это N*(N–1)/2, где N – это число людей. В реальных ситуациях не так все плохо, но все равно намного хуже, чем линейный рост затрат с числом людей.

По данным исследования 5000 работников умственного труда компанией Atlassian, 51% сотрудников вынуждены существенно перерабатывать именно из-за перегрузки совещаниями.

Что касается руководителей, то там все еще хуже: например, исследование Harvard Business Review показало, что руководители высокого ранга тратят на встречи 23 часа в неделю (против 10 часов в 60-е годы прошлого века!), при этом 71% из них указывают на неэффективность встреч.

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

Больше менеджеров — больше встреч

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

Первый самый распространенный тип руководителей/лидеров будем называть «менеджерами команд». В английском есть более емкое название «менеджер-курица», а точнее, «Mother hen leadership style», — здесь имеется в виду поддерживающий стиль лидерства, забота о конкретных людях и конкретных работах.

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

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

Второй тип — «менеджеры проблем». Эти менеджеры сосредоточены на решении определенного класса проблем внутри организации и скорее отвечают за некоторое направление в компании, к примеру:

• процессы в разработке (Agile-коуч, …),

• безопасность (security officer),

• комплаенс (compliance officer),

• архитектура (архитектор),

• инфраструктура (тут имеется в виду проблема «Кто в лес, кто по дрова… давайте у нас будет кто-то один отвечать за общую инфраструктуру»),
• HR-политики и так далее.

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

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

Взгляд со стороны линейного или проектного руководителя

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

Остается личная головная боль «менеджеров команд», которым катастрофически не хватает времени, чтобы приходить на все основные встречи, особенно если в их ведении несколько команд. И эта боль нередко трансформируется в потери для компании.

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

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

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

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

Транскрибация встреч

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

Более того, такие приложения создают не только транскрипты, но и краткие сводки на базе транскриптов (резюме, Meeting Notes, Action Items, Follow-ups и т.п.), которые в некоторых случаях достаточны для менеджеров, интересующихся лишь статусом работ и принятыми решениями.

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

Повышаем прозрачность и узнаем о проблемах автоматически

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

• Особенно полезно, если эти итоги оформлены как «следующие шаги» (action items, они генерируются многими транскрибаторами «из коробки», хотя и не всегда качественно). Тогда менеджер может не приходить на некоторые встречи своих команд (например     , на Daily Scrum Meetings), но при этом знать, кто чем занимается, и приходить к нужным людям с дополнительной информацией или просьбами по этим задачам.
• Или, например, менеджер может дополнить резюме встречи (summary) своими комментариями и отослать другому лицу, заинтересованному в результатах команды.

Кейс 1: уведомления подписавшимся

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

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

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

Кейс 2: регулярные сводки

Однако даже снабженный хитрыми промтами искусственный интеллект не дает и не будет давать 100%-ую гарантию того, что он уведомит менеджера о встрече, где обсуждались интересующие его темы или возникали интересующие его проблемы (в т.ч. потому, что менеджер мог сформулировать это недостаточно подробно). И наоборот, случаются и «ложные срабатывания» таких AI-триггеров. Это происходит не только из-за человеческого фактора, но из-за того, что AI недостаточно хорошо понимает общий контекст: может среагировать на слова, которые в контексте встречи отнюдь не были связаны с искомой проблемой, и т.п.

С саммаризацией связан второй кейс: многим «менеджерам проблем» полезны регулярные сводки о встречах определенного типа (например, об обзорах спринтов всех команд). Они могут приходить, например, раз в неделю, в зависимости от общего количества команд и встреч.

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

Кейс 3: выявление процессных проблем

Впрочем, из-за присутствия на встречах «менеджеров команд» тоже могут возникать проблемы.

• Например, из-за них могут обсуждаться лишние темы, которые наверняка обсудили бы в более узком составе, если бы менеджера на встрече не было. То есть, много людей в результате теряют время на неважные для них обсуждения.
• Что еще хуже, в присутствии менеджеров — даже «своих» — многие сотрудники инстинктивно переключают режим своего общения и мышления, и это вредит продуктивности командного обсуждения. Например, перестают говорить честно об обнаруженных препятствиях, приукрашивают действительность, или начинают думать не о пользе дела, а о том, чтобы понравиться менеджеру и затем получить прибавку к з/п.

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

Например, довольно сложной для AI-детектора проблемой является проблема отсутствия на встрече тех обсуждений, которые являются обязательными для данного типа встреч (без которых смысл встречи отчасти теряется). Например, отсутствие обсуждения цели спринта на планировании спринта. Тем не менее, современные LLM с выявлением таких сложных проблем уже справляются, если их снабдить правильным промтом (см. ниже).

Успешное применение AI к этому третьему кейсу иллюстрируется в видео про анализ транскриптов встреч для Scrum-мастеров и Agile-коучей:

• Скрам-мастер обычно выступает как раз в роли «мамы-курицы» («менеджера команды»). Будучи не обязан присутствовать на дейли митингах, он может получать от AI прокомментированные оценки каждого дейли по нескольким критериям — от факта обсуждения препятствий цели спринта до вовлеченности команды. Вникая в комментарии по низким оценкам, он может принимать конкретные меры, поскольку эти комментарии содержат даже имена (этот промт требует имена от AI).
• Agile-коуч здесь выступает скорее в роли «менеджера проблем», детальные комментарии и тем более имена ему не нужны. Он вообще может не присутствовать на командных встречах, но должен получать краткую выжимку о качестве встреч и наличии дисфункций.

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

Автоматизация менеджмента с MeetingOps

Словом MeetingOps (по аналогии с DevOps) мы называем подход, где создается цепочка автоматизаций (pipeline) на базе транскриптов рабочих встреч. Основные автоматизации здесь, конечно, должны быть на основе генеративного искусственного интеллекта (LLM), который хорошо работает с такими длинными и сложными для понимания текстами как транскрипты. Никакая ручная работа не должна блокировать автоматическое выполнение всего пайплайна.

Вот какие преимущества возникают благодаря такой AI-driven автоматизации во всех трех описанных выше кейсах:

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

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

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

MeetingOps pipelines: пример и техническая реализация

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

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

Все low-code и no-code системы сейчас уже имеют подключения к OpenAI и другим провайдерам LLM. Имеются ввиду zapier.com, make.com, dify.ai, albato.ru (российский аналог Zapier и Make, поддерживает OpenAI), n8n.io (можно развернуть на своих серверах), а также бесплатный activepieces.com (есть примеры развертывания на своем сервере: в виде статьи или в видео).

• Мы в ScrumTrek сейчас используем как раз ActivePieces, но там AI-пайплайны являются скорее low-code, чем no-code: большинство AI-элементов реализуются как функции на python, а не как готовые блоки.
• Возможности готовых блоков в Zapier и Make шире, чем в ActivePieсes.
• Albato является чисто no-code системой и имеет многие возможности своих зарубежных аналогов. Что важно, эта система интегрируется с многими российскими SaaS, поэтому мы в ScrumTrek уже много лет используем ее для многих интеграций. Однако Albato не имеет визуального редактора схем, в отличие от остальных указанных систем. Поэтому разветвленные пайплайны строить там неудобно.

Другие применения MeetingOps

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

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

Создание рабочих артефактов

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

• Без такой цепочки, как показана на схеме выше, люди будут вынуждены вручную либо создавать такие детальные артефакты прямо на встрече (что отнимает время у всех), либо анализировать транскрипт (отнимает время у одного человека, но зато очень много).
• Даже если этот человек уже освоил ChatGPT или подобные российские чатботы, от него требуется немало скучной работы по копированию транскрипта и промта в чатбот, а затем по копированию его результата в таск-трекер (причем по частям).

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

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

Создание авто-отчетов

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

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

Как и создание рабочих артефактов, этот пайплайн фокусируется на генерации контента.

Триггер для конкретной команды

Это пример пайплайна, где ключевым элементом является не генерация контента, а нотификация (уведомлениечеловека об обнаруженном факте).

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

• Пример с «менеджером проблем»: ответственному за безопасность (security officer) могут быть важны обсуждения команд, где они затрагивают вопросы сбора, хранения и передачи данных или применения инструментов от внешних провайдеров. Триггер уведомляет этого менеджера про такие обсуждения, чтобы он мог своевременно вмешаться.

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

AI-ассистент по триггеру

Наконец, возможны еще более продвинутые пайплайны, которые активируют AI-ассистентов. Например, после встречи такой ассистент может прийти с сообщением «Кажется, вы проектируете сервис, в котором идет работа с персональными данными. В этом случае есть обязательная процедура перед выпуском в продакшен. Рассказать об этом сейчас?».

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

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

---

Такие применения подхода MeetingOps мы подробнее опишем в отдельных статьях и видео. Подписывайтесь на наш Telegram-канал ScrumTrek, где мы выкладываем полезные материалы про людей, про искусственный интеллект и про другие инструменты повышения эффективности людей в компаниях. А за ответами на более глубокие вопросы приходите к нам на тренинг AI в менеджменте.