Читать книгу Scrum на практике. Высокая продуктивность и результаты – прямо сейчас - J.J. Sutherland, Джей Джей Сазерленд, James O. Coplien - Страница 8

Если вы никогда раньше не слышали о Scrum либо имеете поверхностное представление о нем и пока не уверены в том, поможет ли он вашему бизнесу, я немного расскажу вам о том, как появился Scrum и зачем он нужен.

С конца 1980-х жители Кремниевой долины размышляли о том, как закон Мура повлияет на технологический прогресс. Поскольку создаваемые устройства могли делать всё в большем количестве, проекты по разработке программного обеспечения становились всё сложнее и, к сожалению, чаще терпели неудачи, оборачиваясь всё большими потерями времени, энергии, продуктивности и мечтаний.

Для примера возьмем проект TAURUS Лондонской фондовой биржи, появившийся примерно в то время. TAURUS – акроним от Transfer and Automated Registration of Uncertified Stock (передача и автоматическая регистрация бездокументарных акций). Проблема заключалась в том, что система урегулирования при конвертации валюты использовала ПО под названием Talisman. Урегулирование – на самом деле красивое словечко для обозначения «того, за что ты заплатил». После того как вы купили на фондовой бирже ценные бумаги, их доставка в ваш портфель могла занять две-три недели и включала переправку настоящих бумажных акционерных сертификатов из одной точки в другую. Система расчетов, покупки и продажи долей называлась Seaq. Она была электронной, но не совместимой с Talisman, которая обгоняла ее на несколько лет.

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

Однако он по-прежнему оставался невероятным. Он интегрировал бы семнадцать разных систем. Восхитительно! Согласно статье Хамиша Макрая, опубликованной в журнале Independent 12 марта 1993 года, проблема была трехсторонней. В первую очередь, попытка создать с нуля огромную систему программного обеспечения и запустить ее, как Вселенную большим взрывом, невероятно рискованна, не допускает даже малейших ошибок или просчетов. Любая досадная мелочь будет иметь катастрофические последствия. Правда, такой подход часто встречался в те времена и существует до сих пор. Компании невероятно рискуют, ставя на то, что масштабная система сразу сможет все исправить. По данным Standish Group, около 40 % проектов, работающих по этому принципу, провальны[7]. Половина из них затягивает сроки, половина превышает бюджет и не обеспечивает то, для чего была предназначена изначально. В случае с TAURUS расклад тоже оказался не в пользу системы, которая должна была полностью заменить систему урегулирования платежей в одном из мировых финансовых центров.

Второй аспект проблемы, согласно Макраю: хотя иметь систему важно, но если есть хорошая система, которая работает, и идеальная, которая не работает, то выбирать нужно первую. Не позволяйте лучшему стать врагом хорошего. В проекте TAURUS, как и почти в любом другом проекте, неконтролируемое расширение масштаба стало удавкой на шее. «Правда, здорово было бы, если бы новая система делала не только то, что мы уже продумали и о чем нас попросили, но и вот это? А если бы она еще варила идеальный эспрессо, пока люди ждут завершения сделки? Еще лучше ведь», и т. д. В итоге проект, который вначале был прост и хорошо определен, становится машиной Голдберга[8], решающей все проблемы всех людей. При этом, естественно, неспособной выполнять простейшие задачи, поставленные изначально.

Я постоянно наблюдаю это в компаниях на примере одной корпоративной системы: SAP[9]. SAP – лидер рынка в сфере систем планирования ресурсов предприятия (Enterprise Resource Planning, ERP). Системы ERP нацелены на выполнение всех задач. Это гигантские базы данных, которые отслеживают ресурсы – например, денежные средства, необработанные материалы, производственные мощности – и соотносят их с платежными ведомостями, счетами на оплату, заказами и т. д. Они затрагивают каждый аспект деятельности компании: закупки, продажи, человеческие ресурсы, бухгалтерию, производство, буквально все, – и интегрируют это в цифровой формат. На самом деле такие системы неплохо работают, если вы используете их в стандартных конфигурациях.

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

Только за последние полгода я работал с тремя международными корпорациями, которые пытались внедрить ERP более десяти лет. В одной международной компании по производству напитков (возможно, и вы их недавно употребляли), когда я рассказал о том, как важно сохранять простоту продукта, один из инженеров подошел ко мне и вкрадчиво, вполголоса сказал: «Мы потратили на это уже больше миллиарда. И система не работает». В другой компании с сотнями тысяч сотрудников, работающих в самых отдаленных уголках планеты, мне сказали, что миллиард долларов – это дешево. Они потратили полтора миллиарда – и ничего не работает. Не буду угнетать вас третьим примером, просто поверьте: там все еще хуже. И во всех случаях был один общий момент: несмотря на миллиарды долларов и тысячи сотрудников, система не работала. И они продолжают тратить годы и выбрасывать сотни миллионов долларов, ничего не меняя и ожидая, что получат иной результат.

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

Чтобы проиллюстрировать третий аспект проблемы с TAURUS, приведу цитату из работы Макрая.

Фондовая биржа не прислушивалась к своим потребителям. А типов потребителей было много: участники биржи, продавцы своих акций, институциональные и частные инвесторы. Все были озабочены затратами на TAURUS, компании сердились (и некоторые отказались помогать в реализации проекта), институты в лучшем случае были недовольны, в худшем – настроены враждебно, а все малые инвесторы, знавшие о проекте, беспокоились по поводу дополнительных сборов, которые им наверняка пришлось бы платить. Нужна определенная самонадеянность, чтобы продавливать что-то при таком сопротивлении.

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

Так TAURUS, рожденный как прекрасная идея, был отменен в 1993 году, спустя годы попыток. Денный и нощный труд тысяч людей и 75 млн фунтов оказались слиты в унитаз. Общий экономический эффект системы на стейкхолдеров оценивается примерно в 400 млн фунтов.

Это очень много потраченного времени и жизней. Множество действительно умных людей, посвятивших годы созданию того, что стало синонимом технологической катастрофы.

И как бы сильно я ни хотел сказать вам, что TAURUS – один из худших примеров, это не так. Есть множество других. Проект Национальной системы здравоохранения (National Health System) под названием Connecting for Health («Вместе для здоровья»), который должен был объединить в электронной форме истории болезни жителей Великобритании: 9 лет и 12 млрд фунтов. Экспедиционная система обеспечения боевых действий (Expeditionary Combat Support System) для армии США: 7 лет и 1,1 млрд долларов. Департамент штата Калифорния по регистрации транспортных средств с 1987 года тратил десятки миллионов долларов на систему, которая к 1990 году была хуже, чем та, которую она должна была заменить. И его руководство не могло это признать до 1994-го. Газета San Francisco Chronicles описала систему как «непригодную, исправить которую невозможно без дополнительного вливания миллионов долларов».

Машины становятся быстрее и способнее, и людям нечего на это ответить. В таких условиях мой отец работал в начале 1990-х. Если вы хотите узнать всю историю, прочтите «Scrum. Революционный метод управления проектами». Однако, коротко говоря, он изобрел новый способ работы. Его важнейшее озарение заключалось в том, что люди не виноваты в подобных ошибках. Менеджеры и инженеры, дизайнеры, вовлеченные в масштабные проекты, которые провалились, не были плохими. Они не были глупыми. Они не нарочно совершили ошибки. Они приходили в проекты с мечтами и целями изменить мир к лучшему.

Провалились не люди, а система. Провалились способы работы, видение будущего, формат собраний для обсуждения и планирования работы. Для них это был просто способ работы, и в их понимании подвергнуть его сомнению – все равно как если бы рыба усомнилась в преданности своего вида воде.