Кто так строит?

Есть ли формализованный алгоритм поведения пользователей и, особенно, администраторов?

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

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

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

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

Как реализуют ИС? Подавляющее число проектов таких систем являются индивидуальными. Поэтому сначала проектируют, потом проводят экспертизу и начинают реализацию и внедрение. Все как положено. Только в России очень часто (если не всегда) все три этапа выполняются одним субъектом. Системным Интегратором (он же проектировщик, он же эксперт, он же генеральный подрядчик, он же разработчик, он же поставщик). Чувствуете разницу?

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

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

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

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

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