Определение бизнес требований для развертывания приложений

Рассмотрим подробнее документ описывающий бизнес требования. За основу возьмем все тот же Scope and Vision из Software Requirements (3 edition) by Karl Wiegers and Joy Beatty. Что же в нем писать?

1. Business requirements

Бизнес требования — это первые(главные) требования к продукту. Если цели неясны и нет определенных ожиданий от продукта, то данный документ написать будет очень сложно. Очень часто заказчики и спонсоры думают, что “все итак ясно” и делать его не надо, но это ошибка, которая потом будет стоить очень дорого (потому что все остальные требования полагаются на бизнес требования).

При этом, действительно, скорее всего не все аспекты продукта будут покрыты данным документом и после определения бизнес требований могут (и это нормально) оставаться неточности и неясности. Таким образом, этот документ поможет структурировать бизнес требования, определить цели, риски, ожидания и ограничения к проекту. Также документ поможет выявить противоречия в требованиях, так как очень часто бизнес требования диктуются несколькими людьми.

1. 1. Background (предпосылки)

Здесь пишем про то, как появилась идея создать продукт (контекст). Кто, почему и при каких условиях придумал продукт? Очень хорошо полагаться на исследования и статистику, если имеются.

1. 2. Business opportunity (бизнес возможности)

Описываем бизнес проблему и рынок на которой существует эта проблема. Если проблем нет, то описываем бизнес возможности(и новшества), которые предоставит продукт (опять же основываясь на рынке). Это и преимущества продукта, уникальные решения и способы удовлетворения нужд пользователей.

1. 3. Business objectives (бизнес цели)

Описание выгоды для бизнеса в качественных и количественных показателях. Это должны быть цели продукта, которые можно оценить и/или измерить.

1. 4. Success metrics (метрики успеха)

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

1. 5. Vision Statement (видение)

Описание долгосрочных целей. Сбалансированное мнение всех заказчиков и заинтересованных лиц. В книге предлагается следующий паттерн:

• Для [целевая аудитория продукта]
• Которая [описание нужд и возможностей]
• [Название продукта]
• Это [Категория продукта]
• Который [основные возможности, ключевые выгоды, причины купить или использовать]
• В отличие от [предыдущие альтернативы, текущая система, текущий бизнес процесс]
• Наш продукт [преимущества нового продукта в сравнении с текущими и альтернативами].

Для* одиноких женщин, *которые* нуждаются в любви и ласке, представляем решение *котик*. Котик — это такое домашнее *животное*, *которое* помогает справиться со злостью лучше всех, он будет ласкать вас, играть с вами и просто радовать глаз. *В отличие от* мужчины, которому нужно готовить свежую еду и периодически стирать носки, *котик* будет кушать готовую еду (продается практически в каждом магазине), ему не надо стирать одежду (достаточно его мыть раз в полгода). А еще котик не играет в танки!

1. 6. Business risks (риски)

Опасения, проблемы и все плохое, что можно ожидать.

1. 7. Business assumptions and dependencies (предположения и зависимости)

Здесь записываются предположения, сделанные заинтересованными лицами, но не имеющие подтверждения, и зависимости от внешних факторов (законодательство, third party приложения и прочее).

2. Scope and limitations (объем и ограничения)

Описание того, что должно быть сделано и, чего НЕ должно быть.

2.1. Major features (главная функциональность)

Пишем основные логические части продукта. Не забываем привлекать экспертов команды и заинтересованных лиц в это дело.

2.2. Scope of initial release (допустимый минимум или объем первоначальных работ)

Говорящий сам за себя заголовок или Глава 5 книги из первого поста.

2.3. Scope of subsequent releases (объем последующих работ)

План. Всегда нужен план. Здесь он будет примерный, но нужен. Проектный менеджер поможет, определенно.

2.4. Limitations and exclusions (ограничения и исключения)

Список того, что хочется, но по каким-то причинам не будет сделано в запланированные версии. Так называемое “out of scope”.

3. Business context (бизнес контекст)

Здесь фиксируем лица и даты, чтобы никто не убежал , чувствовал свой вклад и понимал когда наступит время Х 🙂

3.1. Stakeholdes profiles (заинтересованные лица)

Описание заинтересованных лиц. Для всех заполняем адреса, пароли, явки. Очень хорошо еще сюда зоны ответственности и доступность записать. Заинтересованные лица могут быть ключевыми и нет.

3.2. Project priorities (приоритеты)

Описываем последовательность действий(и действия) и все, что с этим связано. Функциональность, качество, план, стоимость и персонал. Эти приоритеты должны быть согласованы.

3.3. Deployment considerations (особенности развертывания)

Информация об активностях, которые необходимы для развертывания приложения. Доступы, логины, временные зоны, информация о сети, хранилищах. Все, что нужно для развертывания.

1. Всегда помните, что бизнес требования, это не требования к системе, поэтому избегайте упоминания технических и дизайн деталей.
2. Если вам выпала честь самому определять структуру документа, то подумайте какие пункты вам нужны, а какие нет. Здесь представлен пример, вы вправе его адаптировать к своей суровой реальности.
3. Бизнес требования нужны. И да, можно работать и без них, но будут “НО”.

Источник: medium.com

Как разработать
бизнес-требования

Давайте поговорим о том, откуда берутся требования. И бизнес-требования (БТ), и нефункциональные требования напрямую вытекают из потребностей бизнеса.

Напомним, что нефункциональные требования (НФТ) определяют свойства, которые система должна демонстрировать, или ограничения, которые она должна соблюдать, не относящиеся к поведению системы. Например, производительность, удобство сопровождения, расширяемость, надежность, факторы эксплуатации.

Из бизнес-требований, помимо функциональных (ФТ) и нефункциональных требований, напрямую могут вытекать ещё и требования причастных сторон. В свою очередь, из требований причастных сторон могут вытекать ФТ и НФТ.

Культурные образцы — это те требования, которые можно получить на основе стороннего опыта. То есть, изучая какой-то аналогичный готовый продукт на рынке, мы можем сформировать требования к своему продукту (даже если эти требования никто из стейкхолдеров не озвучивал напрямую).

Все виды требований возникают в конкретном контексте, то есть следуют из Операционного контекста, к которому относятся активы, спрос, технологии и так далее. Подробнее про влияние контекста на бизнес-требования смотрите в статье Бизнес-требования. Назначение.

В наглядном виде модель выявления требований представлена на схеме:

Источник: systems.education

Определение бизнес-требований для SharePoint и OneDrive

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

Рекомендации по сбору требований

Определите пути взаимодействия пользователей и основные варианты использования. Как теперь работают пользователи вашей организации? Где хранятся файлы? Как они обмениваются новостями и другой информацией? Важной частью планирования sharePoint и OneDrive является документирование того, как ваша организация выполняет задачи совместной работы в настоящее время.

Затем эти задачи можно сопоставить с новыми процессами с помощью SharePoint и OneDrive. Затем эти задачи могут стать тест-случаями для первоначального пилотного развертывания. Сведения о том, как Microsoft 365 повышает производительность в разных отраслях, см. в библиотеке производительности.

Оцените свои потребности в миграции. Большинство организаций имеют файлы и другое содержимое, которое они хотят переместить в Microsoft 365. Некоторые из этого содержимого могут ежедневно использоваться сотрудниками вашей организации. Перемещение всего этого может занять время.

Планируя развертывание, планируйте, как можно переносить содержимое, сохраняя при этом эффективность работы сотрудников в организации. Дополнительные сведения см. в статье Планирование миграции для Развертывания SharePoint и OneDrive . Если вы используете локальный сервер SharePoint Server, см. статью Гибридное хранилище OneDrive и SharePoint в Microsoft 365. Если у вас есть записи на бумаге для импорта, см. статью Общие сведения о Microsoft SharePoint Syntex.

На ранних этапах привлекайте команды по вопросам законодательства и соответствия требованиям. Большинство организаций имеют юридические требования или требования к соответствию, определяющие, как они обрабатывают различные типы данных. Microsoft 365 предлагает множество вариантов, которые помогут вам обеспечить соответствие требованиям в организации. При планировании развертывания на ранних этапах обратитесь к группе юристов или специалистов по обеспечению соответствия требованиям, чтобы обеспечить соответствие требованиям при переходе на SharePoint и OneDrive. Дополнительные сведения см. в статье Создание соответствующей среды SharePoint и OneDrive .

Достижение согласия между заинтересованными лицами. Обеспечение участия и поддержки ключевых пользователей в вашей организации имеет решающее значение для успешного принятия пользователями. Эту поддержку могут получить руководители, ориентированные на бизнес, ИТ-руководство или кто-либо еще, кто заинтересован в том, чтобы Microsoft 365 преуспел в организации. Важно иметь поддержку как руководителей, так и бизнес-лидеров, а также лидер продукта, который помогает передавать знания своим коллегам. Независимо от того, назначаете ли вы пользователю роль «Лидер продукта» или позволяете ему расти органически, лидеры имеют решающее значение для принятия пользователями.

Основные варианты использования SharePoint и OneDrive

Основные варианты использования SharePoint и OneDrive:

• Хранилище файлов
• Совместная работа над файлами
• Сайты для совместной работы группы
• Сайты новостей и интрасети

Если в настоящее время вы используете другое программное обеспечение или службы для включения этих вариантов использования в своей организации, мы рекомендуем сопоставить каждый из ваших текущих вариантов использования с возможностями SharePoint и OneDrive. Это поможет обеспечить плавный переход при развертывании SharePoint и OneDrive и предоставить список изменений процесса для взаимодействия с пользователями. (Обучение и управление изменениями для развертывания SharePoint и OneDrive предоставляет список ресурсов, которыми вы можете поделиться с пользователями, чтобы помочь им приступить к работе с SharePoint и OneDrive.)

В следующих разделах представлен обзор этих вариантов использования со ссылками на более подробные сведения.

Хранилище файлов

Варианты хранения файлов в Microsoft 365 : SharePoint и OneDrive.

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

Общие файлы хранятся в SharePoint. Сайты SharePoint можно использовать для хранения файлов, к которым будут обращаться несколько пользователей. Люди, у которых есть доступ к сайту, имеют доступ к файлам.

Microsoft Teams использует сайты SharePoint для хранения файлов. При отправке файла на вкладку Файлы Teams он сохраняется на сайте SharePoint. (Дополнительные сведения о взаимодействии Teams и SharePoint см. в статье Обзор интеграции Teams и SharePoint)

Совместная работа над файлами

В SharePoint и OneDrive для создания и редактирования документов пользователь может использовать Приложения Microsoft 365 (версия Office, доступная во многих планах Microsoft 365). Другие приложения можно использовать для создания и редактирования файлов других типов. Эти файлы можно легко предоставить другим пользователям, включая людей за пределами вашей организации (если это разрешено).

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

Совместная работа на сайте или в команде. На сайте SharePoint или в команде Microsoft Teams все участники сайта или команды имеют доступ к файлам, хранящимся на нем, и могут легко работать над ними.

Совместное использование файлов SharePoint с помощью общих ссылок. Если пользователю нужно поделиться файлом SharePoint с кем-то за пределами сайта или команды, он может использовать общие ссылки так же, как в OneDrive.

Синхронизация файлов для автономного доступа. С помощью приложения приложение синхронизации OneDrive пользователи могут синхронизировать файлы между компьютером и облаком Microsoft 365. Когда пользователи добавляют, изменяют или удаляют файл или папку локально, файл или папка добавляются, изменяются или удаляются в облаке и наоборот. Пользователи могут работать с синхронизированными файлами непосредственно в проводник или Finder и приложениях, которые они используют. Когда пользователь находится в сети, все изменения, внесенные им или другими пользователями, будут автоматически синхронизированы.

Intranet

Одна из основных возможностей SharePoint — это широкий спектр возможностей и средств для создания сайтов интрасети для организации. Ваша интрасеть может включать главную целевую страницу вашей организации, порталы для корпоративных коммуникаций и отдельные сайты для отделов или подразделений (например, ИТ или отдела кадров).

Перемещение интрасети в SharePoint в Microsoft 365 может занять некоторое время, особенно если у вас уже есть обширное содержимое интрасети. Мы рекомендуем выполнить эту задачу после завершения развертывания SharePoint и OneDrive.

Управление и соответствие требованиям

Управление и соответствие требованиям являются ключевыми для многих организаций. В рамках планирования sharePoint и OneDrive необходимо заранее определить, какие функции соответствия требованиям необходимо развернуть заранее. Заранее установив функции соответствия требованиям, вы можете снизить риск инцидентов соответствия требованиям. Дополнительные сведения о функциях соответствия требованиям, которые следует учитывать при развертывании SharePoint и OneDrive, см. в статье Создание совместимой среды SharePoint и OneDrive .

Условия успешного внедрения

Внедрение пользователем важно для общего успеха любого нового приложения или службы. В идеале, чтобы почувствовать, что вы максимально влились в SharePoint и OneDrive, необходимо максимально повысить вовлеченность пользователей с ними.

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

Дополнительные сведения о внедрении пользователей и управлении изменениями при развертываниях SharePoint и OneDrive см. в статье Обучение и управление изменениями для развертывания SharePoint и OneDrive.

Источник: learn.microsoft.com