Структура. Людям нужна твердая почва под ногами, поэтому предоставьте им дорожную карту грядущих изменений. Если вы используете эту книгу в качестве основы для ваших изменений, то раздайте всем ее копии и расскажите, какие части в данный момент используете. Когда что-то неясно, объясните, что нужно сделать, чтобы внести определенность, и когда, по вашим ожиданиям, это произойдет. Если нужен промежуточный шаг, например временные команды, то дайте ясно понять, что это временно, и объясните, что будет дальше.
Масштабные изменения
Изменения, затрагивающие множество людей, гораздо более разрушительны, чем те, которые касаются лишь нескольких команд. Это разрушение имеет тенденцию усиливаться. Появляются слухи, люди начинают беспокоиться о своих рабочих местах, и грядущие перемены становятся предметом ежедневного обсуждения.
Большие перемены (непосредственно затрагивающие 30–70 и более человек) требуют профессионального управления изменениями. В зависимости от размеров вашей организации ваш отдел кадров может иметь в своем составе специалистов по изменениям, которые могут вам помочь. Если вы нанимаете внешних консультантов Agile на этот проект, то поинтересуйтесь их опытом и подходом в области управления изменениями.
Руководители организаций часто недооценивают важность управления изменениями. Это большая ошибка! Используя терминологию модели Сатир, к тому времени, как вся остальная организация узнает об изменениях, руководство организации уже восприняло «трансформирующую идею», которая избавила их от ощущений неприятия и хаоса. Для руководства изменения уже кажутся очевидными и необходимыми. Так почему кто-то может быть не согласен?
И тогда они запускают процесс изменений и сталкиваются с огромным сопротивлением и противодействием со стороны людей, которые только начали проходить сквозь собственные ступени неприятия и хаоса. И это способно загубить на корню весь проект изменений.
Правильный процесс управления изменениями не может предотвратить все разрушения, но может их минимизировать. Не скупитесь. Если вы не готовы потратиться на экспертную помощь, то ограничьте масштабы вашего проекта изменений в направлении Agile всего несколькими командами за раз.
Процессы изменений
Кайдзен – общий термин в сообществе Agile. Это японское слово, означающее «совершенствование». В Agile-сообществе этот термин означает непрерывное постепенное совершенствование[17 - Термин «кайдзен» был импортирован в Agile из концепции бережливого производства (lean manufacturing), которая, в свою очередь, основывается на революционной производственной системе компании Toyota, – отсюда и японский термин. Рифмуется с английским I win – «я выигрываю».].
Непрерывное совершенствование – неотъемлемая часть Agile, так не нужен ли кайдзен в первую очередь для того, чтобы направить ваши усилия к Agile? Парадоксально… но, наверное, нет. Кайдзен предназначен для улучшения существующих методов работы. Если в вашей компании особое значение имеют документы, то кайдзен поможет вам рационализировать документооборот. Если культура вашей организации основана на обвинениях, то кайдзен поможет вам точнее устанавливать вину. Но он не поможет вам перейти с любой культуры на Agile.
Чтобы перейти с одного стиля работы на другой, вам понадобится другое японское слово – кайкаку. Оно означает «трансформационное изменение». Вместо того чтобы постепенно улучшать существующие процессы работы, как это делает кайдзен, кайкаку фундаментально меняет основополагающий подход.
Все лучшие команды Agile, которые я знаю, начинали с кайкаку. Они разобрались, что им нужно от Agile, как они собираются инвестировать в достижение этого результата, и пошли ва-банк.
Я вижу команды Agile, которые работают посредственно, значительно чаще, чем те, которые функционируют прекрасно. Первых объединяет то, что их компании в свое время не пошли ва-банк. Они пытались проложить свой путь к Agile через кайдзен. Поначалу кажется, что это работает, но потом все неизбежно останавливается. Люди выгорают из-за несовпадения идей Agile и ценностей компании. Они устают впитывать новые идеи. Изменения вызывают переутомление, прогресс начинает тормозиться и после многолетних усилий полностью останавливается. По иронии судьбы, разрушения при таком способе продвижения к Agile значительно более длительные, чем при кайкаку.
Если ваша компания – новичок в идеях Agile (даже если вы уже используете это слово), то вам нужен кайкаку. Определите зоны применения, выделите необходимые средства, и пусть каждая команда начнет использовать все соответствующие практики сразу. Возможно, это звучит пугающе, однако на самом деле это быстрее и безопаснее, чем осваивать практики постепенно.
Если у вас много команд, то, вероятно, безопаснее действовать постепенно, но даже тогда кайкаку – лучший вариант для вас. Вместо того чтобы в соответствии с кайдзен постепенно внедрять Agile во многих командах, примените кайкаку, чтобы полностью внедрить Agile в подгруппе команд. Если нужно двигаться еще более мелкими шагами, то начните всего с одной команды и, возможно, только с одного уровня фокусировки. Затем добавьте уровень поставки. Далее добавьте еще одну команду, возможно, вместе с уровнями фокусировки и поставки. По мере накопления опыта увеличьте размер шага изменений.
Команды, уже работающие по Agile, могут использовать кайдзен для достижения лучших результатов в рамках их нынешних областей компетентности. Более подробная информация доступна в главе 11. Чтобы добавить новые области (например, если команда компетентна на уровне фокусировки и хочет стать таковой на уровнях поставки и оптимизации), лучше всего выбрать кайкаку. Новые уровни требуют новых инвестиций и серьезных изменений, и лучше делать все сразу.
Успешный кайкаку требует дисциплины и заботы. Рассмотрим, с чего все начинается.
Заручитесь поддержкой руководства
Agile требует поддержки руководства. Без нее несоответствие между Agile-практиками вашей команды и никак не связанной с Agile культурой вашей организации будет вызывать постоянные трения. Если вы сами руководитель, постарайтесь сделать так, чтобы ваш непосредственный руководитель был на вашей стороне, и будет совсем хорошо, если коллеги тоже вас поддержат.
1. Начните с разговора
Все начинается с разговора. Часто проще всего разговаривать один на один, вы получите наилучший результат, если будете общаться лично или, по крайней мере, по видеосвязи. Начните с одного из влиятельных руководителей, которому вы доверяете, и завербуйте его в свои союзники. Он поможет разобраться, с кем еще вам нужно поговорить и как найти к ним подход.
В этих разговорах, начиная с того самого первого руководителя, говорите о проблемах в разработке ПО, с которыми сталкивается ваша организация. Возьмите за основу преимущества, описанные в предисловиях к частям II–IV, и расскажите о том, насколько, по вашему мнению, разработка программного обеспечения могла бы вестись лучше в вашей компании. Не монополизируйте разговор; вовлеките в него вашу аудиторию. Вкратце обрисуйте преимущества свободного владения навыками на каждом соответствующем уровне и поинтересуйтесь, какие уровни важны по мнению собеседников. Спросите почему. Слушайте больше, чем говорите. Прежде всего фокусируйтесь больше на том, что они могут получить и к каким потерям может привести бездействие, чем на продвижении Agile ради него самого. На самом деле, учитывая степень всеобщего недопонимания, что такое Agile, вам может быть лучше вообще не упоминать этот термин.
2. Получите одобрение экономичного покупателя
Ваша конечная цель – поговорить с человеком, обладающим полномочиями распоряжаться инвестициями, которые понадобятся вашей команде. В продажах этот человек называется экономичным покупателем (economic buyer).
Экономичные покупатели часто бывают окружены своего рода привратниками, работа которых – беречь время экономичного покупателя. Они предложат вам передать всю информацию им, чтобы они могли презентовать ее покупателю. Они не пытаются украсть вашу идею; они пытаются помочь экономичному покупателю сберечь его время. Иногда они пытаются убедить вас, что покупатель на самом деле – это они, даже если у них в действительности нет необходимых полномочий.
Не дайте себя обмануть. Заручиться поддержкой привратников полезно и часто даже необходимо, однако этого недостаточно. Они не смогут одобрить нужные вам инвестиции. Вам нужно разговаривать с реальным экономичным покупателем.
До этого разговора фокусируйте ваше общение на выгодах Agile: что на кону. Вопрос инвестиций, скорее всего, будет отвлекать или даже вызывать беспокойство, поскольку люди, с которыми вы будете разговаривать, не имеют полномочий управлять инвестициями.
Когда разговор с экономичным покупателем наконец состоится, вашей целью будет получить его принципиальное согласие инвестировать в Agile. Вероятнее всего, ваше время будет ограниченным, так что удерживайте фокус на общей картине. Кроме того, часто лучше провести эту встречу в формате диалога, а не презентации со слайдами, хотя в вашей конкретной ситуации, скорее всего, ваши союзники смогут предложить вам наилучший подход.
Во время встречи с экономичными покупателями говорите о том, чего они хотят от их организации и как Agile может в этом помочь. Это может сработать еще лучше, если кто-то из руководителей, кому они доверяют, будет говорить от вашего имени.
Заполучив в команду союзников экономичного покупателя, начните говорить об инвестициях. Не перегружайте собеседников излишними подробностями; кратко перечислите несколько ключевых инвестиций, необходимых каждому уровню (врезка «Список необходимых инвестиций» в главе 4 поможет вам подготовиться), а также то, как эти уровни соотносятся с пожеланиями покупателя. Спросите его, какой компромисс между размером инвестиций и выгодой он считает приемлемым. Если вы предложите несколько вариантов, а не потребуете ответа «да или нет», это понизит шансы категорического отказа.
При условии, что экономичный покупатель в принципе согласился инвестировать в Agile или по крайней мере считает возможным дальнейшее рассмотрение этого вопроса, попросите разрешения подготовить конкретное предложение. Спросите, что он хотел бы увидеть в нем в целом, чтобы его одобрить. Попросите рекомендовать конкретное контактное лицо, спонсора, с которым вы будете работать, сообщите дату, когда предложение будет готово (лучше сделать его в течение одного-двух дней, поэтому хорошо иметь готовый черновик документа), и спросите, когда ожидать ответа.
В конце разговора попросите разрешения напомнить. Вероятнее всего, с вами не свяжутся в оговоренный день, поэтому хорошо иметь возможность сказать что-то вроде: «Напоминаю, как вы и просили».
3. Сделайте официальное предложение
Если вы добрались до этого этапа, то поздравляю! Вы преодолели самое важное препятствие. Сейчас вам нужно пройти через официальное предложение.
Степень формальности предложения зависит от вашей организации. Ваш спонсор и ваши союзники помогут вам разобраться, как лучше оформить предложение, помогут доработать его, правильно преподнести экономичному покупателю. Действуйте оперативно, вежливо и настойчиво.
В вашем предложении опишите преимущества, которые может получить ваша организация, и инвестиции, которые ей необходимо сделать. Будьте конкретны. В главе 3 описываются преимущества в целом, а в предисловиях к частям II–IV дана более подробная информация. Перенесите эти преимущества на вашу конкретную ситуацию, на инвестиции, которые экономичный покупатель готов сделать, и объясните, что в реальности это означает для вашей организации.
При подготовке инвестиционного аспекта вашего предложения прочитайте главу 4 и переведите каждый шаг в конкретный запрос. В каких-то инвестициях вам, вероятно, придется пойти на компромисс. В главе объясняется, как это сделать. Но постарайтесь избежать слишком больших компромиссов. В конечном счете именно инвестиции делают возможными преимущества Agile.
Выход на экономичного покупателя
Приведу пример того, как вовлеченность руководства работает в сложной ситуации; он взят из моего собственного опыта в роли консультанта. Это не было обычным проектом по переходу организации к Agile, поэтому у вас все будет иначе, но этапы обсуждения в организации наверняка будут похожими.
Изначально ко мне обратился менеджер по проектированию компании, насчитывающей несколько сотен инженеров и порядка 45 команд разработчиков программного обеспечения. Этот руководитель искал кого-нибудь, кто возглавил бы маленькую команду. Мы поговорили, и я узнал, что у них были сложности с взаимодействием команд. Я предложил свою помощь в решении этой проблемы.
Этот руководитель нашел мои идеи касательно масштабирования довольно содержательными и представил меня своему вице-президенту по проектированию. Мы поговорили спустя две недели. Ему понравилось то, что я сказал, и еще через полторы недели мы обедали с его боссом – директором по продукту. Он и был экономичным покупателем.
Во время того обеда директор по продукту высказал ряд опасений, касающихся его организации. Мы обсудили несколько способов, как я могу помочь, и в качестве продолжения запланировали встречу между мной и их директором по управлению продуктами, который также присутствовал на том обеде.
Я встретился с директором через неделю. Он не являлся покупателем, поэтому моей целью было не убедить его, а узнать больше информации о компании. Я также хотел убедиться, что мы правильно понимаем друг друга, поскольку нам предстояло тесно сотрудничать. К счастью, мы были на одной волне, и мой собеседник запланировал еще одну встречу с участием нас двоих и директора по продукту.
Эта встреча состоялась на следующей неделе. Наша предыдущая встреча за обедом была нашим шансом познакомиться друг с другом, тогда как эта встреча была моим шансом заручиться поддержкой директора по продукту.
Я не пытался развернуть рекламную кампанию. Я никогда не считал полезным говорить людям, что они должны хотеть. Вместо этого я задавал вопросы. У меня была реальная цель: я хотел понять потребности директора по продукту и проинформировать его о тех моментах, которые чреваты трудностями или даже проблемами. Я спросил его, как он представляет себе успех, как он поймет, что успех достигнут, и как, по его ожиданиям, в итоге это повлияет на бизнес.
К концу встречи, которая заняла час, я узнал достаточно, чтобы обрисовать примерный подход и ценовой диапазон. Я спросил, правильно ли я все понял, и мой собеседник ответил утвердительно. Мы ударили по рукам, и я обещал к концу следующего рабочего дня представить детальное предложение, что и сделал. Его рассмотрели в течение недели (директор держал меня в курсе того, что происходило в компании) и одобрили на следующей неделе, внеся небольшие поправки.
Окончательное одобрение заняло еще некоторое время, которое ушло на то, чтобы пробиться сквозь корпоративную бюрократию, однако на тот момент это был уже решенный вопрос. От первой встречи до первого одобрения прошло пять встреч и семь недель. Это довольно быстрый результат для организации такого размера, но они были очень мотивированы. У них была серьезная проблема, которая блокировала прогресс, и они верили, что я могу помочь им решить ее.
Вот те ингредиенты, которые понадобятся и вам: мотивирующая проблема и вера в то, что вы можете ее решить.
Если это выглядит слишком трудозатратным…
Этот осторожный процесс привлечения сторонников предназначен для случаев, когда поддержка под вопросом: если вы работаете со множеством команд, запрашиваете большие инвестиции или работаете в бюрократической организации, для которой идеи Agile не комфортны (даже если люди активно используют это название).
Но иногда все это не так сложно. Иногда вы просто помогаете одной маленькой команде стать более Agile. Если вы и ваш руководитель уже имеете все полномочия, чтобы выделить необходимые вам инвестиции, то просто сделайте это!
Если руководство считает, что они уже Agile…
Некоторые организации (а в наши дни таких много) думают, что они уже Agile. Одна организация говорила мне: «Мы пост-Agile!» Или вы можете услышать: «Мы agile с маленькой буквы “а”, а не Agile с большой буквы “A”!» Но сравнив философию, описанную в главе 1, с тем, как действует организация, вы поймете, что это далеко не так.
Спорить о терминологии бесполезно. Если организация хочет сказать, что она Agile, или пост-Agile, или экстра-супер-пупер-Agile, то пусть говорит. Вместо того чтобы спорить, фокусируйтесь на текущей ситуации: проблемах, с которыми сталкиваются ваши команды, преимуществах, которые организация может получить, и на том, какие инвестиции потребуются для этого.
Если руководство не поддерживает…
Если поначалу вы не можете найти понимание и поддержку у руководства, то не отчаивайтесь. Попробуйте поставить себя на их место. Как Agile может помочь им получить то, что им нужно? Если ответ «не может», то, вероятно, он им и не нужен. Выберите другой подход к разработке программного обеспечения, такой, который лучше впишется в культуру вашей организации. Один из вариантов можно найти во врезке «Как добиться успеха, используя водопадную модель» в главе 4.
Если у вас есть руководитель, которому вы доверяете, то обратитесь к нему за помощью и советом. Если его нет, то попробуйте провести информационное интервью: поговорите с руководителем из другой компании, проходившей через это недавно. (Они могут попытаться нанять вас на работу. Взаимовыгодный вариант, win/win!) Во врезке «Смените организацию» далее в этой главе рассматривается ряд идей на этот случай.
На заре развития Agile, когда это было еще стихийным общественным движением, множество команд приняли экстремальное программирование самостоятельно, при слабой поддержке или согласии руководства, а то и вообще без них. Вы тоже могли бы попробовать это сделать. Но я не рекомендую. Опыт команд, которые попытались это сделать, показал, что кому-то (чаще всего руководителю проекта) в конце концов приходилось все время преодолевать разрыв между корпоративной культурой и философией Agile. Это неблагодарная работа, которая привела к выгоранию команды.
Некоторые используют метод Kanban, чтобы мотивировать организационные изменения[18 - Обратите внимание, что метод Kanban – это значительно более широкое понятие, чем доска Kanban, применяемая некоторыми командами для визуализации планирования.]. Kanban представляет существующие методы работы таким образом, чтобы подчеркнуть узкие места в исполняемой работе и показать стоимость задержек. Его достаточно легко внедрить, и он может мотивировать переход организации к Agile.
Kanban является кайдзен-подходом к изменениям, он медленный и работает только до определенного предела, но очень эффективен и может привести к появлению разрешения на кайкаку. Более подробную информацию вы можете найти в книге [Anderson2010].
Если ничего из того, что вы делаете, не меняет ситуацию, то задумайтесь, а что нужно вам. Представьте, что статус-кво не изменится, поскольку этого, вероятно, и не случится. И тогда или вас это устраивает, или (а часто это как раз такой случай) пришло время перейти в другую, более подходящую вам компанию.
Изменить организацию
Вы можете изменить свою организацию или сменить ее.
Мартин Фаулер
Изменить организацию изнутри непросто, но возможно. Это отнимает много сил и времени, и не всегда оказывается, что оно того стоило. Поэтому более простой способ изменить организацию – сменив работу – может оказаться более разумным выбором. Для тех, кто все же хотел бы попытаться, ниже приведены 13 советов, почерпнутых из моего собственного опыта изменения организации изнутри.
1. Задумывайтесь о своих мотивах. Отвечает ли Agile в наивысшей степени интересам организации или он нужен вам по личным причинам? Есть ли у вас время, энергия и энтузиазм, чтобы проповедовать эти изменения? Есть ли у вас стратегия поиска выхода из проблем, которые могут возникнуть вследствие ваших усилий? Если ответ на любой из этих вопросов – «нет», то смена работы может оказаться лучшим выходом.
2. Организуйте надежную сеть поддержки. Изменения в направлении снизу вверх – неблагодарная работа, часто ведущая к разочарованию. Полагайтесь на семью и друзей, уходите домой вовремя и не живите рабочими проблемами в нерабочее время.
3. Находите для себя маленькие удовольствия. Без поддержки сверху организационные изменения в значительной мере находятся вне вашего контроля. Находите небольшие ежедневные рабочие задачи, благодаря выполнению которых вы будете чувствовать удовлетворение.
4. Не сдавайтесь. Небольшие изменения накапливаются. Поначалу эффект от ваших усилий будет незаметным, но они будут постепенно менять стиль мышления людей в сфере решения проблем. В конце концов, по достижении некоего порога все внезапно начнет меняться.
5. Уважение – ваша валюта. Чем больше люди уважают вас, тем больше ваш авторитет. Завоевывайте авторитет своими действиями и уважительно относитесь к другим, даже в мыслях.
6. Оставайтесь внутри сферы своего влияния. Изменения снизу требуют постоянного повторения. Пытайтесь вносить изменения только в тех отделах организации, с которыми вы находитесь в постоянном контакте.
7. Пополняйте ряды сторонников. Найдите хотя бы одного человека, который уважает вас и ваши идеи и имеет большее влияние, чем вы. Привлеките его к распространению ваших идей.
8. Находите пробелы. Люди должны хотеть изменений, но они будут их хотеть, только если это дает им что-то, что они не могут получить другим способом, или если это убережет их от потери чего-то ценного для них. Фокусируйтесь на этих моментах.
9. Вникайте в причины. Всегда есть причины, почему что-то делается именно так, а не иначе, и вы можете сделать свое вмешательство более эффективным, если разберетесь, что это за причины.
10. Повторяйте. Продвигайте свою идею изменений снова и снова, разными способами и разным людям. Но старайтесь не быть назойливым.
11. Не критикуйте все подряд. Выберите что-то одно и работайте с этим. Если вы будете находить проблемы во всем, то люди просто перестанут вас слушать.
12. Не ищите признания. Если вы успешны, то люди начнут повторять ваши идеи, как если бы они были их собственными. Это не плагиат. Ваши усилия на самом деле могут изменить мышление людей, при этом они даже не будут это осознавать. Пусть они так думают. Они будут более усердно трудиться ради собственных идей.
