Догмы и Практика

Вы готовы узнать что SharePoint это на самом деле скин для 1С портал с расширениями от ФСБ для сбора корпоративной информации? Хм. Кажется я не успел пошутить на эту тему первого апреля — теперь надо ждать год. Зато от идеи шутки (скорее не очень удачной) родилась замечательная идея рассказать вам о Догмах SharePoint на примере замечательной статьи Folders are bad and other urban legends.

Автор статьи, Paul Culmsee, поставил простой эксперимент. Он задал SharePoint разработчикам два вопроса.

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

  1. У нас с технической точки зрения паршивое решение, оно работает и офигенно нравится пользователям. Они активно его используют и довольны.
  2. У нас великолепное архитектурное решение, соответствует рекомендациям и книгам экспертов. Сам Билл любит эту архитектуру. Но пользователи ненавидят ваше решение, практически никто им не пользуется.

Как ответил я, мои знакомые и опрошенные упомянутой выше статьи — практически исключающее большинство выбирает первый вариант. Разумно и практично. Теперь небольшая пауза, расслабились, забыли первый вопрос, посмотрел на улицу — весна, девочки/мальчики, вспомнили любимое слово паттерны, производительность, архитектура, утечки памяти, бардак, юзеры (последние 5-7 слов повторить). Вспомнили как вас задрали эти уроды-пользователи (ну практически все ИТ-шники так считают).

Так — вы готовы. 

Вопрос 2. Какое архитектурное решение вы примите зная специфику среды проекта.

  1. Решение по хранению документов строим на основе контент типов — metadata-based подходе. Мы правильно разрабатываем набор атрибутов, представлений на основе группировок атрибутов, фильтров и тп. Тысячи документов разбросаны по контент типам, все атрибуты будут заполнены при переносе и пользователи должны будут заполнять все атрибуты при работе. Но вы знаете что это вызовет массовую волну недовольства и в связи со спецификой проекта таким решением будут значительно меньше пользоваться чем следовало.
  2. Решение по хранению документов строим на основании простого переноса привычного набора папок и подпапок в которых пользователи хранят своим тысячи своих документов и добавляют десятки документов в день. Эта модель работы привычна для большинства пользователей и они будут гарантированно этим пользоваться.

А вот тут вы как минимум мечетесь между вариантами. А если бы мы сразу задали этот вопрос без преамбулы?

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

  • Зона комфорта пользователей лежит в плоскости привычной работы с документами в папках. Но это неверная информационная модель.
  • Предлагаемая правильная информационная модель содержит не до конца отточенные интеграционные решения. Что мешало этому противному Microsoft-у и этим ИТ архитекторам из Редмонда сделать представление в виде папок в Windows Explorer и диалогах при работе с библиотеками SharePoint? Что мешало этим умным людям не ограничивать так грубо количество вложенности в группировках?  Мы умны задним числом — но эти usability flaws ставят под риск жизнеспособность ключевых архитектурных решений

Мораль вопроса такова.

  • Экосистема в которую вы помещаете вашу архитектура должна принять изменения и решение. Если вся система против — меняйте архитектуру иначе системы выплюнет вас с вашим идеальным SharePoint решением на помойку.
  • Не сдавайтесь. Постепенно меняйте культуру и меняйте вместе с ней поэтапно решение. Да — это затратно. Но в лоб вы получите больно по лбу. Терпение, малые шаги, последовательность.

Задайте и себе эти вопросы и задумайтесь!

  • Ivan_padabed

    или расширьте стандартные возможности SharePoint для поддержки эксплорерообразной структуры папок и настройте автозаполнение метаданных по свойствам документа :) как делают наши заказчики

  • Аноним

    Иван, спасибо!

    Абсолютно согласен что можно и нужно применять такие подходы! Но если посмотреть в общем — то проблема остается.