Scrum на практике. Высокая продуктивность и результаты – прямо сейчас - страница 6
Проект TAURUS должен был исправить это. Он подразумевал использование электронной системы урегулирования, которая заменила бы старую бумажную и была привязана к международным системам для обеспечения торговли международными ценными бумагами. Это было бы невероятно. Но трейдерам нужно было одно, инвестиционным институтам – другое. Большинство трейдеров также хотели, чтобы TAURUS мог взаимодействовать с их системами, а не заменять их. Число требований к проекту все росло.
Однако он по-прежнему оставался невероятным. Он интегрировал бы семнадцать разных систем. Восхитительно! Согласно статье Хамиша Макрая, опубликованной в журнале Independent 12 марта 1993 года, проблема была трехсторонней. В первую очередь, попытка создать с нуля огромную систему программного обеспечения и запустить ее, как Вселенную большим взрывом, невероятно рискованна, не допускает даже малейших ошибок или просчетов. Любая досадная мелочь будет иметь катастрофические последствия. Правда, такой подход часто встречался в те времена и существует до сих пор. Компании невероятно рискуют, ставя на то, что масштабная система сразу сможет все исправить. По данным Standish Group, около 40 % проектов, работающих по этому принципу, провальны[7]. Половина из них затягивает сроки, половина превышает бюджет и не обеспечивает то, для чего была предназначена изначально. В случае с TAURUS расклад тоже оказался не в пользу системы, которая должна была полностью заменить систему урегулирования платежей в одном из мировых финансовых центров.
Второй аспект проблемы, согласно Макраю: хотя иметь систему важно, но если есть хорошая система, которая работает, и идеальная, которая не работает, то выбирать нужно первую. Не позволяйте лучшему стать врагом хорошего. В проекте TAURUS, как и почти в любом другом проекте, неконтролируемое расширение масштаба стало удавкой на шее. «Правда, здорово было бы, если бы новая система делала не только то, что мы уже продумали и о чем нас попросили, но и вот это? А если бы она еще варила идеальный эспрессо, пока люди ждут завершения сделки? Еще лучше ведь», и т. д. В итоге проект, который вначале был прост и хорошо определен, становится машиной Голдберга[8], решающей все проблемы всех людей. При этом, естественно, неспособной выполнять простейшие задачи, поставленные изначально.
Я постоянно наблюдаю это в компаниях на примере одной корпоративной системы: SAP[9]. SAP – лидер рынка в сфере систем планирования ресурсов предприятия (Enterprise Resource Planning, ERP). Системы ERP нацелены на выполнение всех задач. Это гигантские базы данных, которые отслеживают ресурсы – например, денежные средства, необработанные материалы, производственные мощности – и соотносят их с платежными ведомостями, счетами на оплату, заказами и т. д. Они затрагивают каждый аспект деятельности компании: закупки, продажи, человеческие ресурсы, бухгалтерию, производство, буквально все, – и интегрируют это в цифровой формат. На самом деле такие системы неплохо работают, если вы используете их в стандартных конфигурациях.
Проблемы, как и в случае с TAURUS, начинаются тогда, когда люди считают ERP волшебной таблеткой от всего: интегрируют каждую систему, обращаются к мейнфреймам, расположенным в подвале, подключают облачные вычисления, сшивают разнородные системы, используемые разными отделами и держащиеся на честном слове (или все их заменяют чем-то получше!). Вот тут и начинается неконтролируемое расползание рамок проекта. «А давайте сделаем так, чтобы оно обращалось к существующей системе, которую мы уже тридцать лет используем». Или «оно должно включать каждую функцию другого, уже готового продукта, который мы купили двадцать лет назад и который больше не поддерживается». Список можно продолжать бесконечно.
