В 50–60-х годах прошлого века (иногда это время называют третьей индустриальной революцией или цифровой революцией) западный мир перешел от индустриальной экономики к экономике знаний, которой свойственна высокая дифференциация продуктов. Стало понятно, что текущие системы не рассчитаны на поддержание нового типа работы. Если в 1920-х Генри Форд мог заявить, что «покупатель может получить автомобиль любого цвета при условии, что этот цвет – чёрный», то теперь экономический успех все больше основывался на нематериальных вещах – знаниях, умениях, инновационном потенциале как ключевых ресурсах конкурентного преимущества^[11].

Все больше высокообразованных сотрудников понимали, что трудятся в компаниях, пытающихся контролировать работу, которую просто невозможно контролировать. Конечно, можно точно измерить, сколько времени займет закручивание гайки, можно определить степень свободы с учетом заданных технических характеристик, чтобы обеспечить качество, – но как подобный тип количественного мышления можно применить к оценке сложного умственного труда врача или инвестиционного аналитика? Как измерить продуктивность журналиста, пишущего статью? Подсчет количества слов на странице – подходящая замена потребительской ценности?

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

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

В 1959 году Друкер выпустил книгу «Ориентиры будущего» (The Landmarks of Tomorrow), в которой впервые предложил термин «информационный работник». Работа современных сотрудников выполняется с помощью их умов, а не рук, и менеджмент должен развиваться так, чтобы поддерживать эту реальность, создавая среду для роста, развития и обучения, писал Друкер^[12].

Развивая это понятие «информационного работника», в 1990 году Питер Сенге, старший преподаватель Массачусетского технологического института и сооснователь компании Society for Organizational Learning, предложил определение «обучающаяся организация». В книге «Пятая дисциплина: искусство и практика самообучающейся организации»^[13] он пояснял: обучающаяся организация – это организация, которая «обеспечивает обучение всех ее членов и постоянно трансформируется сама». Сенге объясняет, что компании должны меняться, чтобы поддерживать более связный способ мышления. Чтобы пробудить потенциал большинства сотрудников, компания должна вести себя как сообщество, поддерживающее совместные обязательства. (Помните, что мы говорили о городах?)

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПОГЛОЩАЕТ МИР: ПРИНЯТЬ НЕОПРЕДЕЛЕННОСТЬ И СТАТЬ ГИБКИМ

Сразу после появления теории Друкера и Сенге о сообществе и обучающихся организациях стали невероятно популярны, но нигде они не нашли такого отклика, как в новой группе информационных работников, возникшей в конце 1980-х, – разработчиков программного обеспечения. Эта профессия была сравнительно молода, но изобретение персональных компьютеров и интернета создало огромный спрос на разработчиков ПО и на вещи, естественной частью которых оно являлось, – от огромных ЭВМ до карманных калькуляторов и кофемашин; а их количество росло. Число вакансий в сфере разработки ПО быстро множилось, знаменуя появление нового типа работника (и работы), что требовало составления новых правил.

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

Представление о том, что лучшее понимание проблемы появляется посредством экспериментов и совместной работы членов команды, применяется и за пределами разработки ПО – в мире разработки продуктов в целом. В 1986 году в журнале Harvard Business Review вышла статья «Разработка нового продукта. Новые правила игры», авторы которой, Хиротака Такеучи и Икуджиро Нонака, провели аналогию между новым способом работы и регби, метафорически описав, как игроки постоянно делятся информацией и передают мяч знаний друг другу.

Сравнение весьма удачное: подобно спортивной команде, команда разработки ПО – это группа людей, чьи умения дополняют друг друга, собравшаяся, чтобы достичь общей цели.

Для создания решений, которые понравятся потребителям, нужно проверять предположения об их нуждах, способствуя тем самым обучению – неотъемлемой части процесса разработки продукта. Такеучи и Нонака предупреждали, что способы работы, при которых все предположения о потребителях установлены заранее, несостоятельны:

«Транснациональные компании должны стать быстрыми и гибкими в разработке продуктов. Чтобы сделать это, нужно использовать динамический процесс, который во многом полагается на метод проб и ошибок и на обучение в процессе работы. Сегодня, в мире постоянных изменений, нужны непрерывные инновации»^[14],^[15].

Это понимание заинтересовало Джеффа Сазерленда, бывшего военного летчика, занимавшегося развитием IT-систем в Easel Corporation. Вместе с коллегами он начал искать более гибкий путь разработки программного обеспечения, который учитывал бы обучение, основанное на опыте, напряженную совместную работу и частые петли обратной связи. В 1995 году Сазерленд вместе с Кеном Швабером, разработчиком ПО и промышленным консультантом, формализовали этот способ работы и назвали его фреймворком Scrum. Он был представлен на индустриальной конференции OOPSLA^[16]. Scrum помог открытиям Такеучи и Нонаки оформиться в восхитительно простую по структуре, но сложную в овладении методологию, применяемую для разработки продуктов (больше о ^{Scrum можно узнать в главе 3 «Технологии»}).

Scrum обращен к управленческой стороне разработки продуктов, но не освещает специфические технические практики в ПО. Кент Бек, выдающийся инженер ПО, обратился напрямую к этой стороне вопроса, когда в конце 1990-х представил концепцию экстремального программирования (Extreme Programming, XP) в одноименной книге. Главная цель XP – уменьшение стоимости изменений; чем быстрее схлопывается петля обратной связи для поступательных циклических изменений в процессе работы, тем с большей вероятностью мы создаем ПО, которые хотели создать. Бек убеждал менеджеров признать: изменения – естественный и желательный аспект разработки ПО. Вместо того чтобы пытаться определить стабильный набор требований, нужно быть готовым к изменениям и предвидеть их как ожидаемую часть процесса разработки продукта (см. рис. 1.1)^[17].

Рис. 1.1. Практики экстремального программирования создают возможности быстрого обучения посредством множественных слоев петли обратной связи

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

Одновременно с этим, в 1991 году, Алистеру Коуберну, методологу, работающему в новой консалтинговой группе компании IBM, дали задание найти причины успеха проектных групп. Углубившись в изучение проектов на Smalltalk и С++, Коуберн обнаружил, что в литературе того времени не были описаны факторы, делающие проектные группы успешными. Опросив десятки таких групп, он выделил ключевые элементы успешных команд в семейство методологий Crystal: серию легких процессов, подходящих к определенным типам проектов. Основная идея заключается в том, что каждому проекту нужна своя методология и методы должны меняться так же, как меняется ситуация^[18].

Пока эти лидеры мнений искали способы написать лучшее ПО, индустрия сама по себе находилась в плачевном состоянии. На протяжении 1970–1990-х было несколько происшествий, породивших заголовки о крупных превышениях сметы, хронических проблемах с качеством и возмутительных задержках продукта. В 1994 году группа из Стандиша опубликовала отчет CHAOS (акроним, англ. chaos – хаос), согласно которому среднее превышение запланированных расходов на проекты программного обеспечения составляло 189 %^[19]. Отчет часто цитировали. Согласно другим данным, примерно половина проектов работали, но немногие из них считались успешными. Кроме того, три четверти всех крупных программных продуктов, представленных потребителям, не отвечали их требованиям.

Ситуация не осталась без внимания программистов. Они поняли, что текущая ситуация неустойчива. На протяжении 1990-х профессионалы сферы ПО регулярно встречались и делились идеями. Что общего есть у появляющихся подходов? Какими способами можно улучшить написание ПО? Люди понимали, что ситуацию надо менять, но их идеи еще не могли срастись во что-то значимое.

Нужно было что-то делать. Поскольку XP начало продвигаться в сообществе, Мартин встретился в Чикаго с Мартином Фаулером, экспертом XP, с которым он познакомился на конференции Кента Бека XP Leadership осенью 2000 года. Вместе они пришли к выводу, что необходимо организовать что-то вроде саммита, чтобы люди с похожими взглядами смогли собраться и создать манифест легких процессов. Мартин и Фаулер начали подбирать участников этой встречи так, чтобы на ней были представлены разные взгляды. Одним из тех, кто получил приглашение на «саммит легких процессов» по электронной почте, был Алистер Коуберн.

Коуберн, который в тот момент был занят организацией похожей встречи по тем же причинам, что и Мартин с Фаулером, с радостью принял приглашение, предложил взять на себя логистику и организовать встречу неподалеку от его дома в Юте^[20].

Несколько месяцев спустя, в феврале 2001 года, Бек, Коуберн, Мартин, Фаулер, Швабер, Сазерленд и еще одиннадцать опытных лидеров мнений собрались в городе Сноуберде, чтобы понять, что не так в способах создания ПО. Они задались вопросом: как они могли бы улучшить способы разработки ПО, используя свой опыт? Как разработчики ПО, они истово гордились собственным ремеслом, однако их не удовлетворяло ни состояние отрасли в целом, ни негативное восприятие разработки ПО как профессии. Они хотели создавать ПО, которое нравится потребителям, и повлиять на организации, формировавшие среду с лучшим ПО^[21],^[22].