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

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

Стремление к универсальности не обходит стороной и область создания программного обеспечения. Аналитики хотят создавать универсальные требования, архитекторы стремятся к созданию универсальной архитектуры, программисты тяготеют к универсальным компонентам, а дизайнеры - к универсальным пользовательским интерфейсам.

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

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

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

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

Прямая ответственность за излишнюю увлеченность команды игрой в универсализм, за наличие плохих требований лежит на двух персонах (точнее - ролях): руководитель проекта и аналитик. Им никогда нельзя терять связь с реальностью. Они должны твердо стоять на земле и просвещать остальных разработчиков об истинных целях проекта. И ПМ, и аналитик должны постоянно напоминать команде, что заказчику необходим простой воздушный шар для перемещения из точки А в точку В, а не универсальный летательный аппарат в диапазоне от ковра-самолета до межгалактического корабля.

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

Сергей РУБАНОВ,
учебный центр ЗАО "БелХард Групп",
преподаватель бизнес-анализа,
ba.it-strana.by