Контрольный список планирования приложений Teams

  • Статья

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

Рассмотрим планирование жизненного цикла приложения с практической точки зрения.

Важные вопросы

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



Общие сведения о пользователе

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

# Фактор
1 Являются ли пользователи в основном сотрудниками без компьютеров, использующими мобильные клиенты?
2 Понадобится ли доступ к приложению большому количеству внешних пользователей?
3 Пользователи используют команды и каналы или главным образом групповые чаты?
4 Насколько технически развиты основные пользователи?
5 Требуется ли продуманный интерфейс для ознакомления пользователей с приложением, или будет достаточно нескольких подсказок?

Понимание проблемы
# Фактор
1 В чем заключаются преимущества и недостатки текущей системы, используемой пользователями?
2 Какие проблемы, испытываемые пользователями, вы собираетесь решить?
3 Какие функции и возможности существующего процесса больше всего нравятся пользователям?

Общие сведения об ограничениях приложения
# Фактор
1 В чем заключаются проблемы с интеграцией серверной части текущего приложения?
2 Кто владеет данными серверной части — собственная организация или сторонняя компания?
3 Существуют ли брандмауэры, влияющие на работу приложения?
4 Существуют ли API для доступа к данным, необходимым для работы приложения?

Предоставление проверки подлинности

Проверка подлинности подразумевает проверку пользователей приложения и защиту приложения и его пользователей от несанкционированного доступа. Для проверки пользователей, которые хотят использовать приложение Teams, можно воспользоваться методом проверки подлинности, подходящим для вашего приложения. Подробнее см. в статье Проверка подлинности пользователей в Microsoft Teams.

# Фактор
1 Будут ли пользователи получать доступ к разным представлениям данных в зависимости от своих ролей?
2 Используется ли контент клиента?
3 Будет ли взаимодействие также основываться на ролях пользователей?
4 Будут ли внешние пользователи обращаться к приложению?

Планирование процесса адаптации

Чтобы создать отличное приложение Teams, нужно найти правильное сочетание функций, которые удовлетворят потребности пользователей. Чтобы обеспечить удобное подключение для пользователей, можно создать пошаговые инструкции, в которых объясняется, как и что делать с приложением. Например, см. статью Создание разговорного бота Teams.

# Фактор
1 Что происходит, когда пользователь впервые настраивает вкладку в канале?
2 Если доступ к карточкам предоставляется с помощью расширения для сообщений, целесообразно ли добавить краткую ссылку на страницу дополнительных сведений, чтобы ознакомить пользователей с другими возможностями приложения?
3 Вы считаете, что у большинства пользователей уже есть представление о том, для чего предназначено ваше приложение? Пользователи уже использовали ваши службы в другом контексте?
4 Пользователи запускают ваше приложение без каких бы то ни было предварительных знаний?

Личные приложения область
# Фактор
1 Требуется ли индивидуальное взаимодействие с приложением в целях обеспечения конфиденциальности или по другим причинам? Например, для проверки оставшегося количества отпускных дней или других личных сведений.
2 Предполагается ли совместная работа пользователей, не входящих в состав Teams? Например, поиск предстоящих событий для всей организации.
3 Существуют ли персонализированные уведомления или сообщения, которые нужно будет отправлять пользователям через интерфейс приложения Teams?

Общие приложения область
# Фактор
1 Насколько релевантными и полезными для большинства участников команды являются сведения, представляемые приложением на вкладках или с помощью бота? Например, приложение Scrum.
2 Может ли контекст приложения изменяться в зависимости от команды, к которой добавлено приложение? Например, задачи планировщика различаются в разных командах.
3 Возможно ли, что все участники персоны, которым требуется совместно работать, входят в состав одной и той же команды? Например, агенты, работающие над запросом.

Выбор среды сборки

С помощью Teams вы можете выбрать среду сборки, которая лучше всего подходит для вашего приложения. Для начала используйте набор средств Teams или другие SDK, например, C#, Blazor, Node.js и другие. Подробнее см. в статье Планирование приложения с помощью функций Teams.

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


Планирование аналитики для приложения

Как разработчик, который создает приложение для миллионов пользователей Microsoft Teams для достижения конкретных бизнес-целей или целей клиентов и распространяет его с помощью одного или нескольких доступных вам вариантов распространения, вы заинтересованы в оценке производительности приложения в реальном мире после публикации. Вы также будете заинтересованы в отслеживании того, кто заинтересован в вашем приложении, какие пользователи и организации используют ваше приложение, как пользователи взаимодействуют с вашим приложением, какие пользователи отбились после использования вашего приложения в течение некоторого времени и много таких точек данных. Узнав это, вы можете проанализировать данные с учетом ваших бизнес-целей, принять меры по исправлению, исправив проблемы и вмешавшись в путь взаимодействия пользователя, или запланировать дальнейшие улучшения приложения.

Дополнительные сведения см. в статье Аналитика планирования.


Планирование тестирования приложения

После интеграции приложения с Microsoft Teams необходимо протестировать его перед публикацией. Конечная цель — привлечь как можно больше пользователей для приложения, поэтому обязательно протестируйте приложение на разных пользовательских устройствах. Подробнее см. в статье Тестирование приложения.

Предложение: параметры, помогающие определить наилучшую среду тестирования для приложения.


Планирование распространения приложений

Вы можете предоставить приложение Microsoft Teams отдельному пользователь, команде, организации или всем, кто хочет его использовать. Способ распространения зависит от нескольких факторов, включая потребности пользователей, бизнес-требования, технические требования и цели приложения. Подробнее см. в статье Распространение приложения Microsoft Teams.

Предложение: параметры, помогающие определить наилучшую модель распространения.


Планирование уведомлений приложений

Вы можете отправлять уведомления пользователям Teams несколькими способами. Уведомления — это простой способ регулярного привлечения пользователей. Дополнительные сведения см. в статье Планирование отправки уведомлений приложений.

Планирование размещения приложения Teams

Ваше приложение не размещается в Teams. Когда пользователь устанавливает приложение в Teams, он устанавливает пакет приложения, содержащий только файл конфигурации (также известный как манифест приложения) и значки приложения. Логика приложения и хранилище данных размещаются в другом месте, например в localhost во время разработки и в веб-службах Azure. Teams получает доступ к этим ресурсам с помощью HTTPS.

Иллюстрация размещения приложения Teams.

Планирование этапов после сборки приложения

  • Определите, какие функции будут реализованы в Teams: будь то новое приложение или существующее, проверьте, должно ли все приложение работать внутри клиента Teams. Если следует интегрировать только часть приложения, обратите наибольшее внимание на рабочих процессах общего доступа, совместной работы, инициализации и мониторинга.

  • Планирование интерфейса ознакомления с приложением: интерфейс ознакомления с приложением должен быть ориентирован на основных пользователей приложения. Реализация чат-бота в канале с тысячей пользователей отличается от реализации чат-бота в индивидуальном чате.

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

См. также