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

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

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

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

На протяжении нескольких страниц я пытался показать, что неопределенность будет всегда и что необходимо адаптироваться к изменениям. Не исключено, что вам все это надоело до слез и вас клонит в сон. Попробуем разбудить вас и обсудить практические аспекты неопределенности. Как вести себя в среде, характеризующейся неопределенностью? Как управлять непрерывными изменениями? Увы, универсального рецепта не существует. Управление изменениями в значительной степени будет ситуационным и зависит как от операционной среды, так и от характеристик самой организации [Bennett 2004: 10].

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

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

Решение проблемы кроется в критическом анализе всей системы, а не только процессов. В главе 11 мы обсудили семь измерений проектов по разработке ПО: функциональность, качество, инструменты, люди, расписание, процессы и бизнес-ценность. Я убежден, что все семь измерений являются кандидатами на оптимизацию в изменяющейся операционной среде. Управление изменениями достигается не только посредством улучшения процессов. Необходимо постоянное внимание к функциональности, качеству, инструментам, людям, срокам и бизнес-ценности.

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

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

В большинстве Agile-методов цикл обучения системы реализуется через инкременты и ретроспективы, которые происходят итеративно. Инкремент – новый релиз продукта, помещаемый в целевую среду. Основная задача очередного инкремента – получение обратной связи, чтобы на этой основе провести необходимую адаптацию продукта (взгляд назад) и исследование (проба) и снизить до приемлемого уровня необходимость предвидеть изменения, которые могут потребоваться в будущем. Выпущенный продукт влияет на среду, а среда отвечает на это какими-то (возможно, непредвиденными) способами. Полученные знания исспользуются для того, чтобы адаптировать, предсказать, что понадобится для следующего релиза или для продолжения исследований, если мы все еще ничего не знаем.

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