Постараюсь прокомментировать, хотя больше отвечаю не за продуктовую, а за техническую сторону вопроса
Действительно сложно сравниться с продуктами, которые значительно старше, но тем не менее мы действительно видим и знаем как выстроить классную корпоративную платформу для коммуникаций. Из забавного как-то слышал, как один представитель бизнеса упрекал российский продукт аргументом "Даже в Exchange это есть". Нужно время.
Если сравнивать, например со Slack, то действительно треды реализованы иначе и, пожалуй, действительно мы не уделяем им сегодня столько времени, сколько хотелось бы, но это прежде всего связано с тем, что корпоративные заказчики видят другой функционал куда более приоритетным. И тут мы, как и большинство игроков на российском рынке, находимся ПОКА в догоняющей позиции, т.к. пользователи привыкли к лучшим мировым решения, а создать действительно взрослый аналог за несколько лет нереально.
По папкам спорно, лучше с продактами такое обсуждать, но а) они и предназначены для фокусировки внимания б) они хранятся на сервере и точно синхронизируются между устройствами в) для архивации чата не нужно его добавлять в папку, можно точно так же сделать и в основном списке. Опять же массово таких проблем точно не было, возможно какие-то частные случаи, надо разбираться.
По мессенджеру действительно появилось не так много. Зато из больших обновлений - появление оргструктуры в On-premises версии, значительное улучшение ВКС во всех инсталляциях и ряд других функций. В мессенджере появились папки, закрепы, архивы и отложенные сообщения. Всё это заехало за последние пол года. Как я вкратце упомянул в статье, новый подход к архитектуре и приложению в целом заставил нас значительно пересмотреть внутреннюю структуру команды, чтобы дальше мы бежали значительно быстрее.
Апи для ботов опять же развиваем. Безусловно оно не идеально и конечно есть планы его значительно улучшить. Тут, как говорится, следите за обновлениями. Многие клиенты им активно пользуются и свою функцию оно точно выполняет. Нарекания к нему в основном в контексте увеличение функциональности, знаем и делаем.
По поводу отсутствия уведомлений в винде странно, возможно какой-то баг или на уровне системы отключены уведомления, так как это точно работает даже когда "приложение закрыто и значок скрыт под стрелочкой". С уведомлениями в тредах действительно есть неудобство, но о тредах я писал выше уже.
Допускаю, что какие-то команды в VK могут и не использовать Тимс, не смотря на то, что он является официальным мессенджером для корпоративных коммуникаций компании. DAU чуть меньше, чем численность штата всего VK. Каждую минуту отправляется 1-1,5 тыс сообщений. Так же у нас вокруг Тимса и ботов построено много автоматизации, от заведения заявок до регулирования освещения на рабочем месте. Так что тезис, что в VK не используют Тимс не совсем корректен.
Ну и самое главное, мы любим мессенджер, вкладываемся в него, меняем его как технически, так и функционально. Ежедневно получаем предложения по его развитию и действительно слышим пользователей, да, в чём-то нужно банально время, привет "закон Брукса". Ну и по чесноку, сказать, что пользоваться им больно у меня язык точно не повернётся.
Идея как раз в том, чтобы заранее с избытком напилить инстансы, чтобы по ходу эксплуатации было проще балансировать нагрузку между серверами (заранее мы не предугадаем где будет чат будет на 200 человек, а где канал на 200 тыс.) просто перекидывая ячейки между ними. Этот процесс достаточно быстрый, занимает обычно от сотни миллисекунд до 1 секунды, и зависит прежде всего от нагрузки. Мы обычно проектируем так, чтобы не было больше 10к RPS на одну ячейку, даже если фактически она может и на порядок больше переварить.
Если всё же есть потребность "распилить" ячейку, то создаётся ещё одна пара "экземпляр сервис-БД" (плюс реплика для неё) и данные потихоньку начинаю мигрировать в неё. Т.е. происходит решардинг, это более трудоёмкая и длительная операция, но она также происходит без остановки обслуживания.
Нет, в тимсе мы не используем Jitsi, у нас во многом свои наработки. Для того, чтобы не было путаницы, VK Звонки и звонки в VK Teams имеют разную технологическую базу.
Что-то вы какой-то странный "классический регулярный менеджмент" рассматриваете. Открываем классика менеджмента - Друкера, который основные работы написал ещё 60-70 лет назад, и обнаруживаем, что большинство тех качеств, которые вы приписываете регулярному менеджменту, банально свидетельствует о его неэффективности.
Agile не переизобретает менеджмент, он просто специфицирует, как именно им пользоваться применительно к созданию ПО.
Постараюсь прокомментировать, хотя больше отвечаю не за продуктовую, а за техническую сторону вопроса
Действительно сложно сравниться с продуктами, которые значительно старше, но тем не менее мы действительно видим и знаем как выстроить классную корпоративную платформу для коммуникаций. Из забавного как-то слышал, как один представитель бизнеса упрекал российский продукт аргументом "Даже в Exchange это есть". Нужно время.
Если сравнивать, например со Slack, то действительно треды реализованы иначе и, пожалуй, действительно мы не уделяем им сегодня столько времени, сколько хотелось бы, но это прежде всего связано с тем, что корпоративные заказчики видят другой функционал куда более приоритетным. И тут мы, как и большинство игроков на российском рынке, находимся ПОКА в догоняющей позиции, т.к. пользователи привыкли к лучшим мировым решения, а создать действительно взрослый аналог за несколько лет нереально.
По папкам спорно, лучше с продактами такое обсуждать, но а) они и предназначены для фокусировки внимания б) они хранятся на сервере и точно синхронизируются между устройствами в) для архивации чата не нужно его добавлять в папку, можно точно так же сделать и в основном списке. Опять же массово таких проблем точно не было, возможно какие-то частные случаи, надо разбираться.
По мессенджеру действительно появилось не так много. Зато из больших обновлений - появление оргструктуры в On-premises версии, значительное улучшение ВКС во всех инсталляциях и ряд других функций. В мессенджере появились папки, закрепы, архивы и отложенные сообщения. Всё это заехало за последние пол года. Как я вкратце упомянул в статье, новый подход к архитектуре и приложению в целом заставил нас значительно пересмотреть внутреннюю структуру команды, чтобы дальше мы бежали значительно быстрее.
Апи для ботов опять же развиваем. Безусловно оно не идеально и конечно есть планы его значительно улучшить. Тут, как говорится, следите за обновлениями. Многие клиенты им активно пользуются и свою функцию оно точно выполняет. Нарекания к нему в основном в контексте увеличение функциональности, знаем и делаем.
По поводу отсутствия уведомлений в винде странно, возможно какой-то баг или на уровне системы отключены уведомления, так как это точно работает даже когда "приложение закрыто и значок скрыт под стрелочкой". С уведомлениями в тредах действительно есть неудобство, но о тредах я писал выше уже.
Допускаю, что какие-то команды в VK могут и не использовать Тимс, не смотря на то, что он является официальным мессенджером для корпоративных коммуникаций компании. DAU чуть меньше, чем численность штата всего VK. Каждую минуту отправляется 1-1,5 тыс сообщений. Так же у нас вокруг Тимса и ботов построено много автоматизации, от заведения заявок до регулирования освещения на рабочем месте. Так что тезис, что в VK не используют Тимс не совсем корректен.
Ну и самое главное, мы любим мессенджер, вкладываемся в него, меняем его как технически, так и функционально. Ежедневно получаем предложения по его развитию и действительно слышим пользователей, да, в чём-то нужно банально время, привет "закон Брукса". Ну и по чесноку, сказать, что пользоваться им больно у меня язык точно не повернётся.
Добавлю, что в кубере сама БД разворачивается сайдкаром к сервису внутри пода.
Идея как раз в том, чтобы заранее с избытком напилить инстансы, чтобы по ходу эксплуатации было проще балансировать нагрузку между серверами (заранее мы не предугадаем где будет чат будет на 200 человек, а где канал на 200 тыс.) просто перекидывая ячейки между ними. Этот процесс достаточно быстрый, занимает обычно от сотни миллисекунд до 1 секунды, и зависит прежде всего от нагрузки. Мы обычно проектируем так, чтобы не было больше 10к RPS на одну ячейку, даже если фактически она может и на порядок больше переварить.
Если всё же есть потребность "распилить" ячейку, то создаётся ещё одна пара "экземпляр сервис-БД" (плюс реплика для неё) и данные потихоньку начинаю мигрировать в неё. Т.е. происходит решардинг, это более трудоёмкая и длительная операция, но она также происходит без остановки обслуживания.
Нет, в тимсе мы не используем Jitsi, у нас во многом свои наработки. Для того, чтобы не было путаницы, VK Звонки и звонки в VK Teams имеют разную технологическую базу.
Спасибо, поправил
Что-то вы какой-то странный "классический регулярный менеджмент" рассматриваете. Открываем классика менеджмента - Друкера, который основные работы написал ещё 60-70 лет назад, и обнаруживаем, что большинство тех качеств, которые вы приписываете регулярному менеджменту, банально свидетельствует о его неэффективности.
Agile не переизобретает менеджмент, он просто специфицирует, как именно им пользоваться применительно к созданию ПО.