Антипаттерн: Гиперупорядочивание и гиперструктурирование

Проблема. Аналитики чрезвычайно любят упорядочивать – и это верно. Когда это переносится на все-все моменты в разработке решения – возникает антипаттерн негибкой системы – когда количество ограничений, количество предписанных полей и строгость процессов начинают со временем хоронить систему. Ведь в реальности все сложнее, реальность меняется, приходят новые люди – и красивая стройная система уже видится как бремя. В этой проблеме заложен известный конфликт между процессным подходом process management, (BPM) и case-подходом (case-management

Проявления

  • Большое количество полей
  • Большое количество обязательных полей
  • Строго определенные сценарии взаимодействия
  • Все сценарии связаны в последовательность процессов

Причины

  • Глубинная причина – все сложные и сильно упорядоченные системы априори ущербны перед стратегическими рисками и слабо устойчивы перед новыми системными вызовами
  • Страсть аналитика  все прописать, зафиксировать все сценарии и проконтролировать все действия пользователей
  • стремление заказчика к тотальному контроль
  • Невозможность проанализировать все исключительные сценарии
  • Изменения внутреннего порядка или внешнего законодательства
  • Наличие нелегальных сценариев

Рекомендации по уменьшению проблемы:

  • Выбирать гибкую платформу для разработки системы – на такие принципах строятся современные BPM и CASE платформы
  • Давать возможность выбирать между строгим подходом и свободным ручным управлением процессом – это надо закладывать в сам процесс
  • Проверять бритвой количество полей и обязательных полей, создавать для дополнительных полей динамические списки
  • Давать возможность пользователю выбирать следующую последовательность действий (именно так решены вопросы гибкого построения маршрутов в документообороте)
  • Дать возможность пользователю дополнять данные новыми полями, тэгами, создавать свои классификаторы (плавно стремится к нирване ORM)
  • Стараться разбить систему на компоненты и не строить изначально монолит
  • Четко определять интерфейсы взаимодействия между компонентами системы, делать их слабо связанными
  • Выбрать с архитекторами базы данных которые позволяют динамически менять структуру контента и записей

Когда это может быть допустимым

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

PS. У любой деятельности есть свои положительные и отрицательные моменты. Умение держать баланс от одного края к другому – это искусство. Особенно потому что понимание отрицательных эффектов – это риски. И самые сложные из них – это глобальные риски, Черные лебеди – будут стоить настолько дорого, что достигнутые оперативно положительные эффекты будут похоронены под пеплом разваливщейся системы.