и такое: "большинство неплохих информационных проектов просто не реализуется и только малая толика их доходит до массового пользователя". Насколько это положение типично для России и является ли политика единственной причиной того, что хорошие, на первый взгляд, проекты, не находят применения?
Прежде всего, что такое безнадежный проект? Используя определение, данное Эдом Йорданом - известным специалистом в области теории и практики программирования, это проект, имеющий отклонение от нормы как минимум на 50%. Срок разработки сжат в два раза или людских ресурсов в два раза меньше, чем требуется (такие ситуации часто возникают вследствие иллюзорных представлений о возможностях современных инструментальных средств - никакие новые языки или CASE-оболочки не заменят программисту квалификацию); предусмотренный бюджет на 50% меньше реально необходимого; завышен в два раза ожидаемый "профит" от выполнения проекта (производительность, мощность, емкость и т.п.)...
Некоторое время назад в американской прессе всерьез обсуждался проект пилотируемого полета на Марс с запасом еды и воды для экипажа на 40 лет, но без топлива на обратный путь. Этот пример - весьма красноречивая иллюстрация безнадежных проектов.
На такие проекты можно смотреть по разному: амбициозные заявки менеджеров - "синдром Эвереста", возможность поучиться за счет заказчика (очень типичная ситуация для России, где еще недостаточно развит консалтинг и много компаний, готовых сделать все самостоятельно и сразу). Недальновидные старшие менеджеры и наивные пользователи. Менеджеры, в прошлом обычно сами разработчики, оказавшись не на своем месте, за год-два теряют представление о реальном состоянием дел и часто перестают ориентироваться в тенденциях развития ИТ. В то же время предыдущий опыт и практические знания, приобретенные, например, в ходе работы над проектом для мэйнфреймов с алфавитно-цифровыми терминалами, зачастую оказываются ненужными для проекта создания современного мультимедийного комплекса.
Если все так понятно, то в чем причины появления безнадежных проектов?
О политических причинах уже много говорилось, в частности на Форуме. Можно лишь добавить, что существуют не только внешние (по отношению к проекту это политические амбиции, например, диктат чиновников относительно правил распространения систем криптографии), но и внутренние причины: личные цели менеджеров или внутрикорпоративная борьба между подразделениями компании. К этой же группе можно отнести и требования "хозяина" проекта, желающего, например включить в проект ненужную по сути дела фирму-посредника, настаивающую на использовании только определенной технологии и инструментов или на "усилении" коллектива разработчиков на самом деле просто не пристроенными к другим проектам людьми.
Много невыполнимых проектов рожается вследствие раздачи менеджерами по продажам направо и налево необоснованных обещаний, неподкрепленных реальными возможностями компании. Это столь же типичная, сколь и вредная для России, особенность многих "шустрых" компаний, на заре информационного бума именовавших себя системными интеграторами или разработчиками комплексных решений "под ключ". Мало того, что многие из этих компаний сегодня просто "вылетели в трубу", они еще создали у заказчиков стойкий иммунитет против внедрения у себя компьютерных технологий: "А, вы системные интеграторы (консультанты), знаем, знаем, перебывало их тут до вас их уже немало - никто реально ничего не сделал для автоматизации нашего бизнеса".
Для появления заведомо проигрышных проектов существует также и ряд чисто рыночных причин: конкуренция, угроза разорения компании, необходимость поддержки своего имиджа - внешне все хорошо и пристойно, но нет заинтересованности в конечном результате, а важен сам процесс работы. В западных университетах основную роль играет имидж, а не реальные внедрения или экономический эффект работы. Здесь достаточно продемонстрировать коллегам, что "вот у меня на кафедре работает интернациональная группа из Китая, Швейцарии и России", следовательно я, как руководитель, имею хорошие связи. В России, наоборот, при защите кандидатской диссертации, посвященной даже сугубо теоретической теме, всегда требовалось наличие опыта практического использования, а еще лучше, чтобы он измерялся конкретными цифрами экономии или прибыли.
Многие проекты обязаны своим рождением исключительно соображениям престижа - можно назвать несколько таких разработок, проводимых весьма уважаемыми зарубежными компаниями - релизация этих проектов затянулась на много лет. В результате идеи, заложенные в исходный проект 4-5 лет назад, безнадежно устарели. Однако если Запад может себе позволить работать без результата, то избыток безнадежных проектов в России, пусть даже финансируемых на уровне межправительственных соглашений, это непростительная роскошь.
Среди более мелких и по человечески понятных причин появления таких проектов такие факторы, как: работа "на износ" без сна, отдыха и выходных - стиль молодых разработчиков, наивно предполагающих, что это необходимый путь к успеху (маловероятно, например, что ночью в воскресенье программист сможет аккуратно "прогнать" все тесты). Молодым хакерам или "одиноким зубрам" от программирования, как известно, море по колено. В России, где время гениальных одиночек еще не прошло, менеджерам проектов или заказчикам нелишне помнить об этом, чтобы проект не попал в разряд неосуществимых.
Отдельный интерес представляет вопрос, почему программисты и менеджеры сознательно принимают участие в этих проектах (нужны герои, - "я был одним из тех, кто принимал участие в космической программе "Буран"; боязнь остаться без работы и т.п.). Однако это тема отдельного исследования.
Скорее всего, безнадежные проекты, а лучше сказать прожекты, составляют неотъемлемую часть нашей жизни, поэтому единственная задача менеджеров и разработчиков - вовремя распознать их суть и определить свои цели, сведя к минимуму возможные негативные последствия, чтобы в первую очередь не пострадал заказчик. А уж какими именно способами этого добиваться _ более четкая оценка рисков, изоляция гениальных программистов-одиночек, привлечение консультантов-психологов, выявляющих и нейтрализующих внутренние подводные политические течения внутри компании - зависит от специфики каждого конкретного случая.
Короче говоря, не следует все сваливать на политиков, которые, мол, очень активно вмешиваются в ИТ - заведомо невыполнимые программистские (и не только) проекты всегда существовали, и это не только особенность российского компьютерного сообщества.
Дмитрий Волков - главный редактор журнала "Открытые системы". С ним можно связаться по электронной почте по адресу vlk@osp.ru.