Проблема
Чем больше в компании становится сотрудников, которые имеют характерную особенность общаться друг с другом, проводить планёрки, стендапы, собеседовать соискателей и митинговать митинги по разным вопросам, тем острее стоит вопрос об эффективности проведения этих мероприятий.
Можно ввести правило, что участие в планёрке — точно такая же задача, как любая другая работа, поэтому перед тем, как приходить на собрание — нужно создать себе задачу на Битрикс24 и начать её выполнение. Однако сам список планёрок и их участников всё же удобнее вести в модуле календаря, а не в модуле задач.
Получается много рутинных действий: открой планерку, скопируй название, перейди в задачи, создай задачу, поставь название, поставь планируемое время, поставь проект, сохрани. И так для каждого из участников. К тому же, если человек забудет создать задачу по событию, время учитываться не будет, а это важно для анализа временных затрат на планёрки. Рутина раздражает. В один момент она нам надоела и мы автоматизировали описанные выше действия. Разработали модуль, интегрирующий модуль задач и модуль календаря.
Процесс
Нужно было сделать так, чтобы при подтверждении участия в событии у сотрудника создавалась бы задача с автоматически заполненными названием, проектом, планируемой длительностью и крайним сроком. Задача должна создаваться у всех, включая организатора митинга. При отказе от участия в митинге задачи создаваться не должно, либо она должна удаляться, если участник уже успел подтвердить своё участие.
Все события календаря хранятся в базе данных в таблице «b_calendar_event». При создании собрания в неё вставляется запись для самого организатора митинга и в ней сохраняются все заполненные им поля. Затем для каждого участника собрания в ту же таблицу добавляется копия этой записи, независимо от того, согласился он участвовать или же отказался. Отследить момент создания записи в таблице и добавить дополнительную логику можно, используя систему событий фреймворка Битрикс24:
Это же событие будет вызываться при каждом редактировании события, поэтому нам хватит одного обработчика. Например, если событие переименуют, у всех созданных для этого события задач, название тоже поменяется. Но это работает только для организатора события. Подтверждение и отказ от участия создаются через другие методы API модуля календаря, в которых не предусмотрено никаких событий, на которые можно подписаться, поэтому пришлось искать обходной путь.
Есть три способа подтвердить своё участие в митинге:
1. Из ленты уведомлений
2. Из живой ленты
3. Из карточки события
Нужно было найти способ добавить свою логику на эти три варианта. С первым просто — в момент нажатия на кнопку на сервер через открытый вебсокет отправляется информация о том, какое уведомление было показано (модуль Push and Pull).
Можно добавить собственный обработчик, который будет вызван после того, как отработает подтверждение участия. Внутри обработчика мы имеем полный доступ ко всей информации по совершённому действию — какой участник и на какой митинг согласился. Поэтому без труда можем создать для него задачу. Со вторым и третьим немного сложнее. Для этих кнопок не предусмотрено вообще никаких событий — это просто AJAX-запрос к скрипту на сервере. Единственный вариант — добавить обработчик на OnProlog, который вызывается вообще на каждом хите и внутри него проверять, не относится ли текущий хит к этим кнопкам, по косвенным признакам:
После того, как разобрались с этим вопросом всё, что осталось — реализовать создание и удаление задач. Для этого создали отдельную таблицу для хранения привязки «Пользователь — Задача — Событие».
Для этого создали отдельную таблицу для хранения привязки «Пользователь — Задача — Событие»
Сами методы создания и удаления тривиальны и используют стандартное API модуля задач, сохраняя привязку в созданной ранее таблице. Правда, обнаружилось два интересных момента:
- Звонки из CRM тоже хранятся как события календаря. Для них никаких задач создаваться не должно, поэтому перед созданием задачи нужно проверить, что событие является именно планёркой, а не звонком.
- В начальном варианте создание задачи выполнялось от имени авторизованного пользователя. Как потом оказалось, системе прав доступа не понравится, если пользователь попытается добавить задачу в проекте, членом которого он не является — и она запретит создание задачи. Но сотрудника вполне могут пригласить на обсуждение по проекту, над которым он обычно не работает, поэтому во второй версии модуля пришлось сделать так, чтобы задачи создавались от имени администратора.
Итог
Интеграция фиксирует все планёрки и затрачиваемое на них время в единой форме в виде задач. На основании этого можно подсчитать сколько времени и денег каждый отдел тратит на планёрки, собрания, митинги. Уже в первый месяц такая аналитика позволила принять решения по улучшению работы отделов и компании в целом.
- Мы увидели, что митинги часто затягиваются и ввели правило придерживаться таймингов.
- Один и тот же вопрос обсуждается по многу раз на разных митингах, и ввели правило вести протокол и аудиозапись митинга.
- Мы увидели, что в планёрках участвует слишком много людей, и ввели правило минимизировать их количество. В планёрке участвуют только те, кто включён в конкретную задачу или процесс.
