Почему исправная камера, работающий микрофон и подписанный акт ещё не гарантируют, что встреча состоится
Экран включается. Камера показывает. Микрофоны работают. ВКС запускается.
Кажется, переговорную можно принимать.
Но пока её проверяют люди, которые сами её проектировали и настраивали, условия почти лабораторные. Инженер знает систему. Ноутбук уже подключался. Нужное приложение установлено. Все разрешения получены. Даже нужная кнопка давно знакома.
Настоящая проверка начинается позже — когда за пять минут до совещания в комнату входит обычный пользователь с корпоративным ноутбуком и просто хочет начать встречу.
И роль таких пространств растёт. По оценке J’son & Partners Consulting, российский рынок облачных сервисов ВКС в 2025 году достиг 9,6 млрд рублей и к 2028 году может вырасти до 13,5 млрд рублей. Но интереснее сама трансформация рынка: аналитики отмечают, что ВКС перестала быть изолированным офисным инструментом и всё больше становится частью единого корпоративного ИТ-ландшафта.
Источник: Исследование J’son & Partners Consulting по российскому рынку облачных ВКС
О том, почему переговорную полезно попробовать «сломать» до подписания акта, мы поговорили с Мариной Кравченко, коммерческим директором ИТ-интегратора ВИЗАРД.
— Марина, зачем вообще ломать систему, которую только что построили?
Не оборудование, конечно. Я предлагаю сломать идеальные условия, в которых его обычно проверяют.
Во время настройки всё предсказуемо. Инженер знает систему. Ноутбук уже подключался. Сеть настроена. Он прекрасно помнит, куда нажать.
У пользователя всё иначе Он может впервые войти в эту переговорную. У него другой ноутбук. Через пять минут начинается совещание. На связи внешний участник. Нужно показать презентацию. Завтра сюда придёт другой сотрудник, послезавтра — гость со своим устройством.
Вот эту переговорную мне и хочется увидеть до подписания акта. Поэтому для меня существуют два разных вопроса.
Первый: Оборудование работает?
И второй: Встреча состоится?Они похожи только на первый взгляд.
— Но если проект выполнен по техническому заданию, всё оборудование исправно и тесты пройдены, разве этого недостаточно?
У нас был очень показательный случай.
В одном из проектов решение было разработано в полном соответствии с техническим заданием заказчика. Сценарий выглядел удобно: пользователь приходит в переговорную и одним кабелем USB-C подключает ноутбук к PTZ-камере и микрофонной системе.
На ноутбуке инженера всё работало ровно так, как задумано. Подключили один кабель — оборудование определилось, можно начинать встречу.
А потом посмотрели на реальные ноутбуки пользователей. И выяснилось, что у части сотрудников USB-C вообще нет. Есть USB-A и HDMI.
Получилась почти идеальная иллюстрация разницы между технической и пользовательской приёмкой. Оборудование исправно. Проект соответствует ТЗ. На тестовом ноутбуке всё работает.А пользовательский сценарий — нет.
В результате в комнате добавили док-станцию для фактического набора интерфейсов и понятно промаркировали подключения.Причём сама техника здесь вообще была ни при чём. Камера работала, микрофонная система работала, монтаж был выполнен правильно.
Просто техническое условие подтвердили, а парк устройств, с которыми люди реально придут в комнату, — нет.
— Но здесь заказчик может справедливо сказать: «Мы же сами дали такое ТЗ». Почему интегратор должен перепроверять исходные данные?
Он и не должен заново проводить аудит всего технического задания. Но зрелость проекта для меня начинается там, где мы видим критичное предположение и задаём ещё один вопрос.
Если весь удобный сценарий переговорной держится на наличии одного конкретного интерфейса, логично спросить: Он действительно есть у всех пользователей?
Это не попытка снять ответственность с заказчика. Наоборот, это работа с риском до того, как он материализовался.
Иногда один вопрос до монтажа стоит намного дешевле, чем абсолютно точное исполнение неправильного предположения.
— То есть первый совет — тестировать не на инженерном оборудовании?
Я бы сказала жёстче: Уберите инженерный ноутбук и принесите настоящий корпоративный.
И желательно именно такой, с которым пользователь завтра придёт на встречу. Потому что здесь возникает второй слой — информационная безопасность.
У нас был другой случай. На ноутбуке инженера ВКС-приложение сразу видело комнатную камеру и микрофон. А на корпоративном ноутбуке пользователя эти устройства просто не появлялись в списке.
Кабель подключён. Камера исправна. Микрофон исправен. Но операционная система не давала приложению к ним обратиться: внешняя USB-периферия ограничивалась групповой политикой безопасности.
После согласования с ИТ-администраторами оборудование внесли в перечень разрешённых устройств и скорректировали политики. После этого камера и микрофон начали определяться автоматически. Вот почему фраза «у инженера всё работало» сама по себе почти ничего не доказывает.
Такие ограничения — не экзотика. Например, Microsoft Intune позволяет централизованно запрещать установку устройств и разрешать конкретные классы или идентификаторы. В документации Microsoft отдельно разбирается ситуация, когда политика блокирует камеру; там же перечислены классы для камер, наушников и микрофонов.
Источник: Microsoft Learn: управление USB-устройствами через Intune
— Кроме USB где ещё чаще всего пересекаются мультимедиа и ИБ?
Очень быстро они встречаются в сети.
Room-система может быть полностью исправна и при этом нормально не работать из-за сетевых ограничений: firewall, сегментации, необходимых направлений доступа, настроек корпоративной инфраструктуры.
Например, для Teams Rooms Microsoft прямо указывает, что обязательные категории сетевых адресов и сервисов должны быть доступны через корпоративные firewall и другие security-устройства. Источник: Microsoft Learn: требования безопасности и сети для Teams Rooms
Поэтому разговаривать с ИБ полезнее не в формате: — Нам нужна ВКС, разрешите?
А предметно: где будет находиться оборудование, какие взаимодействия ему нужны, какие пользовательские устройства разрешены, как устроен гостевой доступ, что происходит при BYOD.
Тогда ИБ перестаёт быть последней инстанцией, которая появляется перед сдачей и внезапно что-то запрещает. Она становится участником архитектуры.
— Но если проверять разные ноутбуки, ИБ, гостей, внешние ВКС, резервные подключения — приёмка сама превращается в отдельный проект. Не перебор?
Если пытаться воспроизвести все события, которые теоретически могут когда-нибудь случиться, — конечно. Но это и не нужно.
Нужно выбрать несколько сценариев, которыми конкретная компания действительно пользуется. Обычное внутреннее совещание. Гибридная встреча. Корпоративный ноутбук. Гость со своим устройством. Демонстрация презентации. Внешняя ВКС.
Не двадцать экзотических тестов. Пять–семь реальных ситуаций.
Иногда их можно прогнать за час.И я бы предпочла потратить этот час во время сдачи, когда рядом находятся инженер и проектная команда, а не на совещании, где десять человек ждут, пока кто-нибудь разберётся, почему их не слышат.
— Вы несколько раз говорите о пользователе. Но где проходит граница? Может быть, человека просто нужно один раз нормально обучить?
Обучение нужно. Но я против инструкции как лекарства от неудобной системы. Тем более удобство вполне можно измерять.
В марте 2026 года МТС Линк опубликовал результаты собственного UX-тестирования сервиса «Встречи». В нём участвовали 350 человек, в том числе пользователи, впервые столкнувшиеся с сервисом.По данным компании, после редизайна рабочие сценарии стали выполняться в среднем на 68% быстрее, чем в прежней версии. Например, запуск демонстрации экрана сократился с 6,2 до 3,1 секунды, а приглашение участника по ссылке — с 29,5 до 12,2 секунды. Отдельно компания сообщает, что в сравнительном тесте с Zoom, Microsoft Teams и Google Meet скорость выполнения сценариев была в среднем выше на 41%. Это данные самого разработчика, поэтому я бы не превращала их в независимый рейтинг решений. Но сам подход очень показателен: пользовательский сценарий оценивают не словами «понятно или непонятно», а временем. Источник: МТС Линк: результаты тестирования пользовательских сценариев
С переговорной можно сделать ещё проще. Человек вошёл в комнату. Включите секундомер. Через сколько времени удалённый участник его увидел, услышал и встреча действительно началась?
И главное — не помогайте.
— Несколько лишних минут действительно стоят такого внимания?
Пять минут звучат мелочью, пока мы считаем время одного человека. Если на встрече восемь участников, пять потерянных минут — это уже 40 человеко-минут.
Четыре таких совещания — 160 минут. И внезапно вопрос «куда здесь нажать?» превращается из мелкого раздражения в измеримую потерю рабочего времени.
Мне кажется, это важный момент. Мультимедиа в этот момент перестаёт быть разговором про красивые экраны и удобные панели. Она становится частью производительности рабочего пространства.
— С подключением всё понятно. Но приёмка — это ведь ещё звук и видео. Как не превратить их проверку в формальность?
Самый формальный тест микрофона выглядит примерно так:
— Раз-раз. Слышно?
— Слышно.
— Отлично.
Я бы делала наоборот. Посадила людей туда, где они действительно будут сидеть. Человек с дальнего края стола говорит обычным голосом. Другой повернулся к экрану. Двое начали говорить одновременно.
И вопрос нужно задавать не инженеру, который стоит рядом с микрофоном. Нужно спросить удалённого участника:«Вас сейчас устраивает, как вы слышите людей в комнате?»
Здесь нам специально не нужен ещё один красивый кейс. Нужна простая проверка реальности.То же самое с камерой. Наличие изображения ещё не отвечает на вопросы: виден ли человек с крайнего места, что происходит у доски, как ведёт себя кадрирование, когда говорящих несколько. То есть принцип снова тот же: Мы проверяем не функцию устройства, а встречу, которая вокруг него происходит.
— А что насчёт отказа? Вы действительно предлагаете на приёмке что-нибудь отключать?
Да. Но тоже без театра катастроф. Достаточно убрать один элемент основного пользовательского сценария.
Например, недоступна беспроводная демонстрация.
Что делает пользователь? Есть ли понятный проводной вариант? Знает ли он о нём? Может ли перейти на него самостоятельно? Не конфликтует ли этот резервный вариант с корпоративными ограничениями?
Я здесь просто переношу на мультимедиа нормальную ИТ-логику: отказ одного элемента не должен автоматически означать отказ всей функции. И у меня есть простое правило: Резервный сценарий, о котором знает только инженер, для пользователя практически не существует..
— А если заказчик скажет: «Всё включается. Времени больше нет. Подписываем»?
Это вполне нормальное управленческое решение. Но тогда важно честно назвать результат.
Мы подтвердили техническую работоспособность оборудования. Или мы подтвердили работоспособность пользовательского сценария?
Это разные уровни проверки. Потому что после проекта бизнес не будет оценивать, выдаёт ли камера изображение или правильно ли работает коммутация.
Ожидание гораздо проще: человек вошёл, подключился, увидел и услышал участников, показал материалы и провёл встречу.
И именно здесь хорошо видно, куда вообще движется рынок. Чем глубже ВКС интегрируется с корпоративными сервисами и рабочими процессами, тем больше переговорная становится точкой, где одновременно сходятся мультимедиа, ИТ, ИБ и пользовательская среда. J’son & Partners прямо отмечает переход ВКС к роли компонента цифрового рабочего пространства и развитие интеграции с корпоративными сервисами.
А встреча у пользователя всё равно одна. Ему совершенно неинтересно, сколько разных систем пришлось объединить, чтобы она состоялась.
— Кто тогда должен участвовать в приёмке?
Не только мультимедийный инженер. Интегратор знает архитектуру решения. ИТ понимает корпоративную сеть, устройства и ВКС. ИБ — ограничения и политики безопасности.
Эксплуатация обычно задаёт самый неприятный, но очень полезный вопрос: «А нам с этим потом как жить?»
И я обязательно добавила бы ещё одного человека — пользователя, который эту переговорную раньше не видел. Инженер иногда слишком хороший тестировщик.
Он знает систему. Помнит, где какая кнопка. Уже видел все ошибки. А нам в этот момент как раз нужен человек, который ничего этого не знает.
Минимальный стресс-тест переговорной
Перед подписанием акта я бы проверила:
- Реальный корпоративный ноутбук с действующими политиками безопасности.
- Те модели и интерфейсы пользовательских устройств, которые действительно используются в компании.
- Человека, который раньше эту переговорную не видел.
- Звук и видео с реальных рабочих мест, а не рядом с оборудованием.
- Полноценную гибридную встречу с удалённым участником.
- Демонстрацию контента.
- Гостевой или BYOD-сценарий, если он предусмотрен.
- Подключение к внешней ВКС, если такие встречи проходят регулярно.
- Отказ одного элемента основного сценария и понятный резервный путь.
- Время от входа человека в комнату до нормального начала разговора.
Не каждая переговорная обязана проходить именно эти десять тестов. Главное правило проще: принимать нужно реальные сценарии конкретной компании, а не демонстрационный сценарий инженера.
— И последний вопрос. Что вы бы спросили перед подписанием акта?
Один вопрос:
Мы доказали, что оборудование работает — или доказали, что встреча состоится?
Потому что конечному пользователю неважно, насколько сложная инженерия находится за стеной. Он должен войти. Подключиться. Увидеть и услышать участников. Показать материалы. Провести встречу.
Всё. И в этом, пожалуй, главный парадокс хорошей мультимедийной системы: Чем сложнее она устроена внутри, тем проще должна быть жизнь пользователя снаружи.
Проверьте переговорную до подписания акта
Для публикации на сайте после интервью можно вынести отдельный практический блок: Скачать чек-лист стресс-теста переговорной.
Корпоративные устройства, ИБ-ограничения, гибридный сценарий, звук и видео с реальных мест, гостевой доступ, резервный путь и время запуска встречи.
Если проверка показывает, что технически исправная система не выдерживает реальный пользовательский сценарий, лучше разобраться с этим до ввода в эксплуатацию. Команда ВИЗАРД может подключиться к проверке вместе с ИТ, ИБ и эксплуатацией.
