Как мы делали «российский Зум»
С корпоративным софтом есть проблемы, а госкомпаниям в России в текущих реалиях надо как-то разговаривать.
В MS 365 был Teams, поэтому многие приходили к нам и спрашивали, есть ли в нашем офисном пакете такой же. Стало понятно, что нужна разработка такого решения.
При разработке «Р7-Команды» возникало множество сложностей, среди прочих отмечу две, которые отняли у нас немало времени и нервов. Во-первых, оказалось очень трудно обеспечить гарантированную доставку сообщений. Во-вторых, было непросто сделать видеоконференции с очень большим количеством пользователей. Но всё-таки мы уже полтора года на рынке.
Сейчас «Р7-Команду» используют ряд предприятий с тысячами сотрудников и государственные учреждения.
Продукт у нас выделен в отдельное направление, у него своя команда, в которую мы активно привлекаем новые кадры.
Для кого продукт
«Р7-Команда» — это корпоративный мессенджер для общения между сотрудниками организации. Он состоит из Desktop-клиента, клиента для ОС Android, клиента для ОС iOS, Web-клиента и серверной части.
Для чего было необходимо создавать ещё один мессенджер, когда есть много открытых (Telegram, Viber и так далее)? При их использовании вся переписка находится на стороне той компании, которая предоставляет сервис, и нет гарантии, что она не попадёт не в те руки.
Но у бизнеса есть потребность сохранения коммерческой тайны. Вся переписка и звонки должны храниться на серверах компании. Это требование и заставило нас начать развитие этого направления. Изначально, ещё до пандемии, мы планировали делать только облачное решение, но потом увидели большую потребность реальных клиентов именно в сегменте on-prem — это когда вся информация (документы, переписка, файлы) хранится на сервере компании.
Большинство других решений на рынке развивается как отдельные сервисы: сервис хранения и редактирования документов, видео-конференц-связь и мессенджер. Мы же увидели возможности интеграции «Офисного пакета» и «Команды» по аналогии с тем, что сделано у Microsoft Teams. Мы поняли, что можем дать пользователю единую систему, где он может и переписку вести, и документы редактировать.
Сейчас продукт позиционируется как корпоративный мессенджер с возможностью созвонов и переписки. Мы долго шли к этому. Про позиционирование изначально у нас были жаркие дебаты.
Кто-то хотел чистую видео-конференц-связь. Кто-то делал упор на мессенджер. В итоге, глядя на наших конкурентов и рынок, мы решили ориентироваться на MS Teams. Мы поняли, насколько не зря Microsoft выбрал такой формат. Пандемия и удалёнка помогли удостовериться, что направление правильное.
Пользователи ищут себе замену редакторов вместо ушедших с рынка, начинают использовать «Р7-Офис», а потом узнают, что есть ещё и видео-конференц-связь. Так решение одного поставщика может полностью закрыть все потребности клиента. В обратном порядке это тоже работает: тот, кто изначально ищет только ВКС или мессенджеры, в итоге находит всю линейку продуктов «Р7».
Пользователь вряд ли захочет переучиваться только для одного продукта, поэтому важно ориентироваться на дизайн уже популярных решений, тогда новый продукт будет интуитивно понятен клиентам. По этой причине тот же самый «Р7-Офис» очень похож на Microsoft Office.
И мы прежде всего ориентировались на популярные мессенджеры: Telegram, Teams, Skype, Skype for Business.
Помимо дизайна, существуют разные идеологии мессенджеров. Среди них есть такие, как WhatsApp: они хранят информацию не в облаке, а на телефоне, и требуют наличия доступа к телефону по сети.
Есть мессенджеры, которые хранят всё в облаке, сохраняя всю информацию при смене телефонов и компьютеров. Это наш случай, а облако у нас хранится на собственном сервере компании.
Как всё начиналось
Когда мы принимали решение о том, как разрабатывать наш продукт, был большой соблазн форкануть какое-нибудь открытое решение вроде Rocket.Chat или Jitsi Meet. Но мы стали разрабатывать решение самостоятельно.
С любым Open Source-проектом существует много риска. При необходимости доработок для конкретного заказчика («Хочу перламутровые пуговицы» или ещё что-то) нужно разбираться, соотносить, что сделало комьюнити, с тем, что сделал ты, решать конфликты и прочее.
К тому же при нынешней ситуации может вдруг оказаться, что ты не контролируешь весь тот код, который выкладывают в Open Source. Тебе нужно регулярно ревьюить новые версии, потому что мало ли что там было залито, и нет гарантии, что у клиента не вылезет не то сообщение. Мы же имеем полный контроль над своим продуктом.
Когда мы это начинали, все крутили пальцем у виска и говорили: «Зачем вы делаете корпоративный мессенджер? Есть же Teams, Skype for Business. Зачем вам вообще это нужно?»
Никто не верил в то, что этим нужно заниматься и что оно может принести прибыль. Впрочем, в то, что необходимо разрабатывать собственные текстовые редакторы, тоже мало кто верил.
Так что начиналось всё из чистого исследовательского интереса. В команде разработки было несколько человек из одного вуза, некоторые из нас там даже до сих пор преподают.
Мессенджер — это одна из самых сложных для разработки штук, а у нас он ещё и с ВКС. Мы решили попробовать применить полученные навыки на практике совместно с талантливыми ребятами-старшекурсниками, и сейчас они уже стали лидами разработки по разным направлениям.
Одной из непростых задач, с которой мы столкнулись в самом начале пути, стало гарантировать дозвон на смартфон собеседника. Это же корпоративный мессенджер: начальник должен всегда дозваниваться до подчинённого! Мы подумали, что для этого можно использовать push-сообщения, они же для этого и были придуманы. Но тут нас ждало много подводных камней.
Например, если приложение открыто, то FCM считает, что это дело самого приложения — получать уведомления, и нечего надеяться на пуши. Поэтому, когда приложение у нас открыто, для входящих звонков уведомление идёт по Web-сокетам. Если же Android-телефон полежит у вас в кармане 15–20 минут выключенным, то операционная система убьёт службу приёма пуш-сообщений для приложения, чтобы она не ела батарею. Поэтому нам пришлось, как и в приложениях для фитнес-браслетов, просить пользователя снять ограничения для приложения в системном меню, если для него важно гарантированно быть на связи.
Пуши вообще могут приходить с большим опозданием. У нашего разработчика так посреди ночи зазвонил телефон и разбудил всю семью, а никакого звонка-то и не было. Это заставило нас проверять, идёт ли сейчас звонок или он уже завершился.
Но тут выяснилась другая проблема — для уведомления о звонках в iOS-клиенте мы используем VOIP-пуши, а если на мобильное приложение пришёл такой пуш, то по требованиям Apple мы просто обязаны запустить проигрыш мелодии входящего звонка, но, правда, на очень короткое время, чтобы невзначай никого не разбудить. Мы даже пробовали делать уведомления только через Web-сокеты, делали резидентный неубиваемый сервис, но в конечном итоге отказались от этой идеи.
Часто возникают неожиданные баги. Например, у нас изначально была возможность в режиме реального времени увидеть в групповом чате, сколько человек прочитало твоё сообщение.
Это хорошо работало в тестовом контуре на группах малого размера до пяти участников. Но когда мы стали проводить нагрузочные испытания на группах большого размера от 100 человек и выше — оказалось, что это вызывает частую перерисовку сообщений на клиентском приложении и ухудшает пользовательский опыт. В итоге пришлось переделать функционал так, чтобы пользователь видел, что его сообщение в групповом чате прочитали, а список прочитавших вывели в отдельное окно.
Работа самих звонков тоже весьма нетривиальна. Тут мы, как и все конкуренты, используем технологию WebRTC (Web Real Time Communications). По сути, звонок сводится к тому, что каждый собеседник отдаёт свои видео- и аудиопоток на сервер и получает видеопотоки и аудиопотоки других собеседников. И тут тоже есть варианты.
Изначально мы микшировали все потоки на стороне сервера, и отдавали клиентам отмикшированный поток для отображения. Такой подход называется MCU. Его плюс в том, что клиент принимает только один поток, соответственно нагрузка и на вычислительные средства устройства, и на канал приёма/передачи минимальны. Но сервер при этом работает как не в себя. Такое решение требует очень мощного железа на стороне сервера, что в итоге увеличивает стоимость внедрения нашего продукта.
Поэтому мы перешли к технологии SFU. В этом случае сервер ретранслирует всем клиентам потоки от других клиентов, но ничего не микширует. Но тут тоже возникли определённые сложности: клиентам надо было подписываться только на видеопотоки тех собеседников, которые были у них на экране. Это хорошо, когда у вас широкополосный канал с высокой пропускной способностью: вы можете получать высокое качество видеопотоков. А как быть, если у вас мобильный Интернет или вы где-то едете? Тут нам пришлось внедрить адаптивное качество приёма потоков.
Есть ещё проблема приоритетов: что важнее при плохом канале — чтобы я всех слышал или меня все слышали? Вроде бы такие задачи кажутся тривиальными, но в то же время они требуют принимать много сложных решений по их реализации и учитывать кучу ограничений.
Решая одни проблемы, мы переходим к другим следующего уровня. От сопряжения мобильного телефона с вашим автомобилем, чтобы во время поездки вы могли поучаствовать в совещании, до индикации качества канала при совершении звонка. Или применение заднего фона на видеоизображении и шумоподавление, когда вы находитесь в людном месте. Или вот сейчас мы работаем над проблемой эхоподавления.
Ещё «Р7-Команда» умеет звонить в телефонную сеть общего пользования, когда у абонента совсем нет доступа к Интернету, а телефонная сеть есть. Так же и абонент может по добавочному номеру попасть в необходимую ему конференцию и поучаствовать в совещании.
Как шло внедрение продукта
В первых пилотных проектах мы совместно с клиентами тратили очень много времени на инсталляцию. Набивали шишки. Первым клиентом, который купил наш продукт, была небольшая организация из 50 человек. Для нас было ярким рубежом, что это была наша первая продажа, клиент ежедневно пользовался нашим продуктом, и всё хорошо работало.
Следующим рубежом стало то, что наше приложение начали внедрять уже крупные предприятия: у одного было более тысячи, а у второго — около полутора тысяч пользователей. «Пилоты» проходили успешно, наше решение устраивало.
Среди клиентов у нас есть промышленные предприятия, у которых вообще нет выхода во внешний Интернет, но есть внутренняя интранет-сеть компании. На предприятии расположено множество цехов, которые территориально разнесены. Директору надо с утра проводить совещание между ними, желательно безотрывно от производства. Для такого типа клиентов очень остро стоит проблема с самоподписанными сертификатами. Мы работаем над удобством инсталляции нашего решения, в том числе и в закрытых контурах.
В прошлом релизе вышел, например, полноценный офлайн-инсталлятор, который позволяет устанавливать и обновлять серверную часть без доступа в Интернет. При возникновении каких-либо проблем с эксплуатацией решения мы всегда придём на помощь, особенно в этом плане интересна функция удалённого управления рабочим столом собеседника непосредственно в звонке.
Обычно мы собираем требования и пожелания наших потребителей
Они говорят нам, какую проблему нужно решить, например, заменить тот же самый ушедший Skype for Business, или Teams, или ещё кого-то. И обычно обязательно просят, чтобы у нас был определённый набор функционала, без которого внедрение нашего решения невозможно.
Дальше мы всё это приоритизируем в зависимости от количества потенциальных клиентов и считаем экономику продукта. Конечно, выбираем наиболее популярные функции, учитывая как количество пользователей в запросившей компании, так и количество компаний, запросивших одну фичу.
Потребители обычно что-то видят у конкурентов и хотят так же. Ещё у нас есть пилотирование продукта, в том числе — и на облачном решении, где можно потестить и запросить доработку. У нас уже запрашивали, например, поддержку диплинков в десктопных клиентах для возможности подключения по ссылке. Эта доработка выйдет в ближайшем релизе.
Сейчас перед нами стоит сложная и важная задача — интегрировать работу с документами в мессенджер. Тогда прямо там можно будет создавать документ, совместно редактировать и обсуждать его прямо при проведении конференции. Это то, чего хотят все наши клиенты.
Сейчас в нашей конференции одновременно могут участвовать до 550 человек. Мы хотим большего и работаем над увеличением этого количества. Для вебинаров в скором релизе выйдет решение проблемы переключения между видеопотоком участника и демонстрацией его экрана.
Команда «Р7-Команды»
Разработка решения требует наличия в команде специалистов разных направлений: это серверная разработка (бекэнд), мобильные клиенты для IOS, мобильные клиенты для Android, веб-разработка (фронтэнд), десктоп-разработка, а также тестирование, в том числе — автоматизация и нагрузочное, аналитика (продуктовая и системная) и дизайн.
Если брать браузеры, то, к сожалению, в разных из них — куча различий по работе с WebRTC, и грабли для Chrome отличаются от грабель на Firefox, а для Safari это не грабли, а целый комбайн. Десктоп-решение мы строим на базе веб-решения и Electron. Наш десктопный клиент работает на Windows, macOs и Linux, в том числе — Astra Linux, Ред ОС, Rosa, ALT Linux, Debian и CentOS. Мобильные клиенты для iOS и Android пишем нативно на Kotlin и Swift.
В общем, по факту мы написали приложение, которое ежедневно помогает в работе нашим клиентам.
Над какими фишками работаем сейчас
- Комната ожидания при подключении к конференции по ссылке.
- Режим отображения конференции для быстрого доступа к микрофону для мобильных клиентов iOS и Android.
- Выборочный звонок в группе.
- Управление администраторами групповых чатов в панели администратора (изменение списка участников и их ролей на случай, если администратор заболел или уволился).
Ну и общая фишка «Р7» — клиентам не нужно стыковаться с разными поставщиками, мы создаём единое пространство для полной замены Microsoft. У нас есть редакторы, почта, мессенджер, ВКС.
