В 2001 году семнадцать таких людей на пару дней собрались вместе на горнолыжном курорте в городе Сноуберд. Мой отец Джефф Сазерленд был там, как и Кен Швабер, и еще один ранний адепт Scrum Майк Бидл, и четырнадцать человек с разным прошлым и разными методологиями. Однако все они признавали, что пытались решать одни и те же проблемы. Пути их были схожи, но не одинаковы.
В первый день, как мне рассказали некоторые из присутствовавших там, они спорили. В основном о том, как же назвать подход, что они нащупали, но которому еще не дали имя. К концу дня Майк Бидл предложил слово agile. Все согласились с тем, что оно лучше других предложенных, вроде lightweight («легковесность»). Так они решили назвать подход гибким. А потом начали обсуждать, что же именно это будет означать.
На следующий день они снова спорили. Хорошо, они нашли гибкость, но что же это значит? Как ее описать? Девятеро из тех, кто был в комнате, решили выйти покурить, восемь остались внутри. Один из них, Мартин Фаулер, подошел к доске и сказал что-то вроде: «Не правда ли, будет жаль, если мы так ни к чему и не придем за эти два дня?» И примерно за пятнадцать минут восемь человек, что остались в комнате, пришли к следующему.
Мы постоянно открываем для себя более совершенные методы разработки ПО, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать следующее.
Люди и взаимодействия важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
Иначе говоря, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева.
Пятнадцатью минутами позже, когда остальные вернулись в комнату, один из них, Уорд Каннингем, изобретатель Wiki, помимо прочего сказал: «Это невероятно!» И они не изменили ни слова в этих формулировках.
Таков Agile. Это утверждение ценностей. Остаток дня они придумывали двенадцать принципов Agile, например «Простота искусство минимизации лишней работы крайне необходима» и «Над проектом должны работать мотивированные профессионалы. Чтобы получить результат, создайте условия, обеспечьте поддержку и полностью доверьтесь им» и «Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта». Это прекрасно, но в принципах нет описания того, как следовать им. Нет фреймворка, методологии. Только четыре ценности и несколько принципов, согласующихся со здравым смыслом.
Но они изменили мир. Участники того мероприятия выложили свой 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 % проектов, работающих по этому принципу, провальны. Половина из них затягивает сроки, половина превышает бюджет и не обеспечивает то, для чего была предназначена изначально. В случае с TAURUS расклад тоже оказался не в пользу системы, которая должна была полностью заменить систему урегулирования платежей в одном из мировых финансовых центров.
Второй аспект проблемы, согласно Макраю: хотя иметь систему важно, но если есть хорошая система, которая работает, и идеальная, которая не работает, то выбирать нужно первую. Не позволяйте лучшему стать врагом хорошего. В проекте TAURUS, как и почти в любом другом проекте, неконтролируемое расширение масштаба стало удавкой на шее. «Правда, здорово было бы, если бы новая система делала не только то, что мы уже продумали и о чем нас попросили, но и вот это? А если бы она еще варила идеальный эспрессо, пока люди ждут завершения сделки? Еще лучше ведь», и т. д. В итоге проект, который вначале был прост и хорошо определен, становится машиной Голдберга, решающей все проблемы всех людей. При этом, естественно, неспособной выполнять простейшие задачи, поставленные изначально.
Я постоянно наблюдаю это в компаниях на примере одной корпоративной системы: SAP. 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. Революционный метод управления проектами». Однако, коротко говоря, он изобрел новый способ работы. Его важнейшее озарение заключалось в том, что люди не виноваты в подобных ошибках. Менеджеры и инженеры, дизайнеры, вовлеченные в масштабные проекты, которые провалились, не были плохими. Они не были глупыми. Они не нарочно совершили ошибки. Они приходили в проекты с мечтами и целями изменить мир к лучшему.
Провалились не люди, а система. Провалились способы работы, видение будущего, формат собраний для обсуждения и планирования работы. Для них это был просто способ работы, и в их понимании подвергнуть его сомнению все равно как если бы рыба усомнилась в преданности своего вида воде.
Руководство по выживанию
Люди, рабочие места которых под угрозой автоматизации труда, на самом деле мало чем отличаются от корпораций, существование которых постоянно в опасности. Способность быстро адаптироваться всегда определяет ваш успех, чем бы вы ни занимались: принимали личное решение о работе, планировали стратегические цели крупной международной компании, решали, как адаптировать культуру под новую ситуацию с совершенно иным набором граничных условий. Как мы с отцом отметили в нашей последней книге: изменись или умри.
Здесь, однако, я хочу дать вам еще несколько инструментов. Я хочу взять вас с собой в кругосветное путешествие и показать мир, от кол-центра до открытого космоса, от ресторана до принципиально новых технологий. Эти тенденции могут показаться пугающими, но я искренне верю, что мы можем научиться принимать изменения, чтобы стать более жизнестойкими и перестать бояться, суметь сделать больше, не оплакивать то, от чего вынуждены отказаться, действовать в соответствии с глобальными целями и не быть заложниками локальных сил вокруг нас.
Загвоздка Scrum в том, что он сам по себе не делает ничего. Его задача раскрыть потенциал каждого из нас. Он здесь, он может быть скрыт или спрятан в угол, но никогда не исчезнет. Таковы мы, люди. Сегодня мы думаем, что мир работает так, а завтра обнаружим, что все иначе. Однажды мы можем понять, что смотрели на мир через кривую линзу, во Вселенной есть возможности, о которых мы никогда не думали, а теперь переосмыслили всё. И мы всегда были способны на это.
ВЫВОД
Scrum это искусство менять границы возможного. Вы способны адаптироваться к миру нарастающих изменений и увидеть то, на что вы, ваша компания, товарищи и сотрудники способны на самом деле. Умение быстро адаптироваться всегда определяет ваш успех, чем бы вы ни занимались: принимали личное решение о работе, планировали стратегические цели крупной международной компании, решали, как адаптировать культуру под новую ситуацию с совершенно иным набором граничных условий.
Неудачи неизбежны и бесценны. Неважно, кто ответственен за успех или провал, как были потрачены деньги, что пошло не так. Великие компании и лидеры учатся на своих ошибках и успехах, а затем используют полученные уроки, чтобы стать еще лучше.
Совершенство переоценено. Неплохая система, которая работает, дает гораздо больше, чем погоня за идеальной, которая не работает.
БЭКЛОГ
1. Изучите все Agile-ценности и оцените, насколько вы и ваша компания гибки. Запомните: «Не отрицая важности того, что справа, мы больше ценим то, что слева».
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
Исследуйте реакцию вашей компании на неудачи. Становятся ли провалы ценной возможностью для обучения или поводом искать виноватых?
2. Оцените способность вашей компании адаптироваться и внедрять инновации. Насколько вам сложно держать темп в условиях меняющихся спроса, желаний и требований? Вы разрушитель или ждете дня, когда окажетесь за бортом? Что благоприятствует и вредит вашей способности реагировать на изменения?
Глава 2. Как передумать дешево
Мой коллега Джо Джастис любит повторять: «Scrum это про сокращение затрат на то, чтобы передумать». Джо работает в основном с компаниями, производящими товары долговременного пользования: машины, ракеты, медицинское оборудование, средства личной защиты для пожарных и т. д. В общем, материальное обеспечение.