Джей Сазерленд - Scrum на практике. Высокая продуктивность и результаты – прямо сейчас

Но они изменили мир. Участники того мероприятия выложили свой Agile-манифест на сайте agilemanifesto.orgи разъехались по домам для того, чтобы нести тяжкое бремя следования ему. Тогда они еще не знали, что подход распространится далеко за пределы мира программного обеспечения.

Но запомните: если кто-то заявляет о своей гибкости, очень важно уточнить, что именно он под этим понимает. Scrum – самый популярный гибкий фреймворк, около 70 % agile-команд используют его, но он ни в коем случае не единственный. Именно поэтому, зная только то, что компания условно гибкая, вы не сможете составить полной картины.

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

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

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

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

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

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

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

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

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