Внешняя среда находится вовсе не «где-то там»

Говорят, что на севере Швеции живут миллиарды комаров. Не думаю, что это правда. По моему мнению, там живет только 1217 особей. Но они обладают невероятным обонянием и скоростью полета.

Я в этом уверен, потому что, куда бы в Швеции вы ни поехали, комаров не видно до тех пор, пока вы не выйдете из машины и не подставите открытые участки кожи прохладному ветерку. И вот тогда они налетят. Со всей Швеции. Через несколько минут все 1217 комаров будут с жужжанием виться над вами, пытаясь добраться до открытых участков кожи, которые они учуяли с другого конца страны. Шведские комары летают со сверхзвуковой скоростью, поскольку на севере страны практически нет людей. Для меня очевидно, что миллиардам комаров там просто не выжить. Людей еле хватает, чтобы прокормить 1217 комаров. И я кормил их всех в течение пяти дней.

Куда бы я ни поехал на севере Швеции, повсюду видел облако комаров, возникающее потому, что появился я. Мое появление в этой среде вызывало изменения в самой среде. А когда меня не было, не было и комаров. Другими словами:

Когда система попадает в определенную среду, это вызывает изменения в самой этой среде.

Я вынес эти слова отдельно, поскольку считаю, что в них заключено одно из важнейших понятий теории сложности. Среда, с которой системе приходится взаимодействовать, — это уже не та среда, которая существовала до контакта системы с ней. И это самая главная причина, почему так трудно «планировать» нововведения, исходя из описания текущего состояния среды. Появление нового элемента изменит само состояние этой среды и может сделать первоначальный план бесполезным.

Некоторое действие должно предшествовать планированию, поскольку таким образом мы участвуем в создании внешней среды. Окружающая среда вовсе не находится «где-то там», существуя отдельно от нас. Мы можем помочь в создании среды. <…> В испанском языке на этот счет существует удачная фраза: «Compañero, no hay camino. Se hace camino al andar». Она переводится так: «Мой друг, дороги нет. Дорога возникает, когда ты по ней идешь»[89].

Внешняя среда, существующая «где-то там» до того, как появится ваш программный продукт, отличается от среды, в которой этот продукт уже появился. Пользователи изменят свои рабочие привычки, когда возьмут его в оборот. Им будет хотеться что-то изменить, и появятся новые потребности. Другие программные продукты придут во взаимодействие с вашим, возможно, даже образуют с ним симбионты. Прибегут паразиты и попробуют обескровить продукт. Конкуренты начнут адаптировать свои стратегии и попытаются утопить ваш продукт. Может случиться, что я тоже попробую. Конечно же, совершенно непреднамеренно.

Невозможно заранее запланировать, какой метод нужно будет взять на вооружение при разработке конкретного продукта (в смысле использования той или иной типологии проекта и соответствующих подходящих моделей). Мы должны сначала почувствовать реакцию среды на новую систему, прежде чем поймем, как ею в этой среде управлять.

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

Таким образом, становится очевидно, что проект не может рассматриваться независимо от среды, контекста и своей истории. Более того, понимания контекста само по себе недостаточно для выбора метода (как это диктуется стандартной типологией проектов). Скорее, метод управления проектом оказывается встроенным в контекст и проявляется в результате взаимодействия между действующими лицами и средой, в которой они функционируют[90].

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

Страх неопределенности

Кстати о путешествиях и планировании… Годом раньше мы с моим партнером были на Кубе, где нам неожиданно удалось посетить знаменитую табачную плантацию. Это произошло потому, что мы подобрали молодого парня, который голосовал на обочине и оказался одним из рабочих с этой плантации. Мы подвозили его неохотно и немного нервничали, потому что туристов в поездках по острову регулярно предупреждают не брать попутчиков. За два года до этого мою приятельницу Надиру на Кубе ограбили после того, как она подобрала попутных пассажиров. Все это говорит о том, что путешественникам приходится иметь дело с неопределенностью. Вас либо ограбят, либо вознаградят. Но как узнать это заранее?

В своей книге «Сложность: Экскурсия с гидом» (Complexity: A Guided Tour) Мелани Митчелл объясняет, что на решающую роль неопределенности в сложных системах влияют два важных фактора: [Mitchell 2009: 20]. Первый из них — принцип неопределенности Гейзенберга. Он устанавливает предел точности одновременного определения пары характеристик элементарной частицы, например ее положения и импульса. Чем точнее известно положение частицы, тем менее точно можно измерить импульс, и наоборот. Этот принцип показывает, что неопределенность вплетена в ткань реальности. Но все это имело бы не большее значение, чем незначительные статистические отклонения, если бы не второй фактор: эффект бабочки.

Эффект бабочки, открытие которого приписывают Эдварду Лоренцу, это метафора чувствительности системы к отклонениям в ее начальных параметрах. Он утверждает, что порхание крыльев бабочки в Китае может вызвать ураган в США. Я заметил, что эта метафора приводится во многих книгах по теории хаоса и теории сложности. Иногда эта бабочка машет крыльями в Китае, иногда в Индии, а иногда и в Бразилии. Но странным образом ураган при этом всегда случается в Соединенных Штатах. Напрашивается вопрос: не обнаружили ли теоретики хаоса глобальную сеть бабочек-террористок, цель которых — организация ураганов на территории США? (Во время отпуска на Кубе мы стали свидетелями урагана, пронесшегося над островом. Могу подтвердить, что он направлялся в сторону Флориды. Судя по его траектории, бабочка находилась на острове Аруба.)

Мы должны принять за данность, что бизнес-ландшафт в XXI веке характеризуется как неопределенностью, так и сложностью. И ситуация не становится лучше. И хотя неопределенность — естественный феномен, многим она не нравится. Всем хочется в своем будущем видеть определенность и безопасность. Попытки достигнуть такой определенности могут приводить к параличу анализа [Heath 2007: 34–37]. Мы не знаем, какое решение принять, потому что не уверены в результате. Внедрять масштабируемую архитектуру сейчас или позже? Использовать при разработке HTML5 или Flash? Подобрать попутчика или нет? Закончится все это на сигарной фабрике или в полицейском участке?

Когда люди наконец-то набираются смелости, чтобы принять решение, они часто предпочитают избежать рисков, а не воспользоваться потенциальной возможностью. Они склонны полагать, что неопределенность скорее будет иметь негативные последствия, чем позитивные. (Они также могут считать, что последствия потенциальных проблем будут более значительными, чем выгоды от позитивного исхода.) Хорошим примером служит часто упоминаемая «угроза», которую несет для экосистем завоз человеком неместных биологических видов. Многие экологи пытаются активно противостоять этой «угрозе». Но исследования говорят о том, что лишь в нескольких процентах случаев завезенные виды оказывают значительное и негативное воздействие на существующие экосистемы [Davis 2009: 26]. В большинстве остальных случаев воздействие «чужеродных» видов на местные экосистемы было нейтральным или даже положительным. (Интересно, что медоносная пчела стала официальным символом нескольких штатов в составе США, но это не местный вид: он попал в Америку только в 1600-х годах. Наверное, этих пчел занесло в Штаты ураганом.)

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

Законы изменений

Фразу «постоянны только изменения» приписывают древнегреческому философу Гераклиту. Также часто говорят, что выживают только те, кто способен «приветствовать изменения». Кент Бек использует эту фразу в качестве подзаголовка к своему бестселлеру «Экстремальное программирование» (Extrame Programming) [Beck 2005].

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

Некоторые авторы утверждают, что успешное программное обеспечение требует большетехнической поддержки, чем неудачное [Brooks 2005, Glass 2003]. Одна из причин — стремление людей использовать любимое ПО в неожиданных ситуациях. Например, в Африке те, у кого нет банковских счетов, рассчитываются друг с другом, переводя деньги с мобильных телефонов. Еще одна причина состоит в том, что успешное ПО часто живет дольше, чем то поколение «железа» и бизнес-процессы, для которых оно первоначально предназначалось. Так, например, ожидалось, что многие программные продукты не переживут XX век, поскольку их придется серьезно модифицировать в связи с проблемой 2000 года (ее еще часто неправильно называют «ошибка миллениума»).

Необходимость учитывать изменения в окружающей среде при разработке ПО настолько фундаментальна, что рано или поздно в литературе мне должны были попасться соответствующие законы. Их предложил профессор Меир Леман:

1. Непрерывные изменения: система, используемая в изменяющейся среде, нуждается в постоянной модернизации, в противном случае удовлетворенность пользователей будет прогрессивно снижаться.
2. Увеличение сложности: если не предпринимать усилий по ее упрощению, то по мере своего развития система будет становиться все сложнее.
3. Саморегулирование: эволюция системы — саморегулируемый процесс, при этом темпы изменения атрибутов системы в течение ее жизненного цикла близки к нормальному распределению.
4. Влияние организационной стабильности: среднее количество усилий, прилагаемых при поддержании развивающейся системы, в течение ее жизненного цикла остается примерно постоянным.
5. Сохранение преемственности: в то время как система развивается, все связанные с ней люди должны обеспечивать господство ее содержания для достижения удовлетворительной эволюции.
6. Непрерывный рост: чтобы удовлетворенность пользователей не снижалась на протяжении жизненного цикла системы, ее функциональные возможности должны постоянно расширяться.
7. Ухудшение качества: воспринимаемое качество системы будет снижаться, если не предпринимать специальных мер по ее сопровождению и адаптации к изменениям во внешней среде.
8. Система обратной связи: эволюционные процессы представляют собой сложные системы обратной связи и должны рассматриваться как таковые для достижения значительных улучшений.

У меня имеются мелкие разногласия с некоторыми из законов Лемана (в особенности с третьим[91]), но в любом случае их смысл понятен и верен: система должна постоянно изменяться, иначе ее эффективность снижается. А когда система изменяется, то она становится более сложной, если не предпринимать мер по ее упрощению.

Может быть, самое интересное наблюдение Лемана состоит в том, что количество усилий по внесению изменений в систему и ее адаптации остается (приблизительно) постоянным в течение всего жизненного цикла. Мы вернулись к тому, что постоянны только изменения…

Каждый продукт успешен… пока не потерпит неудачу

Каким образом мы судим об успешности продукта?

Индустриальные отчеты, такие как, например, известный (или печально известный) CHAOS, выпускаемый компанией Standish Group, утверждают, что лишь незначительное число проектов по разработке ПО будут «успешными». Но что это означает? За последние годы было много попыток найти правильное определение успешности проектов, но согласие до сих пор не достигнуто. Согласно традиционной точке зрения, проект успешен, если он завершен вовремя и в рамках бюджета, а готовый продукт соответствует спецификациям. Другие говорят, что успешный продукт соответствует ожиданиям заказчика или обеспечивает соответствующий возврат инвестиций с точки зрения созданной ценности. Существует также точка зрения, что проект успешен в том случае, когда удовлетворены все заинтересованные стороны.

Как вы думаете, динозавры были успешны? А люди как биологический вид? Подозреваю, что многие ответят «нет» на первый вопрос и «да» на второй. Однако динозавры господствовали на Земле 160 миллионов лет, в то время как семейство гоминид (все виды, относящиеся к отряду приматов) существует только 6 миллионов лет. И при этом люди наносят ущерб поверхности планеты своим присутствием всего лишь 200 000 лет. С моей точки зрения, нам еще предстоит доказать, что мы успешнее динозавров (рис. 14.1).

А как вы думаете, успешны ли лошади как биологический вид? Скорее всего, моя дочь была бы с этим согласна, но ее мнение вряд ли поддержал бы великий палеонтолог Стивен Джей Гулд. В своих работах Гулд несколько раз отмечал, что почти все виды диких лошадей (Equus ferus) исчезли с лица Земли [Gould 2002]. Успешными можно признать только представителей вида Equus ferus caballus(домашняя лошадь) в том смысле, что они адаптировались и позволили Homo sapiens залезть себе на спину. Скорее всего, именно этому они и обязаны своим выживанием.

Мне кажется, есть основания утверждать, что любой биологический вид успешен до тех пор, пока не вымрет. Если учесть, что 99,9% всех видов из когда-либо существовавших вымерли, то мы располагаем массой примеров неудачных биологических проектов. Вследствие этого я предпочитаю такое определение успешности проектов по разработке ПО:

Программный продукт успешен до тех пор, пока не потерпит неудачу.

Да, я знаю, что это звучит по-дурацки. Но мир в целом иногда выглядит по-дурацки.

Некоторые продукты, в разработке которых я принимал участие, были успешными только в течение короткого промежутка времени — до тех пор, пока клиенты не отменяли заказ, поняв что им действительно нужно (оказывалось, что нужно им нечто совершенно другое). И хотя эти продукты не доживали даже до первого релиза, команды разработчиков и представители клиентов работали над ними к обоюдному удовлетворению до тех пор, пока не изменялась ситуация или не заканчивались деньги. Я знаю и другие продукты, которые были переданы клиентам в оговоренные сроки, в рамках бюджетов и в соответствии со спецификациями, и тем не менее сразу же после первого релиза выяснялось, что они не соответствуют клиентским ожиданиям. Были ли эти проекты неудачными? На самом деле нет, поскольку обычно нам удавалось найти способы исправить свои ошибки, адаптировать продукты в соответствии с полученной обратной связью и предоставить клиенту версии, которые позволяли восстановить доверие. Мне также приходилось видеть проекты, которые получали финансирование даже через несколько лет после выпуска первого релиза, хотя было очевидно, что эти инвестиции себя уже никогда не оправдают. Видимо, в подобных случаях удается временно отложить провал, поскольку в организации клиента есть какие-то заинтересованные лица, готовые продолжать поддерживать проект. Или, может быть, некоторым клиентам просто нравится тратить деньги.

Успех — это длительное отсутствие неудач. С моей точки зрения, продукт может представлять ценность, даже если процесс его разработки не уложился в график и вышел за пределы бюджета; даже если имеет место неудовлетворительный возврат инвестиций и даже если не все заинтересованные стороны довольны. Биологические виды успешны, пока не вымрут. Мой автомобиль успешен до тех пор, пока он мне не разонравится. Программные продукты успешны, пока не потеряют всех своих пользователей. Принципы принятия изменений и непрерывного улучшения направлены на то, чтобы отложить неизбежный момент потери последнего пользователя. Рано или поздно все программные продукты постигает неудача. Я на 99,9% в этом уверен.