Agile-менеджмент. Лидерство и управление командами

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

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

Сложные проблемы обычно связаны с непредсказуемостью. Они не просто непредсказуемы – невозможно предсказать, в чем именно проявится их непредсказуемость[92].

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

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

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

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

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

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

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

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

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