«Авантюристы» и «консерваторы» в выборе платформы

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

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

Как правильно выбирать платформу? И кто должен это делать?

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

• актуальные бизнес-процессы, их модели "как есть";
• предложения по реинжинирингу бизнес-процессов с целью компенсации источников выявленных проблем, иными словами, требования к новым бизнес-процессам, их моделям "как должно быть".

Если бы речь шла о следовании этапам ставшего уже классическим процесса Rational Unified Process (RUP), то на этом перечень можно было бы закончить. Но на практике, при разработке серьезных корпоративных ИТ-решений практически никто уже не ограничивается строго заказной разработкой. В качестве программной платформы будущего решения выбирается программное обеспечение, уже обладающее полезной функциональностью, покрывающей ряд потребностей бизнес-процессов to-be. Но поскольку на этом этапе еще не до конца может быть определена эта самая программная платформа, то границы этой функциональности для разных платформ будут также разными. Следовательно, список исходных данных не без основания можно дополнить следующим пунктом:

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

В качестве иллюстрации сказанного приведем три рисунка: рис. 1 — схема интуитивного выбора, рис. 2 — классический реинжиниринг бизнес-процессов без учета потенциальных возможностей программных платформ и рис. 3 — рекомендуемый авторами подход, предполагающий выстраивание новых бизнес-процессов с максимальной опорой на базовую функциональность программного обеспечения.

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

В области ИТ часто можно встретить ярко выраженных «консерваторов» и «авантюристов». Их суждения об использовании того или иного продукта, как правило, диаметрально противоположны. Первые стремятся к проверенным надежным решениям, вторые — к инновациям и риску. Без «консерваторов» невозможно существование устойчивых надежных систем, работающих годами без существенных инвестиций, без «авантюристов» — движение вперед. «Консерватор» и «авантюрист» являются представителями двух противоположных полюсов, которые находятся в постоянном противодействии. Именно экспертиза призвана поставить точку в споре между ними. Рассмотрим пример.

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

Основное условие состояло в том, что проект надо было выполнить в стандартной для заказчика операционной системе — Sun Solaris. Наиболее серьезная технологическая проблема при реализации системы — необходимость работы с большими объемами неструктурированной информации. После анализа возможностей различных продуктов и на основе требований, выявленных в процессе обследования, были выбраны два программных продукта, наиболее подходящих для реализации системы. Первый продукт был традиционной программной платформой — как для разработчика, так и для заказчика. Между тем, первичный анализ функциональных возможностей второго продукта сулил существенное сокращение сроков и стоимости разработки (примерно в полтора раза), что было очень привлекательным.

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

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

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

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

При принятии окончательного решения о выборе платформы для разработки учитывались следующие факторы:

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

К сожалению, первоначальные надежды на существенное уменьшение стоимости разработки при использовании второго продукта оказались неоправданными. Поэтому решающим фактором, повлиявшим на выбор программной платформы, стала оценка рисков, связанная с неопытностью команды и с относительной незрелостью реализации второго продукта в среде Sun Solaris. В итоге, выбор пал на традиционно используемую программную платформу, как на наиболее «надежную» в смысле предсказуемости процесса разработки.

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

По сути, описанная ситуация является характерным примером борьбы между «авантюристами» и «консерваторами». Судьей в споре между ними должен выступать «прагматик». Часто это спонсор проекта. В случае, когда невозможно формализовать задачу, и решение не может быть основано на формальных признаках, стоит использовать экспертизу. Положитесь на конкуренцию, позвольте двум идеям — «консервативной» и «авантюрной» — проявить себя сначала на небольшом проекте. Затраты окупятся сполна.