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

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

При работе над мессенджером для корпоративных коммуникаций Kato.im мы уделили много внимания проблеме достижимости собеседников и снижению объёма информационного шума.

Twitter против шума

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

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

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

В Kato нет модели «присутствия» пользователя в той или иной беседе. Для того, чтобы привлечь внимание нужного человека, его можно просто упомянуть (как в Twitter) и независимо от уровня подписки, он увидит сообщение.

Подход Kato подразумевает отсутствие жесткой связи между личностью и комнатой — если сотрудника упомянули в комнате, в которой он раньше не участвовал, он все равно может моментально ее открыть и вступить в дискуссию.

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

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

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

Масштабирование коммуникаций

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

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

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

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

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

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

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

Широковещательное общение

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

Для этого ему не обязательно знать имена конкретных инженеров — обычно он просто пишет электронное письмо на общий адрес вроде support@companyname.com, и его проблемой начинает заниматься доступный в данный момент специалист. В Kato реализована подобная возможность «широковещательной» коммуникации одного человека с целой командой.

Для того, чтобы на сообщение обратили внимание сотрудники нужного подразделения, нужно упомянуть название комнаты, которая объединяет это подразделение (например, все тот же Support). Таким образом, если идет обсуждение какой-либо темы, где должен быть задействован кто-то из нужного подразделения, очень удобно «призывать» в чат профильных специалистов без необходимости знать их имена.

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

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

Важность поиска

Распространенной проблемой в мессенджерах является также крайне сложный поиск нужной информации. Человек, который участвует во множестве обсуждений, не может легко и просто найти нужные данные или файл в истории сообщений. Вместо этого ему приходится сначала открывать нужный чат, а затем с помощью ctrl+f осуществлять поиск в истории, подгружая ее до «победного конца».

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

На сегодня все, спасибо за внимание. В ближайших материалах мы расскажем об архитектуре Kato и том, как организованы интеграции мессенджера со сторонними сервисами.

Автор: KatoProject

Источник