Почему стоит использовать Discourse внутри компании/команды вместо Slack (4 года использования)

Мы используем Discourse как основной инструмент для коммуникации, ведения записей, документирования исследований и ведения лабораторного журнала уже более 4 лет.

Я утверждаю, что большинство компаний получили бы огромную пользу от использования Discourse в качестве основного инструмента коммуникации вместо Slack, цепочек писем и WhatsApp.

Всё сводится к следующему: если вы считаете, что разговоры между сотрудниками имеют ценность для будущего анализа, то вам необходим Discourse.
Простая причина в том, что приложения для мгновенного обмена сообщениями, основанные на каналах (например, Slack), хороши именно для этого — для мгновенных разговоров, к которым никто не захочет возвращаться, если только не ищут что-то очень конкретное. Они склонны смешивать множество разговоров в один длинный канал с тысячами строк и сотнями подтем.
Напротив, Discourse по своей природе разбивает разговоры на категории, темы и теги, что делает его чрезвычайно мощным инструментом для того, чтобы новые члены команды могли быстро погрузиться в конкретные темы, области исследований и связанные обсуждения, просто читая темы Discourse как журнал, вместо того чтобы пытаться извлечь суть из канала, где переплелись 6 других тем, включая, например, заказы на обед от всех участников.
Если ваша компания/команда/лаборатория занимается любыми видами НИОКР, я считаю, что Discourse просто необходим.

Чат — недостающее звено

Не все разговоры являются золотыми жилами информации… На самом деле, многие разговоры — это повседневные вещи: консультации, вопросы, быстрые мозговые штурмы, которые не обязательно заслуживают отдельной темы. Не говоря уже о таких сообщениях, как «У меня появилась ошибка и лог, кто знает, что это значит?» или «Что сегодня будем есть на обед?». Поэтому Slack действительно должен оставаться для быстрого и эффективного общения. С появлением чата в Discourse все формы общения и обсуждения могут быть интегрированы в одну отличную платформу!

Наша настройка — Быстро и безопасно

Мы установили Discourse на AWS EC2. В первые несколько лет мы были небольшой командой из ~5 человек, поэтому экземпляра t3.small было более чем достаточно. Сегодня мы стали больше и богаче, так что можем позволить себе m5.xlarge.
Поскольку мы работаем на сервере AWS, мы можем предоставить ему доступ к бакету S3, что позволяет легко включить объектное хранилище S3 для загрузок, чтобы все прикрепленные файлы, изображения, таблицы Excel, CSV, PDF-файлы надежно резервировались.
Мы включаем Безопасные загрузки, что защищает наши данные (мы установили режим Discourse только по приглашениям и запретили доступ к форуму или файлам для любого посетителя без входа в систему).
Примечание: Мы, конечно, игнорируем рекомендацию использовать CDN, так как это противоречило бы цели безопасных загрузок.

Плагины для повышения производительности

  • Assign —> назначение тем конкретным людям — хороший способ поручить сотруднику ответственность за задачу/проблему/проект
  • Math —> если вы занимаетесь исследованиями, вам нужна поддержка LaTeX и формул
  • Reactions —> это просто современный способ общения. На мой взгляд, это должно быть встроено в Discourse.
  • Shared Edits —> очень удобно для команд, чтобы совместно создавать и редактировать вики-страницы или другие страницы с информацией/знаниями.
  • Whos Online —> в команде обязательно нужно знать, кто сейчас онлайн
  • Footnote —> компаниям нужны юридические оговорки… это место для написания пункта о конфиденциальности.
  • Можно также упомянуть Calendar, который полезен, но способ его реализации и функционирования нам не совсем подходит. Голосование за темы — еще один потенциально полезный плагин.

Компоненты темы:

  • Custom Header Links —> размещение важных ссылок компании/команды в шапке. У нас есть доска отпусков, раздел «Мои задачи» (для плагина Assign), ссылка на нашу доску Jira…

  • PDF previews + iframe Lightboxes —> установка обоих плагинов вместе и настройка доменов origin для iframe с включением вашего собственного домена позволяют всем загруженным на форум PDF-файлам открываться прямо в потоке обсуждений, а также добавляют кнопку для просмотра в полном размере. PDF-файлы очень полезны, и такой способ делает их обмен простым.

  • Discourse Chat Sidebar —> вывод чата на передний план. У всех нас экраны 24–27 дюймов, и мы хотим перенести всю активность из Slack/WhatsApp в Discourse.

  • Почетные упоминания:
    ** discourse gifs, который, на мой взгляд, должен быть встроен в Discourse.
    ** Discourse Kanban, который не заменяет Jira, но помогает с задачами высокого уровня и хорошо работает с плагином «Assign». Его нужно просто правильно настроить, что не было тривиальной задачей.
    ** Sidebar Theme Toggle — мы используем только стандартную темную/светлую тему, поэтому даем пользователю возможность легко выбрать свои предпочтения.

Заключение

Прежде всего, спасибо замечательной и вдохновляющей команде Discourse :clap:
Discourse — это надежная, быстрая и безопасная платформа для общения без компромиссов, и я надеюсь, что больше команд будут вдохновлены использовать её для компаний, университетских лабораторных групп, стартапов и не только!

86 лайков

Нам очень нравятся ваши идеи о том, как вы используете Discourse. Здесь удобный призыв к другим читателям :loudspeaker: — мы будем рады узнать больше о том, как вы используете Discourse внутри компании. Это действительно помогает нам понять, что работает хорошо, и расставить приоритеты в исправлении того, что не работает.

Мы сами используем Discourse внутри компании, поэтому нам довольно интересно слышать о наших сходствах и различиях (их немного!).

:writing_hand:t2: записываю — Мы подумаем над этим, спасибо!

24 лайка

Спасибо за полезные сведения. Вы заставили меня задуматься о традиционной комбинации чата — например, Slack, Mattermost, Rocket.Chat — плюс обмена знаниями — например, Confluence — по сравнению с Discourse как платформой, которая может решать все эти задачи.

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

9 лайков

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

На мой взгляд, проблема с пуш-уведомлениями заключается в том, что на их путь к пользователям слишком много препятствий. Нужно включить их в личных настройках Discourse, разрешить в браузере и разрешить на системе Android/Windows. Если хотя бы одно из этих трёх звеньев блокирует уведомления, пользователи их не получают. Лично, даже если я активно хочу получать пуш-уведомления, они всегда перестают приходить после какого-то случайного периода. Возможно, из-за обновлений браузера? Не знаю. Поэтому даже в случае с Android я не могу сказать, что они действительно работают так, как мне хотелось бы.

Вчера я попробовал уведомления через Pushover. Это решение функционально работает на Android, Apple и Windows, однако у него есть два серьёзных недостатка (по которым я в итоге не стал его использовать):

  1. Каждый пользователь должен установить стороннее приложение на свой телефон и вручную скопировать свой user_id на страницу настроек Discourse :grimacing:
  2. Уведомление всплывает, но вместо того чтобы сразу открыть чат/тему Discourse, оно переводит в приложение Pushover, откуда нужно сделать ещё один тап по ссылке на чат/тему. Это может показаться мелочью, но если речь идёт об уведомлениях о личных сообщениях, то добавление промежуточного приложения между пуш-уведомлением и тем местом, куда вы хотите попасть, серьёзно ухудшает опыт.

Discourse постоянно развивается: десятки коммитов в день, поэтому я остаюсь оптимистом и надеюсь, что работа с пуш-уведомлениями улучшится. Мой идеальный сценарий — это открытое нативное приложение для Android/iOS, которое можно настроить и загрузить в Play/App Store администратором. Но, возможно, работа через сторонние сервисы, такие как OneSignal и подобные, окажется проще и позволит достичь той же цели.

9 лайков

Спасибо за тестирование вариантов push-уведомлений. У меня тоже сложилось такое впечатление: независимо от выбранного варианта возникает слишком много трения. Это не специфическая проблема Discourse, а общая проблема, которая сдерживает широкое внедрение Discourse и подобных платформ — речь о уведомлениях и удержании пользователей благодаря этим уведомлениям.

4 лайка

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

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

В наши дни PWA на iPhone (пока вы не находитесь в Европе) и PWA на Android работают довольно хорошо. Однако законодательные изменения в Европе заставляют нас гораздо серьезнее задуматься над созданием собственного приложения.

17 лайков

Я лишь поддержу нижесказанное.

Я считаю, что уведомления PWA на Android работают хорошо, когда они вообще работают, но это случается редко, так как я долго замечаю, когда они перестают функционировать.

2 лайка

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

Тем не менее… запрет PWA в Европе со стороны Apple означает, что нам придётся столкнуться с этой проблемой, и мы это сделаем.

9 лайков

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

По моим наблюдениям, это цикл: около месяца уведомления приходят, затем около двух месяцев я не замечаю, что они отключены, после чего включаю их снова, чтобы начать цикл заново. Я попробую ещё раз и надеюсь, что это больше не повторится. Больше всего меня беспокоит то, что я, безусловно, самый активный пользователь на своём сайте. Обычные пользователи не обращают внимания на такие вещи, как я. Я уверен, что на данный момент лишь небольшая их часть заходила в настройки уведомлений более одного раза.

Только что я проверил данные в исследователе данных и обнаружил 30 активных пользователей с записью push_subscriptions на сайте, где ежедневно посещают 450–500 человек. Это примерно 6% охвата. Треть из них обновляла подписку после 2024 года.

Я ценю всю проделанную в этом направлении работу и понимаю, что многое зависит от внешних факторов (например, Apple, Google). Но я просто хочу выразить своё мнение, что формулировка «работает довольно хорошо» не соответствует ни моему опыту, ни мнению автора оригинального поста.

6 лайков

Как мы знаем, сейчас это уже не так.

Тем не менее, мы хотим, чтобы Discourse стал флагманом в развертывании PWA и боролся с гегемонией push-уведомлений!

9 лайков

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

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

1 лайк

Мы используем Discourse send PDF inline без каких-либо нареканий.

5 лайков

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

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

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

5 лайков

Спасибо за этот очень интересный и полезный отчёт.

Мой путь схож: я использую Discourse для создания личных и организационных виртуальных инфраструктур.

Я в основном индивидуальный предприниматель, и у меня уже несколько десятилетий идут несколько ключевых проектов. Поэтому мне нужны инструменты, которые позволяют на лету создавать новые направления и подпроекты (а также под-подпроекты) и задачи.

Это тексты и коллекции связанных исследований.

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

В последние несколько лет я чаще всего вижу Discourse и Ghost в центре моих различных рабочих процессов.

4 лайка

Вы поднимаете важный вопрос!
Каждый форум имеет свою культуру, которая формируется вокруг него, и устоявшийся порядок, складывающийся со временем.
Когда я начал использовать Discourse как средство общения между членами команды, сохранения исследовательских инсайтов, более эффективного отслеживания обсуждений по сравнению с цепочками писем и т. д. в начале пандемии COVID-19, я хотел убедиться, что этот инструмент используется правильно, по крайней мере, в соответствии с моим представлением о том, что такое «правильно».
В моём случае это было не так уж сложно, потому что мы были командой всего из 7 человек, и я мог буквально провести каждого участника команды через создание тем, чётко разделённых по тематике, но не дублирующих одну и ту же тему в нескольких обсуждениях. Я также обращал внимание на то, чтобы ответы писались с учётом их будущей ценности (например: провели эксперимент? опишите его, дайте контекст, покажите, что и как вы делали, используйте графики с подписанными осями… чтобы, перечитывая этот пост через несколько месяцев, вы могли извлечь из него пользу), размещали материалы в правильной категории, были эффективны — писали максимум информации минимумом слов, проявляли доброту и так далее.
Как только у вас сформировалась хорошая базовая культура, каждый новый сотрудник, присоединяющийся к компании, естественно принимает её при минимальном руководстве.
Я до сих пор иногда веду беседы с конкретными людьми о том, как можно улучшить их темы и ответы. Это помогает поддерживать хорошую культуру.
В итоге я считаю: если вы работаете над своей базовой культурой, когда команда ещё мала, она отлично масштабируется по мере роста.

8 лайков

Как поступить, если у вас есть обсуждения между отделами, но вы не хотите добавлять всех пользователей в группу другого отдела? Или, возможно, у вас все обсуждения доступны всем? В моём случае некоторые обсуждения на уровне отделов должны быть скрыты от остальных.

1 лайк

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

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

4 лайка

На мой взгляд, это одно из самых важных решений для внутренних сообществ, и его нельзя принимать в спешке. Поскольку наше сообщество в основном состоит из разработчиков, я выбрал подход, основанный на инструментах. Само по себе это решение помогло устранить разобщённость между отделами и одновременно удовлетворило требования отдела информационной безопасности в части ограничения доступа к информации. Мы пошли по тому же пути, что и @Alon1: пользователи состоят в нескольких группах — достаточно вступить в группу, соответствующую интересующему вас инструменту.

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

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

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

4 лайка

Действительно, права доступа к категориям очень ценны.

Например, отдел может иметь две группы: одна для руководства (те, кто в некоторых категориях может создавать темы). Хотя это также можно реализовать с помощью групп тегов, ограниченных для конкретной группы.

1 лайк