{"id":14284,"url":"\/distributions\/14284\/click?bit=1&hash=82a231c769d1e10ea56c30ae286f090fbb4a445600cfa9e05037db7a74b1dda9","title":"\u041f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u0444\u0438\u043d\u0430\u043d\u0441\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u043d\u0430 \u0442\u0430\u043d\u0446\u044b \u0441 \u0441\u043e\u0431\u0430\u043a\u0430\u043c\u0438","buttonText":"","imageUuid":""}

Resolvit.io: как я устал от хаоса в мессенджерах и сделал сервис по решению рабочих задач

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

Привет! Я Антон, продакт-менеджер и создатель сервиса Resolvit.io. В нем пользователи общаются только по делу, а обсуждения привязаны к конкретной проблеме и существуют, пока она не будет решена. Но главное ― кнопка Resolve, которая все упрощает.

TL;DR: Если хотите краткую выжимку — скрольте в самый конец.

Как мессенджеры мешают нам быть эффективными

Первое время я считал, что моя боль никому не понятна. Но когда я порылся в интернете, то понял, что дело не во мне. Когда-то мы все перешли из email в мессенджеры, чтобы экономить время, но вышло наоборот.

Главное преимущество мессенджеров — возможность мгновенно отвечать на сообщения ― стало его недостатком.

Мы отвлекаемся на уведомления, иногда ещё и бесполезные. Продуктивность падает. Вместо решения задач мы проваливаемся в бесконечные параллельные обсуждения. Согласно исследованиям профессора Глории Марк из Калифорнийского университета в Ирвайне, прерываясь на рабочий чат во время выполнения задачи, работнику нужно 23 минуты, чтобы снова вникнуть в задачу. Microsoft подсчитал, что общение в чатах, электронной почте и на собраниях отнимает примерно 57% рабочего времени.

https://www.microsoft.com/en-us/worklab/work-trend-index/will-ai-fix-work

Как общение в мессенджерах отнимает время?

Обсуждение простого вопроса растягивается на 100+ сообщений. Представим, что вы создали тред, чтобы утвердить дизайн. В процессе обсуждения решили, что тексты надо отредактировать. Потом захотели еще и иллюстрации докрутить, но иллюстратор на аутсорсе, а связь через Telegram. Как итог ― хаос, неразбериха из 3-х тем в одном треде.

Одновременное обсуждение разных тем в одном треде замедляет работу:

  • Сложно читать. Треды завалены параллельными обсуждениями, много сил уходит на сортировку информации.
  • Часть вопросов теряется. Если после вашего вопроса кто-то поднял тему поинтереснее, будьте уверены — на ваш вопрос так никто и не ответит.
  • Нерелевантные уведомления. Если в треде про дизайн начали обсуждать еще и иллюстрации, то вы начинаете получать тонну уведомлений о том, что вас не касается.
  • Нет приоритизации. В куче непрочитанных тредов непонятно, что важно, а что можно отложить на потом.
  • Неясно, что в итоге решили. Какое решение приняли и где его найти?

Как Resolvit.io борется с этим хаосом

Поговорили о проблемах. Теперь к решениям!

Дискуссии вместо каналов и чатов

Дискуссия — это пространство, где можно обсуждать конкретные задачи с понятным результатом ― согласовать, создать, выпустить и так далее. Это не чатик «с разработкой», «без разработки», «без разработки, но с Мишей».

Вот я посвятил дискуссию обсуждению нашей статьи:

То же самое можно сделать с презентацией, релизом, сайтом или отдельной иллюстрацией.

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

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

Не превратить дискуссию в хаос помогают треды.

Один тред — одна тема

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

Выставляйте треды в удобном порядке. Не хронологически и не в порядке обновлений ― а так, как удобно вам.

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

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

Тред можно разделить или перенести в другую дискуссию. Участник начал обсуждать новую тему в треде? Нестрашно, из сообщения можно создать отдельный тред, а из треда — большую дискуссию.

Кнопка Resolve

Кнопка Resolve — ключевой инструмент, который поддерживает дискуссию в актуальном состоянии. В Resolvit.io вы видите только активные треды. Если вы все обсудили и пришли к решению — можно «зарезолвить» как тред, так и всю дискуссию.

Шеринг дискуссии в один клик

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

Саммари в один клик

Позвали в тред, где уже 100+ сообщений? В Resolvit.io есть возможность посмотреть Summary в один клик. Сервис интегрирован с ChatGPT, который подготовит выжимку.

Resolvit.io особенно полезен, когда нужно

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

Resolvit.io уже можно использовать

Все, что описано выше, уже функционирует. Сейчас это бесплатно. Попробуйте Resolvit.io на одной дискуссии ― app.resolvit.io

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

Что Resolvit.io ждет в будущем

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

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

Если вам близка наша идея — вступайте в нашу группу в Telegram.

Краткая выжимка

  • Мессенджеры создавались, чтобы работать было легче, но теперь нас перегружают. Мне это не нравится, и я создал новый сервис.
  • Resolvit.io решает проблему хаоса в тредах и чатах
  • В тредах и чатах теряются вопросы, обсуждается сразу много задач, приходится отвлекаться на чужие проблемы.
  • В Resolvit.io все проще. Заходите, создаете тред ― а он привязан к конкретному вопросу. Если в треде появляется новый вопрос, мы делаем отдельный тред. И так дробим все, что нужно обсудить. Когда вопрос решается, тред закрывается.
  • Сервис уже работает ― заходите и делитесь, что бы вы хотели добавить. Так мы сможем приоритизировать обновления и сделать его еще более полезным.
0
309 комментариев
Написать комментарий...
Георгий

Мне не совсем нравятся такие решения.
Нормальные компании стремятся у себя поднять self-hosted /on-prem решения: Mattermost, Rocketchat и т.п. У кого на это пока нет сил, средств и желания используют Teams, Slack, на худой конец Skype, Telegram, но это больше, как временная мера, у любой нормальной компании все-равно в планах развернуть у себя сервис и не зависеть от сторонней компании, тем более, если сервис от неизвестной компании.

Ответить
Развернуть ветку
Sergei Zotov
у любой нормальной компании все-равно в планах развернуть у себя сервис и не зависеть от сторонней компании

ага, и именно поэтому ежегодные расходы компаний на SaaS'ы растут с каждым годом (на ~30% с 2021 года), даже у энтерпрайза.

понятно, что все мы смотрим на мир через разные призмы, но иногда стоит взглянуть и на данные :)

Ответить
Развернуть ветку
Anton Lebedev
Автор

Спасибо за интересную статистику!

Ответить
Развернуть ветку
Георгий

SaaS хорошая тема, но он не для всего подходит, он упрощает развёртывание и администрирование сложных систем, таких, как БД, Kubernetes, Load Balancer и др. Но такие сервисы как: Мессенджер, Документация, Хранилище паролей, Git репозитории с внутренним кодом компани – разумнее хостить на своих ресурсах, причём за свои ресурсы можно считать даже VM"ки в облаке, потому что их легко мигрировать между разными облаками, либо на собственный ЦОД. А, если эти сервисы привязывать к SaaS'у конкретного вендора может боком потом выйти.

Ответить
Развернуть ветку
Sergei Zotov

Это круто, что у вас такое мнение, но данные подтверждают, что оно далеко не у всех - это мой главный поинт)

Как пример можно привести любые видеосозвоны - почему-то никто не хостит у себя замену Zoom/MS Teams/Google Meet. Потому что зачем? Слишком много мороки с поддержкой собственного решения

Из вашего коммента я также не совсем понимаю, например, зачем БД хостить у вендора, а мессенджер - на своих серверах. В моем понимании на рынке экспертов по обслуживанию любой популярной БД на собственных серверах намного больше, чем экспертов по обслуживанию какого-нибудь Mattermost на своем сервере. Не уверен также, что у своего решения, например, uptime будет выше, чем у Slack/MS Teams/Telegram/etc.

При этом user adoption у популярных сервисов выше - разномастные сотрудники гораздо быстрее освоят популярный инструмент, чем Rocketchat с Matrix. Приплюсуем сюда же наличие частообновляемых клиентов на macos/windows/linux/ios/android с закрытием дыр в безопасности

Я бы мог притянуть аргумент за уши, думая, что мессенджер или систему документации предлагается раскатывать у себя из-за очень высокой безопасности, но если БД в SaaS, то он отпадает) ну и, честно говоря, я насмотрелся на дыры в безопасности у компаний, которые хостят опенсорс своими силами, - платные SaaS вызывают больше доверия

Плюс не слышал, чтобы хоть кто-нибудь разворачивал k8s с помощью SaaS - в моем понимании, когда у компании возникает желание развернуть k8s, у нее уже есть девопсы, а им зарплату не плати - дай только дебианы с центосами поразворачивать на собственных/арендованных серверах

Ответить
Развернуть ветку
Георгий
Как пример можно привести любые видеосозвоны - почему-то никто не хостит у себя замену Zoom/MS Teams/Google Meet

Да хостят, есть несколько решений для звонков, шаринга экрана и т.п., которое интегрируется в Mattermost, RocketChat и другими платформами. Такие решения внедрены в нескольких компаниях, с которыми я пересекаюсь.

Потому что зачем? Слишком много мороки с поддержкой собственного решения

Это обычные сервисы с удобной и простой настройкой, иногда падают, как и все иногда падает :).

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

В случае с БД в облаке (RDS / DaaS), упрощается процедура бекапа и масштабирование, повышается отказоустойчивость. При этом экспертность БД специалистов (DBA) никуда не девается, они все также востребованы и могут обслуживать и настраивать базу, но у них на это уходит меньше времени, чем на self-hosted решениях.

Плюс не слышал, чтобы хоть кто-нибудь разворачивал k8s с помощью SaaS - в моем понимании, когда у компании возникает желание развернуть k8s, у нее уже есть девопсы, а им зарплату не плати - дай только дебианы с центосами поразворачивать на собственных/арендованных серверах

Тут такие же преимущества, как с RDS. У managed K8s, мастер узлы находятся в зоне ответственности облачного провайдера, их обслуживание и настройка очень трудозатратное удовольствие, трудозатраты DevOps инженеров разумнее направить на развёртывание сервисов на worker узлах, чем на обслуживание самих серверов.
По статистике, в 2020 г. 28% компаний хотели K8s хостить у себя, в 2023 г. число снизилось до 16%. 84% компаний не видят преимущества хостить K8s на своих мощностях.
https://thenewstack.io/survey-shows-companies-moving-away-from-diy-kubernetes/

Не уверен также, что у своего решения, например, uptime будет выше, чем у Slack/MS Teams/Telegram/etc.

Не страшно. У облачных провайдеров часто тоже сбои в инфраструктуре. Недавно Slack был недоступен, была новость. В качестве резервных каналов связи, всегда можно использовать альтернативные каналы связи: email и сторонние мессенжеры.

Ответить
Развернуть ветку
Sergei Zotov
Такие решения внедрены в нескольких компаниях, с которыми я пересекаюсь.

госуха? Сколько работаю в b2b, причем даже с крупным энтерпрайзом - у всех SaaS

В случае с БД в облаке (RDS / DaaS), упрощается процедура бекапа и масштабирование, повышается отказоустойчивость. При этом экспертность БД специалистов (DBA) никуда не девается, они все также востребованы и могут обслуживать и настраивать базу, но у них на это уходит меньше времени, чем на self-hosted решениях.

дело не в поиске экспертов ДБА (найти такого, кто поднимет и будет обслуживать БД где угодно - на своем сервере или в облаке) - не сложно.

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

упрощается процедура бекапа и масштабирование, повышается отказоустойчивость

это все понятно) то же самое можно сказать и про мессенджеры

я за свою 10-летнюю карьеру видел 2 типа компаний:
1. госуха или окологосуха - все на своих мощностях, да еще и в закрытых контурах. Там я понимаю self-hosted мессенджер. Возможно, даже понимаю видеосозвоны на своем решении
2. все остальные арендуют Slack/Jira/Confluence/Trello/Asana/что угодно, и не заморачиваются с их развертыванием у себя

Я не могу себе представить компанию, которая будет где-то по середине: ей будет пофиг на секьюрность БД (гораздо более важный узел в компании) - развернет ее в облаке, но при этом ей будет обязательно нужен мессенджер (или документация/система управления проектами), развернутый на своем сервере/виртуалке

Ответить
Развернуть ветку
Георгий
госуха? Сколько работаю в b2b, причем даже с крупным энтерпрайзом - у всех SaaS

Нет. С компаниями выполняющими гос. заказы тоже пересекался, как с российскими, так и иностранными. Иностранные плотно на Teams сидят. Российские, до сих пор некоторые не ушли с Teams, но параллельно развернули у себя несколько self-hosted решений. А некоторые российские гос. компании не парятся и используют Telegram, Skype и даже WhatsApp, так было до 2022 и так сейчас, как ни странно.

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

Любой синьор DevOps инженер должен справится по идее, им не привыкать осваивать новые вещи, даже если не было опыта конкретно с этим сервисом.

я за свою 10-летнюю карьеру видел 2 типа компаний:
1. госуха или окологосуха - все на своих мощностях, да еще и в закрытых контурах. Там я понимаю self-hosted мессенджер. Возможно, даже понимаю видеосозвоны на своем решении
2. все остальные арендуют Slack/Jira/Confluence/Trello/Asana/что угодно, и не заморачиваются с их развертыванием у себя

Я привёл выше примеры своего опыта, где госуха не парится, а частные компании парятся о self-hosted решениях. Бывает по-разному, но я заметил многое зависит насколько технически прошаренное руководство в этих компаниях и сами специалисты. Чем технически грамотнее, тем больше используют схему описанную мной, где критически важные сервисы предпочитают не делать в виде SaaS, а вот там, где больше мороки с администрированием выносят на SaaS.

Я не могу себе представить компанию, которая будет где-то по середине: ей будет пофиг на секьюрность БД (гораздо более важный узел в компании) - развернет ее в облаке, но при этом ей будет обязательно нужен мессенджер (или документация/система управления проектами), развернутый на своем сервере/виртуалке

О есть много таких компаний. Про статистику K8s в облаке, которую я выше привёл вы тоже так думали. Я тоже с многими пересекался. Кроме документации, многие как гос. компании так и частые компании, тикетные системы предпочитают хостить у себя. Когда Atlassian заявила, что будущая версия Jira будет только в облаке, они получили много критики. Если самая популярная тикетная система (Jira) станет только облачной, многие будут искать именно похожие self-hosted решения, а не SaaS.

Ответить
Развернуть ветку
Sergei Zotov
Про статистику K8s в облаке, которую я выше привёл вы тоже так думали.

вернемся к первому комментарию, где вы точно так же думаете наоборот:

ага, и именно поэтому ежегодные расходы компаний на SaaS'ы растут с каждым годом (на ~30% с 2021 года), даже у энтерпрайза.

поэтому важно смотреть на данные :) про k8s не знал, - это да. У меня опыт с ним был только на собственных серверах компаний

Ответить
Развернуть ветку
Георгий
вы точно так же думаете наоборот

Я статистики по расходам на SaaS не знал, но не был этим удивлён и с этим не спорю, наоборот, я же говорю, тренд, что компании используют облака/SaaS не снижается, но есть часть сервисов, которые никогда не стоит выводить на SaaS по причинам безопасности, привязанности а конкретному вендору, конкретному проприетарному решению, это то чего грамотные менеджеры стараются избегать. Если уже так вышло что компания, например, использует GitHub (хоть и приватный) для своих внутренних проектов, то тот же GitHub есть в self-hosted варианте (GHE) и компании выносят такие сервисы, пусть даже не на собственный ЦОД, а на VM облачного провайдера.

Ответить
Развернуть ветку
306 комментариев
Раскрывать всегда