Люди в среднем не умеют проводить встречи. Меня это дико бесило, когда я впервые столкнулся с качеством принятия решений на родительских собраниях. Оно близко к отрицательному.
Мы тут писали транскрибатор встреч — это когда можно загрузить запись в трекер и получить список задач на выходе.
За время тестов мы узнали, что про архитектуру встречи вообще никто не думает, а чтобы у неё было продолжение — ну там, следующие шаги, ответственные, сроки и задачи на выходе — это вообще необязательно.
Коротко основное, что может показаться вам странным:
Встреча без повестки — можно не начинать. Для чего встреча? Что мы делаем? Информируем? Генерим идеи? Принимаем решение? Это разные типы встреч.
Встреча без решений, следующих шагов, ответственных и сроков — впустую.
Легко перепутать постановку проблемы с поиском решения. Самая частая ошибка.
Встреча ради встречи не работает. У неё должен быть осязаемый результат: заполненный бриф, принятое архитектурное решение, список задач.
Есть понятие «социальная леность» (эффект Рингельмана) — чем больше людей в группе, тем меньше усилий прилагает каждый. В конце все кивают, кажется, что договорились, только конкретики нет. Включается диффузия ответственности. Каждый уверен, что задачу пойдёт делать кто‑то другой. Итог: через неделю выясняется, что не сделано ничего.
Теоретический парадокс: чем сложнее вопрос, тем меньше времени группа его обсуждает, и наоборот. Команда собирается обсудить смену архитектуры серверов и дизайн новой формы.
За время тестов мы поняли главное: заставить людей соблюдать эту гигиену практически невозможно.
Но хотя бы давайте расскажу про основные методологические выводы.
Вот самые частые антипаттерны, которые мы увидели.
Статусная синхронизация под видом брейншторма
Руководитель собирает 10 человек на час, чтобы просто рассказать им то, что можно было написать одним сообщением в рабочий чат.
Оправдывается это тем, что «мы же команда». Итог: минус 10 человеко‑часов компании просто ради того, чтобы один человек почувствовал себя услышанным.
Правило простое: встреча без повестки — можно не начинать. Если вы позвали людей просто послушать, им там делать нечего, они могут потом прочитать результат. Ну или посмотреть в доску.
Вообще, когда мы видим результаты внедрения своего Кайтена, большая часть экономии времени как раз на таких вещах — когда не надо с кого‑то спрашивать отчёт или собирать всю команду, а надо открыть доску и увидеть все текущие статусы у всех.
Иллюзия консенсуса и диффузия ответственности
Команда бурно обсуждает проект. Все согласны, что «надо бы ускорить релиз». Все кивают. Кажется, что мы договорились. Но есть уже упомянутый эффект Рингельмана — чем больше людей в группе, тем меньше усилий прилагает каждый. Встреча заканчивается, следующие шаги и сроки не зафиксированы.
Через неделю все удивляются, а как же так, никто ничего не делал.
Прямо надо в конце встречи писать, кто за что отвечает, к какому сроку, что именно обещал и как это проверить.
Там ещё есть следующий прикол, что «как это проверить» — это ещё и принять задачу, и принимает обычно не исполнитель, и это 2–3 дня с правками минимум. Но про это люди даже не думают на этой стадии зрелости.
Подмена поиска проблемы поиском решения
Это самая частая ошибка. Команда собирается обсудить проблему (например, «у нас падает конверсия»), но вместо того, чтобы докопаться до корневой причины (дивергенция: сбор фактов, гипотез, где работает правило «не критикуй, собирай»), участники сразу начинают накидывать идеи: «А давайте перекрасим кнопку!», «Дадим скидку!». Встреча скатывается в хаотичный брейншторм неисследованной проблемы. До этапа конвергенции (фильтрация идей и принятие решения) группа так и не доходит.
Логика в том, что надо собрать все возможные решения, оценить их, если надо — обдумать и синтезировать. А не выбирать случайное, которое подошло. Это «вьетнамское мышление» — долго в психологии считалось, что человек в критической ситуации перебирает 3–4 варианта действий и выбирает лучший. Исследования во Вьетнаме показали, что перебирается ровно 1 вариант, и если он вообще в принципе с любой вероятностью (хоть 1%) может привести к результату — сразу исполняется.
Закон Паркинсона о тривиальности
Чем сложнее вопрос, тем меньше времени группа его обсуждает.
Выбор архитектуры серверов, где цена ошибки — миллионы, пробегают за 5 минут — мало кто в этом разбирается, и все боятся показаться глупыми.
А вот цвет рамочки в форме регистрации обсуждают 45 минут с криками и привлечением CEO, потому что в цветах «разбираются» все. В итоге критические решения принимаются вслепую, а время тратится на микроменеджмент.
Что с этим делать? Прямо закладывать в повестку, кто должен высказаться на эту тему.
Ведущие не справляются
За время тестов мы поняли главное: на то, чтобы одновременно фасилитировать встречу, вести записи, вычленять задачи и фиксировать договорённости, у ведущего просто не хватает когнитивного ресурса. Обычно эту роль выполняет менеджер, и его функция — хотя бы записать основное. Или собрать всех. Или не давать им переругаться.
Для проверки гипотезы мы не стали пилить всё с нуля. Мы взяли стороннего бота (сервис mymeet ai) и сделали быструю интеграцию на коленке с нашим ядром на JavaScript/TypeScript. Бот просто синхронизировался с Яндекс Календарём, сам заходил на встречи, записывал звук, раскидывал его по спикерам и выдавал транскрипцию. Параллельно мы тестировали ещё один сторонний сервис, Palatine, для расшифровки голосовых комментариев прямо в карточках задач.
Как всегда бывает с внешними сервисами, мы хлебнули горя: плохая документация, непредсказуемое поведение API. Пользователям мы выкатили это как MVP и получили массу забавной обратной связи. Например, как только люди узнали, что бот делает дословную расшифровку, они резко перестали материться и поносить друг друга за глаза на созвонах. Все стали очень учтивыми. Кто‑то даже начал вести статистику, кто сколько раз выругался.
Основной проблемой было то, что модель не понимала специфические для отрасли термины. Пришлось менять и дотренировывать модель.
Спрос был огромный, но юнит‑экономика не сходилась. Пользователи не были готовы платить много за сторонний сервис, а мы на этом ничего не зарабатывали. Ну и для кровавого энтерпрайза (а‑ля Газпром) отдавать записи рабочих звонков во внешний API — это недопустимо с точки зрения безопасности в принципе.
Мы поняли, что нужно переносить всё на свои мощности (on‑prem), ставить собственный сервак, настраивать свои словари терминов и полностью контролировать процесс. Kaiten — это большой продукт с приличным объёмом зависимостей. Любая, даже самая простая интеграция, которая затрагивает ядро, тянет за собой огромное количество каскадных взаимосвязей. Первые версии мы делали по принципу «программисты для программистов». Нам‑то всё было понятно, а вот пользователи терялись: как запустить процесс, где найти настройки бота, как из этого всего собрать задачу. Потом уже доделывали UX и чтобы всё «само работало».
В текущем виде это работает так:
Полная автоматизация календаря. Пользователь один раз связывает свой календарь с Kaiten. Всё. Бот автоматом ходит на все твои встречи. Не нужно ничего нажимать ручками. Если звонок уже прошёл (или это была офлайн‑встреча), можно просто загрузить аудио/видеофайл прямо в систему, и она всё распознает (раньше ИИ‑шки падали от часовых файлов, а мы эту проблему решили).
Вот так выглядит список встреч Личные копии и защита от редактирования. После встречи транскрипция падает прямо в документ внутри Kaiten. Причём каждому участнику создаётся своя копия документа с транскрипцией. Мы сделали это специально: чтобы не было ситуаций, когда кто‑то один потёр кусок текста, и он пропал у всех. Плюс в системе сохраняется история версий. Даже если кто‑то отредактировал расшифровку, всегда можно отмотать назад и посмотреть изначальный лог.
Мы прогоняем транскрипцию через подготовленные промпты в LLM. В шапке документа бот выдаёт саммари и предлагает список так называемых «черновиков задач». Они не создаются сами по себе, чтобы не плодить мусор. Вы просматриваете список, видите нормальную договорённость и рядом нажимаете одну кнопку: «Создать задачу». Она тут же падает организатору встречи в бэклог.
Список задач на основе встречи Уведомления в привычной среде. Сам процесс вычленения дорожки и перевода в текст занимает время. Мы сделали так, что у пользователя в разделе «Личное» видно статус: какие транскрипты в очереди, какие обрабатываются, а какие (редко, но бывает) упали с ошибкой. Когда всё готово, падает уведомление в колокольчик, в Telegram или МАХ (мы как раз недавно выпустили свежую интеграцию) — в тот же поток, куда приходят обычные комменты по рабочим карточкам.
Уведомления от бота
Неочевидные сценарии, которые мы открыли
У тимлида в календаре стоит дейлик на 15 минут. Но по факту они сидят дольше. Менеджер открывает выборку транскрибатора и видит: средняя длина — 40 минут.
Идеальное алиби. Политика есть везде. Часто бывает, что ты договорился с человеком, а через какое‑то время он говорит: «Я такого не обещал». Вообще, мы посмотрели прикол про мужика, который писал все разговоры с родственниками, а потом начал им предъявлять за их обещания: они говорили, что такого не обещали, а он показывал им запись. Так мужик остался без родственников. В корпоративной среде поначалу примерно так же, потом только люди начинают отвечать за базар.
В конце каждого дня некоторые менеджеры просто садятся разбирать накопившиеся транскрипты. Пробегаясь по тексту или прогоняя его через нейронку, очень легко найти повторяющиеся действия команды или паттерны, которые сигнализируют о том, что нужно внедрять новый процесс.
Скармливание контекста большим LLM. Это моя любимая история — эти встречи — они как контекст для других задач. У себя мы их просто RAG«аем, и получается большой внутренний контекст. »
Но в целом сама суть остаётся неизменной: заставить людей фиксировать итоги встреч нереально. Проще научить машину слушать, делать выводы и сразу заводить карточки. Иначе мы так и будем вечно сидеть на бесконечных «родительских собраниях».