Как адаптироваться к изменениям

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

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

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

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

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

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