. Создание фундамента включает в себя:

  • идентификацию и планирование рисков;
  • создание тестового стенда;
  • сбор данных;
  • документирование требований и другой важной информации;
  • формирование единого мнения.

Важно, чтобы члены команды активно принимали участие во всех описанных шагах. В противном случае они не разберутся в проекте, и вы рискуете столкнуться с активным сопротивлением на стадии закрытия проекта. Дополнительная информация о командах разработчиков архитектуры SharePoint приведена в статье «Проектирование архитектуры SharePoint», опубликованной в этом же номере журнала.

Идентификация и планирование рисков

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

Система SharePoint – это в первую очередь многофункциональный репозиторий, предназначенный для совместного использования корпоративной информации. Ценность системы для организации и риски несоответствия юридическим требованиям напрямую связаны с содержимым репозитория, аудиторией и уровнем доступа к содержимому, которым обладает аудитория. Если ваша организация планирует использовать функциональность системы SharePoint по управлению документами, могут возникнуть осложнения с управлением учетными записями. Более того, когда на весах лежат вопросы соответствия юридическим требованиям, то в случае если система SharePoint не соответствует критериям аудита, ваша организация рискует показать себя не в лучшем свете.

Уровень планирования рисков зависит от истории выполнения проектов в вашей компании. Например, последние пять проектов были успешными? Почему? Чтобы минимизировать возможность ошибки, подобное обсуждение необходимо провести с несколькими членами команды.

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

  • имя или описание риска;
  • имя человека, описавшего риск;
  • вероятность проявления (высокая или низкая);
  • влияние (сильное или умеренное);
  • как риск проявляет себя.

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

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

Создание стенда

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

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

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

 

Компоненты стенда SharePoint

Сбор данных

Имея готовый стенд, можно начинать сбор данных, которые помогут вам обосновать архитектурные решения, подготовленные в процессе проектирования. В таблице 2 приведены ключевые действия по сбору данных, итерационные по своей природе. Имейте в виду, что я использовал подход, предусматривающий два плана: план A и план B. План A – это идеальный подход, который при прочих равных даст лучшие результаты. План B содержит минимальную необходимую информацию и предполагает определенные допущения.

 

Основные действия по сбору данных

Не стоит ожидать, что все данные будут собраны сразу. В зависимости от размеров, сложности и «прозрачности» вашей организации на сбор могут уйти месяцы.

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

Документирование требований и другой важной информации

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

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

Формирование единого мнения

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

В качестве аналогии для данной ситуации я предлагаю слои луковицы. Снимая слой за слоем, вы узнаете больше, а, следовательно, можете вступать в дискуссии и более подробно документировать требования. Такой подход очень полезен, ведь вы никогда не получите всю необходимую информацию на первом проходе. Сколько же слоев у луковицы? Это зависит от объема изначально доступной информации, навыков и знаний членов вашей команды, а также корпоративной культуры. Обычно выделяют три слоя:

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

Следующий шаг

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