Адаптация, исследование, прогнозирование

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

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

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

Инкременты и ретроспективы – это вариант двойного цикла обучения, концепцию которого предложили Крис Аргирис и Дональд Шон. В качестве примера двойного цикла обучения часто приводят простой термостат, управляемый оператором (за неимением вдохновения я повторю этот пример). Термостат регулирует себя сам на основе поступающей из внешней среды информации о температуре воздуха (это первый цикл, использующий модель внешней среды). Но у термостата также есть оператор, который корректирует его установки, основываясь на своем опыте и ожидаемых изменениях, которые могут быть вызваны, например, праздниками или прогнозом погоды (второй цикл, уточняющий модель окружающей среды) [Augustine 2005: 170].

Я думаю, что непрерывное улучшение в бизнес-контексте тоже происходит в два цикла и включает в себя адаптацию, исследование и прогнозирование (рис. 14.2).

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

Мы готовы к неопределенности и контролируем ее путем итераций, прогнозирования и адаптации (Декларация взаимозависимости).

Но разве сама идея прогнозирования не противоречит философии Agile?

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

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

В моем предыдущем маленьком стартапе нам приходилось прибегать как к адаптации и исследованию, так и к прогнозированию. Откровенно говоря, мы вместе с командой прошли столько двойных циклов обучения, что иногда у меня голова шла кругом. Но время от времени у всех нас возникал вопрос: «Действительно ли нам удается усовершенствовать продукт? Или мы просто еле-еле успеваем не отстать от остального мира?»