Microsoft Teams за неделю: три организации, один sprint

Когда Microsoft объявила, что открывает Teams бесплатно на полгода, нам прилетело сразу три запроса за два дня. Все три клиента находились примерно в одинаковой ситуации: Zoom уже запрещён или под вопросом, что-то мессенджерное нужно прямо сейчас, и «а Teams - это ведь то, за что мы уже платим в M365?». Последний вопрос задавали с разной степенью уверенности, но ответ одинаковый: да, если у вас Business Premium или E3/E5 - Teams уже в лицензии, просто не был включён.

Неделя вышла насыщенная. Разворачивали параллельно, с небольшими сдвигами по дням. Фиксируем что нашли.

Точка входа: Teams Policies

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

Что проверяем в первую очередь:

• Meeting policies. Кто может записывать встречи, куда сохраняются записи (по умолчанию - Microsoft Stream, но это нужно явно проверить), разрешено ли участникам без аккаунта Teams подключаться к звонкам. Последний пункт - частая ловушка: анонимное участие включено по умолчанию, что в корпоративном контексте обычно нежелательно.
• Messaging policies. Возможность удалять и редактировать сообщения, Giphy и сторонние стикеры. Звучит несерьёзно, но политика допустимого использования корпоративного мессенджера должна это регулировать.
• App permission policies. Сторонние приложения из Teams App Store - по умолчанию пользователи могут их устанавливать самостоятельно. Это нужно ограничить или полностью закрыть для большинства корпоративных сценариев.
• External access. Федерация с другими организациями в Teams - отдельная история, разберём ниже.

Все три клиента получили базовый набор политик через PowerShell-скрипт Teams Admin Center. Ручная настройка через GUI болезненна - там кнопочки и вкладочки, а нам надо воспроизводимо и документируемо.

DLP: корпоративный мессенджер это тоже канал утечки

У двух из трёх клиентов действуют политики DLP (Data Loss Prevention) - они уже настроены для Exchange и SharePoint через Microsoft 365 Compliance Center. Частая ошибка: считать, что DLP автоматически применяется к Teams. Это не так.

Teams DLP - отдельная настройка, и на момент развёртывания она уже поддерживается в M365, но нужно явно включать. Что важно:

• DLP в Teams работает на уровне сообщений в каналах и личных чатах (1:1 и групповые). Но только для обмена текстом и файлами через Teams - если человек сделал скриншот и отправил картинкой, классический DLP это не поймает.
• Политики нужно создавать с понимаем какие данные реально ходят через мессенджер. У одного клиента - персональные данные сотрудников (HR-канал), у другого - детали сделок (отдел продаж). Под каждый сценарий - свой профиль.
• Нотификации пользователям при срабатывании политики: настраиваем так, чтобы блокировка сопровождалась понятным объяснением, а не просто ошибкой «нельзя».

DLP по факту это один из аргументов в пользу Teams перед сторонними мессенджерами - интеграция с M365 Compliance Center позволяет держать корпоративный мессенджер внутри той же политики, что и почта и документы.

Федерация с внешними организациями

Один клиент - строительная группа - работает с десятком подрядчиков, и все хотят созваниваться в Teams. Тут включается External Access (федерация) и Guest Access - это разные вещи, которые часто путают.

External Access - это федерация между двумя организациями в Teams. Пользователи из другой организации могут найти вас в поиске и позвонить, не становясь гостями. Никаких каналов, только звонки и чаты 1:1. Настраивается в Teams Admin Center, по умолчанию открыто для всех доменов Microsoft 365 - что нужно ограничить до конкретного whitelist.

Guest Access - приглашение внешнего человека в команду (Team) как гостя. Гость видит каналы, файлы, историю. Это более широкий доступ, и он требует явной политики: кто может приглашать гостей, в какие команды, на какой срок.

Для строительного клиента: внешний доступ ограничили тремя доменами подрядчиков, Guest Access включили только для конкретных команд-проектов с явным согласованием. Это не идеальная схема - ручное управление списком гостей утомительно на больших масштабах, но для их размера пока рабочая.

Обучение пользователей: самая недооценённая часть

Три клиента - три разных уровня готовности аудитории. Один клиент уже частично использовал Teams для звонков. Другой переходил с Skype for Business (там отдельная история с миграцией политик). Третий вообще не имел корпоративного мессенджера - только почта и телефон.

Что работает:

• Не пытаться обучить всему сразу. Люди в карантине и так перегружены. Делаем материал на один лист A4: как зайти, как создать встречу, как прикрепить файл. Всё.
• Видеозапись короткого демо (10-15 минут) по основным сценариям - для тех, кто предпочитает смотреть, а не читать. Записывали прямо в Teams, что само по себе демонстрировало инструмент.
• Чат поддержки внутри Teams. Сделали канал #it-helpdesk в каждой организации - вопросы по Teams задают там же, в Teams. Рекурсия полезная: человек, который пишет вопрос в инструменте, уже умеет его использовать хотя бы минимально.

Сложнее всего шло у третьего клиента - где не было вообще никакой культуры корпоративного мессенджера. Там первые три дня половина вопросов поддержки была «а зачем это вообще, мы же можем позвонить по телефону». Переключение происходит, когда люди обнаруживают конкретную задачу, где Teams удобнее - обычно это совместное редактирование документа прямо из чата.

Что не успели

На этапе первичного запуска осознанно отложили несколько вещей. Информационные барьеры (Information Barriers) - для клиентов с требованиями о разделении отделов - требуют отдельной проработки, там архитектура нетривиальная. Интеграция Teams Phone (облачная АТС) - у одного клиента в плане, но телефония не горит так как видеозвонки. Автоматизация жизненного цикла команд - сейчас команды создаются вручную, потом разберёмся со скриптами и политиками именования.

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