Групповушке не место на работе

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

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

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

Получив сообщение, специалист должен проделать следующее:

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

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

Не забываем, что каждое новое сообщение требует внимание присутствующих, а если не требует - зачем их всех собрали в одном чате?!

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

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

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

Во-первых, это не правда - если процессы не заставляют заносить артефакты в задачу, то артефакты так и останутся в чате. Я заявляют это просто с позиции своего опыта.

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

Хорошо настроенная автоматизация в системе учета задач позволяет задаче двигаться по процессу меняя ответственных естественным образом:

Создание запроса -> Передано руководителю -> Назначена на исполнителя -> Вернули постановщику

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

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