Проблема. Аналитики чрезвычайно любят упорядочивать — и это верно. Когда это переносится на все-все моменты в разработке решения — возникает антипаттерн негибкой системы — когда количество ограничений, количество предписанных полей и строгость процессов начинают со временем хоронить систему. Ведь в реальности все сложнее, реальность меняется, приходят новые люди — и красивая стройная система уже видится как бремя. В этой проблеме заложен известный конфликт между процессным подходом process management, (BPM) и case-подходом (case-management
Проявления
- Большое количество полей
- Большое количество обязательных полей
- Строго определенные сценарии взаимодействия
- Все сценарии связаны в последовательность процессов
Причины
- Глубинная причина — все сложные и сильно упорядоченные системы априори ущербны перед стратегическими рисками и слабо устойчивы перед новыми системными вызовами
- Страсть аналитика все прописать, зафиксировать все сценарии и проконтролировать все действия пользователей
- стремление заказчика к тотальному контроль
- Невозможность проанализировать все исключительные сценарии
- Изменения внутреннего порядка или внешнего законодательства
- Наличие нелегальных сценариев
Рекомендации по уменьшению проблемы:
- Выбирать гибкую платформу для разработки системы — на такие принципах строятся современные BPM и CASE платформы
- Давать возможность выбирать между строгим подходом и свободным ручным управлением процессом — это надо закладывать в сам процесс
- Проверять бритвой количество полей и обязательных полей, создавать для дополнительных полей динамические списки
- Давать возможность пользователю выбирать следующую последовательность действий (именно так решены вопросы гибкого построения маршрутов в документообороте)
- Дать возможность пользователю дополнять данные новыми полями, тэгами, создавать свои классификаторы (плавно стремится к нирване ORM)
- Стараться разбить систему на компоненты и не строить изначально монолит
- Четко определять интерфейсы взаимодействия между компонентами системы, делать их слабо связанными
- Выбрать с архитекторами базы данных которые позволяют динамически менять структуру контента и записей
Когда это может быть допустимым
- Когда система позволяет быстро клонировать сценарии и формы и на лету их менять
- Когда пользователи смогут оперативно адаптировать решение
- Когда цена модификации ниже цены ошибки изза слабой строгости в сценариях
PS. У любой деятельности есть свои положительные и отрицательные моменты. Умение держать баланс от одного края к другому — это искусство. Особенно потому что понимание отрицательных эффектов — это риски. И самые сложные из них — это глобальные риски, Черные лебеди — будут стоить настолько дорого, что достигнутые оперативно положительные эффекты будут похоронены под пеплом разваливщейся системы.
