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



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

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

Мессенджер для командной работы Slack — отличный способ оптимизировать коммуникации внутри компании. Однако у этого инструмента есть минус — он не дает легкой возможности объединения двух существующих команд (внутри компании или из разных организаций).

К примеру, в digital-агентстве есть команда (SMM-отдел или разработчики приложений), которая использует Slack для общения. Пока дело касается внутренних коммуникаций, все просто отлично, но если у агентства появится клиент, который также использует Slack, возникнет коллизия — кому-то из двух компаний придется уступить и зарегистрировать новые учетные записи, чтобы попасть в нужную команду и участвовать в обсуждениях.

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

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

В последние несколько лет наблюдается взрывной рост числа мессенджеров и сервисов для командной работы — Slack, HipChat, Gitter, Kato — перечислять можно долго (вот тут есть небольшое сравнение подобных сервисов).

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

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

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

Соответственно, технологический прогресс шел не только по направлениям увеличения мощности процессоров, объемов памяти или уменьшения размеров устройств, но и в области улучшения эффективности работы с данными. В результате появилось большое количество различных систем управления базами данных (СУБД).

В нашем продукте, мессенджере для корпоративных коммуникаций Kato, используется СУБД PostgreSQL. Сегодня мы хотели бы напомнить историю возникновения этого прекрасного инструмента и показать преимущества его использования для стартапов в области информационных технологий.

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

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

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

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

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

Это явление описывается с помощью специального термина «теневые технологии» (“shadow IT” в английском варианте) — программные продукты и железо, которые в жизни компании используются, но не одобрены официально. Риски утечки, фрагментации, потери, искажения и воровства информации в результате применения теневых технологий для профессионального общения чрезвычайно высоки.

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

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

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

В сегодняшнем материале мы сравним собственный сервис Kato.im с лидерами рынка мессенджеров для командной работы Slack и HipChat.

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

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

Интеграция сервиса для проведения аудио-конференций UberConference с мессенджером для командной работы Kato решает именно эту проблему.

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



Всю эту информацию желательно объединять в одной точке, и эта роль традиционно отводилась электронной почте, которая не всегда является наилучшим решением.

Большая часть сервисов и продуктов, которыми все мы пользуемся каждый день, были построены с применением открытых технологий (open source).

Например, сотрудниками Facebook были созданы «открытые» инициативы Cassandra и React, а в последнее время даже такие апологеты «закрытости» как Microsoft, который ранее пытался уничтожить движение open source, начали открывать свои разработки (корпорация из Редмонда сделала открытым ядро платформы .NET).

При создании мессенджера Kato был использован открытый инструмент для обработки запросов с очень высокой интенсивностью — язык программирования и виртуальная машина Erlang. Эту платформу используют многие популярные проекты и компании (примеры — Amazon, Goldman Sachs, RabbitMQ, WhatsApp, Whisper). Существует крупное сообщество разработчиков, пишущих Erlang-библиотеки. С помощью одной из них, веб-сервера Cowboy, был создан мессенджер Kato — сегодня мы расскажем об истории этого open source проекта подробнее.

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

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

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

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

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

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

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

Горячие клавиши (или shortcuts) позволяют ускорить работу с любым продуктом — можно вспомнить известную всем комбинацию клавиш Ctrl+C/Ctrl+V, используемую для копирования и вставки. Приложения для общения не являются исключением — например, в Gmail присутствуют десятки шорткатов. Проблема с этими клавиатурными сокращениями заключается в том, что многие из них могут не работать на различных устройствах или операционных системах.

Для того, чтобы избежать таких проблем, разработчикам приходится прибегать к нестандартным решениям. Сегодня мы расскажем о том, как внедряли в сервис Kato клавиатурные сокращения, соответствующие идеологии Unix-редактора Vim.

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