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

Джордж Бернард Шоу,

драматург (1856–1950)

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

В таблице 15.1 в обобщенном виде показаны пять наиболее известных моделей улучшения. Я называю этот обобщенный процесс простым линейным процессом улучшения (SLIP, Simple Linear Improvement Process). Он предусматривает восемь этапов.

ПРИМЕЧАНИЕ: я сам составил приведенную здесь таблицу соответствий между распространенными моделями других авторов и моей собственной, поэтому она субъективна. У других сравнение этих моделей могло бы выглядеть иначе.

Вполне очевидно, что все эти модели имеют сходную логику, и в том виде, как это показано у меня, предполагают выполнение восьми этапов:

1. Мы анализируем текущую ситуацию и определяем, в чем состоит самая насущная проблема. (Например, мы толстеем.)
2. Формулируем цель, достижение которой поможет нам выбраться из данной проблемной ситуации. (Хотим похудеть на четыре килограмма.)
3. Выбираем показатель, по которому будем судить о том, удалось ли нам этой цели достичь. (Достаем с чердака старые весы.)
4. Определяем желательное улучшение в поведении, которое продвинет нас к поставленной цели. (Решаем делать пробежки и есть более здоровую пищу.)
5. Проводим внедрение, желательно в рамках небольшого контролируемого эксперимента. (Покупаем кулинарную книгу и кроссовки.)
6. Затем следует этап повседневного исполнения, результаты которого подвергаются измерениям. (Ежедневно бегаем и едим здоровую пищу.)
7. Проводим анализ проведенных измерений, чтобы узнать, наступили ли желаемые улучшения. (О боже, всего полкило за три недели?)
8. И наконец, в результате проведенного анализа у нас появляется новая информация — как о проблеме, так и об эффективности применяемого решения и используемых показателях. Эту информацию мы можем использовать при следующей итерации. (Внезапно выясняется, что старые весы все это время показывали неверный вес.)

Завершив этап 8, мы возвращаемся к этапу 1 — либо для того, чтобы убедиться, что проблема все еще существует (лишний вес никуда не делся), либо чтобы решить новую, более насущную проблему (купить новые весы).

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

Линейные улучшения в сравнении с нелинейными

Адаптивные ландшафты далеко не всегда способствуют линейным изменениям. Осуществляя пошаговые улучшения, легко застрять в точке локального оптимума. Но как перейти из состояния, когда уже достигнута определенная эффективность, в состояние, где эта эффективность гораздо выше, если между этими точками сплошные овраги (см. рис. 15.1)?

Это стандартная проблема для многих программ улучшения. В результате возникают фразы вроде «шаг назад — два шага вперед» или «прежде чем станет лучше, временно будет хуже». Адаптивная прогулка сложной системы по адаптивному ландшафту не всегда проста. Стандартные процессные модели не принимают во внимание (по крайней мере в явном виде) тот факт, что множественные итерации, даже если они, по идее, должны способствовать движению в правильном направлении, могут сделать ситуацию только хуже. Хочется верить, что ненадолго.

Эта особенность изменений — отсутствие линейности — вторая причина, почему большинство методологий «управления изменениями» неэффективны. Неизбежные попытки втиснуть непредсказуемость в рамки линейных подходов оказывают разрушительное воздействие на управление жизненными циклами продуктов, циклы разработки систем и тому подобное. <…> Теория бизнеса переполнена моделями жизненных циклов продукта, большинство из которых не в состоянии описать нелинейную и непредсказуемую природу этих циклов, особенно в условиях, когда рынки, запросы потребителей, бизнес и экономика в целом постоянно усложняются.

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

В книге «Как привести в действие процесс инноваций» авторы отмечают, что бизнес может нуждаться не только в постепенных инновациях, но и в радикальных (Davila 2006: 51–55]. И тем не менее большая часть литературы по бережливым методологиям в основном проповедует кайдзен (постепенные улучшения) и почти не упоминает ситуации, когда необходимы принципы кайкаку (радикальное улучшение процессов) [Middleton, Sutton 2005: 31].

Таким образом, при возникновении проблемной ситуации вначале могут потребоваться радикальные улучшения (кайкаку) и лишь затем серия постепенных (кайдзен).

А в чем тогда состоит роль адаптации? Как мы знаем, когда речь идет о непрерывном улучшений, имеются в виду процессы адаптации, прогнозирования и исследования. Адаптация по своей сути реактивна: она заключается в реагировании на изменения внешней среды. Прогнозирование проактивно: мы представляем в своем воображении наиболее оптимальную точку в адаптивном ландшафте и начинаем двигаться к ней. Исследование интерактивно: мы делаем что-либо в пробном режиме, чтобы выяснить, какой эффект получим на выходе. Однако мы делаем это не потому, что того требует внешняя среда или мы уже представили себе, как должны выглядеть оптимальные результаты. Системы, в которых люди не участвуют, улучшаются исключительно путем приспособления к внешней среде (адаптация) и методом случайных проб (исследование). Но группы людей могут прибегнуть к своему воображению, чтобы представить себе оптимальные результаты (прогнозирование). Процесс непрерывного улучшения подразумевает использование всех трех методов.

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

Определите свое местоположение

Когда во время отпуска мы с моим партнером путешествуем на автомобиле по незнакомой стране, то обычно у меня лучше получается находить дорогу до очередной достопримечательности, рассчитывать время, необходимое, чтобы добраться в пункт назначения, и расшифровывать дурацкие символы на картах. К сожалению, меня легко вводят в заблуждение неожиданные повороты, незаметные съезды с дороги и невидимые знаки. Мой партнер, наоборот, обычно не имеет ни малейшего представления о том, куда мы едем, и пару раз мне приходилось видеть, как он держит карту вверх ногами. Но поскольку он несколько умнее меня, то понимает, что совсем не разбирается в таких делах. Я же всегда уверен, что точно знаю, куда мы едем и как пользоваться картой. В результате я слишком поздно осознаю, что дорога в очередной раз сыграла с моей самоуверенностью злую шутку. Так что не имеет значения, кто из нас в данный момент за рулем. Все равно рано или поздно мы заблудимся.

Пытаясь улучшить ситуацию первое, что нужно знать наверняка, — это ваше текущее положение. Вам не удастся найти дорогу до следующего отеля или дожить до следующего успешного релиза продукта, если вы не имеете представления о том, где в данный момент находитесь. Майк Кон называет это развитием осведомленности [Cohn 2009: 23–26], а Мэри и Том Поппендик — представлением проблем в явном виде [Poppendieck 2009: 169–172]. Чтобы определиться со своим местонахождением, необходимо посмотреть по сторонам и распознать наиболее насущные проблемы. В противном случае вы обречены вечно блуждать в темноте, не представляя, приближаетесь ли вы вообще к своей цели. В такой ситуации улучшение будет зависеть исключительно от удачи и совпадений.

Литература по гибким методологиям изобилует рекомендациями, как оценивать свою текущую ситуацию. Существует огромное количество инструментов — диаграммы сгорания задач (Burn-Down), карты потока ценности, метод пяти «почему», ретроспективы и десятки других. Все они помогают разобраться с тем, насколько мы продвинулись вперед и какие при этом обнаружились проблемы. В дополнение к этой книге потребовалось бы сочинить еще несколько томов, чтобы описать все имеющиеся в вашем распоряжении опции. Но мне приходится себя ограничивать. Я очень хорошо понимаю, в чем состоит цель этой книги, поэтому любой уход в сторону значительно замедлил бы наше движение. Пока я ограничусь советом отправиться туда, где живут и работают ваши команды, чтобы узнать и лично увидеть, какие из существующих проблем наиболее важны [Poppendieck 2009: 172].

Однажды мы путешествовали в горах между Аргентиной и Чили. Для начала мы проехали озеро, которое — видимо, для того, чтобы запутать меня, — находилось не на той стороне дороги, как это было показано на карте (как выяснилось, это произошло потому, что мой партнер держал карту вверх ногами). Вскоре после этого нам повстречался человек с машиной, застрявший в этой глуши, потому что кончился бензин. До ближайшего форпоста цивилизации оставалось несколько часов пути. Но мы-то провели предварительные расчеты и точно знали, где находимся. Мы представляли, где наша точка назначения и сколько времени до нее ехать. Поэтому мы могли спокойно поделиться половиной бензина, который имелся у нас в запасной канистре. Заправив машину, незнакомец помчался дальше, причем на дикой скорости. Нам едва удавалось не отстать от него, так он торопился добраться до следующей заправки, и в итоге у него снова кончился бензин. Судя по всему, этот человек так и не понял, почему у него возникли проблемы и как избежать подобных ситуаций в будущем.

Советы путешествующим по зыбкому ландшафту

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

• Если смотреть из долины, часто видишь только ближайшие горы, а другие (иногда гораздо более высокие) пики, расположенные за ними, совсем не видны. Об этом не стоит беспокоиться. Когда вы заберетесь на ближайшую вершину, то окажетесь в лучшем положении (и в лучшей форме), чтобы увидеть открывшийся более широкий пейзаж.
• Чем больше времени требуется, чтобы добраться до любого из удаленных пиков в адаптивном ландшафте, тем выше шансы, что к моменту, когда вы туда доберетесь, его уже не будет на месте.
• Скорее всего, вы не сможете сразу увидеть самые лучшие вершины. Но по крайней мере вы поймете, где находятся основные горные хребты. Кроме того, в горах даже долина может располагаться выше, чем холм на равнине.
• Можете быть уверены, что в горах все пики достаточно высокие. Не имеет значения, на какой из них вы собираетесь забраться, ваша цель — просто карабкаться.
• Только когда вы окажетесь на вершине, будет легче увидеть, какой из пиков действительно самый высокий.

Давайте проверим эти идеи на практическом примере (рис. 15.2). Предположим, вы отвечаете за команду, которая использует устаревшие процессы, и ее эффективность в результате находится на ужасающе низком уровне…

1. Прежде чем радикально менять команду и процессы, выполните ряд мелких шагов, чтобы несколько улучшить ее положение в адаптивном ландшафте (через повышение дисциплины, принятие стандартов по написанию кода, улучшение ежедневной коммуникации и так далее). Когда команда окажется в лучшей форме, ее членам будет легче увидеть, понять и принять радикальные изменения.
2. После этих небольших изменений команда будет лучше подготовлена к более радикальным реформам (вроде внедрения Экстремального программирования, Scrum или канбана). Эти реформы должны быть реализованы небольшими «прыжками» в течение нескольких дней или недель. Не затевайте крупную реорганизацию, на которую уйдет несколько месяцев: за это время оптимальное положение в адаптивном ландшафте, к которому вы стремитесь, может исчезнуть.
3. Не стоит ожидать, что совершенный командой «радикальный прыжок» (например, внедрение Scrum в полном объеме) сразу же значительно повысит ее эффективность. На некоторое время может возникнуть ситуация, когда эффективность даже снизится. Если вы все сделали правильно, проведенная вами радикальная реформа (кайкаку) будет прыжком в правильном направлении и вы, скорее всего, окажетесь поблизости от горного хребта. Теперь при помощи ретроспектив вам предстоит провести постепенные пошаговые улучшения (кайдзен), чтобы взобраться на ближайшую вершину. Есть много способов постепенно повысить эффективность команды. И не слишком беспокойтесь в этот момент, правильный ли выбор вы сделали, решив внедрить Scrum. Если вы выбрали хорошую методологию и на этой основе постепенно оптимизируете эффективность команды, то все в порядке.
4. После того как данный этап оптимизации будет завершен, у команды появится возможность осмотреться в адаптивном ландшафте. Команда может даже захотеть провести еще одну полурадикальную реформу и перейти на Экстремальное программирование или канбан, если считает, что это позволит ей еще больше повысить свою эффективность.
5. После прыжка на очередной многообещающий пик команде опять предстоит заняться постепенной оптимизацией, которая даст ей возможность еще больше повысить свою глобальную приспособленность к реализации проектов.

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

Снижение производительности, которое наблюдается в командах после любых изменений, отображено на кривой изменений, предложенной Вирджинией Сатир (рис. 15.3) [Satir 1991]. С точки зрения сложности это явление можно визуализировать как попадание после прыжка в долину в адаптивном ландшафте. С этого момента должно начаться регулярное, непрерывное улучшение. Низкая эффективность — не более чем временный эффект, который достаточно трудно предотвратить.

Похожие результаты были получены Робертом Глассом, который также обнаружил, что в процессе научения пользованию новыми инструментами или техниками качество и эффективность сначала снижаются, прежде чем вновь вырасти [Glass 2003: 23].

Измените внешнюю среду: пусть гора придет к вам

«Если Магомет не идет к горе, то пусть гора идет к Магомету». В этом виде цитата из истории Магомета, конечно, неверна, поскольку в правильном виде она звучит так:

Если гора не идет к Магомету, то Магомет пойдет к горе.

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

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

Если вы менеджер, то у вас действительно есть возможность изменять внешнюю среду так, чтобы командам было легче достигать более высокой эффективности. Можно проанализировать и путем переговоров изменить контракты с клиентами и поставщиками. Не исключено, что понадобится поработать с административным и финансовым отделами, а также с отделами HR и маркетинга, чтобы их политика начала поддерживать самоорганизующиеся гибкие команды, а не устраивать им обструкцию [Cohn 2009: 38–39]. Также важным аспектом внешней среды будет организационная структура, которую мы обсуждали в главе 12 и главе 13. С точки зрения трудности перейти от функциональных команд к кросс-функциональным и от иерархического принятия решений к сетевому — это все равно что передвинуть вулкан Охос-дель-Саладо из Анд в Амстердам.

Но есть один аспект, который может компенсировать любые негативные последствия и трудности. Это желание меняться.

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

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

Мы постепенно подошли к теме коммуникации относительно организационных изменений. Вам следует прилагать усилия, чтобы люди поняли: непрерывное изменение — это нормальное для организации поведение по умолчанию. Исключением будет как раз отсутствие изменений. Возможно, поэтому стоит избегать термина «реорганизация», который посылает сигнал, что изменения становятся нарушением существующего «организованного состояния». И не давайте своим инициативам названия вроде «Качество-2012» или «Переход к гибким методологиям». Это, опять же, подчеркивает, что организационные изменения — какое-то «экстраординарное» явление, имеющее начало и конец [Cohn 2009: 34]. Если вы будете относиться к изменениям как к «исключению из правил» или отходу от нормы, то дадите людям убедительный повод для снижения мотивации в тот момент, когда они поймут: этот процесс на самом деле никогда не заканчивается.

Часто эксперименты с изменениями имеют форму пилотных проектов. Но, если их проводить в специально созданных тепличных условиях, пилотные проекты бесполезны. Сложность проблем, с которыми приходится иметь дело в реальности, часто превосходит возможности «рабочих групп», специальных «комиссий» и других специально созданных для решения конкретной проблемы объединений, функционирующих в искусственных условиях [Dent 1999: 14]. Сама по себе идея проведения эксперимента вполне продуктивна. Эксперимент — это как отправка разведчика в адаптивный ландшафт, с целью удостовериться, не подстерегают ли основную массу войск какие-то опасности. Но тепличные условия, в которых такие эксперименты часто проводятся, сильно отличаются от реальных. Реакции искусственно созданной среды будут не похожи на реакции реальной. Например, не имеет особого смысла тестировать методики канбана в рамках какого-то побочного проекта, не важного и не приоритетного для компании. Приобретенный таким способом опыт будет неприменим в реальных условиях и не поможет предсказать, какими будут результаты внедрения в ходе реальных проектов.

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

Сделайте изменения желанными

Мне нравится меняться, когда в результате улучшается мое самоощущение. Так, я изменил стиль своих презентаций, перейдя от использования фотографий к рисункам, потому что простые рисунки как раз входили в моду. Я попытался изменить стиль своего общения в Twitter и Facebook, поскольку доверял мнению экспертов, что это поможет улучшить мой бизнес. Я купил смартфон Google Nexus One, поскольку это дало мне статус первого (и практически единственного) владельца такого устройства в нашей компании. И я вступил в политическую партию как раз в тот момент, когда у нее дела шли особенно хорошо — нас же учат ассоциировать себя с победителями.

Люди готовы изменять свое поведение, если это престижно. Есть разные способы воспользоваться данным принципом, чтобы помочь командам изменить привычные способы работы:

• Продемонстрировать, что новая модель поведения сейчас на пике моды и что отказ меняться заставит людей воспринимать вас как зануду-консерватора с причудами.
• Дать возможность экспертам, к которым сотрудники испытывают доверие, поделиться своим энтузиазмом и опытом, потому что энтузиазм заразителен.
• Праздновать даже небольшие успехи, потому что в результате люди начнут ассоциировать изменения в нужном направлении с победой, счастьем и бесплатной выпивкой.
• Сделать так, чтобы изменения удовлетворяли внутренние потребности людей: любознательность, идеализм, независимость, потребность в общении или стремление повысить свой статус (см. главу 5).
• Создать ассоциацию между изменениями и еще чем-то, что нравится людям. Лекарство должно иметь вкус, перед которым невозможно устоять, — например, темного шоколада.

В этом контексте интересно вернуться к главе 12, в которой мы говорили о различных типах коммуникации среди сотрудников. Некоторые эксперты по управлению изменениями рекомендуют проанализировать социально-сетевую структуру организации и идентифицировать в ней людей, которые являются концентраторами, барометрами, объединителями и продавцами, чтобы с их помощью распространить желательную модель поведения по всей компании [Manns, Rising 2005]. Вы также можете воспользоваться кривой восприятия инноваций Эверетта Роджерса (рис. 15.4) и начать с инноваторов, которым нравится пробовать что-то новое. Затем вы постепенно можете охватить ранних последователей, раннее большинство и позднее большинство. При этом не стоит обращать внимание на отстающих, которые в любом случае сопротивляются нововведениям до тех пор, пока их не примут все остальные.

В контексте сложных систем уместно сделать одно предупреждение: менеджерам не следует стремиться к полной организационной гармонии. Часто они считают, что изменения будут успешными, если удалось обратить в свою веру всех сотрудников. Однако на практике это может выливаться в искоренение или подавление расхождений во взглядах, которые на самом деле необходимы для спонтанных креативных изменений [Stacey 2000a: 105].

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

Сделайте застой болезненным

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

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

Вот к какому выводу в результате я пришел: воспринимаемая ценность изменений пропорциональна масштабу проблем, которые наступят, если данные изменения не реализовать.

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

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

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

О пользе ошибок

Ошибки — это неотъемлемая часть биологических процессов. ДНК подвергается постоянному воздействию химических веществ, радиации и ошибок копирования. В каждом человеческом эмбрионе присутствует около 100 мутаций, большинство из которых не будут ни полезными, ни вредными [Le Page 2008: 33]. Но даже в тех случаях, когда ошибки не важны и не вызывают немедленного эффекта, они расширяют набор возможных реакций системы в случае, если в будущем возникает неожиданная ситуация.

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

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

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

Стратегия шума

Мутации в сложных системах, независимо от того, преднамеренные они или нет, представляют собой «случайный процесс». Сначала возникает сама мутация, и лишь затем внешняя среда решает, будет ли данное изменение полезным. Таким образом, полезность мутаций можно назвать случайным результатом [Gell-Mann 1994: 67]. Они позволяют выяснить, что работает, а что нет. Следовательно, к ошибкам нужно относиться не как к безусловно нежелательному явлению, а как к механизму обучения [Weinberg 1992: 181].

В книге «Управление фабрикой дизайна» (Managing the Design Factory) Дональд Райнертсен убедительно показал, что невозможно максимизировать доступную нам информацию, если целиком ориентироваться на максимизацию успеха [Reinertsen 1997: 71–79]. Многие специалисты по теории сложности разделяют представление, что, если вы стараетесь не совершать ошибок вообще, многому вы не научитесь.

Преднамеренные или случайные ошибки должны стать неотъемлемой частью любого творческого процесса. Эволюцию можно воспринимать как систематическое управление ошибками.

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

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

Еще 6000 лет назад люди выяснили, что нагревание металлов с последующим охлаждением меняет их свойства, в частности повышает прочность и твердость (металлов, не металлургов!). Это процесс называется закалкой. При нагревании атомы металла приходят в движение, а когда металл быстро охлаждают, атомы образуют более регулярную структуру. Это своеобразная форма «снятия стресса», при которой намеренное воздействие помогает системе легче обрести новое равновесие, чем она могла бы сделать без вмешательства извне.

Исследователи полагают, что подобные явления происходят и в сложных системах. Ошибки и шум в системе, привносимые внешней средой, приводят систему в движение, позволяя ей отойти от субоптимальных результатов и относительно более легко перейти в лучшее состояние. Ученые называют этот процесс модельной закалкой; в нем случайность помогает системе найти глобальный оптимум [Miller, Page 2007: 24, Lissack 1999: 115–116].

Это выглядит как будто бы систему во время прогулки по адаптивному ландшафту подталкивают в том или ином направлении, заставляя скатиться с холма, на котором она могла застрять (рис. 15.5). После такого толчка система может внезапно оказаться в долине, а оттуда добраться до более высокого пика. Модельная закалка демонстрирует, как случайные процессы оказываются полезны при движении по адаптивному ландшафту [Miller, Page 2007: 108].

А разве все не наоборот? Я рисую адаптивные ландшафты, как это обычно делают биологи — точкам максимальной приспособленности соответствуют пики. Это интуитивно понятнее, поскольку с совершенством обычно ассоциируются вершины. Однако физики рисуют адаптивные ландшафты ровно наоборот: у них позициям наибольшей приспособленности соответствуют самые низкие положения. И действительно, для иллюстрации понятия модельной закалки их способ подходит лучше, поскольку в результате «встряски» система благодаря гравитации скатывается вниз, к более оптимальному положению. Но не забывайте, что, как бы вы их ни рисовали, адаптивные ландшафты — это метафора. В действительности нет никаких горных цепей, встрясок или гравитации. Есть только чрезвычайно сложная математика.

При разработке ПО аналогичный подход позволяет командам не застрять в точке локального оптимума и найти способы повышения своей эффективности. Демарко и Листер призывают использовать политику «конструктивного привнесения дозированного беспорядка» [DeMarco, Lister 1999: 160]. Я иногда называю это «повышение эффективности через несовершенство».

Стратегия секса

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

Кроссинговер — способ, к которому прибегает природа, чтобы биологические виды могли достигать пиков в адаптивном ландшафте за один прыжок, а не в результате серии мелких шагов. Ребенок наследует половину своих генов от матери, а другую половину — от отца. Мать и отец — вполне приспособленные особи, каждая из которых располагается в своем адаптивном ландшафте на пике или где-то рядом с ним. (Если бы это было не так, они были бы больны или мертвы — в том и другом случае размножение было бы затруднено.) Случайным образом перемешанные гены, унаследованные ребенком, помещают его в адаптивном ландшафте где-то посередине между отцом и матерью. Если в этой точке долина, то ребенок будет хуже приспособлен к данной среде, чем его родители. Но существует достаточно высокая вероятность, что в этой точке может оказаться даже более высокий пик, чем те, на которых находятся его родители. С точки зрения сложных систем две системы произвели на свет третью, которой за один прыжок удалось достичь более высокой точки в адаптивном ландшафте (см. рис. 15.6)!

Данная стратегия работает, потому что в сильно пересеченных адаптивных ландшафтах пики часто группируются. Поэтому при выведении улучшенных сортов растений или при разведении скаковых лошадей люди применяют кроссбридинг [Holland 1995: 66]. В качестве родителей берут две особи, показавшие лучшие результаты, их гены перемешивают и в итоге получают потомство, которое часто превосходит своих родителей.

Мутации — это способ, при помощи которого природа ставит эксперименты. Это осторожные шаги в новых направлениях с помощью произвольного изменения маленьких составляющих системы. Кроссинговер позволяет природе объединять хорошо зарекомендовавшие себя практики. Это способ относительно безопасно совершить прыжок в адаптивном ландшафте и таким образом провести дополнительное исследование территории, о которой в общих чертах уже известно достаточно много [Miller, Page 2007: 184].

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

Стратегия горизонтального переноса опыта

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

Микробы обмениваются друг с другом генной информацией, выбрасывая геномный материал. Исследования показывают, что 10% геномов бактерий заимствованы у других видов бактерий, и это типичный показатель. Известный микробиолог Карл Вёзе даже полагает, что горизонтальная генная передача была доминирующей формой эволюции до тех пор, пока у многоклеточных организмов не закрепилось половое размножение [Buchanan 2010: 34–37]. Считается, что беспорядочное распространение генетического кода среди разных видов позволило создать «объединенный генетический механизм», что в свою очередь позволило с большей легкостью видам делиться друг с другом инновациями.

Бактерии крайне расточительны и неразборчивы в том, что касается обмена генами — они практикуют истинный генетический коммунизм. <…> Иногда бактерии занимаются «сексом», обмениваясь генетическим материалом через межклеточные «мостики». В других случаях просто происходит выброс содержащих генный материал плазмид и вирусоподобных фрагментов, адресованных «всем и никому конкретно». В том и другом случае результатом становится свободный обмен генной информацией. Одно из следствий такого обмена генами — гораздо бóльшая коллективная адаптивность.

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

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

Мне представляется очевидным, что организации должны применять все три стратегии для постоянного улучшения: мутации, кроссинговер и горизонтальную передачу. Мутации необходимы при осуществлении постепенных улучшений в неизвестных и потенциально опасных ландшафтах. Кроссинговер нужен для осуществления более радикальных изменений путем комбинирования методов и команд, которые уже достаточно эффективны. А горизонтальный перенос требуется для копирования практик между командами, что позволит им сдвигаться в «новых» направлениях, которые уже знакомы остальным (рис. 15.7).

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

Вы хотите сказать, что состав команд должен постоянно меняться? Вообще-то нет, я несколько преувеличил. Первый год может быть посвящен оптимизации структуры команд, следующий — стандартным процессам, а затем оптимизации уровней управления или бизнес-единиц. В здоровой организации какие-то из ее частей всегда находятся в стадии (ре)формирования. Я не хочу сказать, что состав команд должен постоянно меняться. Это противоречит требованию, что команды должны оставаться стабильными достаточно протяженный промежуток времени, о чем более подробно сказано в главе 13.

Компьютерные симуляции показывают, что комбинация мутаций, кроссинговера и горизонтального переноса — прекрасный способ достичь глобального оптимума эффективности [Buchanan 2010: 36]. Мы имеем право предположить, что то же самое применимо к командам и организациям. Используйте метод мутаций, чтобы создавать инновации. Пользуйтесь горизонтальным переносом, чтобы копировать инновации у других команд. И применяйте метод кроссинговера для создания новых практик путем комбинирования уже известных.

Но биологические виды далеко не то же самое, что бизнес! Это правда. Биологические изменения — ненаправляемые, в то время как оптимизация в бизнесе — направляемая (см. конец главы 14 «Ландшафт изменений»). Биологические виды производят потомство с большим запасом, чтобы из него одна или две особи в конце концов пошли в нужном направлении. В бизнесе для достижения аналогичных результатов мы можем воспользоваться прогнозированием. При этом как биологические виды, так и бизнес могут процветать, а могут и потерпеть неудачу. С точки зрения практических результатов я не вижу разницы между ненаправляемыми и направляемыми изменениями.

Не копируйте улучшения

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

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

Примеры?

«Не надо заключать контракты с фиксированной ценой и фиксированным объемом разработки, потому что…»

Звучит разумно, но мне от этого не легче, поскольку мои клиенты заключают только такие контракты. Вы рекомендуете мне прикрыть свой бизнес?

«Не нужно начинать с объемных и детализированных требований к продукту, поскольку…»

Возможно, но клиент только что вручил мне технические требования на 500 страниц и готов платить за то, чтобы я их реализовал. Советуете мне отказаться от этого проекта?

«Команды должны быть кросс-функциональными и располагаться в одном помещении, при этом в них должны быть собраны специалисты всех необходимых профилей, потому что…»

Это было бы здорово, но, помимо меня, клиент для концептуального проектирования только что нанял еще одну компанию, а их офис находится на другом конце страны. Я должен попросить их переехать к нам?

«Продолжительность итераций должна составлять две недели, потому что…»

Да, но в чем польза от этого совета, если у меня краткосрочный проект, который продлится как раз две недели?

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

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

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

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

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

Несколько завершающих практических советов по теме непрерывного улучшения

Трудно предложить более конкретные рекомендации по непрерывной оптимизации. Как отмечалось в главе 14 «Ландшафт изменений», природа сложности такова, что практически невозможно предложить универсальные подходы, которые подошли бы большинству организаций. И тем не менее я постараюсь дать вам несколько простых советов, которые вы сможете использовать, приспособив их к своей ситуации.

• Регулярно проводите ретроспективы, на которых обсуждайте текущее положение дел и способы внесения в него улучшений. Ретроспективы могут проводиться на разных уровнях в организации, а не только на уровне команд. Вы должны позаботиться о том, чтобы речь на них шла не только об адаптации (реагировании на возникающий в процессе разработки опыт), но и об исследовании (экспериментировании) и прогнозировании (подготовке к возможному развитию событий). Этим вы сможете обеспечить, чтобы двойные циклы обучения учитывали как уже состоявшиеся, так и возможные будущие события. Огромное количество полезных советов об организации ретроспектив можно найти в книге «Ретроспективы в гибких методологиях» (Agile Retrospectives) [Derby, Larsen 2006].
• Ведите журнал улучшений для каждой команды и на разных уровнях в организации, при этом журналы должны быть доступны всем. Это помогает людям отслеживать идеи, которые пока еще не внедрены. Как и в случае с любыми другими журналами, в любое время старые идеи, которые так и не были внедрены, могут быть заменены в них на новые [Cohn 2009: 62–63]. Может потребоваться ежемесячно резервировать для непрерывной оптимизации какое-то время в графиках загрузки, иначе есть риск, что идеи, перечисленные в журнале оптимизации, будут лишь обсуждаться, но до внедрения дело так и не дойдет.
• Создайте в очевидном виде цикл улучшений, состоящий из отдельных этапов. При этом вы можете использовать как те восемь этапов, которые я перечислил при описании обобщенного процесса оптимизации SLIP, так и любую другую серию этапов, которую находите полезной. Как и задачи, представленные на любой доске задач, применяемых в Scrum и канбане, позиции в журнале оптимизации должны пройти определенные стадии проработки, что поможет не пропустить ни одного из важных шагов (например, этапы измерения и проверки).
• Создайте переходную группу сотрудников (их еще иногда называют сообществами лидеров изменений), задачей которой будет продвигать и поддерживать изменения на уровне организации в целом. В эту группу должны входить старшие менеджеры и представители всех подразделений организации, которым предстоит переход на новые методы работы. Задачей «чемпионов изменений» будет не навязывать данные изменения, а помогать людям в их осуществлении [Cohn 2009: 63–70]. Как мы обсуждали ранее, поскольку изменения никогда не заканчиваются, такие группы могут создаваться на полупостоянной основе.
• Изучайте методы канбана, которые представляют собой отличный инструмент для управления непрерывным улучшениям. Канбан — управление изменениями, где в качестве механизма используются ограничения на объем незавершенного производства, а также широко применяется визуализация потоков ценности (или сетей создания ценности) как способ предъявления командам необходимости изменений [Anderson 2010].
• Рекомендуйте сотрудникам своей организации инициировать создание собственных сообществ по оптимизации вокруг тем, которые выходят за рамки отдельных проектов. Примерами таких тем могут быть тестирование, разработка архитектуры или пользовательских интерфейсов [Cohn 2009: 70–78]. Если вы менеджер, то лучше не создавать такие сообщества самому, поскольку это должны делать сами команды в результате самоорганизации и в зависимости от своих потребностей. В случае необходимости вы всегда сможете им помочь. (Такие сообщества будут результатом самоотбора, который мы обсуждали в главе 13.)

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

Продолжайте движение

Изменяющаяся внешняя среда — а в случае коэволюционирующих систем и Гонка Черной Королевы — оказывает огромное воздействие на адаптивные ландшафты. В результате эти ландшафты как будто бы сделаны из резины (по ним было бы удобно передвигаться на роликах). Пики и долины постоянно сдвигаются, растут или понижаются. Система, которая еще вчера была отлично приспособленной, завтра может оказаться совершенно неприспособленной к изменившейся внешней среде. Сегодняшние лучшие практики завтра могут превратиться в худшие. Биологические виды, компании и команды должны постоянно изменять себя, поскольку требуется бежать изо всех сил, чтобы не сорваться с постоянно движущегося пика. А если гора вдруг превращается в долину, нужно уметь перепрыгнуть на соседнюю вершину.

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

Гарантия выживания заключается в гибкости.

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

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

Резюме

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

Одним из способов движения будет внесение изменений в сам ландшафт. Это подразумевает целенаправленное изменение внешней среды (включая клиентов, топ-менеджмент и различные подразделения внутри компании), чтобы создать условия, позволяющие командам найти точку своей максимальной эффективности. Еще одна стратегия, которой могут воспользоваться менеджеры, — сделать изменения желательными с точки зрения сотрудников, а стагнацию — болезненной.

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

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

Подумать и сделать

Посмотрим, как применить некоторые идеи из данной главы в вашей компании:

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

Отправить