Scrum на практике. Высокая продуктивность и результаты – прямо сейчас

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

Все это напоминает мне историю создания революционной книги Антуана Лавуазье Traité élémentaire de chimie («Элементарный курс химии») в 1789 году. Лавуазье предположил, что с помощью строгих экспериментов можно вывести следующие базовые принципы.

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

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

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

Его идеи ошеломляли. Его работа стала одной из тех, что разделили историю науки на «до» и «после». До Лавуазье ученые и интеллектуалы предполагали, что мир работает определенным способом. После – стало понятно, что все иначе. Зародилась современная химия. Мир основательно изменился. Все современное – от кнопок на вашей одежде до холода в холодильнике, от краски, которой напечатана эта книга, или чипов, управляющих устройством, с которого вы читаете эти слова, – стало возможным благодаря его открытию.

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

Новый способ мышления

После публикации моей первой книги, написанной в соавторстве с моим отцом Джеффом Сазерлендом, «Scrum. Революционный метод управления проектами»[2], все больше людей постепенно соглашались с тем, что мы находимся в эпицентре подобного изменения в мире бизнеса. Революция управляет переменами в этой сфере. И, как и работа Лавуазье, она показывает новый мир, в котором неприменимы ограничения старого. Последнее время в своих переговорах с CEO[3], исполнительными директорами и компаниями я использую новую фразу: Scrum – искусство изменять возможности.

Потребность в этой методике продиктована быстрыми социальными, экономическими и политическими изменениями, которые, в свою очередь, обусловлены невероятной скоростью развития технологий. Наверное, вы слышали о законе Гордона Мура, сооснователя компании Intel. В 1965 году он написал работу с занимательным названием «Впихивание большего количества компонентов в интегральные схемы» (Cramming More Components onto Integrated Circuits). Законом Мура названо заключение этой публикации: количество транзисторов, размещаемых на кристалле интегральной схемы, удваивается каждые два года. Экспоненциально. Да, и цена этой возросшей вычислительной мощности при этом падает вдвое.

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

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

Один. Только один. На двадцать девятый день кувшинки покроют половину пруда. А на следующий задушат его полностью.

Предложу другой пример того, что даст удвоение количества транзисторов и вычислительных мощностей. Используем известную историю с зернами пшеницы на шахматной доске, которая датируется 1256 годом[4] (представляете себе теперь, как давно люди задавались подобными вопросами). Если вы положите одно зерно пшеницы на первую клетку доски, а на каждую последующую вдвое больше, чем на предыдущую, то к тому времени, как вы доберетесь до последней, вам придется удвоить количество зерен 63 раза. И на последней клетке окажется 9 квинтиллионов (9 223 372 036 854 775 808, если точнее) зерен пшеницы. Это большое, очень большое число. Непостижимое. И оно показывает скорость изменений в мире. Старые способы работы ломаются, сталкиваясь с быстро меняющимися проблемами, которые оказываются за пределами их пропускной способности. Запутанность уже не редкость; с ней нам приходится сталкиваться ежедневно.

Что происходит потом

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

Чтобы по-настоящему использовать мощность Scrum и обеспечиваемый им рост продуктивности, нужно основательно изменить управление и операционную деятельность. Несколько scrum-команд могут отлично выполнять свою работу с примечательной скоростью, но вам нужен Scrum на уровне организации. Должны меняться традиционные структуры, меры поощрения, управление эффективностью. Да и людям во всей организации, даже если они не члены scrum-команд, тоже нужно научиться взаимодействовать со scrum-командами, поддерживать их, помогать и управлять ими новым способом.

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

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

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

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

Мир из кубиков Lego

Отправимся в Северную Европу, в Швецию, – на родину IKEA, «Девушки с татуировкой дракона», поп-группы ABBA, возможно, лучших в мире тефтелек и полярных дней. Кроме того, Швеция – родина компании Saab. Возможно, она вам знакома как производитель автомобилей, который больше их не выпускает; однако автомобилестроение всегда было ее побочным бизнесом. В первую очередь Saab занимается производством боевых самолетов.

Saab создавала истребители десятилетиями с 1937 года. В то время было очевидно, что вскоре мир охватит пожар войны, и Швеция, не имея союзников, решила создать свои военно-воздушные силы. Страна, как и Швейцария, официально придерживалась политики нейтралитета со времен Наполеона. И Швеция смогла также официально придерживаться ее на протяжении Второй мировой и холодной войны. Однако, зажатые между силами НАТО с одной стороны и Советским Союзом с другой, шведы, скажем так, оказались в напряженной ситуации.

В 1960 году они представили реактивный истребитель Saab 29 Tunnan, один из лучших в мире по меркам того времени. Они построили около 55 боевых эскадрилий, многие из которых находились в состоянии боевой готовности и могли подняться по тревоге в течение шестидесяти секунд. Со временем компания начала продавать свои самолеты другим странам: Австрии, Бразилии, ЮАР, Таиланду и не только.

После Saab 29 Tunnan были выпущены Lansen, Draken, а в 1980-х – Gripen А/В и Gripen C/D. И тут возникла проблема. Это был хороший самолет, который отлично продавался, но Saab и шведская армия хотели его модернизировать, сделать мощнее, увеличить дальнобойность и оснастить лучшим оружием. Так пришла идея Gripen Е. Сначала инженеры Saab хотели модернизировать порядка шестидесяти уже готовых Gripen 39С, потому что вообще-то самолеты дорогие и их нелегко собрать с нуля. В результате, обновляя самолеты, они приняли Scrum – сначала только в группе программного обеспечения, но затем и в отделах дизайна, разработок, отделе качества – повсюду. Scrum@Scale, масштабированный Scrum – модульный организационный фреймворк с кросс-функциональными командами, быстро доставляющими ценность. По мере распространения Scrum в компании у ее лидеров возникла радикальная идея: что, если самолет отражает организационную структуру Saab?

«Мы хотим, чтобы воздушное судно потенциально могло находиться в летной готовности на протяжении пятидесяти лет, – сказали в Saab. – Мы знаем, что за столько десятилетий технологии значительно меняются. Современные модели воздушных судов сложно модернизировать, они жестко связаны. Каждый элемент привязан к другим. Но что, если мы создадим модульный самолет, который будет легко разобрать и собрать снова, так же как и организацию, состоящую из scrum-команд? Мы могли бы модернизировать все системы постоянно. Нам не пришлось бы ждать программы полной модернизации. Вместо этого почему бы нам не построить воздушное судно так, чтобы при появлении нового радара, новых компьютеров или лучших двигателей можно было извлечь старую деталь и поставить новую, не трогая другие? Почему бы не сконструировать истребитель так, будто мы строим его из LEGO?»

«Мы хотим использовать системы автоматической конфигурации, системы типа plug and play, – сказал Йорген Фурухьельм, менеджер проектов из Saab. – Мы называем такие борты умными истребителями. Мы же не знаем, чего будут хотеть наши потребители через несколько лет».

Нужно освоить лучший двигатель? Без проблем – замените его. Радар получше? Готово. Оружие поизящнее? Решено. Философия Saab позволяет Gripen решать задачи, которые кажутся невозможными. Он способен приземлиться на шоссе в экстремальных погодных условиях. Его можно заправить и перевооружить менее чем за десять минут – нужны всего шесть человек и никаких специальных инструментов. Большинству других истребителей для этого потребуется в два-три раза больше времени. Saab может поменять в самолете двигатель в течение часа. Вот что дает модульность.

И компания – веселое место для работы. Шведские студенты-инженеры оценивают только одну компанию выше – Google. И, в отличие от большинства компаний в мире, где люди предпочтут заняться чем угодно, только бы не идти в офис, сотрудники Saab хотят каждый день возвращаться на работу.

«Это приверженность делу. Люди думают, что проект крутой. Действительно крутой. Они обожают самолеты. Чувство приверженности в команде почти осязаемо», – говорит Фурухьельм.

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

Gripen Е лучше, чем его предшественник, с лучшими частями и оборудованием, лучше во всем; Gripen Е дешевле разработать, построить, обслуживать. Поддерживать в летном состоянии 150 самолетов модели Gripen на протяжении сорока лет обойдется примерно в 22 млрд долларов. Это примерно вдвое меньше, чем содержать 65 пригодных к полету построенных в США моделей F35.

И этого компания добилась благодаря Scrum. Сконструировала технически совершенные истребители с нуля. Часто мне приходится работать в компаниях, менеджеры которых говорят: «Ой, фреймворк Scrum придуман для разработки программного обеспечения. А наш продукт слишком сложно сделать гибким». Именно в такие моменты я обычно начинаю рассказывать им о самолетах Gripen. «Я почти уверен, – говорю я, – чем бы вы ни занимались, это не сложнее истребителя».

Не уверен, правильно ли вы понимаете это слово

В последние годы Scrum распространился по всему миру, зачастую под знаком Agile (гибкости). Теперь это уже способ работы не только технологических компаний и производителей ПО, но и многих крупных компаний почти во всех сферах. И он становится все популярнее. Компании, которые специализируются на банковском деле, автомобилях, медицинском оборудовании, биотехнологиях, страховании, здравоохранении и других областях, приняли agile как способ идти в ногу со временем. Такие ведущие компании, как Bosch, Coca-Cola, USAA, Schlumberger, Fidelity и Lockheed Martin, обратились к Scrum, чтобы доставлять ценность и качество с необходимой в нынешнем мире высокой скоростью.

Многое в этом методе обусловлено цифровыми трансформациями. Суть в том, что сошедшее на нет разделение между IT и бизнесом – к лучшему. Сейчас каждая компания технологическая, программное обеспечение поглотило мир. В вашей машине больше строк кода, чем в Windows. Да даже моя новая стиральная машина хочет знать пароль от Wi-Fi.

Теперь компании, зачастую с подачи CEO, который посмотрел TED Talk[5] или услышал о преимуществах Agile от товарищей либо консалтинговой компании, решают, что «после нас хоть потоп» и гибкими стать нужно.

И на этом моменте, думаю, пора дать определение термину Agile («гибкость») и тому, как с ним соотносится Scrum. Scrum появился в 1993 году, и был формализован его двумя соавторами – Джеффом Сазерлендом и Кеном Швабером – в 1995 году. В середине 1990-х в новостных группах Usenet[6] и на конференциях многие пытались придумать пути разработки программного обеспечения, которые обеспечили бы меньшую частоту провалов.

В 2001 году семнадцать таких людей на пару дней собрались вместе на горнолыжном курорте в городе Сноуберд. Мой отец Джефф Сазерленд был там, как и Кен Швабер, и еще один ранний адепт Scrum Майк Бидл, и четырнадцать человек с разным прошлым и разными методологиями. Однако все они признавали, что пытались решать одни и те же проблемы. Пути их были схожи, но не одинаковы.

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

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

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

Люди и взаимодействия важнее процессов и инструментов.

Работающий продукт важнее исчерпывающей документации.

Сотрудничество с заказчиком важнее согласования условий контракта.

Готовность к изменениям важнее следования первоначальному плану.

Иначе говоря, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева.

Пятнадцатью минутами позже, когда остальные вернулись в комнату, один из них, Уорд Каннингем, изобретатель Wiki, помимо прочего сказал: «Это невероятно!» И они не изменили ни слова в этих формулировках.

Таков Agile. Это утверждение ценностей. Остаток дня они придумывали двенадцать принципов Agile, например «Простота – искусство минимизации лишней работы – крайне необходима» и «Над проектом должны работать мотивированные профессионалы. Чтобы получить результат, создайте условия, обеспечьте поддержку и полностью доверьтесь им» и «Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта». Это прекрасно, но в принципах нет описания того, как следовать им. Нет фреймворка, методологии. Только четыре ценности и несколько принципов, согласующихся со здравым смыслом.

Но они изменили мир. Участники того мероприятия выложили свой Agile-манифест на сайте agilemanifesto.org и разъехались по домам для того, чтобы нести тяжкое бремя следования ему. Тогда они еще не знали, что подход распространится далеко за пределы мира программного обеспечения.

Но запомните: если кто-то заявляет о своей гибкости, очень важно уточнить, что именно он под этим понимает. Scrum – самый популярный гибкий фреймворк, около 70 % agile-команд используют его, но он ни в коем случае не единственный. Именно поэтому, зная только то, что компания условно гибкая, вы не сможете составить полной картины.

Закон Мура, применимый к людям

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

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

Для примера возьмем проект TAURUS Лондонской фондовой биржи, появившийся примерно в то время. TAURUS – акроним от Transfer and Automated Registration of Uncertified Stock (передача и автоматическая регистрация бездокументарных акций). Проблема заключалась в том, что система урегулирования при конвертации валюты использовала ПО под названием Talisman. Урегулирование – на самом деле красивое словечко для обозначения «того, за что ты заплатил». После того как вы купили на фондовой бирже ценные бумаги, их доставка в ваш портфель могла занять две-три недели и включала переправку настоящих бумажных акционерных сертификатов из одной точки в другую. Система расчетов, покупки и продажи долей называлась Seaq. Она была электронной, но не совместимой с Talisman, которая обгоняла ее на несколько лет.

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

Однако он по-прежнему оставался невероятным. Он интегрировал бы семнадцать разных систем. Восхитительно! Согласно статье Хамиша Макрая, опубликованной в журнале Independent 12 марта 1993 года, проблема была трехсторонней. В первую очередь, попытка создать с нуля огромную систему программного обеспечения и запустить ее, как Вселенную большим взрывом, невероятно рискованна, не допускает даже малейших ошибок или просчетов. Любая досадная мелочь будет иметь катастрофические последствия. Правда, такой подход часто встречался в те времена и существует до сих пор. Компании невероятно рискуют, ставя на то, что масштабная система сразу сможет все исправить. По данным Standish Group, около 40 % проектов, работающих по этому принципу, провальны[7]. Половина из них затягивает сроки, половина превышает бюджет и не обеспечивает то, для чего была предназначена изначально. В случае с TAURUS расклад тоже оказался не в пользу системы, которая должна была полностью заменить систему урегулирования платежей в одном из мировых финансовых центров.

Второй аспект проблемы, согласно Макраю: хотя иметь систему важно, но если есть хорошая система, которая работает, и идеальная, которая не работает, то выбирать нужно первую. Не позволяйте лучшему стать врагом хорошего. В проекте TAURUS, как и почти в любом другом проекте, неконтролируемое расширение масштаба стало удавкой на шее. «Правда, здорово было бы, если бы новая система делала не только то, что мы уже продумали и о чем нас попросили, но и вот это? А если бы она еще варила идеальный эспрессо, пока люди ждут завершения сделки? Еще лучше ведь», и т. д. В итоге проект, который вначале был прост и хорошо определен, становится машиной Голдберга[8], решающей все проблемы всех людей. При этом, естественно, неспособной выполнять простейшие задачи, поставленные изначально.

Я постоянно наблюдаю это в компаниях на примере одной корпоративной системы: SAP[9]. SAP – лидер рынка в сфере систем планирования ресурсов предприятия (Enterprise Resource Planning, ERP). Системы ERP нацелены на выполнение всех задач. Это гигантские базы данных, которые отслеживают ресурсы – например, денежные средства, необработанные материалы, производственные мощности – и соотносят их с платежными ведомостями, счетами на оплату, заказами и т. д. Они затрагивают каждый аспект деятельности компании: закупки, продажи, человеческие ресурсы, бухгалтерию, производство, буквально все, – и интегрируют это в цифровой формат. На самом деле такие системы неплохо работают, если вы используете их в стандартных конфигурациях.

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

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

Но вернемся к TAURUS, бриллианту систем урегулирования, и к тем несчастным, которым выпал сизифов труд интегрировать семнадцать разных наборов требований к работе системы. Она должна была делать все за всех. И они пытались воплотить ее в жизнь. Действительно пытались.

Чтобы проиллюстрировать третий аспект проблемы с TAURUS, приведу цитату из работы Макрая.

Фондовая биржа не прислушивалась к своим потребителям. А типов потребителей было много: участники биржи, продавцы своих акций, институциональные и частные инвесторы. Все были озабочены затратами на TAURUS, компании сердились (и некоторые отказались помогать в реализации проекта), институты в лучшем случае были недовольны, в худшем – настроены враждебно, а все малые инвесторы, знавшие о проекте, беспокоились по поводу дополнительных сборов, которые им наверняка пришлось бы платить. Нужна определенная самонадеянность, чтобы продавливать что-то при таком сопротивлении.

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

Так TAURUS, рожденный как прекрасная идея, был отменен в 1993 году, спустя годы попыток. Денный и нощный труд тысяч людей и 75 млн фунтов оказались слиты в унитаз. Общий экономический эффект системы на стейкхолдеров оценивается примерно в 400 млн фунтов.

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

И как бы сильно я ни хотел сказать вам, что TAURUS – один из худших примеров, это не так. Есть множество других. Проект Национальной системы здравоохранения (National Health System) под названием Connecting for Health («Вместе для здоровья»), который должен был объединить в электронной форме истории болезни жителей Великобритании: 9 лет и 12 млрд фунтов. Экспедиционная система обеспечения боевых действий (Expeditionary Combat Support System) для армии США: 7 лет и 1,1 млрд долларов. Департамент штата Калифорния по регистрации транспортных средств с 1987 года тратил десятки миллионов долларов на систему, которая к 1990 году была хуже, чем та, которую она должна была заменить. И его руководство не могло это признать до 1994-го. Газета San Francisco Chronicles описала систему как «непригодную, исправить которую невозможно без дополнительного вливания миллионов долларов».

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

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

Руководство по выживанию

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

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

Загвоздка Scrum в том, что он сам по себе не делает ничего. Его задача – раскрыть потенциал каждого из нас. Он здесь, он может быть скрыт или спрятан в угол, но никогда не исчезнет. Таковы мы, люди. Сегодня мы думаем, что мир работает так, а завтра обнаружим, что все иначе. Однажды мы можем понять, что смотрели на мир через кривую линзу, во Вселенной есть возможности, о которых мы никогда не думали, – а теперь переосмыслили всё. И мы всегда были способны на это.

ВЫВОД

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

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

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

БЭКЛОГ

1. Изучите все Agile-ценности и оцените, насколько вы и ваша компания гибки. Запомните: «Не отрицая важности того, что справа, мы больше ценим то, что слева».

• Люди и взаимодействие важнее процессов и инструментов.

• Работающий продукт важнее исчерпывающей документации.

• Сотрудничество с заказчиком важнее согласования условий контракта.

• Готовность к изменениям важнее следования первоначальному плану.

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

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

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

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

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

Как работает Scrum

Scrum работает так.

Для начала вам нужно понять, что в Scrum есть три – и только три – роли: владелец продукта, scrum-мастер и член команды. Здесь нет бизнес-аналитика, тех-лида, старшего мастера – только те, кого я перечислил выше. Такой состав позволяет scrum-команде независимо доставлять ценность. Команда – наименьшая организационная единица. Она доставляет ценность потребителям в короткие временные циклы, которые называются спринтами.

Владелец продукта (PO, Product Owner) отвечает на вопрос «Что мы будем делать?» Под продуктом подразумевается то, что команда собирается создать, какую услугу или процесс представить. Владелец продукта получает данные от пользователей, стейкхолдеров, самой команды и всех, кто извлекает ценность из деятельности команды. Это могут быть фермеры из Уганды, пострадавшие от заболевания сельскохозяйственных культур; или инженеры, строящие беспилотный автомобиль; или посетители кинотеатра, которые идут посмотреть новый фильм. Владелец продукта должен собрать все входные данные, часть которых может быть противоречива, и создать видение того, что команда будет делать. Затем (это обычно сложнее всего), после сбора всех идей, владелец продукта должен расставить их в порядке убывания ценности. В Scrum может быть только одна приоритетная задача на отрезок времени. Это сложно обеспечить, но именно так работает методика.

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

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

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

Следующее событие – ежедневный Scrum, или ежедневный стендап. Это мероприятие длится всего пятнадцать минут, и на нем команда делится тем, что было сделано для достижения цели спринта, тем, что планируется сделать в течение следующих двадцати четырех часов, и тем, что может помешать достичь цели. Ежедневный Scrum – не статусное мероприятие, оно больше похоже на совещание игроков на футбольном поле перед игрой. Мини-сессия планирования. Команда уже изучила то, чем занимается, и для нее это возможность поделиться информацией, полученной днем ранее. Она выступает как группа людей, которая отправилась в путешествие: они наметили маршрут и едут по нему, каждое утро за завтраком проверяют карту, прогноз погоды, договариваются, чья очередь быть за рулем, когда продолжить ехать. Пятнадцать минут на все про все.

Теперь в дело вступает scrum-мастер. Странное название должности, не правда ли? Я убеждал моего отца, одного из создателей Scrum, выбрать другое, что-то вроде коуча. Он сказал мне, что я опоздал и название уже устоялось в культуре. Слишком поздно. Ну что ж. Сейчас роль scrum-мастера – новинка для большинства компаний. Его задача – помочь команде двигаться быстрее. Скорость – икона, на которую они молятся.

Зачем кому-то платить за это? Если эти люди могут заставить команду создавать ценность вдвое быстрее, то они более чем окупаются. Сделать так, чтобы текущая команда работала быстрее, всегда лучше, чем нанимать новых людей. Scrum-мастер помогает ей наращивать скорость (Velocity), и владелец продукта отвечает за то, чтобы она превращалась в ценность. Нет ничего более грустного, чем замечательная группа людей, которая быстро делает никому не нужные вещи. Помните Nokia Mobile? Там были отличные scrum-команды, невероятно быстро создававшие телефоны, которые не были нужны поклонникам iPhone. Всего за несколько лет из лидера рынка они превратились в компанию с нулевой рыночной ценностью.

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

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

Для примера возьмем то, чем я часто занимаюсь, – запись в блоге. Сейчас мне легко сказать: «Вот, я ее сделал, она готова». Но так ли это на самом деле? Текст нужно отредактировать, вычитать. Необходимо добавить картинку. Потом запись нужно поместить на сайт. Кто-то должен нажать кнопку «Опубликовать». Нет никакой пользы от того, что я написал, пока все это не произойдет. Важно убедиться, что учтена вся работа, а не только малая ее часть.

Критерии могут быть простыми – вроде наличия картинки на странице – либо сложными, например указывающими, что работа должна соответствовать стандартам безопасности человеческой жизнедеятельности Управления по надзору за пищевыми продуктами и медикаментами прежде, чем она будет считаться готовой, поскольку проект команды – имплантируемые медицинские устройства. Трудно переоценить важность выполненной работы: она удваивает продуктивность команды. Причина проста. Если неясно, как выполнять работу, неизвестны стандарты ее качества, команда потратит невероятное количество времени на то, чтобы понять, что делать, и, скорее всего, обнаружит, что не может приступить к делу, поскольку ее часть работы зависит от той, которой занимается другая команда.

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

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

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

Удивительно видеть, как маленькие события, которые казались непоследовательными в свое время, стали рычагами, изменившими будущее. Нечто вроде «не было гвоздя – враг вступает в город»[10]. И первый обзор спринта стал одним из таких событий.

Первая scrum-команда работала над технически сложным проектом, поэтому не могла попросить рядовых потребителей прийти и посмотреть на промежуточный результат. Мой отец нанял нескольких экспертов из Массачусетского технологического института, чтобы они посмотрели на предварительный итог. Они были жестоки. Они поставили под вопрос навыки команды, указали на значительные недостатки, неверные предположения и т. д. Команда утратила почву под ногами. Мне сказали, что это был непростой день и к концу встречи члены команды хотели умыть руки. Они посмотрели на Джеффа и сказали ему, что не хотят повторения. Еще один такой день сломал бы их.

«Хорошо, – сказал мой отец. – У вас есть выбор: быть одной из многих команд разработки ПО или стать отличной командой разработки ПО. Я не могу вас заставить, вы должны выбрать сами».

Решение этих семерых людей изменило мир. Именно благодаря им вы читаете сейчас эту книгу, и благодаря им люди по всему миру теперь работают лучшими методами. Не так часто в истории удается четко определить время, день, людей, которые стали чему-то причиной, но нам это удалось. В тот день родился Scrum.

«Хорошо, – сказали они. – Еще одна попытка».

Дальнейшее вам известно.

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

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

Реальность постоянно меняется

Приведу два кратких примера того, как Scrum сработал в реальных ситуациях, и отвечу на вопрос, который мне часто задают: «Звучит отлично, но как насчет реальности?» Оставим в стороне странное встроенное в вопрос предположение, что существует некая другая «реальность». Для начала перенесу вас на заснеженные улицы Миннеаполиса, к парню по имени Том Олд. Он занимается перепродажей недвижимости. И в своей работе использует Scrum.

Начинается все довольно типично: Том находит дом для перепродажи, обычно в ценовом диапазоне 80–100 тысяч долларов. Затем он собирает свою команду, которая состоит из подрядчиков – как правило, пары генеральных подрядчиков, электрика, сантехника и плотника. Все эти люди могут работать, на кого захотят, но они предпочитают сотрудничать с Томом.

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

Свою работу они делят на шесть спринтов, каждый из которых занимает неделю. Как правило, в первый спринт происходит снос ненужных конструкций, затем в среднем два спринта занимают работы с электричеством, сантехникой и структурные работы. Еще два спринта уходят на специфические улучшения, а в последний спринт происходит чистовая отделка. Каждую неделю они собираются вместе, планируют работу, которую будут выполнять в следующий спринт, решают, какими будут критерии готовности для каждой задачи, и приступают к работе. Каждый день команда обращается к бэклогу и совместно решает, как выполнить работу, чтобы достичь поставленной цели к концу недели. Конечно, у всех своя специализация, но члены команды знают, что любой успех или неудача общие. В конце недели приходит Том и они проводят обзор спринта, вместе обходя дом и решая, что готово, что нет, как этот спринт повлияет на бэклог следующих спринтов. Может быть, они снесли стену или, как часто бывает при ремонте домов, обнаружили, что задача, которая казалась легкой, на самом деле сложна: например, в перекрытиях поселилась семья енотов или проводка не соответствует нормам. По мере обсуждения готовой работы Том расплачивается с подрядчиками. При подряде строителям обычно не платят до тех пор, пока весь проект не готов. Даже после этого клиенты обычно не торопятся, но Том настаивает на том, чтобы оплачивать инкрементально[11] доставленную ценность.

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

Еженедельно после обзора спринта члены команды собираются и обсуждают свою совместную работу. Как электрику и плотнику лучше действовать на следующей неделе? Есть ли лучший способ справиться с неизбежными зависимостями? Зависимость – это когда нужно ждать, пока что-то произойдет или какой-то этап завершится, прежде чем вы сможете продолжить работу. Нечто вроде: «Ой, нам нужно ждать доставки из строительного магазина» или «Он должен доделать свою работу прежде, чем я начну свою». Каждую неделю они используют то, что узнали за предыдущую, чтобы изменить то, что планируют сделать, в зависимости от текущих условий, и то, как они будут работать, в зависимости от потока задач на проекте. Хотя дома в целом схожи, в каждом конкретном случае есть своя специфика.

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

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

Мы знаем, что работа изменится. Мы знаем, что клиент передумает, когда увидит что-то (вспомните закон Хемфри). Вместо того чтобы сражаться с неизбежными изменениями, Scrum принимает их. На крупных проектах порой целые компании сопротивляются изменениям. Они меняют запросы, и Комиссия по контролю внесения изменений реагирует на это ограничением предложения. И поскольку мы знаем, что все меняется, выходит, они платят людям, чтобы убедиться в том, что потребитель не получит желаемого.

Иди ва-банк или домой

Приведу другой пример: масштабнее, но процесс аналогичен. Компания 3М производит все, от стикеров, респираторов, лент для нанесения дорожной разметки и пленки для тонировки автомобильных стекол до стоматологического оборудования и программного обеспечения для здравоохранения. В 2017 году ее прибыль превысила 30 млрд долларов. Она работает по всему миру. Не исключено, что сегодня вы использовали один из ее продуктов.

В марте 2017 года я провел несколько тренингов в Сент-Поле для сотрудников разных подразделений 3М. Один из них, менеджер Марк Андерсон, выступал в аудитории. Он не смог точно объяснить мне, чем занимался, но спросил, использовался ли когда-нибудь Scrum для слияния и поглощения. Я честно сказал ему, что не слышал о таком применении фреймворка, но не вижу причин, почему это не получится.

Несколько недель спустя я наткнулся на следующий пресс-релиз.

3М (Фондовая биржа Нью-Йорка: МММ) сегодня объявила о том, что заключила соглашение о приобретении компании Scott Safety у Johnson Controls по общей стоимости, составившей 2 млрд долларов. Scott Safety – основной производитель инновационных продуктов, включая системы изолирующих дыхательных аппаратов, приборы обнаружения возгорания и утечек газа и другие устройства, которые пополнят портфель средств индивидуальной безопасности 3М.

«Два миллиарда долларов – это куча денег», – сказал я Марку, когда снова его увидел. Он заявил, что это второе по величине поглощение в истории 3М, которая существует уже больше ста лет, и он был назначен ответственным за интеграцию процесса. «Расслабься», – ответил я и улыбнулся ему. Тогда он рассказал, что планирует провести интеграцию, задействуя Scrum, и расскажет мне потом, как все прошло, если представится возможность.

Без опыта интегрировать поглощение сложно, тем более при подобных масштабах. Нужно учесть операционные вопросы, продажи, зарплаты и кадры, процессы, маркетинг, финансы, исследования и разработки. По моему опыту, самая сложная часть – культура. В существующую корпоративную культуру нужно привнести культуру поглощающей компании. Особенно сложно это при наличии сильных культур в обеих компаниях. В 3М выдающаяся инженерная культура, существующая десятилетиями. Жизни людей зависят от продуктов 3М, которые должны сработать с первого раза и работать всегда. В Scott Safety похожий дух. Средства защиты органов дыхания, датчики тепла и другие устройства для пожаротушения, которые должны правильно сработать с первого раза и работать всегда.

Марк позвонил мне в конце 2017 года, чтобы сказать, что они не только сделали это, но и что все вышло иначе, чем если бы они действовали традиционными методами. Традиционный способ управления проектами в Scrum – каскадная модель. При ее использовании руководители стараются распланировать весь проект до его начала. Собираются все возможные требования – иногда их тысячи. Я видел документы с требованиями, стопка которых, если их распечатать, в высоту достигала метра. Подписывая ее, люди пребывают во взаимно согласованной иллюзии о том, что кто-то действительно прочел все это, и только потом команда менеджеров проекта делит работу на фазы. «Сначала мы сделаем эту часть, – говорят они, – и это займет две недели». И рисуют полосочку в верхней части диаграммы Ганта[12]. «Затем мы приступим к следующей фазе; она займет два месяца». Тут они рисуют еще одну полоску на графике, ниже и правее предыдущей. И так далее. Похоже на очень красивый водопад. Эта цветная диаграмма может тянуться месяцами, даже годами. Я видел такие графики высотой тридцать сантиметров и длиной несколько метров. Они в самом деле бывают произведением искусства. Восхитительно. Но они всегда ошибаются. Всегда. Ведь ничто не идет по плану. Никогда. Всегда что-то случается, и приходится менять график. То, что нужно, не поставляется вовремя. Проект затягивается. А значит, и диаграмма неверна. Но она не может быть неверна. Поэтому компании нанимают людей, чтобы диаграмма выглядела реальной, ведь реальность меняется. Это базовый человеческий недостаток: «Если я хорошо подумаю над этим, я смогу устранить ошибку». Но это иллюзия контроля.

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

Как же им это удалось? В первую очередь они составили бэклог всех задач, которые нужно решить. Затем определили, какие области компетенций необходимы для выполнения его элементов. Они собрали кросс-функциональную команду владельцев продукта, обладающих нужными навыками: компетентностью в сферах финансов, исследований и разработок, продаж, маркетинга, кадров. Эти группы нужны были для дальнейшей координации того, что должно быть интегрировано, чтобы Scott Safety стала частью 3М.

У каждого владельца продукта была команда. Или команда команд. Марк сказал, что только отделы IT-исследований и разработок использовали Scrum в полной мере. Такой уровень координации все равно оказался крайне важным для проекта. Что было главным? Владельцы продуктов постоянно собирались вместе, чтобы координировать усилия, делиться знаниями, обращаться друг к другу за помощью и изменять приоритет элементов бэклога по мере поступления новой информации. Например, если финансовому отделу нужны были данные по зарплатам, они обращались к бэклогу продукта за полной интеграцией, и каждая команда получала данные о том, что ей нужно сделать, чтобы ее часть работы считалась готовой.

Шесть месяцев. Таким был крайний срок. Каждый ставил перед собой свою высокоуровневую цель и выбирал направление движения, и еженедельно они пополняли свой бэклог элементами из высокоуровневого скоординированного бэклога, рассчитанного на весь проект.

Они работали недельными спринтами. Каждую среду они просматривали бэклог, определяли приоритетность задач на следующую неделю, оценивали усилия, необходимые для реализации каждого элемента, который, по их мнению, они могут выполнить за один спринт, и начинали работу. Они не всё делали так, как я рассказывал: отводили на ежедневный Scrum по 15 минут трижды в неделю, а не каждый день. Так, они встречались по пятницам, чтобы сообщить, что все в порядке, затем собирались в понедельник. И каждую среду, прежде чем планировать следующую неделю, они проверяли, сколько работы готово на самом деле из того, что было запланировано.

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

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

Результат? В первый день все менеджеры оказались на местах, а каждый сотрудник должен был отчитаться. Финансовый отдел отреагировал незамедлительно: никаких проблем с несогласующимися или запутанными прогнозами, все отслеживалось и было прозрачным. Проект запускался глобальный, и HR четко обозначили это. Невероятно сложные взаимосвязанные части крупной интеграции сомкнулись без зазоров. 3М гордится собой как постоянным инноватором не только в части продуктов, но и операций. Насколько мне известно, тогда Scrum впервые использовался для многомиллиардного корпоративного поглощения. Причем успешно.

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

3М гордится сотрудничеством внутри компании. Я слышал, что они используют Scrum всеми возможными способами, поскольку гибкое мышление подходит их культуре. И, как вам скажут некоторые сотрудники 3М, Scrum культивирует гибкое мышление.

Изменения происходят всегда

Неважно, перепродаете вы дома или интегрируете многомиллионное поглощение. Сила Scrum в том, что он позволяет внедрить изменения дешево. Все мы знаем, что они наступят. Единственный вопрос в том, будете вы с ними бороться или примете их.

По данным Standish Group, в любом проекте в процессе разработки меняется 67 % требований. Почему? Потому что люди обучаются по ходу работы. Когда мы создаем что-то, то узнаём, что некоторые вещи, казавшиеся важными, на самом деле не так существенны. Нам становится известно, что покупатели, обозначившие задачи и подписавшие пачку требований, на самом деле не были уверены, что меняется рынок и мир.

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

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

Суть в том, чтобы изменения были быстрыми, дешевыми и веселыми. И если не получается – значит, вы что-то делаете не так.

ВЫВОД

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

Обман и «каскады». Сократите риски и повысьте вероятность успеха – таковы обещания традиционных каскадных систем управления проектами. Проблема в том, что они не работают. При планировании каждой детали не учитывается, что нечто неожиданное обязательно случится. Обязательно. Когда вы в последний раз видели диаграмму Ганта, соответствующую реальности?

Scrum 3-5-3. В Scrum всего три роли: владелец продукта, scrum-мастер и член команды. Пять мероприятий: планирование спринта, спринт, ежедневный Scrum, обзор спринта и ретроспектива спринта. И три артефакта: бэклог продукта, бэклог спринта и инкремент продукта, который команда создает за каждый спринт. Это не сложно, но требует дисциплины.

БЭКЛОГ

1. Начните внедрять Scrum 3-5-3 на своем рабочем месте.

2. Кто будет заниматься приоритизацией?

3. Кто будет коучем?

4. Кто будет выполнять работу?

5. Составьте бэклог продукта.

6. Составьте план вашего первого спринта.

7. Вперед!

8. Ежедневно встречайтесь, чтобы координировать усилия и вносить изменения в планы.

9. Сделайте что-то полностью готовое к концу спринта.

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

11. Повторите снова.

У вас есть проблема – вы только что о ней узнали.

Это может быть что угодно. Вы создаете что-то и понимаете, что дизайн нужно изменить. Вы наткнулись на то, чего не ожидали, когда планировали работу, и вам нужно решить, что делать. «Мне сейчас решить этот срочный вопрос или подождать и работать над чем-то невероятно важным, что потом станет очень ценным?»

Это совпадает с матрицей Дуайта Эйзенхауэра – известной матрицей принятия решений, позволяющей ранжировать вопросы по степени важности и срочности.

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

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

Задержка решения

Джим Джонсон, основатель и председатель Standish Group, начал интересоваться этим вопросом несколько лет назад. С 1985 года компания в основном занимается исследованиями работы проектов по всему миру с помощью интервью, фокус-групп и опросов. Мы говорим о десятках тысяч проектов. Она регулярно публикует CHAOS Report, содержащий разного рода данные о том, почему проекты преуспевают или терпят неудачу. График, объясняющий всемирное распространение Agile, выглядит так.

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

Но проясним кое-что: не каждый agile-проект заканчивается хорошо. Компания Scrum Inc. и Джим рассматривали причины, по которым 50 % agile-проектов испытывают затруднения, затягиваются, превышают бюджет или оставляют клиентов неудовлетворенными.

Какова глубинная причина неудачи проекта? Что в scrum-проектах повышает вероятность их успешного исхода? Несколько лет назад, когда Джим брал интервью у главы бюро закупок штата Массачусетс, он понял, в чем дело.

«Он рассказал мне историю, – говорит Джим. – Он работал в городском Совете Бостона. Им требовалось получить решение заместителя мэра, чтобы перейти к следующему этапу проекта. У них было 60 подрядчиков, ждущих решения. Шестьдесят человек в течение шести недель не могли работать. Именно столько заняло принятие решения».

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

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

«Оказалось, – говорит Джим, – данные показывают, что на каждую потраченную на проект тысячу долларов приходится одно решение. Для миллионного проекта вам придется принять тысячу решений». Картинка быстро складывалась. Чем дольше принимать решения, тем дороже они обойдутся, согласно замечательному следствию общей теории относительности Эйнштейна: не только время и пространство – один континуум, но также время и деньги. Так Джим придумал метрику, которая показывает, сколько времени занимает принятие решения, начиная с момента, когда становится понятно, что оно необходимо, и заканчивая моментом, когда оно принято. Он назвал это задержкой решения. Затем он сопоставил показатели со статистикой успешности проектов. Он учел сотни проектов по всему миру. Каковы же результаты? Хуже, чем вы думаете.

Графики показывают конечный результат сотен проектов. Из тех, в которых решения были приняты быстро, меньше чем за час, успешно завершились 58 % (они также уложились во временные рамки и бюджет). Если на это уходило больше 5 часов, вероятность успеха резко снижалась: только 18 % таких проектов работают. Пять часов. Это не так много.

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

«Реакция была очень интересная, – вспоминает Джим. – Сначала они говорили, что такое невозможно, что это не может быть глубинной причиной. А затем немного обдумывали данные, возвращались и сообщали, что я подал им интересную идею».

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

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

Расскажу немного грустную историю о том, как это работает. Предположим, вы трудитесь на автомобильной фабрике в США и хотите потратить деньги на что-то, допустим, оборудование для завода. Хотя деньги на него в годовом бюджете уже предусмотрены, вам нужно сдать ринги – на бумаге. Необходимо подробно и убедительно описать причины того, почему вы хотите потратить деньги. Включить все бухгалтерские данные: сколько вы планируете потратить, откуда поступают средства, кому идут. Повторю еще раз: на бумаге. Затем вам надо провести обзор среды: сколько электричества потребляет прибор, будут ли от него какие-то выбросы. Все это также записывается на бумаге. Стопка бумаг и есть ринги.

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

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

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

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

Одной группе дали задание автоматизировать процесс. Они, конечно, использовали для этого Scrum. Цель? Избавиться от бумаги. Проводить распечатанные документы через множественные петли обратной связи, скажем так, невероятно медленно. Также они собираются автоматизировать некоторые проверки, которые проводит центральная группа планирования.

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

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

«Scrum так изящен потому, что позволяет вывести решения на уровень команды, – говорит Джим. – Для этого нужны только владелец продукта и команда. Тогда стейкхолдерам или высшему руководству не придется принимать много решений».

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

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

Измеряйте совещания

Предположим, вам нужно принять решение. Вы договариваетесь о совещании. Допустим, на встрече двадцать человек и решение принимается за час. Спросите себя: во сколько оно обошлось? Посчитаем стоимость одного только времени: сколько денег вы потратили за час. А теперь посчитаем все бесполезные совещания, которые прошли у вас на этой неделе.

Мой друг раньше работал в университете из Лиги плюща. Иногда он говорил мне, что приходит на совещания, даже не зная, зачем он там. А если и знает, то совещания длятся вечность. Упражнения ради мы решили посчитать. Каждая встреча, по нашим выкладкам, стоила около тысячи долларов. За ту неделю он был по меньшей мере на десяти – пятнадцати совещаниях. Делаем выводы.

На деле все даже хуже: решения, которые принимаются на совещаниях, с высокой вероятностью будут отклонены. По данным Standish Group, так происходит более чем с 40 % подобных решений. Предположим, решение принимается за одно совещание и мероприятия проходят раз в неделю. За неделю первое решение уже начинает внедряться, а каждый из тех, кто его принял, передумал. Принимается новое. Это не только потеря недели времени, но и переделка всей уже выполненной работы. Все равно что копать ямы и тут же их засыпать. Сизифов труд.

Согласно исследованию Standish Group, это случается по двум причинам: из-за тех, кто был на совещании, и тех, кого там не было. Решение, к которому приходят в комнате, обычно принимается самым громким человеком в аудитории. Он бульдозером едет по всем, кто стоит на пути. И когда совещание закончено и люди возвращаются к своим рабочим местам, они порой говорят: «Хм, по здравом размышлении я не вполне согласен с тем решением. На следующей неделе подниму этот вопрос».

А еще есть те, кто не пришел на совещание. Возможно, они и не должны были, но чувствуют, будто им это необходимо. Почему их не спросили? В следующий раз они определенно придут, чтобы быть услышанными.

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

Какие решения принимать

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

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

Один из радикальных примеров проталкивания решений – компания Mirai Industry. Она производит оборудование для электромонтажа: распределительные блоки, кабели, изоляторы и т. п. В отличие от большинства японских компаний, она не следует ринги полностью. Основал компанию и долгое время занимал пост CEO до самой своей смерти 30 июля 2014 года Акио Ямада. Он считал, что сама идея ринги несуразна, и запретил ею пользоваться. «Делайте свою работу так, как считаете нужным, – говорил он своим сотрудникам. – Пусть те, кто выполняет работу, принимают решения». «Я дурак, – писал Ямада в своей книге The Happiest Company to Work For («Самая счастливая компания для работников»). – Как же я могу решать?» Он часто узнавал о новых офисах продаж, открывающихся в Японии, только когда видел чью-то новую бизнес-карту. Сотрудники сами решали, запустить ли новый офис, снимали помещение в здании, нанимали и обучали новичков. Если бы Ямада не позволил людям самим принимать решения, они бы тратили уйму энергии, убеждая руководителей в том, чего те просто не понимали.

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

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

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

Здесь такое не сработает

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

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

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

Коммандер военно-морского флота США Джон Хаас связался со мной пару лет назад. Незадолго до того он принял командование подразделением с супом из букв вместо названия, EODMU2 (Explosive Ordnance Disposal Mobile Unit 2, или Мобильный отряд по обезвреживанию боеприпасов № 2), и хотел использовать Scrum в своем подразделении. Он желал двигаться быстрее, с лучшим качеством в одной из самых требовательных сред на планете.

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

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

Ответ начинается с такой ремарки.

Высказанное в данном письме мнение принадлежит его автору и необязательно представляет точку зрения Экспедиционного боевого командования военно-морского флота, Министерства ВМС, Министерства обороны или Правительства США.

Когда вы впервые узнали о Scrum?

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

Что вдохновило вас использовать Scrum для отряда по обезвреживанию боеприпасов?

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

Внедрение Scrum соответствовало всем этим требованиям.

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

Как вы структурировали Scrum? Что вы использовали?

Мы структурировали работу, последовательно внедряя Scrum – все роли, события и артефакты фреймворка. Scrum-мастером стал наш строевой офицер корабельной службы, владельцем продукта – командир корабля, а в команду вошли остальные ключевые штабные должности. Состав группы менялся со временем, и мы в итоге поняли, какие продукты поддерживает каждый член командования.

Вы сразу увидели результат?

Сначала команда показывала скорость 4 балла в день, но показатель стабильно рос до 50 баллов в день. Сразу же улучшились коммуникации, приоритизация, выполнение задач.

Какие элементы стали наиболее значимыми? Почему?

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

Временные рамки также стали неотъемлемой частью нашей жизни.

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

Можете привести пример того, что вы не могли сделать ранее, но чего добились с помощью Scrum?

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

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

Что вызывало сложности? Вы что-то меняли?

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

Пройдемся по спринту. Как и где проходило каждое событие?

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

Затем мы переходим к планированию спринта, где учитываем всю полученную информацию и включаем ее в план. Когда план спринта готов, мы переходим к ежедневному Scrum и обсуждаем, как начнем работу. Все это происходит в зале совещаний.

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

Изменится ли что-то после того, как ваша служба завершится?

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

Задумайтесь над тем, что вы только что прочли. Оставим в стороне военный контекст и сосредоточимся на основных пунктах. Это не армейская дисциплина, это пример работы Scrum в сложной, запутанной и непредсказуемой среде.

Хаас и его команда всегда были высококвалифицированны и мотивированы. Поскольку они служат в спецподразделениях, они по умолчанию лучшие из лучших. Однако после внедрения Scrum Хаас и его команда зафиксировали повышение продуктивности с 4 до 50 баллов в день за восемнадцать месяцев. Это рост на 1250 %.

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

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

На краю хаоса

В Анн-Арборе, городе, где расположен Университет штата Мичиган, в начале 1980-х на программе бакалавриата учился студент, захваченный идеей моделирования жизни внутри компьютера. Его звали Кристофер Ленгтон, и он начал заниматься тем, что назвал клеточными автоматами.

Клеточные автоматы – клетки решетки, состояние которых меняется со временем на основании ряда правил. Каждая клетка расположена по соседству с другими, состояние которых влияет на нее. Простейший вариант соседства – ситуация, когда одна клетка касается другой. И правила перехода могут быть простыми: например, если клетка рядом со мной во включенном состоянии, то и я включаюсь. Если взять более сложный сценарий и предположить, что две клетки по соседству от меня активны и одна неактивна, я тоже становлюсь неактивен.

Здесь можно быстро запутаться. Я опущу подсчеты, но Ленгтон категоризировал наборы правил в зависимости от степени изменений, которые они порождают. Он назвал этот параметр лямбдой. Чем он выше, тем больше изменений вызывает набор правил. Чем ниже, тем меньшим количеством изменений она управляет. Тут и случаются по-настоящему интересные события. Если лямбда слишком мала, вся система замирает и становится статичной. Если слишком велика, то система скатывается в хаос. Между двумя этими состояниями – переходная зона. Правила не могут быть слишком жесткими, поскольку это парализует систему, или слишком свободными, ведь это повергает ее в хаос. Должно быть ровно столько структуры, сколько достаточно для того, чтобы оставаться на краю хаоса.

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

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

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

И вот тут возникает проблема с проблемами. Не только клеточные автоматы действуют сложными адаптивными путями; то же касается экономики, экологии, нейрологии, команд и даже самого общества. Если правила слишком жесткие, ничего не меняется. Культура замирает. Ничего нельзя сделать. Структура в итоге гибнет. Именно это произошло в конце 1980-х с СССР. Долгое время страна была стабильна, а затем внезапно разрушилась. Но если правила слишком свободны, вы получите хаос. Беспорядки на улицах. Каждый сам по себе. Никакой сплоченности в обществе.

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

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

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

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

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

Распространенная реакция традиционного менеджмента на запутанные среды – установление контроля, введение большего количества правил на местах в попытке совладать с хаосом. Больше стоп-сигналов. Больше камер. И вся система встает. Останавливается процесс принятия решений.

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

Международная нефтяная компания попросила нас поработать с некоторыми из ее команд, которые решили, что им нужно пробурить несколько новых скважин. Для инженеров была проработана система фаз проекта, которые нужно проходить, а сама система требовала запредельного объема планирования и документации и очень, очень большого числа встреч. Затем приехали коучи Scrum Inc. и сформировали scrum-команды из обычных команд. Мы сказали руководству: «Хватит говорить им, что делать. Станьте наставниками. Каждый член команды – личность, и они работают вместе, чтобы достичь своей цели, а их цель – поставить новые скважины. Дайте им свободу, чтобы они могли это сделать». Конечно, командам нужно было создать определенные документы и провести необходимые исследования. Но они поняли, что нужно для принятия решения о бурении. Мы попросили их рассказать, что они сделали на каждой фазе проекта, и поместить информацию на стену так, чтобы каждый мог ее увидеть. Затем, игнорируя эти традиционные шаги и фокусируясь на доставляемой ценности, они смогли определить приоритеты – увидеть, как работать вместе и доставлять ценность инкрементально. Они взяли жесткую систему проектных фаз, которая ограничивала их, и превратили ее в гибкий бэклог, с которым можно начинать действовать.

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

Scrum сосредоточен на недетерминированной и сложной динамике систем и использует это. Он доставляет ценность не за счет централизованного принятия решений в одном месте, а за счет передачи решений к вершинам графа, где находится знание – к командам или владельцу продукта, – и работа выполняется без промедления. Это осмысленная система с определенной целью. Или, как ее назвал Ленгтон, детерминированный хаос[13].

Лучшее – враг хорошего

Независимо от того, какое решение вы принимаете, оно возникает вследствие взаимодействия отдельных элементов системы. Снова процитирую Эйзенхауэра[14].

План – ничто, планирование – всё. Между этими понятиями огромная разница. Когда вы планируете действия для экстренной ситуации, нужно учитывать, что само ее определение подразумевает ее неожиданность: все произойдет не так, как вы планируете.

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

Повторюсь, идеального плана не существует, поскольку невозможно предсказать заранее результаты деятельности динамической системы. Единственное, что вы можете, – попытаться сделать что-то и получить обратную связь. Любое действие лучше, чем ничего. Не нужно колебаться, действуйте. В определенном смысле неважно, что вы делаете; важен сам факт деятельности, которая позволяет чему-то научиться и двигаться дальше.

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

В 1999 году Дейв Сноуден работал в компании IBM и нашел способ рассмотрения проблем, позволяющий руководителям узнать, с чем они столкнулись и какое решение им стоит искать. Он назвал это фреймворком Cynefin (киневин), что переводится с валлийского как «место обитания»: для принятия решения нужно знать, где вы находитесь.

Первый тип проблем, обозначенных в фреймворке Сноудена, называется простым или очевидным. Это проблемы, которые уже решались ранее. Для них есть лучшие практики, которые всегда работают. Как только вы понимаете, что проблема проста, вы используете готовое решение из вашего набора инструментов. Если вы играете в покер, то никогда не смешиваете колоды. Банк не дает кредиты тем, у кого уже есть долг. В простых проблемах отношения между причиной и следствием не просто ясны, а очевидны.

Второй тип проблем – сложные, когда вам известно неизвестное. Возьмем для примера нефтяную компанию: геологи проводят сейсмологические исследования, чтобы узнать, где можно производить бурение. Они знают, что пока не знают точное место, но понимают, как его найти. Это область экспертизы. Как только вы поняли, что проблема решаема, вы можете найти решение, даже если это непросто. Если вы достаточно компетентны, то способны выявить причину и следствие. Я всегда думаю об этом, когда еду в автомастерскую на своей машине. Она издает странные звуки, и я беспокоюсь. Я знаю, что не знаю, как решить проблему, но я знаю, что мой механик знает, в чем она состоит или как ее определить.

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

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

Расскажу вам историю стримингового сервиса Twitch. Это веб-сервис, который позволяет людям транслировать в реальном времени то, как они играют в видеоигры, а другим – наблюдать за процессом. Только спустя годы этот продукт кажется очевидным. Но Twitch – невероятная история успеха. Amazon приобрел его за 970 млн долларов в 2014 году.

Какова была изначальная идея? Календарь, который можно интегрировать в почтовый сервис Google – Gmail. Конечно, затем Google выпустила свой календарь. Поэтому компания решила переключиться на трансляции в реальном времени. Один из основателей показывал всю свою жизнь, 24/7. Камера на голове, большой рюкзак с компьютером за спиной. Постоянно в эфире. Они создали невероятно быстрый стриминговый сервис, который множество людей могли использовать одновременно. Но оказалось, что никто не хочет смотреть такие трансляции. По этой причине они пришли к новой идее – возможно, люди хотят показывать себя? Но и она не продавалась на рынке, средства иссякали. Тогда сотрудники компании заметили, что много людей смотрели трансляции того, как другие люди играли в видеоигры. Странно. Но они приняли это, и оказалось, что существует аудитория фанатов и геймеров-любителей, которые желают понаблюдать за лучшими игроками. Люди могут заработать деньги, просто транслируя свои состязания в видеоиграх, чтобы другие могли понаблюдать за ними.

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

Именно поэтому вам нужно пытаться сделать что-то и посмотреть, что произойдет потом. Принять результаты и скорректировать свои действия. Затем попробовать снова. Опять внести поправки. И вот у вас есть решение. Именно так работает Scrum: серия небольших экспериментов за короткие отрезки времени позволяет вам найти решение запутанной проблемы.

Последний, четвертый тип проблем в фреймворке Cynefin – хаотичные. Они подразумевают кризис. Как сказал Эйзенхауэр, вы не можете запланировать экстренные ситуации. Вам, как лидеру, нужно быстро начать решать экстренную ситуацию и действовать уверенно. Представим себе цунами, либо взрыв буровой установки, либо восстание, перерастающее в революцию, либо падение фондовой биржи. В первую очередь, нужно действовать быстро, начать делать шаги по сдерживанию проблемы, определить ее границы, вывести ее из состояния хаоса на границу запутанности. Один из примеров, который я использую для описания проблем такого типа, – бунт. Однажды во время Арабской весны я находился в толпе, которая решила штурмовать здание парламента или что-то вроде того. Толпа из десятков тысяч людей потекла к воротам. Затем с одной стороны раздались крики. И в этот момент толпа стала хаотичной: все бегали вокруг, не зная, что делать. Из отдельных людей они превратились в народную массу. Я стоял среди них с молодой американской студенткой, которую я нанял из-за того, что она говорила по-арабски. Я сказал ей и скажу вам, что делать во время бунта. Во-первых, не поддаваться панике. Важность этого совета невозможно переоценить. Слепой страх – верный путь к тому, чтобы быть растоптанными и убитыми. Во-вторых, найдите что-то твердое, что нелегко снести. Фонарный столб или нечто вроде того. Как ни удивительно, толпа будет расступаться вокруг вас подобно речному потоку вокруг камня, упавшего в русло. Тем самым вы обращаете хаотичное в запутанное. Остановитесь на минуту. Дышите. Найдите пути отступления. Теперь вы можете себе это позволить. Вы не способны ничего сделать, если вы одно из тел, которые тащит за собой толпа. Но если вы способны выбраться из этого шума и страха, то можете начать планировать свои действия.

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

Хаос. Неопределенность. Действия

Однажды утром 11 сентября 2001 года Кеннет Холден и его помощник Майкл Бертон стали лидерами мрачного бюрократизма в глубинах городского правительства, в Департаменте проектирования и градостроительства (Department of Design and Construction, DDC). Они осуществляли надзор за договорами строительного подряда для ремонта улиц, библиотек, судов – физических составных частей гигантской системы Нью-Йорка. В то судьбоносное утро вторника самолеты врезались в здание Всемирного торгового центра и никто не знал, что делать. Хваленая городская Служба по чрезвычайным ситуациям бездействовала. Единственное, что понимали Холден и Бертон, так это то, что им нужно доставить невероятное количество оборудования и специалистов к Всемирному торговому центру и начать разбирать завалы, чтобы найти выживших и расчистить горы рухнувших вниз обломков.

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

Сначала департаменты полиции и пожарной службы пытались им помешать. Но они продолжали принимать решения: «Безопасно ли проводить спасательные работы? Возможно». Как правило, подобные катастрофы передают на федеральный уровень и ими занимаются Федеральное агентство по ликвидации последствий чрезвычайных ситуаций и Инженерный корпус вооруженных сил США. Но в тот раз, когда федеральные агентства спросили, что происходит, им сказали, что уже сделано, и попросили не вмешиваться. Бертон ни у кого не спрашивал разрешения.

Они были так эффективны, столько сделали, они координировали огромный проект так хорошо, что мэр Рудольф Джулиани сказал другим службам города – тем, которые должны были отвечать за происшествие, – чтобы они отступили и позволили Департаменту проектирования и градостроительства действовать. Они создали командный центр в одной из комнат детского сада, как вспоминает в своей великолепной книге American Ground («Американская земля») Уильям Лангевиш.

Не было времени перебирать варианты и писать планы. Только действия и были необходимы. Из-за потребности в четкой коммуникации Бертон проводил собрания дважды в день в одной из комнат детского сада – эта простая, не технологичная система управления отлично подошла в той ситуации апокалипсиса. Аргументация Бертона, как и всегда, была предельно ясна. Он сказал мне: «Единственный способ для нас контролировать ситуацию – сделать так, чтобы здесь был каждый. Нет времени рассылать уведомления или ждать, пока указания дойдут до нужных людей. Каждый должен слышать о том, какие проблемы возникают. Нужно принимать решения, и каждому стоит знать о них. Мы должны сделать так, чтобы все мы работали на общее дело»[15].

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

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

Не позволяйте теням обмануть себя

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

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

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

Не ждите. Действуйте.

ВЫВОД

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

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

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

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

БЭКЛОГ

1. В следующий раз на встрече для принятия решений засеките время и посчитайте стоимость мероприятия. Включите в общую сумму зарплаты всех, кто присутствует в аудитории. Сколько времени вы потратили зря на то, чтобы принять решение?

2. Вспомните о том, как ваша компания относительно недавно оказалась в кризисной ситуации. Могли ли вы действовать быстрее? Или вы, наоборот, удивились тому, как быстро организация отреагировала на ситуацию? Как вы можете изменить ваш процесс принятия решений?

3. Какой абсолютный минимум действий вы можете выполнить для того, чтобы достичь желаемых результатов? Что вы могли бы перестать делать?

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

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

Confirmation занимается подтверждением финансовых данных с привлечением крупной всемирной сети бухгалтерских компаний, финансовых институтов, юридических компаний и корпораций. Ее цель – обеспечить легкий доступ к достоверной информации. И она понимает, что финансовые махинации никуда не исчезнут, поэтому девиз ее основателя, Брайана Фокса, гласит: «Мы помогаем хорошим людям поймать плохих».

Приведу пример для иллюстрации. Основатель и председатель Peregrine Financial Group Рассел Вассендорф-старший обманул инвесторов более чем на 200 млн долларов за несколько лет. Как? Создавал в Photoshop банковские справки о состоянии счета, которые выглядели как настоящие. Схема рухнула, когда компанию вынудили использовать Confirmation.com. Всего за несколько дней стало понятно, что это мошенничество. Теперь Вассельдорфу еще несколько десятков лет сидеть в тюрьме за свои преступления.

Более ста лет процесс подтверждения финансовых данных велся на бумаге. Аудитор отправлял запросы в банк почтой: «Действительно ли у учреждения, находящегося в процессе аудиторской проверки, именно столько денег?» Банк получал не только эти запросы, но и тысячи других, сотни тысяч ежегодно. Приходилось нанимать команды, которые этим занимались. На каждое подтверждение нужно было отвечать, вручную проверяя банковские записи, составляя письмо, удостоверяющее, что у учреждения достаточно денег, и отправляя его обратно почтой. Бумаги. Очень много бумаг. Чтобы ответить на каждый из многих десятков тысяч таких запросов, требовались недели.

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

Confirmation.com стала первопроходцем электронной передачи подтверждений почти двадцать лет назад, получила семь патентов на свою деятельность и по-прежнему лидирует в этой сфере с большим отрывом от конкурентов. Все началось с одного банка и одной бухгалтерской компании в Нэшвилле, а сейчас платформой пользуются 16 000 бухгалтерских компаний, 4000 банков и 5000 юридических компаний в 160 странах. Каждый год она подтверждает сделки на сумму более триллиона долларов.

В 2000 году, когда компания начала работу, в ее штате было четверо сотрудников, офис располагался в гараже. Они пытались состряпать новый продукт, который никто и никогда ранее не создавал и который Брайан визуализировал и описал в своем учебном задании по предпринимательской деятельности в бизнес-школе. Естественно, крупные банки начали понимать, сколько усилий они могли бы сэкономить и насколько повысилась бы скорость работы, и сказали, что будут принимать запросы только на платформе Confirmation. Больше никакой бумаги. Confirmation.com быстро росла, на платформе появились новые функции и типы подтверждений, например юридические.

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

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

Факты – упрямая штука

Приоритет – старое слово. Оно появилось в конце XIV в. Французы позаимствовали латинское слово, чтобы обозначить предшествование – тот факт, что одно событие произошло раньше другого. В английский язык оно вошло в начале XV в. и обозначало первоочередность в правах или статусе[16].

Если вы запустите поиск Google Ngram (сервис, подсчитывающий количество использований слова в книгах за последние несколько сотен лет) по слову «приоритеты» (priorities) на английском, то получите следующий результат.

Но до 1940 года множественного числа у этого слова даже не было. Я не уверен на 100 % в причинно-следственной связи, но прослеживается некая корреляция роста современного управленческого движения в послевоенный период с рождением нового слова, которое звучит условно логично и строго, а на самом деле бессмысленно. Мне кажется, это неспроста.

Перестаньте начинать, начните заканчивать

Когда мы со Scrum Inc. приходим в компанию для оценки ее гибкости, то, как правило, обнаруживаем, что около 30 % ее работы выполнять вовсе не нужно. Чаще всего она идет вразрез с целями бизнеса. Остановитесь. Согласно данным Standish Group и нашим наблюдениям, 64 % из оставшихся 70 % задач – работа над функциями, которыми потребитель пользуется редко или не пользуется вовсе. Получается, 75 % сотрудников компании либо активно работают против интересов бизнеса, либо корпят над тем, что никому не нужно. Попробуйте осознать это. Три четверти сотрудников вашей компании не должны заниматься тем, чем они занимаются.

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

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

У нас есть множество противоречащих друг другу приоритетов.

Наши команды постоянно переключаются на новые приоритетные задачи.

Все задачи – с приоритетом номер один.

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

В Confirmation.com у каждого были свои приоритеты. Отдел продаж требовал более качественный перевод на японский, чтобы продавать продукт в Японии; маркетинг хотел запустить ребрендинг сайта; руководство занималось вопросами конкуренции. На чем же сфокусироваться продуктовым командам? «Я всегда с нетерпением жду, какие же новые правила прозвучат сегодня», – сказал один из руководителей компании в беседе с Ави Шнейером, руководителем проекта со стороны Scrum Inc. Когда Ави спросил, что главное для компании, ему ответили: «Выполнение работ в срок». Заметьте: срок сам по себе, а не задача, которую нужно решить.

Ави хотел, чтобы они работали над настоящими приоритетами компании. Что важнее всего? Он помог компании увидеть, что без списка приоритетов она все равно что без руля и каждый день выбирает новое направление. И она сделала верный выбор. Это возможно, но требует искренней рефлексии и трудных решений.

Результаты работы vs Результаты деятельности

Разберем эти две темы по отдельности. Результаты работы – то, сколько команда производит за каждый спринт, их скорость. Когда вы внедряете Scrum, то хотите, чтобы скорость удвоилась или утроилась за несколько месяцев. Если вы не можете довести дело до конца, даже ненужное, то ничто другое уже не имеет значения. Сфокусируйтесь на том, чтобы команда доводила дело до готовности. Если окажется, что это не то, что нужно (а так наверняка и будет), со Scrum вы выясните это быстрее, и вам не придется тратить миллионы долларов и годы жизни, чтобы понять, что ваша работа никому не нужна.

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

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

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

Критерии готовности и сущность архитектуры

Ключ к тому, чтобы довести что-то до готовности, – заранее определить, что означает «готово». Когда команда выбирает элемент из бэклога продукта, она должны знать, какова природа готовности этого элемента. Отчасти здесь дело в том, как элемент встраивается в систему других элементов. Почему? Потому что – и это важно – архитектура вашего продукта определяет критерии готовности.

Приведу пару примеров. Один касается аппаратного обеспечения, другой – программного, но мышление в основе примеров идентично.

Существует некая частная космическая компания, которую я назову Stealth Space Company (Незаметная космическая компания). Так они называют себя на своей странице в LinkedIn, в любой нежелательной публикации в СМИ и постоянно всем повторяют: «Мы не хвалимся, мы не говорим – мы делаем». Они располагаются на заброшенной морской авиационной станции на краю залива Сан-Франциско у побережья США. Военные базы вроде этой отличаются в зависимости от расположения и основавшей их службы, но у них есть одна общая черта – жесткая, бескомпромиссная архитектура, в которой функциональность доминирует над формой.

Крис Кемп – СЕО этой компании. У него светлые волосы, он обычно носит черные футболки, пиджаки и брюки. Его мантра – скорость. Приведу отрывок из его письма, в котором он анонсировал первую попытку запуска.

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

Он смотрит на компанию SpaceX Илона Маска и видит цель, которую не просто превзойдет, но превзойдет громко: в пять раз быстрее и в пять раз дешевле. И он использует Scrum, чтобы добиться того, чего хочет. Его цель – стать космическим FedEx[17], ежедневно отправляя небольшие целевые нагрузки на низкую орбиту. Армии необходим комплекс разведывательных спутников над новой проблемной зоной? Без проблем; спутники будут там через 30 минут, а не через три года.

Беседуя с его сотрудниками, вы чувствуете их стремление к успеху. Один из его лидеров всю свою карьеру посвятил космическому бизнесу: SpaceX, Virgin Galactic, Boeing. Он сказал, что некоторые члены его команды полагали, будто фреймворк Scrum подходит только для программного обеспечения.

«Для меня это все в новинку, – сказал он мне. – Но я увидел, насколько плохи старые способы работы. Я говорю новым инженерам, что они пока не знают, как им повезло, и я полностью вовлечен в общее дело. Я ясно дал им понять: либо они тоже вовлечены, либо им нужно искать другую работу».

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

Приведу простой пример. В их первой ракете комплекс бортового оборудования контролировался рядом специальных монтажных схем, которые были соединены друг с другом и с ракетой, а переключатели выполнялись из очень редкого унобтаниевого[18] материала. Если одна схема ломалась, нужно было снимать все и восстанавливать сотни коннекторов вручную, используя невероятно дорогие материалы. В какой-то момент редкоземельные элементы, которые они применяли для коннекторов, просто ушли с рынка: Apple и Samsung смели мировой запас для производства нового поколения телефонов. Чтобы раздобыть материалы, потребовалось двенадцать недель. Кемп был в ярости и выругался: «Три месяца, чтобы достать коммутатор Ethernet? Подобное [непотребство] нас в могилу сведет!»

Мой коллега Джо Джастис сел вместе с Итаном, руководителем отдела авионики, и объяснил проблему. «Во-первых, – сказал Джо, – у вас есть все эти схемы со специальными коннекторами и все они разные, каждая передает свою информацию. Вам нужно снизить запутанность, заменить их другими коннекторами, с лучшим дизайном. Но если демонтировать один, сломаются все. Поэтому наладим стабильный интерфейс между комплексом бортового оборудования и другими системами ракеты. Перестроим их так, что они могли передавать все виды данных, больше, чем вам нужно, но с общими коннекторами, которые можно купить готовыми и недорого. Ограничим проблему, сделаем выборку элементов, которые не изменятся. Убедимся, что остальные проектировщики ракеты знают, как нужно подсоединять свой интерфейс, используя одну сторону коннектора, а проектировщики радиоэлектронных систем в курсе, что им нужна вторая. Так вы сможете менять что угодно в любой части системы; пока общий интерфейс сохраняется, неважно, где будет происходить изменение. Нужно сделать задачи модульными. По принципу конструктора LEGO. Чтобы части легко соединялись и разъединялись».

Такой подход упростил формирование критериев готовности: элемент должен работать и подходить известному стабильному интерфейсу. Теперь вы можете решать проблемы одну за другой. Лишний вес из-за самого интерфейса? Займетесь этим позже, когда решите остальные проблемы.

Теперь возьмем пример гибкой архитектуры из сферы программного обеспечения. Схема та же. Spotify – музыкальный сервис. Его цель, как и цель аэрокосмической компании, – скорость. Когда компания еще была стартапом, ее CEO Дэниел Эк как-то сказал Scrum Inc.: «Apple, Google и Amazon хотят нас убить. И это умные, крупные компании со множеством навыков. Единственный способ выжить для нас – скорость. Нам надо быть быстрее, чем они».

Так Spotify разделился на модули, подобно ракете. Есть система воспроизведения, рекомендательный движок, функции плейлиста, мобильное приложение и т. д. И точно так же, как Stealth Space Company, они разработали стабильные интерфейсы между частями. Команды, занимающиеся плейлистами, могут вносить столько инноваций, сколько хотят, менять столько, сколько пожелают, пока их участки укладываются в нужные рамки, передают и получают нужные данные и не ломают ничего другого. Так они могут быстро двигаться вперед и не беспокоиться о том, что повредят другие части системы.

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

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

Исправление

Что вы будете делать? У вас десятки проектов, сотни приоритетов, и все их нужно довести до конца. Так вы решили.

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

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

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

Это первый шаг: признать, что у вас не все и не всегда получается сразу. Нужно делать выбор. И иногда это сложно. Зачастую сталкивается множество конкурирующих интересов. Но если руководство не синхронизировано и не понимает, что должно быть сделано и в каком порядке, у команд тоже не будет понимания, что им делать. Руководство Confirmation.com смогло с этим справиться. Они изменили и модернизировали структуру и убедились в том, что каждая команда имеет понятный, приоритизированный бэклог на каждый спринт. И это кардинально изменило всю работу.

Важность слова «нет»

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

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

Одно подразделение не могло выпускать продукты на рынок достаточно быстро. У них были великолепные идеи, но не получалось довести их до ума. Тогда они обратились в Scrum Inc., и в начале 2016 года спокойный молодой человек Стив Даукас пришел к ним, чтобы узнать, чем он может помочь.

Он собрал руководство лаборатории в одной комнате и сказал: «Для начала поговорим о том, что вы делаете. Перечислим все проекты на стикерах и поместим на стены, чтобы все было видно».

Через четверть часа напряженного сочинительства все проекты были на стенах. Их оказалось больше сотни.

«Хорошо, – сказал Стив. – Интереса ради давайте напишем на каждом проекте имена тех, кто над ним работает. Кто эти люди?»

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

«Почему вы работаете над несколькими задачами?» – спросил Стив.

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

«А хоть один из них уже готов?»

Тишина в ответ.

Я слышал этот разговор в разных вариантах от разных людей, начиная с родителей малышей и до стартапов и компаний из списка Fortune 500. Им столько нужно сделать, что они начинают миллиард проектов одновременно. По их мнению, они должны так поступать. А потом они говорят: «Смотрите, сколько мы делаем! Мы так заняты, это безумие! Мы работаем над всеми этими важнейшими задачами».

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

А потом, когда мы спрашиваем их о результатах, они понимают, что потерпели фиаско.

Тогда Стив вынудил группу признать, что не все ее проекты будут завершены. Более того, если она продолжит в том же духе, то не будет сделано ничего.

Поэтому они взяли эти сто с лишним проектов и начали отбирать те, которыми не будут заниматься. На чем должны сосредоточиться команды лаборатории? Что действительно нужно рынку? Они спорили. Пытались проталкивать свои проекты. Убивали любимые проекты сотрудников. Тяжко трудились, чтобы сделать то, что лидеры должны делать, – принимали решения. Легко сказать «да» проекту, согласиться с кем-то, что его идее нужно следовать, избегать тяжелых разговоров. Легко не отказывать.

Количество проектов сократилось до двенадцати. Затем Стив попросил руководителей группы составить бэклоги для них. Не слишком, но достаточно подробные, чтобы передать «замысел командира»: не то, как команды будут работать над проектами, но что они будут делать и почему. Затем двенадцать человек, которые стали владельцами продуктов, выступили перед группой ученых, двумя сотнями человек, и представили им свои бэклоги – то, что ученые постараются выполнить, почему это важно и какие навыки нужны для этого. Затем владельцы продуктов и менеджмент покинули комнату со словами: «Вы умны, вы сможете сами распределиться по командам, чтобы достичь эти двенадцать целей».

Полчаса спустя они вернулись в комнату. У каждого бэклога была команда или команды, кроме одного. Работа над ним включала утомительные обновления в соответствии с установленными государством требованиями. Необходимый, но никто не хотел им заниматься. Наконец один храбрый человек поднял руку и сказал: «Хорошо, я возьмусь. Это нужно сделать, посмотрим, насколько быстро мы управимся».

За десять недель их продуктивность выросла вдвое, они открыли новые возможности получения прибыли, которых не видели раньше, устранили более 53 препятствий, возникших на пути команд. Поскольку цель сместилась с результатов работы на результаты деятельности, произошли структурная реорганизация и значительные изменения. Стандартный цикл разработки длился два с половиной года; со Scrum выходило по два новых продукта каждые шесть недель. Подразделение привлекло покупателей, крупных клиентов, которые сразу захотели купить его продукты. Вот на что способен правильный фокус. Люди смогли перейти от сотен проектов, которыми никто не занимался, к двенадцати, которые выполнялись. Они изменили судьбу подразделения и повлияли на котировки акций многомиллиардной материнской компании.

Сфокусированность на доведении дела до готовности дает свои плоды. Нужно только уметь говорить «нет».

Не «в работе», а «готово»

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

Вот что с нами сделала многозадачность. Приведу цитату из своей любимой работы по данной теме.

Даже если участники дорожного движения направляют взгляд на объекты в зоне вождения, они часто не могут «увидеть» их, когда говорят по мобильному телефону, поскольку их внимание перенаправлено с внешней обстановки на внутренний когнитивный контекст, ассоциирующийся с переговорами[19].

Люди будут смотреть на объект – машину, в которую они вот-вот врежутся, или дерево, которое вот-вот погладит капот их автомобиля, – и не видеть его. Однако мы продолжаем разговаривать по телефону за рулем.

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

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

На эту тему есть исследования: согласно им, люди не способны к многозадачности. Поместите людей в аппарат МРТ, попросите выполнять несколько заданий одновременно, и вы увидите, что они не могут справиться с этим. Однако, делая выбор, отказываясь, четко определяя приоритеты, вы можете изменить свою судьбу. Международный производитель смог. Confirmation.com тоже. Stealth Space Company запустила свою первую ракету. Мы живем в постоянно меняющемся мире, есть способы выжить в нем и даже процветать. Но для этого нужны настоящие открытия, настоящий выбор. В первую очередь (подробнее я расскажу об этом в главе 5) нужно спросить себя, что движет вами: страх или надежда. Вам решать. Даже если вы думаете, что все вышло из-под контроля. Даже если вы видите, как приближаетесь к пропасти. Именно вам решать, что с этим делать.

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

ВЫВОД

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

Доводите дело до конца. Здесь нужно заранее определить, что значит «готово». Когда команда выбирает элемент из бэклога продукта, она должна знать, когда его можно считать готовым, как он встраивается в систему других элементов. Архитектура вашего продукта определяет критерии готовности.

Не путайте «в работе» и «готово». Фокус на утилизации как метрике прогресса поддерживает занятость персонала, но не способствует доставке ценности. Сфокусируйтесь не на результатах работы, а на результатах деятельности.

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

БЭКЛОГ

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

2. Каковы ваши критерии готовности? Запишите их. Поместите на стену так, чтобы каждый мог видеть их каждый день.

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

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

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

Большую часть своей взрослой жизни я провел в зонах боевых действий, работая военным журналистом на Национальном общественном радио (National Public Radio, NPR). Когда люди узнавали об этом, они всегда спрашивали меня: «На что это похоже?» Первые несколько лет вопрос возмущал меня. Но я понял, что они хотели понять мои чувства в ситуации, с которой они, надеюсь, никогда не столкнутся. И наконец я придумал ответ: невероятно страшно и ужасно громко.

Однажды ночью в Бенгази (Ливия) я не мог заснуть. Шел 2011 год, и бессонница не была редкостью по большей части из-за того, что добрые граждане были охвачены революционным пылом. Когда они несли плоды мародерства в виде всего оружия, какое могли найти, они думали, что не выстрелить из него было бы откровенным неуважением к Отчизне. При любой возможности они стреляли в воздух, вероятно, не зная, что пули не исчезают в небе просто так. Мое простреленное окно было тому свидетельством. Той ночью они действительно разошлись.

Ливия стала крайней остановкой на моем революционном пути. Я работал по контракту, был основным поставщиком материалов для NPR. Я обозревал события Арабской весны с самого начала, и власть имущие отдела международных новостей считали, что после революционных событий в Каире Ливия станет естественным продолжением карьеры для Лурдес Гарсия-Наварро[20] и меня. Мы были дома лишь несколько дней за последние месяцы.

Я пережил много перестрелок в разных войнах, беспорядках, переворотах и за годы научился определять оружие по звуку выстрелов: как короткими очередями строчит АК-47, как хрипло захлебывается в огне пулемет 50-го калибра, как черным знамением глухо стреляет миномет. Я различаю их все, вплоть до артиллерии, ракет, танков и (моих любимых) девятитонных высокоточных авиационных боеприпасов прямого поражения (или попросту очень больших бомб) – такие Израиль сбросил на одно из зданий в Бейруте, и взрывная волна буквально смела меня с постели. Но в Ливии у Каддафи определенно было пристрастие к оружию, известному только посвященным; я видел и слышал орудия, которые не мог узнать. Той ночью город был охвачен огнем, выстрелы освещали его так, будто опустошающая битва колоссальных масштабов пронеслась по улицам. Мой разум кричал, что тут все неправильно – не потому, что группа идиотов бушевала, стреляя из боевого оружия в многолюдном городе, а потому, что звуки были не теми.

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

Я общался в Facebook с Арнольдом Стронгом – моим приятелем, который служил в диверсионно-разведывательном подразделении рейнджеров. Мы встретились в Кандагаре в 2006-м, когда он еще был майором. Мы поладили и до сих пор остаемся хорошими друзьями. «Ненавижу войну, – написал я. – Она открывает самые черные уголки человеческой души и придает им значение».

«Разве только война?» – ответил он. Арнольд знал, что такое война. Все лето мы провели вместе, скитаясь по югу Афганистана. Никогда не забуду, как утром трясся от страха и как этот огромный угрюмый разведчик по-доброму отнесся ко мне и накормил завтраком. NPR отправляли меня в другую горячую точку. Чтобы добраться туда, мне пришлось двигаться вниз по дороге, которую регулярно сотрясали авиаудары. Он знал войну, страх – и меня.

«Это очень хороший вопрос», – написал я в ответ.

Обветшалые чертоги разума

Чтобы объяснить страх, мне нужно немного рассказать о памяти. Когда вы испытываете что-то, оно сохраняется в вашем мозге. Неважно, что вы думаете о воспоминании, хорошее или плохое. Глубоко в вашем мозге им занимается маленькая группа ядер миндалевидной формы – миндалевидное тело. Это происходит без участия когнитивной функции. Сначала наступает эмоциональная реакция.

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

Утром 11 сентября 2001 года Элизабет Фелпс подходила к своему офису, когда второй самолет врезался во Всемирный торговый центр. Из окна она смотрела, как падает одна из башен. Как и большинство людей в тот день, она не могла в это поверить. Она ушла с работы. Целый день смотрела телеканал CNN. Пыталась сдавать кровь. Как и многие люди в тот день, чувствовала себя парализованной и хотела сделать хоть что-то.

Но доктор Фелпс не была первой, кто откликнулся на беду; она не была солдатом, журналистом. Она исследовала память. И особенно ее интересовало то, как связаны эмоции и память. Она и ее коллеги по всей стране решили опросить людей об их воспоминаниях сразу после трагедии. К 18 сентября они распространили опросники по Манхеттену. Затем – еще тысячи анкет по всей стране. Вот некоторые вопросы.

1. Пожалуйста, опишите, как вы узнали о террористическом нападении на США.

2. В котором часу вы впервые услышали о нападении?

3. Откуда вы узнали о трагедии (из какого источника получили информацию)?

4. Где вы были?

5. Что вы делали?

6. Кто находился с вами?

7. Как вы себя чувствовали, когда впервые услышали о нападении?

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

Исследователи снова провели опрос год спустя. Затем три года спустя. Затем десять лет спустя. Вот что удивительно: со временем воспоминания становились все менее точными, однако уверенность оставалась высокой. В интервью научно-популярному журналу Scientific American доктор Фелпс сообщила следующее.

Если вы изучите воспоминания об 11 сентября, то заметите, что почти каждый говорит: «Я знаю, где был, с кем был», – и т. д. Каждый думает: «Я никогда этого не забуду». Но исследования за последние тридцать лет показали, что люди не всегда правы, когда так говорят. У вас не получится даже убедить их в том, что воспоминания неверны. Единственное возможное возражение: данные предполагают, что воспоминание ложно.

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

Такова память. Самые сильные воспоминания, которые «вспышками» возникают в сознании, изменяются. Они теряют свое эмоциональное воздействие – по крайней мере, оно меняется и эволюционирует. Это к лучшему. Если бы они не изменялись, мы были бы вынуждены носить свои душевные раны вечно. Ужас, который мы испытали в тот день, никогда бы не померк, не угас. Он навсегда остался бы нашим настоящим, вместо того чтобы отойти в прошлое.

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

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

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

Решение – меняться. Адаптироваться и развиваться. Scrum – способ обрести возможность изменять свою личную и организационную структуру. Однако остерегайтесь сопротивления. Любое изменение, любая инновация в корпорации стимулирует выработку «антител» корпоративной иммунной системы.

Почему? Почему мы ведем себя так?

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

Безумие безумия

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

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

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

У них проходили собрания. Много собраний. Они встречались, чтобы запланировать встречи, обсудить, сколько встреч уже прошло. Дни этих менеджеров были забиты важными собраниями с другими важными людьми, которые делали акт посещения таких мероприятий символом статуса. Ведь если важный человек приходил на него, оно наверняка должно быть важным, просто потому что он там присутствует. Каждый, кто проходил мимо стеклянных дверей переговорной и видел действительно важных людей на встрече, знал: раз собрались такие люди, наверняка и решается какой-то крайне значимый вопрос. И те, кто был внутри стеклянных стен переговорной, получали немного удовольствия, ощущали свою важность, знали, что другие люди испытывают страх по той лишь причине, что они смотрят, как более важные люди встречаются.

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

Когда я впервые об этом услышал, то принялся считать. Предположим, что средняя зарплата этих людей составляла 75 000 долларов. Умножим на две сотни – получится 15 млн долларов. Умножим на пять лет – выйдет минимум 75 млн долларов, а то и больше, учитывая, каких менеджеров они привлекли.

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

Когда Scrum Inc. наняли, чтобы разобраться с этим беспорядком (а описанное выше – малая и, честно говоря, не самая важная часть бардака в компании), в первую очередь мы спросили: «Кто выполняет работу?» Наша команда искала ответ месяц. Она провела много времени на собраниях, где ей показывали презентации и организационные диаграммы. Когда мы попросили продемонстрировать завершенную часть работы, менеджеры и исполнительное руководство удивились. Они собирались показывать нам отчеты, а не саму работу.

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

Наша команда посоветовала компании сократить 175 человек на этом проекте. Бесконечные собрания закончились только тогда, когда главный владелец продукта сказал руководству: если они хотят получить отчет о ходе работ, пусть приходят на обзор спринта. Больше никаких собраний. Или собраний по собраниям. Также они начали приоритизировать – выбирать нужную работу, которую будут выполнять, и порядок действий. Команды смогли сфокусироваться, направиться к единой цели, спринт за спринтом. Они начали показывать подлинный прогресс каждую неделю. Конечно, поскольку они были успешны, другие менеджеры пытались переманить членов команды в свои проекты. Но главный владелец продукта мог сказать «нет» руководству: «Нет, вы не получите отчет о ходе работ. Нет, мы не пойдем на те встречи. Нет, я не буду проводить презентацию». «Нет» – самое важное слово в лексиконе владельца продукта. Если вы на все соглашаетесь, вы никогда ничего не доведете до конца.

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

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

Никто не хочет на нас работать

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

Покажу вам этот пример в развитии. Самый богатый человек в мире на момент написания этой книги – Джефф Безос. По данным журнала Forbes, его состояние в 2018 году составляло 112 млрд долларов. Он купил дом в Вашингтоне, где я живу. Тот ранее был музеем и обошелся Безосу в 23 млн долларов; ходят слухи, что он потратил еще 20 млн на ремонт. Это кажется абсурдным. Но когда я посчитал, то оказалось, что 43 млн трат Безоса эквивалентны тому, как я потратил бы пару сотен долларов. Свидание в хорошем ресторане для меня – особняк площадью в 2500 квадратных метров для него. Это деньги в масштабах государства. Состояние Безоса превышает ВВП 120 стран. Он находится между Марокко и Кувейтом.

Каждый из банков, о которых я говорю, обладал средствами на порядок большими. Когда я разговаривал с представителями одного из них, я спросил: «Зачем вы обращаетесь ко мне? Все деньги у вас».

«Никто не хочет на нас работать», – отвечали они.

Я слышал это не только от банков. Но и от страховых компаний. От крупных промышленных компаний. От производителей. Как правило, от тяжеловесов, которые десятки лет сталкивались с незначительной конкуренцией и не слишком мотивированы меняться. Компания GE, например, повысила оклад при поступлении на работу, чтобы привлечь больше талантов. Они проводили публичные хакатоны[21]. Они провели идеальную рекламную кампанию, нацеленную на миллениалов.

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

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

Очень часто компании говорят, что хотят меняться, быть гибкими. Но когда начинаешь им объяснять, что нужно сделать, чтобы добиться результата, они отвечают: «Здесь это невозможно. Тут мы иначе всё делаем. Мы всегда делали именно так. Да, мы хотим преимущества Scrum, но не желаем менять наше поведение». Это безумие.

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

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

«Нам нужно менять способы работы, – сказал он громким и сильным голосом. – Потому что они отстойные. Все мы знаем об этом. И это боль каждого из нас».

Комната замерла в тихом согласии.

«Все мы хотим делать хорошее, – продолжил он. – Мы хотим создавать лучший из возможных продуктов. Гордиться тем, что делаем».

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

«Мы прекрасно научились развешивать ленту вокруг кабинки, – сказал он. – И преуспели в рисовании таблички “Не работает”. – Он замолк, подумал некоторое время, а затем продолжил: – Почему мы так хороши в этом, а не в решении проблем? Это уже само по себе проблема. Именно поэтому мы починили туалет».

Толпа застыла в восхищении. На самом деле. Наконец один сотрудник встал и сказал: «Это вопрос времени. Спасибо».

Затем женщина из отдела поставок сказала: «Это замечательно. Тогда, может, вы почините и раковину в женской уборной за соседней дверью?»

«Да! – ответил лидер. – Но только если вы все скажете своим scrum-мастерам и мне о том, что есть проблемы. Иначе мы не узнаем о них. Нам нужно, чтобы вы рассказывали нам о том, что замедляет вас».

«Начните с раковины, и тогда я поверю в то, что вы говорите серьезно», – ответила она.

И они начали.

Вам не нужно принимать как данность, что вещи сломаны и их нельзя починить. Даже если речь идет о простых вещах.

Прозрачность шторма

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

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

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

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

А затем произошло кое-что интересное. В США случается сезон штормов, когда гигантские ураганы приходят со стороны Карибского моря или южной части Атлантического океана, принося с собой шквалистые ветры, ливни и штормовые волны, яростно накатывающие на побережье. С тех пор как начали отслеживать такие ураганы и тропические штормы, худшим годом стал 2017-й: произошло 17 штормов, которым дали имена, в их числе 10 ураганов, шесть из которых были крупными (3-й категории и выше). Ураганы Мария и Ирма опустошили Карибские острова и захлестнули Флориду. Ураган Харви затопил города Галвестон и Хьюстон. Это был очень дурной год.

Ураган может разрушить коммуникации и электрические сети – порой на недели, а в случае Пуэрто-Рико на многие, многие месяцы. Я был в обслуживающей компании в США примерно через месяц после шторма. Тогда сотни тысяч их клиентов остались без электричества.

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

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

Правила должны бороться за жизнь

Несколько лет назад в NPR менеджмент попросил меня на время стать линейным продюсером программы Morning Edition. Этот человек – один из тех, кто решает, что будет на шоу, в каком порядке и сколько займет времени. Было весело. Находиться на работе в полночь не слишком радостно, но сами задачи приносили мне удовольствие.

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

– Так нельзя.

– Как?

– Нельзя ставить рядом два интервью.

– Почему?

– Таковы правила.

– Это глупые правила.

– Это структура шоу. Ты сейчас подменяешь человека и, возможно, просто не понимаешь наше видение звучания и структуры Morning Edition.

– В самом деле?

– Давай покажу.

Он вытащил небольшой блокнот на трех кольцах, на обложке которого было написано «Как сделать Morning Edition» или что-то вроде. Там четко утверждалось, что я не смогу сделать то, что намеревался. Я уступил – на какое-то время.

Следующие три дня я пытался понять, кто придумал это правило. Я хотел высказаться. В итоге я позвонил Джею Кернису. Именно он запустил программу в 1978 году.

– Джей, у меня есть вопрос по поводу правила.

– Какого правила?

– Утверждающего, что нельзя подряд ставить несколько фрагментов одного формата.

– А, так это потому, что на катушечных магнитофонах не получается быстро перемотать ленту, нужно время. Вот и приходилось увеличивать промежутки.

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

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

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

Закон Сарбейнза – Оксли вступил в силу в 2002 году, вскоре после катастрофических скандалов с Enron, WorldCom и Tyco International. Он суров: если CEO или коммерческий директор компании сознательно подает ложные данные ведомственным аудиторам, его могут оштрафовать на сумму до 5 млн долларов и посадить в тюрьму на срок до двадцати лет. Это не шутки. Каждая публичная или международная компания должна быть зарегистрирована в Комиссии по ценным бумагам и биржам США, и любая бухгалтерская фирма, поставляющая такой компании услуги, обязана соблюдать закон Сарбейнза – Оксли.

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

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

«Вы правы, – сказала она. – У меня этого нет. Но я могу доказать, что мы на самом деле делаем больше, чем вы просите, и куда более эффективно».

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

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

«Вы правы, – сказал аудитор. – Гибкий процесс – это лучший путь [в сравнении с традиционным]».

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

«Старые правила нам больше не подходят, – сказал он группе. – Что нам сделать, чтобы улучшить ситуацию?»

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

Вот еще один пример. Много лет назад в компании Siemens сотрудники были завалены горами документов и отчетов, которые им нужно было писать. И никто, совсем никто не мог это изменить. Поэтому в качестве эксперимента команды стали набирать бессмысленные тексты примерно в середине документов и оставляли номер телефона, на который нужно позвонить, если у кого-то возникнут проблемы. Если никто не звонил в течение шести недель, они прекращали работу над документом или отчетом. Согласно правилам они должны были продолжать, и сотрудники бездумно следовали им. Виноватыми оказались правила, не люди. Это безумие – почти в духе Франца Кафки. Вынуждайте правила бороться за жизнь. Люди заслуживают этого.

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

«Здесь просто все так работает».

«Это никогда не изменится».

«Я знаю, это кажется безумием, но…»

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

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

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

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

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

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

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

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

Почему все время не может быть временем шторма?

Доктор Отто Шармер, профессор Школы управления Слоуна при Массачусетском технологическом институте, выдвинул теорию. Суть ее в том, что каждый испытывает страх. Он управляет всеми нами. И контролирует нас.

Все исследования показывают: когда люди напуганы, они не слишком изобретательны. Они возвращаются к старым шаблонам – Шармер называет этот процесс загрузкой, привычным мышлением. Работая в мире быстрых изменений, которые мы не можем понять, мы загружаем прошлое поведение, даже если оно явно непродуктивно, а то и контрпродуктивно в текущей обстановке. Но мы защищаем эти шаблоны до самой смерти. Мы ложимся на баррикады и говорим No pasarán! Если мы не можем контролировать изменения в мире, то по крайней мере способны контролировать перемены в себе. И обрекаем себя на свалку истории.

Шармер утверждает: чтобы преодолеть этот страх, нам нужно услышать три голоса, которые ведут беседу внутри нас.

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

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

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

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

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

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

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

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

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

Или так казалось – пока не удалось поговорить с людьми на несколько уровней ниже в иерархии. Они цинично говорили мне: неважно, что сказал CEO. Менеджеры среднего звена не станут это делать. Они не позволят командам самим принимать решения, разрушать подразделения или делать еще что-то по agile-принципам. Тогда они не в первый раз посещали тренинги, сессии и конференции, не в первый раз получали электронные письма с обратной связью. Раз такое уже было и ничего не изменилось, с чего бы верить, что в этот раз будет иначе?

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

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

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

Последний голос, с которым придется иметь дело согласно классификации Шармера, – голос страха, с которого я и начал эту главу. Подумайте о своей работе сейчас, о самом важном проекте. Нашепчу вам всего несколько вопросов на ухо. «Что, если я потерплю неудачу? Что мой руководитель подумает обо мне? А команда? Что подумает обо мне семья, когда меня уволят? Что скажет мой отец?»

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

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

Эдвардс Деминг научил японцев концепции постоянного улучшения после Второй мировой войны. В поздние годы он глубоко заинтересовался состоянием бизнеса в Америке. И в 1980-х выпустил книгу «Выход из кризиса»[22], когда понял, что американская промышленность столкнулась с экзистенциальным кризисом, как Япония после войны. Он разработал список из четырнадцати правил, которые компании нужно соблюдать, например: «Улучшайте каждый процесс. Улучшайте постоянно, сегодня и всегда все процессы» и «Учредите лидерство». Я особенно хочу обратить внимание на номер 8: «Изгоняйте страхи».

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

Я мог бы привести много других цитат о психологической безопасности, доверии, создании великих организаций. Но правда в том, что страх – убийца разума. Для вас, вашей команды, вашей компании.

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

Это поистине безотрадно.

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

Люди – это связь

Недавно я обедал с профессором Икудзиро Нонака из Университета Хитоцубаси, лидирующей бизнес-школы Японии. Нонака – соавтор работы, в которой в 1986 году впервые был предложен термин Scrum. Он сказал, что ключ к формированию великой организации и миссия великих лидеров – создать среду, в которой происходят инновации. А среда эта существует в связях между людьми. Он использовал японское слово «ба», что можно вольно перевести как «контекст, который несет в себе смысл». Это общее пространство между личностями, основа для создания знания.

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

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

Мы в Scrum Inc. рассеяны по всему миру. Сейчас у нас есть команды в Японии, Германии, Техасе, Массачусетсе, Великобритании, Австралии, Сингапуре, Мексике. Мы работаем везде. Каждый квартал мы прекращаем работу и слетаемся в один город, чтобы встретиться лично. Мы говорим. Хорошо проводим время. Вместе едим. Не так много работы делается за это время, если честно. Мы встречаемся, чтобы поддерживать связь друг с другом. Чтобы наше ба оставалось сильным. Я обычно могу сказать, как давно мы не виделись, по тому, как часто в нашей беседе в Slack возникают конфликты. Они начинают появляться примерно через десять недель после того, как мы встречались последний раз. Работает почти так же точно, как часы. Собираться вместе дорого – как с точки зрения возможностей, так и в плане финансов. Но эта инвестиция возвращается в виде более счастливой и сплоченной команды. Овчинка стоит выделки.

Задача лидера – убедиться, что эти отношения здоровые. Что сообщество сильно. Что есть плодородная почва для решения проблем, творчества и инноваций. Связи – противоядие от страха.

ВЫВОД

Признайте, что безумие – это безумие. Люди, вовлеченные в сумасшедшие ситуации, настолько привыкают к ним, что не могут распознать его. Именно поэтому от людей часто можно услышать: «Здесь просто все так работает», или «Это никогда не изменится», или «Я знаю, это кажется безумием, но…» Борьба с безумцами – игра с нулевой суммой. Если безумие выиграет, вы проиграли.

Правила должны сражаться за жизнь. Правила придуманы по причине, очень веской на момент их появления. Но времена, технологии, среда меняются. Если правило кажется глупым, оно может и правда быть глупым, – и вы должны определить, кто изменит его. Кто-то на это способен. Правило не закон природы.

Используйте «время шторма». У вас есть возможность работать размеренно и сосредоточенно все время. Люди боятся вносить необходимые изменения. Это рациональный страх. Но он поймает вас и вашу компанию в порочный круг отрицания и репрессий. Вы можете проснуться завтра утром и решить измениться в чем-то.

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

БЭКЛОГ

1. Подумайте о каждом из голосов в классификации страха Отто Шармера.

• Голос рассудка. Когда мы оцениваем новую информацию сквозь призму своего мировоззрения, актуальные факты или данные не могут изменить нашего мнения; на самом деле мы ищем подтверждения тому, во что уже верим.

• Голос цинизма. Толика цинизма иногда полезна, но если его слишком много, то он может убить компанию. Циники всегда против нового. Неважно, хороши изменения или плохи, – циник видит в них только плацебо, которое позволит другим чувствовать себя хорошо, но ухудшит его работу.

• Голос страха. Подумайте сейчас о своей работе, вашем самом важном проекте. Вот несколько вопросов. «Что, если я потерплю неудачу? Что мой руководитель подумает обо мне? А команда? Что подумает обо мне семья, когда меня уволят?»

2. Какой голос (или голоса) лучше всего описывают вас и ваш образ мыслей? Что вы можете сделать, чтобы исправить это?

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

4. Каковы ваши связи с людьми, с которыми вы работаете? Сделайте что-то, чтобы упрочить эти связи.

Riccardo’s – небольшое местное заведение в округе Челси в Лондоне. «Вкус Тосканы» – так гласит белая надпись на красном козырьке под вывеской. Меню наполнено классическими блюдами Тосканы: паппа аль помодоро, риболлита, паппарделле кон рагу ди серво и т. д. Риккардо Марити открыл ресторан в 1995 году. Его отец был из Тосканы, поэтому у Риккардо остались теплые воспоминания о столе, который накрывала его бабушка, когда он приходил к ней в гости, будучи ребенком. В ресторане 90 посадочных мест, а снаружи могут устроиться еще 40–50 человек, если позволяет погода. Когда вечер удачный, каждый стол занимают два, может, даже три раза.

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

Затем он открыл для себя Scrum, начав знакомство с ним с моей первой книги. Потом начал посещать обучающие сессии в Scrum Inc. одну за другой: сначала в Германии, затем в Швеции, потом в Бостоне. Дальше он вернулся к своему ресторану и все в нем изменил.

«В Scrum, – говорит он, – никто не указывает тебе, что делать. Тебе говорят, что должно быть сделано, а ты сам определяешь лучший способ выполнить задачу. И, знаете, мне это близко».

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

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

Риккардо понял, что структура – это культура. А она определяет границы. Жесткая структура создает жесткую культурную и продуктовую архитектуру. И в результате меняться становится намного сложнее. Это верно на уровне команды, но еще более верно и важно на уровне организации.

Ваша структура – не просто организационная диаграмма. Один из моих менторов, Даррел Ригби из Bain & Company, сказал мне однажды, что две компании могут иметь очень похожие организационные диаграммы, но очень, очень разные культуры и операционные модели.

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

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

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

Человеческий фактор

Есть правда, на которую мы не можем закрывать глаза, как бы сильно ни хотелось ее проигнорировать. Она настолько типична для нашей природы, что ее невозможно избежать, если вы собираете людей вместе ради общей цели. И вам нужно знать о ней. В первую очередь это закон Конвея, названный так в честь Мелвина Конвея, который в 1968 году выразил эту идею в своей работе «Как сообщества изобретают». «Организации, проектирующие системы (в нашем случае в широком смысле), – писал он, – ограничены дизайном, который копирует структуру коммуникации в этой организации»[24].

В 1968-м, кстати, также появились Hot Wheels, кресла-мешки и самозакрывающиеся пакеты со струнным замком. Как и все это, закон Конвея прошел проверку временем. Исследователи МТИ, Гарвардской школы бизнеса, Университета Мэриленда и даже Microsoft снова и снова подтверждали правдивость его идеи.

Вторая правда, о которой вам нужно знать, – следствие Шеллоуэя, впервые предложенное несколько лет назад Алом Шеллоуэем, CEO Net Objectives, который много писал на данную тему: «Когда группы разработки изменяют способы организации, архитектура приложения начинает работать против них».

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

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

Как и при создании продукта, вы не знаете заранее, какая структура вам подойдет. Таково невежество каскадных моделей управления проектами: неспособность признать, что вы не знаете. Отчасти суть гибкости – умение признаться в том, что вы не знаете всех ответов и не можете предсказать будущее; что верное решение появится по ходу работы, из обратной связи, в результате итеративного создания решений.

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

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

Стоял полдень, небо было затянуто облаками, и мы с ним гуляли среди бархатных зеленых деревьев по извилистым дорожкам парка Вондела, направляясь к одному из величайших музеев мира – Рейксмюзеуму. Его коллекция нидерландских живописцев – Рембрандта, Вермеера и других – поразительна. Если вы никогда не видели шедевр Рембрандта «Ночной дозор», изображающий, как стрелковый отряд гражданского ополчения Нидерландов выступает на стражу, вам явно стоит посетить этот музей. Когда вы подниметесь по лестнице в зал, где висит картина, сначала вы отметите масштабность полотна, доминирующего в интерьере. Размеры изображения огромны, 363 на 437 см. Композиция и свет создают иллюзию движения; кажется, будто нарисованные люди сейчас промаршируют с картины в зал под ритм ударов сопровождающего их барабанщика.

Когда мы рассматривали картину, Якоб рассказал мне очень интересную историю о музее. Более сотни лет коллекция полностью повторяла его организацию. Каждый раздел – живопись, скульптура, керамика – казался крайне разобщенным. Не было системы ни в подаче, ни в расположении выставок. Если вы интересовались живописью, нужно было начать с 1200-х, затем двигаться вперед во времени, очевидно, задержавшись в XVII веке, Золотом веке голландской живописи, и год за годом, десятилетие за десятилетием, пройти к современности. В следующем зале, например скульптур, вы снова начинали со Средневековья и двигались вперед во времени. Затем тот же цикл в зале керамики. Выставки в залах музея полностью повторяли его организационную диаграмму.

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

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

Открытие Рейксмюзеума прошло громко, и реконструкция обернулась ошеломительным успехом. Газета The Guardian написала тогда: «Долгожданные результаты реконструкции оказались настолько впечатляющи, что музей, кажется, стал другим институтам примером на долгие годы». Но работа истощила сотрудников. Диббитс сказал, что тогда пришло время задать себе вопросы: «Что же нам делать дальше? Как оставаться актуальными?» Они создали новые гибкие кросс-функциональные команды, включавшие всех, от кураторов до охраны, чтобы подумать над тем, как люди воспринимают музей и отдельные выставки. Структура определяла теперь то, на что они были способны. Они не использовали Scrum полностью – в силу унаследованных структур, – но для их важных проблем, глобальной цели сохранить актуальность в постоянно меняющемся мире структура должна была быть сломана, поскольку она ограничивала их возможности.

Когда я рассказал эту историю Даррелу Ригби, он тут же спросил меня: «Как они поняли, что организация по эпохам лучше, чем по категориям?» Он указал на очень интересный вопрос, касающийся того, как создать опыт, который покажется посетителям наиболее ценным и значимым. Он постоянно затрагивает этот вопрос, когда работает с крупными торговыми центрами. Большая часть таких магазинов, как вы знаете, организована по брендам – здесь тренажерный зал Under Armor, а рядом теплый деревянный уголок Body Shop, который совсем на него не похож. Но всегда найдутся «люди, которые утверждают, что это неправильный способ организации торгового центра», что все нужно организовать по категориям. «Они постоянно пререкаются».

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

Компания Adobe более десяти лет назад перешла на использование Scrum, после чего команды решили, что им нужно больше обратной связи от потребителей. До Scrum единственным способом получить отклик для них были сообщения об ошибках. В результате они не делали то, чего хотели потребители. И они решили изменить это. Команда Flash Pro приглашала суперпользователей на каждый обзор спринта. Другие команды создавали частные серверы и давали к ним доступ наиболее увлеченным пользователям. Они становились всё ближе к потребителям. Теперь, как мне сказали, они уже не создают функций, которыми никто не пользуется, хотя раньше такое бывало. Причем часто.

Управление превращается в лидерство

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

В ресторане Riccardo’s сотрудники избавились от всех управленческих ролей. Измениться должно было поведение не только персонала, но и самого Риккардо. Отныне он не имел права мешать процессу. А это нелегко.

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

«Вот что мы сделали, – сказал он однажды, стоя перед scrum-доской в своем ресторане. – Мы сказали каждому члену команды, что ему нужно принимать решения самому».

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

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

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

Первое, что нужно лидеру, – быть лидером

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

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

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

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

Неудачное свойство человеческой психики

Мы все лжецы. Все врут. Но не все делают это постоянно. Есть одно поразительное исследование, которое показывает, что большинство взрослых лгут не так много. Чаще всего говорят, что среднестатистический человек обманывает один-два раза в день. Но стоит учесть, что это средний показатель. Распределение лжи весьма интересно: около половины ее производят 5 % человек. 60 % не сообщают о том, что лгали за последние 24 часа.

Но это среднестатистический день. В каких-то ситуациях почти все мы врем. На собеседованиях, согласно исследованиям, к обману прибегают 90 % человек. Не всегда это наглая ложь, скорее умалчивание о некоторых деталях – сознательное лукавство. Подростки – сплошная ложь. 82 % сообщают, что врали своим родителям по меньшей мере на одну из следующих тем: деньги, алкоголь, наркотики, друзья, свидания, вечеринки и секс. Неверность? Вот дела, изменники лгут – и на этом всё. 92 % людей при анонимном опросе отвечали, что лгали нынешнему или прошлому сексуальному партнеру. И я могу предположить, что остальные 8 % врали о том, что не лгали.

Есть кое-что интересное о лжи: она меняет нас сама по себе. Химия нашего головного мозга корректируется с каждым обманом. Несколько исследователей из Университета Дьюка и Университетского колледжа Лондона решили исследовать, что происходит в нашем мозге, когда мы лжем. Они поместили людей в аппарат МРТ и попросили их играть в игру, где им нужно лгать партнеру. Как только они говорили неправду, наш старый друг – миндалевидное тело высказывал свое мнение. Оно выделяло химические соединения, которые дарили нам уже знакомое чувство страха и давящее ощущение вины, которое посещает всех нас, когда мы лжем.

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

Исследователи подвели итоги в работе под названием «Мозг адаптируется к обману» и заключили следующее.

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

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

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

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

Ценности Scrum

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

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

Каждый человек в scrum-команде должен брать на себя обязательства перед другими, перед изменениями, которые команда хочет провести, работой, которую она обязалась завершать каждый спринт, перед производством ценности. Обязательство – не просто слова «Мы постараемся сделать это, постараемся выполнить работу, постараемся следовать Scrum». Это утверждение: «Мы сделаем всё, что в наших силах, чтобы добиться этого».

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

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

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

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

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

«Сейчас члены команды должны отодвигать на второй план все, что они делают, когда в ресторане много людей», – говорит Риккардо. Джо работает в отделе маркетинга, но если перед рестораном появляется очередь и что-то подсказывает, что сейчас будет много людей, то он бросает все и бежит в зал собирать тарелки и убирать столы. Такое случается не каждый день. Но если это происходит, официанты, повара и помощники официантов знают, что вся команда с ними. Это их обязательство.

Я хотел бы, чтобы так было всегда. Но для этого нужна сфокусированность.

После того как команда берет на себя обязательства выполнить работу, которую она выбрала для спринта, ей нужно сфокусироваться на задаче. Люди и события постоянно пытаются ослабить наш фокус. Руководитель требует что-то сделать; друг из отдела продаж просит оказать ему небольшую услугу. И все это якобы легко. «Ой, это займет немного времени. Я просто сделаю вот это, хотя этого нет в нашем бэклоге спринта».

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

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

Это напоминает мне одного писателя. Он очень хорош и плодотворен. Каждый будний день он просыпается, приезжает в свой офис, закрывает дверь и ровно в 8:00 начинает работу. Он сфокусирован на протяжении четырех часов. Затем он останавливается. «Иногда приходит муза, – говорит он. – А иногда нет. Но если бы я не сидел там и не был сосредоточен на работе, которую пытаюсь выполнить, то я не дал бы ей и возможности прийти».

Одна из основ Scrum – прозрачность. Собрания открыты для всех. Бэклоги наглядны и помогают понять, куда вы направляетесь и когда окажетесь у цели. Каждый знает обо всем, что происходит. И каждого нужно услышать. Только тогда вы на самом деле поймете, когда все будет готово.

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

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

В современном мире значительная часть нашей работы невидима. Это идеи, код, дизайны, мышление, направленное на решение проблем. Вам нужно вывести всё на свет. Какая работа выполняется? Кто ее делает?

В Riccardo’s это сразу повлияло на результаты. Если вы никогда не работали и не управляли рестораном, то можете этого не знать, но худшая задача там – составление расписания. Это занимает часы. Кто может работать в эту смену? Звонки, чтобы узнать, кто доступен в нужный час, посыпание головы пеплом, когда получилось заполнить все позиции, кроме бара, вынужденный поиск нового бармена. Это сводит с ума. Я этим занимался.

Riccardo’s открыты семь дней в неделю. Они подают обеды и ужины. Как вы понимаете, составление расписания – один из подвигов Геракла. Риккардо решил это так: повесил на стену большую таблицу, в которой были перечислены все смены и нужный персонал. Затем он попросил каждого члена команды взять то количество стикеров, которое отражало бы количество их рабочих смен, и развесить их. В первый раз составление расписания на месяц таким способом заняло около часа.

«Когда мы закончили, оказалось, что у нас еще много стикеров, – уточняет Риккардо, стоя у доски с расписанием. – Тогда мы поняли, что менеджеры ставили сотрудникам смены, которые не были нужны компании, и никто не знал об этом». Они давали людям дополнительные смены, чтобы их порадовать, вместо того чтобы сделать то, в чем компания нуждалась на самом деле. Такая политика сокращала прибыль на 10–20 %. На самом деле в ресторанах небольшая добавочная стоимость.

Когда Риккардо сообщил это командам, он не был зол. Он не говорил, что делать. Он просто сделал график прозрачным и сказал, что им придется решить вопрос самостоятельно.

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

«Они сразу поняли это, – сказал Риккардо, отвел взгляд и замолчал. Затем задумчиво продолжил: – Они были способны к саморегуляции и самоконтролю в вопросе планирования смен, и все работало. Более того, они стали намного счастливее как команда».

Тайити Оно, создатель производственной системы Toyota, сказал: «Худшая проблема из всех – не иметь проблем». Неурядицы есть всегда. Мы окружены ими. Если вы не знаете о своих проблемах, то не можете исправить их.

Такой взгляд противоречит культуре многих организаций. Обычно людей наказывают за наличие проблем, не пытаясь выяснить причину их появления. Естественно, люди скрывают неприятности, не признают их существование. В Scrum нужно говорить открыто о проблемах, радоваться, когда они проявляются. И иногда они крайне серьезны! Но это прекрасно, потому что именно они становятся главным подарком. Хизер Тимм, одна из владельцев продукта в Scrum Inc., часто говорит своей команде: «Иногда нужно нырнуть к обломкам, чтобы найти сокровище. Проблема всегда существовала; просто была невидима. Порой это нелегко, но под затонувшим кораблем лежат богатства».

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

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

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

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

Во многих компаниях – да и в стольких отношениях – нет уважения. Это следствие культуры обвинения: «Ты это сделал. Ты в этом потерпел неудачу». Именно поэтому каждый всегда пытается прикрыться, избежать наказания, солгать.

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

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

Он спросил сотрудников, обеспечили ли они новому члену команды достойную обратную связь. Пытались ли поговорить и помочь ему, а не вести себя так, будто он ничего не значил? Риккардо говорит: раньше он бы опустил руки и сказал, что ничего не может с этим поделать. Но Scrum позволяет вам определить, как исправить ситуацию. Теперь я говорю: “Решение проблемы – элемент бэклога номер один. Решайте ее!”»

Риккардо сказал команде, что она не может совершить ошибку. «Если вы принимаете решение и внедряете его, то скажите, что вы сделали, и мы обсудим, как все прошло. И на данный момент не было ни одной серьезной ошибки. Посетители стали намного счастливее. Они заметили, что команды стали счастливее, даже в ситуациях стресса, под давлением».

Дайте людям свободу знать, что их не будут обвинять, что вы уважаете их, их идеи и решения.

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

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

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

Цените ценности

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

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

Минимально жизнеспособная бюрократия

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

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

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

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

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

Приведу пример моего партнера Фабиана Шварца. Он работает по всей Латинской Америке. Одна из компаний, с которой он сотрудничал, была подразделением Drummond Company в Колумбии. Они хотели ускорить бурение месторождений газа. Проблема была не в бурении, а в неадекватной коммуникации и сотрудничестве. Информация и документы не передавались, а решения не принимались в нужный момент. Они теряли уйму времени.

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

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

Команда руководства собиралась каждый день на пятнадцать минут. Они проводили все мероприятия Scrum: планирование, обзор, ретроспективу, видеопереговоры с командами на месторождении. И они заметили кое-что весьма интересное: проблемы, на решение которых раньше уходили недели, теперь разруливались за несколько часов. Вся группа стремилась обеспечить работу скважины; а ведь раньше каждый фокусировался на своей части работы. Мотивация возросла. Повысилась прозрачность, поскольку люди говорили друг с другом и боролись с проблемами вместе.

Раньше среднее время бурения составляло девятнадцать дней; рекордным результатом было десять дней. После перехода на Scrum процесс стал занимать шесть дней. Средние показатели времени стали в три раза выше. Они не меняли технологии или сотрудников. Они изменили только способы работы.

«Scrum – успешное нововведение в нашей организации, – сказал Альберто Гарсия, вице-президент направления добычи углеводородов Drummond в Колумбии, – и мы внедрим его в других нефтегазовых операционных командах: бурения, интенсификации потока, вскрытия нефтяного пласта, строительства производственных объектов».

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

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

Приведу небольшой пример. В главе 1 я упоминал, как Saab Aerospace создавала с нуля боевые истребители – модель Gripen E. А вот как в компании проходит масштабированный ежедневный Scrum. Каждый день в 7:30 команды собираются на Scrum. В 7:45 scrum-мастера из этих команд отправляются на масштабированный Scrum со всеми препятствиями и зависимостями, которые нельзя устранить на уровне команды. В 8:00 представители каждой группы отправляются на масштабированный ежедневный Scrum следующего уровня с проблемами, которые они не смогли разрулить. В 8:15 проходит еще один масштабированный ежедневный Scrum. В 8:30 команда руководителей всего проекта получает перечень проблем, которые только они могут решить. На это им отводится 24 часа. Они координируют действия около 2000 человек менее чем за час. И лидеры рассматривают это как необходимый контроль уровня издержек. Они считают, что их работа – сделать готовый самолет настолько быстро, насколько возможно, а все, что замедляет команды, выбивает их из потока, – это издержки.

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

Инновации рабочего процесса

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

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

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

Это занимает около часа. И показатель не меняется десятилетиями. От «выкатить» до «закатить», с момента, когда пациента вывозят из операционной, и до момента, когда привозят другого. Около часа.

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

Кевин Бол из Scrum Inc. – бывший морпех, страстный поклонник джаза и человек, который рвет процесс на части, чтобы добиться результатов. Для него этот час был вызовом.

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

Первый день Кевин наблюдал за процессом. «Сначала мы работали с командой, которая занималась подготовкой помещения», – вспоминает Кевин. Затем, на второй день, он задал команде вопрос: «Как, по-вашему, вы можете улучшить процесс?»

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

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

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

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

За счет нежелания верить, что улучшение невозможно.

И все это заняло две недели.

Кому многое дано, с того много и спросится

Как лидер, вы должны не только поддерживать ваши команды, устранять препятствия и подкреплять их уровень счастья, но и призвать их к ответственности. В стандартной ежегодной оценке работоспособности, учитывающей 50 измерений со шкалой от 1 до 5, только 10 % сотрудников выдают лучшие показатели, поскольку те находятся в рамках нормального распределения. Вы знаете, как это выглядит. Этот график разве что демотивирует. Как же мы действуем в Scrum? Ким Антело из Scrum Inc. проводила ежегодную оценку работоспособности совместно с крупной компанией по оказанию услуг нефтяной отрасли, и с тех пор мы используем ее способ. Нужно лишь задать несколько вопросов, а данные легко найти.

• Действительно ли они работают по Scrum – используют три роли, пять событий, три артефакта и пять ценностей?

• Существуют ли рабочие соглашения команды? Она документирует свои нормы и поведение?

• Измеряется ли скорость команды? Повышается ли она по меньшей мере на 10 % каждый квартал?

• Измеряется ли уровень счастья команды как ведущий индикатор?

• Улучшают ли они Scrum в компании за пределами своей команды?

• Обучаются ли они постоянно?

• Доставляет ли команда больше ценности при прежней скорости? Иными словами, получается ли заработать больше денег при том же объеме работы за счет того, что она выполняется правильно и потребитель получает желаемое в нужное время?

• Соответствует ли их продукт ключевым критериям успеха?

• Достаточно ли быстро она уничтожает продукты, которые недостаточно отвечают критериям успеха? (Последняя часть вопроса особенно важна. Многие проекты бродят подобно зомби, годами пожирая людей и деньги, поскольку никто не хочет признавать, что это была плохая идея.)

• Создают ли они правильные вещи? Повышается ли качество?

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

• Обучают ли они других членов команды своей специальности?

• Обеспечивают ли они ясное видение?

• Способствуют ли они росту и развитию людей?

• Люди, которые отчитываются перед ними, счастливы и рады приходить на работу?

• Их команды организованы лучшим возможным для доставки ценности способом?

• Есть ли у их команд все необходимые навыки и инструменты?

• Они призывают к ответственности владельцев продуктов и scrum-мастеров?

Scrum дает людям свободу действий. Они решают, как будут работать и сколько. От них ожидают, что они будут организовываться самостоятельно. Это великолепно. Но главное – доставка. Влияют ли они на нее?

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

Давайте их обсудим.

Сопротивление повстанцев

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

Лидеров высшего звена также обычно легко убедить. «Вдвое больше работы за половину времени? Я в деле. Люди счастливее, на рынок выходим быстрее, защищены от краха? Запишите меня».

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

Например, они иногда ощущают угрозу: «Scrum может раскрыть проблемы, которые существуют давно. Не исключено, что их причина – во мне. Я не уверен во всей этой идее прозрачности».

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

И они погубят вас пассивно-агрессивным неподчинением. Прилюдно они будут поддерживать изменения, но втайне – распространять яд. Это может произойти даже на высоких уровнях. Люди не способны быть лидерами, если не верят в изменения. А если они не верят в изменения, они будут ждать: «О, скоро они перестанут обращать на меня внимания. Это должно закончиться. Я опущу голову и притворюсь, что меняюсь. Я выживу».

Ни секунды не терпите это. Вам нужно окружить себя людьми, которые искренне хотят внести серьезные изменения в свои способы работы. Когда клиенты спрашивают меня о людях, которые сопротивляются и не хотят меняться, я говорю им, что есть правила приема на работу. Некоторые из них обязательны. И стоит ли дискомфорт одного человека того, чтобы поставить под угрозу всю компанию? Решать вам.

Меняйте культуру, меняйте свои границы

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

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

Помните: структура появится. Не ждите, что вы получите все, что может дать Scrum, просто изменив названия должностей. Думать, что вы знаете ответы заранее, – фундаментальная ошибка. Вы не знаете. Подходящая организационная архитектура появится, как только вы начнете стремиться быстрее доставить больше ценности покупателям. Вот что важно. Как и в случаях с Adobe, Рейксмузеумом, Apple, Google и Amazon, вам нужно оказаться достаточно близко к потребителям, чтобы увидеть, как вам стоит организовать себя, чтобы доставлять лучшие впечатления или продукты.

Риккардо сейчас начал заниматься двумя новыми проектами – ресторанами, которые управляются только с помощью Scrum. «Все будет организовано по Scrum. Дизайн. Найм. Всё», – говорит он. Он воодушевленно рассказывает о стабильных командах и для зала, и для кухни. Еженедельные спринты. Шеф-повар станет владельцем продукта. Scrum-мастер – первым человеком, который ищет препятствия. Работают ли телефоны и компьютеры? Пришли ли поставки? Что может замедлить команду сегодня?

Без Scrum, по словам Риккардо, он ушел бы из бизнеса. Теперь он видит, как масштабировать свое дело. Два ресторана. Три. Больше. Мир снова открыт.

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

ВЫВОД

Структура – это культура. Ваша культура определяет ваши границы. Жесткие структуры порождают неповоротливую культурную и продуктовую архитектуру. Это серьезно затрудняет изменения. Утверждение верно на уровне команды, но еще вернее и важнее – на уровне организации.

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

Цените открытость и прозрачность. В современном мире значительная часть нашей работы невидима. Это идеи, код, дизайны, мышление, направленное на решение проблем. Вам нужно вывести невидимое на свет. Какая работа выполняется? Кто ее делает? Открытость и прозрачность – ключ к преодолению неопределенности. Когда мы делаем работу наглядной, понимаем, на какой стадии выполнения она находится, мы можем начать планировать, основываясь на данных, а не на мнениях.

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

БЭКЛОГ

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

2. Вы менеджер или лидер? Хорошо подумайте. Вы указываете или даете возможность действовать? Принуждаете или делитесь видением? Принимаете решения или улучшаете их?

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

4. Используйте ценности Scrum в своей работе каждый день. Поощряйте других использовать их. Как они влияют на процесс?

Иногда в решении проблемы самое сложное – борьба со словами, которые вы используете для ее описания, уж не говоря о решении. Кристофер Александер – очень влиятельный архитектор, который боролся с той же проблемой, пытаясь говорить о том, почему то или иное решение работает в здании или пространстве. Иногда места просто кажутся правильными. Это может быть комната. А здесь – перекресток. А тут рабочее место. Он хотел, чтобы язык описывал вещи, которые мы используем в дизайне для создания того, что он называет «качеством без имени». Когда некое пространство становится платоническим эталоном мест своего типа.

Его теории дизайна изменили то, как строятся сообщества, здания и системы. В начале 1970-х Александер попытался определить общие решения общих проблем, которые будут стабильно работать во множестве контекстов. Он хотел, чтобы люди могли говорить о них ясно и коротко. В 1977 году он опубликовал книгу «Язык шаблонов»[26], где описывались сотни шаблонов, достаточных для того, чтобы сформировать язык.

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

Приведу пример из книги Александера.

Шаблон 150: места для ожидания

Процесс ожидания таит в себе внутренние конфликты

Затем он жалуется на состояние ожидания. Неважно, чего мы ждем: автобуса, приема у врача или поезда. Мы тратим много времени впустую, и это отстой. Мы не можем полностью отвлечься, потому что не знаем наверняка, когда произойдет то, чего мы ждем. Мы не можем уйти и вернуться позже. Мы застряли в определенном месте. А типовые залы ожидания обычно скучны. А что, если бы мы могли изменить это и превратить ожидание в положительный опыт, замечательный промежуток свободного времени? Что, если окружение тому способствует, человек может погрузиться в себя и посидеть в тихой задумчивости?

Шаблон таков.

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

Шаблон мест для ожидания связан с другими шаблонами, например оконными нишами, уличным кафе и организацией офисного пространства. Каждый шаблон связан с другими, создавая синтаксис решений. Мой отец Джефф Сазерленд сформулировал это следующим образом.

Язык шаблонов – это попытка выразить глубокую мудрость в виде набора взаимосвязанных выражений, порожденных контекстуальным знанием. Он выходит за пределы перечня процессов и включает деятельность или качества, повторяющиеся во множестве процессов, в попытке определить то, что работает. Это взаимосвязанное целое, которое при последовательном использовании формирует «качество, у которого нет имени». Сочетание множества шаблонов создает целое, превосходящее сумму отдельных элементов[27].

Команды, которые заканчивают рано, разгоняются быстрее

Несколько лет назад ребята из компании OpenView Venture Partners пришли в Scrum Inc. с головоломкой. Они думали, что Scrum построен вокруг скорости: насколько быстро работает команда? Могут ли они сделать больше за спринт? Именно поэтому они нагружали свои команды бэклогом, достаточным для того, чтобы его можно было закончить в спринт, но он оказывался забит полностью, до последнего дня. Затем они заметили кое-что. Команды, которые придерживались постоянной скорости, выполняли одинаковое количество работы, но не получали четырехкратного повышения продуктивности, ради которого изначально был разработан Scrum. Другие, которые раньше завершали свои спринты, становились всё быстрее. В итоге они поняли, что Scrum затрагивает не скорость, а ускорение.

Шаблон таков.

Команды, которые заканчивают рано, разгоняются быстрее.

Команды часто берут слишком много работы на спринт и не успевают ее закончить.

Неудача в достижении цели спринта мешает улучшению команды[28].

Работая с группой экспертов над проектом языка шаблонов Scrum (Scrum Pattern Language Project), мы создали язык шаблонов для гиперпродуктивных команд. Они использовались во многих компаниях и областях множество раз. Эти практики лежат в основе добротного следования фреймворку Scrum.

Можно получить данные без информации, но не информацию без данных

Это высказывание, которое снова и снова, как мантру, цитируют специалисты по обработке и анализу данных, принадлежит специалисту по теории вычислительных машин и систем, писателю и гуру больших данных Дэниелу Кису Морану. И в нем описана проблема, которую Системы медицинской информации компании 3M (3M Health Information Systems, 3M HIS) пытаются решить для больниц, страховых компаний и планов медицинского обслуживания. Вот пример: согласно Закону о доступном медицинском обслуживании США, федеральное правительство может оштрафовать больницу, если у нее, например, высокие показатели повторных госпитализаций или внутрибольничного инфицирования. Это происходит в рамках перехода от сдельной системы оплаты лечения, при которой больница получает деньги за количество проведенных процедур и тестов (модель оплаты за фактически оказанные услуги), к ценностной, при которой платежи основаны на результатах пациентов (деятельности, а не работе). В 2017 году 751 больница недополучила средства по федеральной программе медицинской помощи престарелым США, поскольку все они не соответствовали новым стандартам.

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

Было бы хорошо, если бы существовал способ узнать, какие пациенты с высокой долей вероятности будут госпитализированы снова. Ведь очень небольшое число пациентов создает большую часть статистики по повторной госпитализации. Ключевой вопрос, конечно, в том, как узнать, что человек попадает в эту группу риска. Зайдите в Системы медицинской информации компании 3M (3M HIS). Они обрабатывают массив больших данных. Они смотрят на базу – от заметок докторов до отчетов лабораторий и демографических данных – на все типы данных и помогают больницам принимать проактивные, а не реактивные меры для обеспечения пациентов поддержкой, которая им необходима. Люди становятся здоровее, немногие попадают на станции скорой помощи, затраты снижаются, каждый получает лучшие результаты. Здорово, правда?

В сентябре 2014 года мы с отцом опубликовали нашу первую книгу «Scrum. Революционный метод управления проектами». Той осенью она оказалась на столах у многих людей. В том числе попала к Дэвиду Фрази и Тэмми Сперроу из 3M HIS. Дэвид был техническим директором подразделения, а Тэмми – его правой рукой. Они показали книгу всей команде руководителей. И затем позвонили нам.

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

Пострадал из-за нападения утки

Код W61.62XD определяет несчастный случай с участием утки и последующим обращением к врачу. О таком не любят говорить. Но этот код по-настоящему важен. Он часть Международной классификации болезней десятой версии, МКБ-10. Точнее, часть Международной статистической классификации болезней и проблем, связанных со здоровьем. Будем использовать термин МКБ. Существуют тысячи таких кодов, около 141 000. Всемирная организация здравоохранения использует их для того, чтобы классифицировать все, что может произойти с человеческим телом, например V97.33XD: травмы, сопряженные с попаданием в реактивный двигатель. Или Y93.D: травмы вследствие деятельности, включающей искусства и ремесла. Или трагически распространенный код V91.07XD: ожоги вследствие возгорания водных лыж.

В 2015 году система здравоохранения США решила перейти от МКБ-9 к МКБ-10. В МКБ-9 содержалось около 14 000 кодов, намного меньше, чем в МКБ-10. Эти коды невероятно важны для системы здравоохранения, поскольку помогают понять, что на самом деле происходит с людьми. Также именно благодаря им страховые компании определяют, за что они будут платить и сколько. Возможно, страховое покрытие не распространится на код Y92.146: смерть в тюремном бассейне по внешним причинам. Да, именно так: отдельный код для травм, которые человек получил в бассейне в тюрьме. Также есть отдельные коды для тюремной столовой, ванной и кухни.

В то же время у 3M HIS около 5000 клиентов, которые пользуются системой, чтобы точно определить все эти коды и больница могла получить компенсацию расходов от страховой компании или государства. Перейти на МКБ-10 нужно было к 1 октября 2015 года. И это не казалось привлекательной перспективой.

Мы начали работать с лидерами подразделения тем летом. И тогда Тэмми получила новую должность: директор agile-путешествия. Теперь она также отвечает за качество и коммерческую реализацию. Для начала мы сказали 3M HIS, что они не умеют определять приоритеты. Сотрудники были заняты слишком многими задачами одновременно, хотя было очевидно, что МКБ-10 – приоритет номер один. Работая с Тэмми и Дэвидом, мы запустили пять команд, чтобы успеть вовремя. Ситуация накалялась: сроки нельзя было изменять и стоял вопрос, будет работать их флагманский продукт или нет.

Код W55.29XA: прочие контакты с коровой и последующим обращением к врачу. Также есть отдельные коды для коровьих укусов и ударов. О таких инцидентах тоже обычно не говорят. Как и в случае с уткой.

Наступило 1 октября, но их пламя не угасло. За год, используя шаблон «Команды, которые заканчивают рано, разгоняются быстрее», они повысили cкорость на 160 %. Теперь сотни их сотрудников организованы в scrum-команды. Тэмми считает, что этот шаблон заставляет команды отслеживать то, что они делают, устранять препятствия и фокусироваться. «Если вы сфокусированы, вы можете закончить быстрее. Ваша цель – не перегрузить команды, а дать им возможность выполнять работу».

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

Стабильные команды

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

По причине этого сохраняйте стабильность состава и старайтесь не перемещать людей между командами. Стабильные команды верно оценивают свои возможности, что позволяет внести определенную предсказуемость в работу. При любой возможности выделяйте людей только в одну команду, а не в несколько[29].

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

Я вспоминаю группу людей, которые запустили и продюсировали ток-шоу на радио WBUR в Бостоне. Оно называлось The Connection («Связь»). Все мы сидели в офисе, который явно не соответствовал нормам пожарной безопасности. Мы говорили по телефону, печатали сценарии, придумывали новые креативные идеи, выпускали по два шоу каждый день, без перерывов и повторения тем. Боже, это было невероятно. О нас говорил весь город. Мы могли зайти в бар в центре, а люди там обсуждали, что в тот день было в нашей передаче. Это опьяняло. Нередко мы дрались. Но чаще смеялись. Я придумал особые послания, которые вписывал в сценарии и которые могла понять только моя девушка (теперь жена). Бывало, что гость не мог прийти на передачу, а мы узнавали об этом за пятнадцать минут до эфира. Тогда мы немедленно бросались в бой, за считаные минуты изобретая что-то другое. Мы знали таланты и взгляды друг друга настолько хорошо, что, если бы кто-то бросил мяч, другой вслепую бы его поймал. Я никогда не забуду этого.

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

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

Второй шаг Такман назвал негодованием (storming) и описал так.

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

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

Третий шаг – нормализация (norming), когда споры разрешены. Границы установлены, и группы начинают выстраивать внутреннюю связность. Люди уже воспринимают себя как часть команды. Они могут адаптироваться к новым ролям, поскольку команда определяет лучшие способы совместной работы. Это соглашение о действиях.

Четвертый шаг Такман называет исполнением (performing), поскольку здесь структура команды становится инструментом, с помощью которого она справляется с заданием. Мне это нравится. Социальная динамика группы превращается в энергию, которую команда использует для выполнения замечательной работы. Уже не так важно, кто чем занимается. Важнее то, что команда выполняет задачу как единое целое.

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

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

Другая теория постулирует, что причины, по которым группы, длительное время работавшие совместно, успешны, находятся в рамках концепции трансактивной памяти. Ее впервые изучали на материале романтически увлеченных друг другом пар (в источнике используется термин «двухэлементные отношения», и так я назову свою новую группу): то, как общий опыт создает воспоминания, для восстановления которых необходимы оба партнера. Классические примеры – когда один партнер спрашивает другого: «Где было то место, где была та утка?» (W61.62XD: повреждения, нанесенные уткой. Помните: мы не любим говорить об этом.) И партнер отвечает: «А, ты имеешь в виду тот раз, когда там были Джим и Салли, а ты немного перебрал?» – «Да, именно тот раз!» – «Тогда это было в Бруклине».

Частицы общих воспоминаний хранятся в памяти у разных членов группы. Чтобы восстановить их, членам группы нужно полагаться друг на друга. Скорее всего, они этого не осознают, но общий опыт создал общую память, которая порождает новые явления, существующие исключительно в отношениях между людьми, то, что профессор Икудзиро Нонака называет «ба». Заметьте: ученые говорят, что такой процесс невозможен, если в группе слишком много людей, поскольку размер сети общей памяти ограничен. Ее предел – около семи человек. Хм-м-м. Тот же размер, что и у scrum-команды. Интересно.

Данное исследование включено в метаанализ материалов по теме, и вот что написано в заключении к нему.

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

Близкое знакомство, общий опыт и личное взаимодействие: то, вокруг чего построен фреймворк Scrum. Все это нужно создавать осознанно, а не ждать счастливой случайности. Стабильные, расположенные в общем пространстве кросс-функциональные команды, – вот в чем секрет. Это несложно.

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

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

Эти данные учитывают показатели более чем 75 000 команд. Источник данных – Rally[31], один из крупных онлайн-инструментов Scrum. Они проанализировали данные, которых набралось немало, и обнаружили: если в команде есть участники, которые трудятся только на нее, то она почти в два раза продуктивнее, чем те, что состоят из людей, которые одновременно работают более чем в одной команде.

Это очевидно, но многие совершают одну и ту же ошибку: «Ой, только Люсинда знает это, так что она будет работать в пяти командах». Это убивает несчастную Люсинду, которая переживает изменения контекста ежедневно. Ей нужно не только выполнять различную работу, но и сотрудничать с разными людьми. Честно говоря, это не только неэффективно, но и негуманно. Это мешает Люсинде получать преимущества работы в команде, нарушает ее ба и препятствует появлению общей памяти.

Прежде чем 3M HIS перешла на использование Scrum, у нее были стабильные команды, но без выделения их членов. «Большинству сотрудников приходилось работать над 5–6 проектами или в 5–6 командах, – говорит Дэвид, директор корпоративных исследований систем в 3M. – Мы настояли на том, чтобы по меньшей мере 80 % сотрудников были выделены на отдельные проекты. Как и ожидалось, это сразу внесло ясность. Проект МКБ-10 оказался возможностью, которую нельзя упустить. Мы изменили всё за несколько недель». Несколько месяцев спустя у них было уже более двадцати команд. Успех говорил сам за себя.

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

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

Вчерашняя погода

[32]

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

По этой причине в большинстве случаев количество очков оценки за последний спринт – надежный индикатор того, какой будет производительность команды в следующем спринте[33].

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

Конечно, иногда могут. Но иногда нет. И гораздо лучше закончить раньше, выполнить больше работы и иметь возможность ускориться. Не закончить то, что было запланировано, – значит уничтожить боевой дух. Вы будете заниматься самобичеванием, даже если знали, что изначально преувеличили свои возможности.

Часто руководство настаивает на том, чтобы ставить более высокие цели, подталкивая команду или компанию. Проблема такова: если вы говорите, что цель – это Х, то люди сделают что угодно, чтобы добиться Х. Начнут срезать углы или даже сознательно ошибаться, чтобы казалось, что Х достигнута. Помните, что я писал о лжи? Мы советуем учесть скорость за последние три спринта, а не за один. Это неудобная метрика со множеством переменных, поэтому ее стоит усреднить.

И помните, что вы не сможете закончить раньше, если возьмете на себя обязательство сделать всё. Умение сказать «нет» входит в Scrum.

Не команды в 3M HIS брали в работу слишком много элементов, а менеджмент. «До того как мы перешли на Scrum, – говорит Дэвид, – люди брали на себя слишком много обязательств. Классический случай – когда бизнес хочет обеспечить что-то к определенной дате, а технические команды не могут выполнить всю необходимую работу в такие сроки». Когда появились данные об их скорости, они смогли давать отпор и говорить: «Вот на что мы способны». Также это помогло лидерам лучше представлять, когда что-либо будет сделано.

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

Рой

[34]

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

По причине этого предельно сфокусируйте усилия команды на одном элементе в бэклоге продукта, чтобы довести его до готовности максимально быстро[35].

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

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

Снова вспомним основателя производственной системы Toyota Тайити Оно. Он придумал классификацию потерь – вещей, которые замедляют систему. Он разделил их на три группы: муда, мура и мури. «Муда» переводится с японского как «отсутствие результатов» – незаконченная работа. «Мура» – «непостоянство, неравенство»; изначально это термин из ткацкого производства, который относится к зацепкам на ткани. «Мури» – «отсутствие причины». В эти три группы входит все, что мешает выполнению работы, например перепроизводство, ожидание, логистика, абсурдные ожидания и т. д.

Худшим типом потерь для Оно, в любом контексте, было незаконченное производство. Часто его называют незавершенной работой (Work-in-progress, WIP). Это худшая форма потерь, поскольку вы тратите время, деньги и усилия, но ничего не получаете взамен. Работа не доводится до готовности.

Решение проблемы – переход к тому, что Оно называет «производством по принципу непрерывного потока», а я – «сделать дело, и быстро». У любой scrum-команды в бэклоге есть 10–20 элементов, которые они обязались выполнить за спринт. И почти в каждой компании, куда я приходил, все эти элементы начинали выполнять, но ни одного не доводили до готовности.

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

Представьте себе экипаж механиков «Формулы-1». Если вы ни разу не видели, как они работают, изучите видео в интернете. Впечатляет. Гоночный автомобиль въезжает на заправочно-ремонтный пункт и полностью останавливается. Когда гоночный болид тормозит, он тут же отстает от гонки, поэтому команде нужно починить и выкатить машину обратно на трассу настолько быстро, насколько возможно. Как только машина с визгом останавливается, двадцать человек немедленно принимаются за работу. Чтобы поменять колесо, нужна слаженная работа трех человек: один с помощью пневматического пистолета снимает болты, удерживающие покрышку, второй снимает колесо, третий надевает новое. Важна каждая десятая доля секунды. А это только колеса; другие люди регулируют автомобиль, заправляют его, производят все манипуляции, необходимые для того, чтобы уже через несколько секунд вытолкнуть машину обратно на трассу.

В этом суть методики роя – полная концентрация команды на доставке ценности, возвращении машины на трассу. И того же вы хотите от своих scrum-команд.

Тэмми признаёт, что в 3M HIS у команд еще есть проблемы с кросс-функциональностью и использованием методики роя. Команды, которые работают над их облачными сервисами, могут это делать, поскольку так было задумано изначально. В унаследованной ими системе невероятно сложно разделять работу.

«Закон Конвея, верно», – говорит она. Продукт отражает организационную архитектуру. Но они вносят изменения. В 3M HIS сейчас намного меньше подразделений, все команды отчитываются перед отделами исследований и разработки и уже не разнесены по всей компании. Они вкладывают значительные силы и средства в переход к облачным технологиям и в создание моделей услуг. Но на все это нужно время. За один день такого не сделаешь.

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

Буфер на отвлечения

[36]

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

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

Алекс Шейв – один из коучей в Scrum Inc. Впервые он столкнулся со Scrum около десяти лет назад. Он говорит, что когда увидел шаблон буфера на отвлечения, то сразу понял, что должен так работать. В июле 2007 года его наняли в компанию финансовых услуг – не лучший карьерный ход на тот момент. Тогда финансовый рынок США столкнулся с рекордным обвалом впервые со времен Великой депрессии. Шейв присоединился к команде, которая создавала инструменты для трейдеров, и оказался в том же кабинете, что и ведущий разработчик команды. Сосед по офису был хорошим парнем – они поладили и оба усердно трудились. Менялось то, над чем они работали. Причем часто. Однажды один из семи партнеров компании говорил: «Вот это важнее всего». А через неделю или даже на следующий день другой партнер мог захотеть что-то совершенно другое. Не слишком много сфокусированности. Но Алекс не задумывался над этим. Его команда выполняла запросы и не слышала в свой адрес ничего, кроме похвал.

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

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

Решение этой и многих других проблем в Scrum – сделать стоимость решений наглядной. Иногда и правда возникают чрезвычайные ситуации, с которыми нужно справляться немедленно. Но не все ситуации такие. Именно поэтому команде не нужно загружать себя полностью, лучше выделить часть времени на формирование буфера на отвлечения. Допустим, обычно команда доводит до готовности 20 элементов бэклога за спринт. Значит, в следующем спринте им нужно взять 15 элементов, оставив резерв для подстраховки.

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

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

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

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

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

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

Практика буфера на отвлечения позволила 3M HIS перейти от традиционной организации к гибкой. Вначале около 60 % усилий команды уходили на побочные задачи. Но с годами они смогли сфокусироваться на том, чтобы снизить этот показатель. Теперь он составляет около 20 %. И они всерьез задумались об этом. Они работают над разными изменениями, которые позволят им выйти на следующий уровень.

Соблюдение чистоты

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

Поэтому поддерживайте чистоту продукта и рабочей среды постоянно или в конце каждого рабочего дня[38].

В 2006–2007 годах на войска коалиции в Ираке, преимущественно американские, совершались сотни нападений в день. Излюбленной целью повстанцев стали американские колонны грузовых автомобилей: они взорвали множество бронированных военных джипов, грузовиков и другой техники.

Однажды мой редактор из NPR спросил у меня:

– А что со всем этим делают?

– В смысле?

– Что делают со взорванными джипами? На ремонт уходят миллионы долларов, но где их чинят?

– Не знаю. Попробую узнать.

Оказалось, что значительная часть поврежденных грузовиков оказывается на складе в Ред-Ривер примерно в сорока километрах от города Тексаркана в штате Техас. Те, кто бывал в западном Техасе, знают, что там есть целое ничего. Когда война набрала обороты, Пентагон решил закрыть пункт обслуживания в целях экономии – передать ремонт на аутсорсинг и закрыть эту тему. Почему? Потому что в Ред-Ривер чинили по три джипа в неделю. А если у вас по сто взорванных единиц техники в день, то три штуки в неделю никак вам не помогут.

Из нескольких тысяч работников ремонтной базы только один был одет в форму – ответственный за работу базы полковник. Все остальные сотрудники оказались гражданскими. Для них это была хорошая работа, и, если бы базу закрыли, это нанесло бы невероятный экономический удар по региону. Поэтому полковник решил узнать, как Ford и GM производят свои автомобили. Если вы никогда не видели бережливую производственную линию, посмотрите видео на YouTube: выглядит волшебно, словно тщательно отрепетированный танец людей и деталей. Все это основано на производственной системе Toyota, как я уже упоминал ранее.

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

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

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

Когда я впервые приехал в Ред-Ривер, они восстанавливали по 32 джипа в день. Через несколько месяцев – уже более сорока. Увеличение скорости ремонта от трех в неделю до сорока в день – это улучшение на 6600 %. Время производственного цикла также сократилось – с сорока до десяти дней.

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

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

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

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

Если на вашу долю выпало финальное тестирование, то знайте, что можете изменить это. Вы можете заставить проблемы исчезнуть навсегда так же, как это сделали сотрудники Ред-Ривер. Измените свои способы работы – и вы будете поражены тем, на что вы способны.

Аварийная процедура

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

Именно поэтому, когда вы видите, что показатели команды находятся в верхней части диаграммы сгорания задач, примените технику, которой постоянно пользуются пилоты. Когда случаются неприятности, запустите аварийную процедуру, разработанную специально для вашей проблемы[39].

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

Мой отец был летчиком-истребителем во Вьетнаме. Он говорит, что, когда в самолете случаются неполадки, нужно немедленно запустить аварийную процедуру. До момента, когда вы поймете, в чем проблема, можно и не дожить. Именно поэтому к левому бедру крепился список действий, и в аварийной ситуации пилоты начинали ему следовать. Без вопросов. В Scrum тоже есть похожий список, и scrum-мастер должен начать следовать ему незамедлительно – таково правило.

Список выглядит так.

1. Измените способы работы команды. Сделайте что-то иначе.

2. Попросите помощи, передайте элементы бэклога спринта кому-то еще.

3. Уменьшите объем работ.

4. Прервите спринт и спланируйте его заново. Предупредите руководство о том, насколько аварийная ситуация повлияет на сроки сдачи работ.

Автоматически следуйте шагам в списке. Если вы ничего не предпримете, вся команда потерпит крушение. Тяните штурвал на себя.

Дэвид из 3M HIS сказал, что Тэмми периодически сталкивается с аварийными ситуациями: «Тэмми использовала “бэт-сигнал”, чтобы прояснить ситуацию. Такое случалось, наверное, раз пять». На самом деле Тэмми хочет, чтобы ее команды пользовались аварийными сигналами чаще, не жертвовали качеством ради скорости. Используйте «бэт-сигнал». Он позволяет обозначить проблемы. Если команды этого не делают, то и вы не можете понять, почему начинает падать качество или сроки затягиваются. Вам нужно поощрять свои команды. Хвалите их за то, что они сообщают вам об аварийных ситуациях.

Scrum для Scrum

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

Поэтому определите одно самое важное препятствие во время ретроспективы и устраните его до конца следующего спринта[40].

Scrum помогает создавать гиперпродуктивные команды. Именно поэтому в подзаголовке нашей предыдущей книги говорится о выполнении вдвое большего объема работ за половину времени. Это не преувеличение, а цель. И она достижима, если подходить к ней ответственно. Но многие scrum-команды не достигают такого уровня улучшений, причем почти всегда по одной причине: они не могут успешно определять и устранять препятствия.

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

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

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

Вернувшись в Scrum Inc., Джефф сказал: «Попробуем это сделать. Когда найдем возможные улучшения кайдзен, всей командой оценим их, составим критерии соответствия, чтобы всегда знать о мере готовности, и поместим в верхнюю часть бэклога. На следующий спринт наш главный приоритет – кайдзен». Так мы и поступили. И в течение двух или трех спринтов наша скорость возросла вдвое. Более того, она растет по сей день.

Нередко в компаниях я сталкиваюсь с нигилистами: «Это место полный отстой. Сейчас, завтра и навсегда!» Когда я начинаю разговаривать с такими людьми, все встает на свои места. Такое отношение обычно возникает из-за того, что все знают о проблемах, но никто их не решает. Насколько это деморализует? Известны проблемы, возможно, и решения, но никто ничего не делает.

Я отправляюсь к руководителям и говорю им об этом. И они отвечают: «Мы знаем. Но не можем исправить проблему по причинам А, Б и В».

Прежде чем ответить, я слишком долго жду. Можно почувствовать, как нарастает немое напряжение. Затем я смотрю на них и говорю: «Так не должно быть. Это вопрос выбора. Ситуация может улучшиться».

Иногда мои слова не проходят даром. Люди действительно начинают исправлять проблемы, устраняя препятствия на пути команды. Но не всегда. Я не могу заставить их действовать. Но когда проблемы начинают решаться, нигилисты превращаются в самых активных поборников Scrum в компании – ведь ситуация выправляется.

3М по-прежнему использует кайдзен каждую неделю. «Возможно, это больше всего помогло нам. Команды постоянно становятся лучше. Длина спринта составляет неделю, и они внедряют 50 улучшений в год», – говорит мне Тэмми. Улучшения могут быть крупными и занимать какое-то время, даже находиться за рамками полномочий команды, но именно они меняют мировоззрение. Вместо того чтобы принимать проблемы как данность, люди ищут решения, изменяя ситуацию. Проблемы любят прятаться. Они как тараканы в стенах. Вытащите их на свет. Вы будете поражены: избавляться от них не так страшно, как вам кажется.

Метрика счастья

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

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

В книге «Scrum. Революционный метод управления проектами» мы посвятили целую главу счастью (глава 7). Я не хочу пытаться убедить вас в том, как важен настрой. Просто поверьте. Он важен. Очень. Если люди в вашей организации несчастливы и им не нравится их работа, у вас серьезная проблема. Счастливые люди быстрее и лучше работают. Это просто.

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

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

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

Когда говоришь слова, помогаешь делать дела

Эти восемь шаблонов – секрет грамотного использования Scrum.

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

Следующие четыре – Рой, Буфер на отвлечения, Аварийная процедура и Соблюдение чистоты – помогут решить наиболее распространенные проблемы команды, возникающие во время спринта.

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

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

Тэмми Сперроу признаёт, что 3М HIS не идеальна. Компании еще есть куда расти. Но она значительно продвинулась. Главное, подчеркивает Тэмми, направленность диалога уже не та, что была раньше. Прозрачность системы позволяет видеть самые трудные задачи: воздействие организационной архитектуры, проблемы с унаследованными продуктами, которые эта архитектура произвела. Но все они кажутся решаемыми. Она изменила границы возможностей.

«Если мы выполняем все элементы бэклога как нужно, – говорит Тэмми, – команды выходят на новый уровень».

Я не говорю, что это легко. Это может быть легко. Или невероятно трудно. Чтобы было легко, нужна дисциплина, а она требует сфокусированности и принятия обязательств. Иногда я слышу о том, что Agile – способ сделать жизнь людей лучше и счастливее. Это правда, гибкость этому способствует. Иногда я слышу о том, что гибкость на самом деле затрагивает создание великолепной культуры и компании. Совершенно верно.

Но все эти задачи второстепенны и служат одной цели – быстрой доставке ценности. Быстрой. Скорость важна – как в вопросах качества, так и в принятии решений. Цифры поразительны: если вы медлите, вероятность добиться успеха значительно падает.

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

Все эти шаблоны пересекаются и усиливают друг друга. Это шаблоны языка. Начните с одного из них. Всего одного. Другие придут сами.

ВЫВОД

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

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

Используйте шаблоны Scrum.

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

• Рой, Буфер на отвлечения, Аварийная процедура и Соблюдение чистоты помогут решить самые распространенные проблемы команды, возникающие во время спринта.

• Scrum для Scrum и Счастье – ключи к постоянному улучшению в устойчивом ритме. Они помогут добиться гиперпродуктивности – цели, для которой был разработан Scrum. Вдвое больше работы за половину времени.

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

БЭКЛОГ

1. Определите по меньшей мере по одному примеру мура, муда и мури на вашем рабочем месте. Как вы можете их исправить?

2. Создайте диаграмму сгорания задач и начните отслеживать прогресс вашей команды на протяжении спринта.

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

Раз есть полезные шаблоны – непременно существуют и такие, которым не стоит следовать, – антишаблоны. Не каждый переход на Scrum сработает. Здесь тоже есть вероятность неудачи. Интересно здесь то, что провалы случаются, как правило, по одним и тем же причинам.

Повторюсь: Scrum создан для быстрого выявления проблем. Зачастую это болезненно. Вот почему иногда организационные изменения невозможны.

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

– Джей Джей, ты меня возненавидишь.

– Что случилось?

– Ничего не работает.

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

Она была права.

По этой причине Scrum Inc. прекратила сотрудничество с той компанией. Мы не можем заставить людей меняться – можем только помочь им измениться самим.

Годами я составлял список подобных проблем, постоянно возникающих в компаниях. И я понял: знать, как не нужно делать, так же важно, как и знать, что нужно. Вот список антишаблонов и контрмер для них.

Что делать лидерам

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

Приведу пример из своей жизни. Последняя компания, в которой работал мой отец до того, как основал Scrum Inc., называлась PatientKeeper. Они занимались производством портативных устройств для врачей и больниц. С помощью такого мобильного устройства медицинский персонал мог делать все необходимое: выписывать препараты, назначать лабораторные исследования, видеть их результаты и т. д. Администрации нравились эти портативные устройства: с их помощью можно было собирать финансовые данные, выставлять счета за медицинские услуги и подавать заявления о страховых случаях.

Мой отец руководил техническим отделом компании. Он встретился с CEO PatientKeeper и рассказал ему, как собирался использовать Scrum. «Хорошо, – сказал тот, – но я устал слышать от команд, что все “готово”. Единственное “готово”, которое имеет значение, – выплаты от больниц и отсутствие спорных вопросов».

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

Как только они это сделали, CEO сказал, что теперь они могут менять приоритеты каждую неделю. По понедельникам он организовал собрания владельцев продуктов и scrum-мастеров, чтобы проводить обзоры их прогресса в доставке; изменять все, что требовало перемен; выделять средства на то, во что нужно вложить деньги; переводить фокус внимания на клиентов или конкурентов, по вине которых возникали проблемы. Сотрудники говорили, что CEO действует, как будто он scrum-мастер в команде владельцев продуктов. Он позволил ведущему владельцу продукта управлять процессом и вмешивался, только чтобы устранить препятствия в тот же день, включая смену руководства, если того требовала ситуация. Мой отец говорит, что он был похож на английского солдата былых времен. Каждую неделю владельцы продукта расставляли пушки, чтобы он мог стрелять в своих врагов. Новая неделя – новая цель. Через год у компании не осталось конкурентов. Значительную часть времени стал занимать демонтаж продуктов конкурентов в больницах, одной за другой. Прибыль подскочила на 400 % в год.

Тогда мой отец решил обучать людей использованию Scrum и основал Scrum Inc. Его преемник в PatientKeeper привлекал новые больницы каждый спринт как по часам. Несколько лет спустя он ушел из компании, и CEO нанял нового технического руководителя, который не понимал Scrum. Уже через месяц компания не могла доставлять ценность. CEO сказал новому руководителю: «Верни все как было – или ты уволен». Но ситуация повторилась. Тогда CEO решил взять на себя отдел и восстановил каскадную модель управления проектами. Доставки стали затруднительны и занимали много времени. Прибыль упала вдвое. PatientKeeper влачила жалкое существование еще несколько лет и стала примером отличной компании, которую разрушили старые практики.

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

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

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

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

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

Одному из них дали экземпляр книги «Scrum. Революционный метод управления проектами», и он был убежден, что Scrum – единственный способ разрешить их ситуацию. Я и мои коллеги из Scrum Inc. приехали, обучили сотрудников, запустили ряд scrum-команд. Все шло очень хорошо, изменения внедрялись быстро. Но они продолжали сталкиваться с одной и той же преградой – действиями другого лидера компании. Ей нравились результаты, но она не могла понять, что ей нужно изменить свое поведение. Именно поэтому она продолжала управлять группой так же, как раньше.

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

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

Организационный долг

Принципы бережливости невероятны. По сути, это западная версия принципов производственной системы Toyota – устранения всех потерь в системе. Lean Enterprise Institute перечисляет следующие принципы.

1. Определите ценность с точки зрения конечного потребителя линейки продуктов.

2. Определите все этапы потока ценности для каждой линейки продуктов, устраняя все этапы, которые не добавляют ценности.

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

4. Сформировав его, позвольте потребителям извлекать ценность из каждого последующего действия по мере продвижения продукта в потоке – вытяните производство.

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

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

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

Они сосредоточены на кайдзен, инкрементальных улучшениях, которые позволяют им улучшить систему или команду. На постоянном усовершенствовании. Это прекрасно, но они сосредоточены исключительно на текущем процессе, на том, как они сейчас выполняют работу. Они не думают о том, по-прежнему ли это верный способ решения задач и стоит ли их вообще решать. Ключевой аспект производственной системы Toyota – кайкаку, радикальные изменения. Они позволяют преобразить бизнес полностью: внедрять новые продукты, стратегии, инструменты. Радикальные изменения дают возможность отвечать на действия сил, меняющих рынок. Пример таких сил – изобретение iPhone, когда всем пришлось создавать смартфоны вместо обычных телефонов. Радикальные изменения могут идти не только снаружи, но и внутри компании. Как правило, при инкрементальных изменениях кайдзен небольшие шаги незначительно изменяют ситуацию. Именно поэтому нужно начинать проект, который изменит все: создавать чистый лист, начинать сначала, неважно, как именно вы это назовете. Вам нужны радикальные изменения.

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

Бережливость в компании – это прекрасно, но если вы слишком полагаетесь на нее, то ваша компания не сможет меняться.

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

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

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

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

Способ действий имеет значение

Островное государство Вануату, расположенное примерно на восьмидесяти островах, известно по нескольким причинам. Это одно из первых государств, на которые повлияло повышение уровня моря. Здесь разворачиваются действия книги Джеймса Миченера Tales of the South Pacific («Сказания юга Тихого океана»), которую он написал в 1947 году и которая вдохновила Ричарда Роджерса и Оскара Хаммерстайна на мюзикл «Юг Тихого океана». Один из десятков этих островов, простирающихся на 800 морских миль, называется Танна. 15 февраля там празднуют День Джона Фрума. Это мессия, который придет и спасет их всех, сбросив богатства с неба. Здесь сделаем небольшое отступление.

До Второй мировой войны это островное государство, тогда Новые Гебриды, не имело значения для мирового расклада сил. Однако глобальный конфликт придал этим крошечным островам вес. Там высадились войска морского флота США, инженерно-строительные части прорезали пути сквозь джунгли, построили дороги, аэродромы, базы и бараки. Здесь расположились 400 000 американских солдат. С собой они привезли грузы – сотни тысяч тонн продовольствия и строительных материалов, которые выбросили на острова как из рога изобилия. Тогда и родился образ Джона Фрума: «Я Джон из Америки. Хочешь шоколадку?»

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

В наши дни островитяне по-прежнему рисуют на груди надпись «США» и танцуют, имитируя военные построения и размахивая деревянными ружьями. Они уверены, что Джон Фрум обязательно вернется. Они создали политическую партию. Карго-культы существовали и по-прежнему существуют в нашей реальности.

Подобная ритуализация случается и со Scrum. Я видел это. Люди повторяют действия, воспринимают руководство по Scrum как Священное Писание и, кажется, верят, что единственная цель Scrum – сам Scrum. Я заходил в «комнаты Scrum», яркие и прекрасно освещенные, и все казалось прекрасным, пока я не спрашивал о том, доставляют ли команды ценность каждый спринт. Тогда всем становилось немного неудобно.

Одна компания, наш клиент, у которой около 50 тысяч сотрудников и примерно 70 млн покупателей, решила, что раз они переходят на Scrum, то все менеджеры, которые работали в отделе руководства проектами, станут scrum-мастерами.

С подлинной верой и религиозным рвением новообращенных менеджеры проектов взялись за Scrum и превратили его в нечто странное. Они ходили на занятия, читали книги, посещали конференции, изучали правила игр по гибким фреймворкам, много говорили о том, что значит быть лидером-слугой. Они ходили на работу. Проводили мероприятия. Использовали разноцветные стикеры. Как и верующие в возвращение Джона Фрума, они путали ритуалы и пантомиму с действиями.

Никто не слушал этих новых scrum-мастеров. На собраниях их игнорировали. К их советам оставались глухи. Их воспринимали как бесполезные приложения к компании, отнимающие время, пространство и деньги без каких-либо результатов.

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

Кажется, они не понимали, что Scrum – способ довести дело до готовности. Да, жизни людей станут лучше; возможно, они будут относиться друг к другу с уважением; в идеале работа станет для них интереснее. Но, как я уже сказал ранее, единственная причина существования scrum-мастеров – скорость. А ее им не хватало.

«В своей команде вам нужно быть экспертом», – сказал мне Маккоул Бэггет из Scrum Inc., когда я спросил его, как исправить карго-культ в Scrum. Маккоул – коуч, тренер и человек, к которому я обращаюсь, когда scrum-мастерам клиента нужна помощь.

«Чтобы стать успешным scrum-мастером, – сказал он, – нужно постоянно поддерживать коммуникацию. Решение кажется простым, но на самом деле оно гораздо глубже».

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

Scrum-мастерам необходимо следить за тем, как проходит общение. Маккоул говорит, что мировоззрение scrum-мастера очень сильно отличается от мировоззрения члена команды или владельца продукта. Хороший мастер смотрит не на то, что команда говорит о правильных вещах, а на то, верно ли она говорит о них. Именно это ускоряет процессы.

Он судит о мастерах так: команда постоянно становится лучше? Люди счастливы? Это главное. Далее: улучшают ли люди компанию? Последнее легко проверить по тому, устраняют ли они препятствия. Суть их работы – устранять то, что замедляет команду, и это не только влияет на их коллектив, но и, скорее всего, помогает многим другим командам и всей компании.

Не повторяйте действия бездумно. Ритуалы далеки от реальности.

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

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

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

Проверяя успехи каждой из ваших команд, вы легко можете составить представление о состоянии Scrum в вашей компании. Также таблица сделает препятствия для Scrum видимыми. Ваши scrum-мастера могут использовать ее как основу приоритизированного списка препятствий. Лучше всего отслеживать прогресс после каждого спринта. Или даже после каждого события, поскольку вы движетесь вперед. Это занимает не так много времени. Когда препятствия наглядны, вы можете действовать быстро, а не обнаруживать проблему с опозданием в три месяца. Тогда команда не доставит инкремент вовремя, поскольку у нее нет хорошего бэклога – ведь она начала пропускать этап его уточнения.

Все эти элементы могут и не быть в идеальном состоянии всегда. Это нормально. Начните с того, что имеете, и работайте, чтобы постепенно улучшать эти элементы. Если вы начнете проводить ежедневный Scrum, одно это уже добавит наглядности и поможет вам. А затем можно заняться другими элементами, решая проблемы по одной.

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

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

Большинство крупных компаний, с которыми мы работаем, привлекают огромное количество внешних подрядчиков. Где-то и вовсе большинство сотрудников – «со стороны». Я, кстати, считаю, что это безумие. Но сфокусируемся на scrum-аспекте этой практики. Нередко кто-то звонит и говорит: «Добрый день, нам завтра нужно пятьдесят scrum-мастеров. Найдете?»

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

Я не говорю, что вы не должны привлекать тренеров и коучей. Возможно, они вам потребуются. Но убедитесь, что и ваши сотрудники обучаются. Вам нужно научиться следовать Scrum самостоятельно. Мы в Scrum Inc. верим в то, что можно создавать действительно замечательные компании, которые способны нанимать, тренировать, поддерживать и ускорять свои команды. Наша задача – дать вам такую возможность, чтобы вы больше в нас не нуждались. Всем нашим коучам и консультантам я говорю, что наша работа – оставлять после себя постоянные изменения. И главное – уходить.

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

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

Пару лет назад я был в Кремниевой долине, в офисах нескольких новых компаний-гигантов в сфере технологий, социальных сетей и интернета. Я выступал с докладом в одной из них и спросил у аудитории: «Какое ваше самое большое препятствие? Что замедляет вас сильнее всего? Что стоит у вас на пути и сводит вас с ума?»

Один смельчак поднялся с места и сказал: «Перед разверткой выстраивается очередь. Сейчас она составляет восемь дней. И она растет. Вместо того чтобы устранять узкие места в доставке, мы создаем всё больше функций, потому что нам приказывают заниматься этим».

Я спросил у аудитории, правда ли это. Многие кивнули. Несколько человек аплодировали.

Я спросил у scrum-мастеров, донесли ли они проблему до руководства. Они сказали, что сообщали об этом, но им приказали молчать.

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

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

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

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

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

Решайте возникающие проблемы. Хотя бы начните ими заниматься. Покажите людям, что вы делаете для решения проблем. Так вы очень четко даете понять, что обязуетесь стать scrum-компанией.

Сфокусированность на том, что работает

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

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

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

Одно из самых грустных зрелищ, которым я был свидетелем, – ситуация, когда очень хорошие люди выполняют по-настоящему невероятную работу и очень быстро, но заняты неправильным делом. Или действуют неправильно. Приведу два примера. Nokia Mobile всего за несколько лет прошла путь от лидера индустрии до полной несообразности. При этом у нее были очень хорошие scrum-команды. Быстрые. Даже был Nokia-тест, который определял, гибкие вы или нет, с помощью вопросов, например: «Сколько длится спринт в вашей организации? У вас есть владелец продукта? А диаграмма сгорания задач? У вас есть приоритизированный бэклог?»

Но любой тест может выдать ошибочный результат, если вы просто выбираете вариант ответа. В Nokia были по-настоящему хорошие scrum-команды, которые доставляли ценность невероятно быстро. Конечно, после выхода iPhone все эти команды невероятно быстро доставляли неправильные вещи! И все из-за того, что владельцы продуктов недостаточно быстро отреагировали на изменения рынка. Неудача Nokia произошла не по вине команд, а по вине владельцев продуктов.

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

Подлинной причиной успеха того проекта стала отличная группа владельцев продуктов, которые сосредоточили все свое внимание на том, чтобы поставить нужный бэклог в нужное время. Они не позволяли отвлекаться на работу, не прописанную в бэклоге. Владельцы продукта несли ответственность за каждый спринт. Они периодически присылали мне диаграмму сгорания задач за весь проект. Задачи сгорали практически идеально, компания должна была добиться своей цели в нужный день. Ей это удалось. К Черной пятнице они полностью перешли на новую систему: 600 транзакций в секунду, время отклика 50 миллисекунд, коэффициент использования 99,9 %. Теперь они могли обновлять модель защиты от мошенничества незаметно для пользователей. Это сэкономило им 38 млн долларов в год. А за счет отказа от услуг посредника они сэкономили еще 40 млн. Вот на что способен отличный владелец продукта.

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

Знайте, что должно и не должно случиться

Дейв Слейтен – один из заклинателей владельцев продукта в Scrum Inc. Один из тех неудержимых людей с вкрадчивыми голосами. Он видел смерти многих компаний, почивших из-за плохого владения продуктом, и поэтому решил разработать набор инструментов, который поможет исправить ситуацию. Я хотел бы поделиться с вами той его частью, которую считаю наиболее важной в жизни владельца продукта: что не нужно делать.

Дейв проводит упражнение, которое называет картой синхронизации. Я же – «стеной боли». Дейв для начала просит владельцев продукта покинуть комнату (ведь они должны проводить с командой только половину своего времени) и записывает самые важные задачи для команды. Как только владельцы продуктов ушли, он просит членов команды записать, над чем они на самом деле работают. Затем он приглашает владельцев продуктов обратно к командам и просит их сравнить записи. Большую часть времени, по словам Дейва, команды действительно работают над какой-то из приоритетных задач. Но очень важно учесть то, что они делают из задач с низким приоритетом. Тех, которые никому не нужны.

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

Как объясняет Дейв, добротные критерии соответствия «не говорят команде, что ей нужно сделать», но проясняют, «чего ей делать не нужно». Решать, что не нужно делать, гораздо важнее, чем определить, что делать. Создавайте только то, что нужно прямо сейчас. В этот спринт. Не пытайтесь все сделать сразу.

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

Внутри этого безликого здания находилась безликая переговорная комната, примечательная только размерами. Она была огромна. За большим столом в форме буквы U одновременно сидели 30 или 40 исполнительных директоров. Проходило их ежегодное собрание по планированию, где они решали, какими проектами займутся в следующем году. Мне было интересно увидеть, как они станут принимать решения.

Один из главных вице-президентов вывел на экран проектора таблицу с перечнем проектов. Они были не слишком приоритизированы: просто было перечислено то, что казалось нужным. «Основные задачи». Главный вице-президент осмотрел комнату: у каждого из присутствующих за столом имелись куча бумаг и ноутбуки с открытыми презентациями, у каждого были ассистенты, которые периодически им что-то нашептывали. Он сказал: «Хорошо, у нас 500 тысяч человеко-часов в следующем году. Это с учетом сотрудников и подрядчиков. Сара, у тебя первый элемент из списка. Сколько часов, по-твоему, уйдет на реализацию?»

Сара посмотрела в свои бумаги, в ноутбук и переговорила с ассистентом. «Двадцать пять тысяч часов».

Другой вице-президент вмешался: «Разве этого достаточно? Могут быть проблемы».

«Хорошо, пусть будет тридцать пять тысяч».

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

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

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

Знаете что? Обе эти компании, возможно, делали все, что могли. Поскольку у них не было нужных данных.

Scrum обеспечивает значительные объемы данных: скорость, эффективность процесса, метрики счастья и т. д. Но нужно уметь ими пользоваться. Знать скорость своих команд. Позволить оценивать работу тем, кто будет ее выполнять. Отслеживать прогресс в реальном времени, спринт за спринтом. И если проект начнет отклоняться от курса, вы сразу узнаете об этом и сможете внести коррективы.

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

Пытаясь сойти с этого пути, они создали команду владельцев продуктов, чтобы были те, кто наблюдал бы за происходящим. Они смогли сократить количество продуктов до двухсот в двадцати разных группах. Команда владельцев продуктов на тот момент представляла собой группу ведущих владельцев продуктов, каждый из которых направлял действия ведущих владельцев продуктов в своих группах, где у каждого была своя команда владельцев продуктов, которая независимо работала со своими командами. (В одной из групп было три уровня ведущих владельцев – и да, они часто обращались к человеку на вершине иерархии, как к дроиду C3PO из «Звездных войн» – Chief3 Product Owner.)

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

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

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

Мы сказали ей, что это не проблема. Достаточно сложить оценки команд. «Но ведь нельзя сравнивать скорость и оценки в разных командах, – возразила CEO. – Вы сами нам так сказали». Конечно, мы сказали ей это, но что мы знаем обо всех оценках? Что они неверны. Все они. Но в данном случае у нас достаточно команд для того, чтобы усреднить их оценки, и тогда различия проявятся сами.

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

Предположим, они выполняли 20–25 элементов важного проекта каждую неделю на протяжении нескольких недель. Диаграмма сгорания задач выглядела восхитительно, все были уверены в том, что смогут осуществить доставку вовремя. Но случилось странное. CEO неделю за неделей наблюдала отличные показатели, но вдруг они упали на несколько спринтов. Что случилось? Это же был приоритет CEO. Мы решили разобраться. Оказалось, другой исполнительный директор обозначил другие приоритеты для команд и снизил их скорость работы над тем важным проектом.

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

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

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

• Стабильные команды. Давайте людям проекты, а не проектам людей.

• Вчерашняя погода. Берите на себя обязательства только за то, что сделали в прошлый раз.

• Выделенные команды. Переключение контекстов между командами погубит вас.

• Ежедневный Scrum. Каждый день. В одно время. В одном месте.

• Буфер на отвлечения. Составьте план на случай неожиданностей.

• Маленькие команды. От трех до девяти человек. Если команда будет больше, вы значительно замедлитесь.

• Готовый бэклог. Четкость в вопросах того, что нужно сделать.

• Соблюдение чистоты. Не позволяйте известным дефектам прожить и дня.

• Люди с пересекающимися навыками. Не допускайте неудач ни в одном элементе.

• Готовое готово. В конце каждого спринта работа должна быть полностью готова.

• Совместное расположение. Каждый должен находиться на расстоянии слышимости остальных.

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

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

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

И вы можете этого добиться. Ваши решения – это ваш выбор. Будущее не предопределено.

ВЫВОД

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

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

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

Данные, а не мнения. Scrum создает массивные объемы данных. И вам нужно ими пользоваться. Вы можете проводить эксперименты и быстро видеть их результаты. Эмпирическая система позволяет постоянно проверять и адаптироваться: пробовать, реагировать, оценивать, пробовать, реагировать, оценивать.

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

БЭКЛОГ

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

Когда Эрик Абекассис стал директором по информационным технологиям в компании Schlumberger в январе 2017 года, он столкнулся с одной из проблем, которые могут сделать карьеру или сломать ее. Schlumberger тогда уже вкладывала значительные средства в проект, который мог серьезно повлиять на будущее компании: важное обновление их ИТ-систем. Несмотря на потраченные ресурсы, проект был сопряжен со значительными трудностями.

Он решил, что пришло время для решительных действий. Он обратился к Scrum Inc., чтобы мы помогли найти более гибкие способы работы. Эрик Абекассис объяснил свои действия исполнительному руководству Schlumberger так: «Эксперимент со Scrum продлится всего несколько месяцев. Но если мы преуспеем, то он станет невероятным прорывом в вопросах эффективности». Результаты будут видны во всей компании, не только в бэк-офисе. Эксперимент мог значительно повлиять на способы работы компании.

Рождение тихого гиганта

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

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

По мере роста спроса на нефть росла и Schlumberger. В компании тратили много времени и ресурсов на исследования и разработки, оставаясь на передовой технологического прогресса в индустрии углеводородов. В 1981 году Schlumberger стала первой использовать электронную почту для передачи данных; одной из первых начала применять Arpanet, предшественник интернета. В 1991-м в Schlumberger разработали свою сеть передачи данных, одну из крупнейших в мире в то время, использовав протоколы TCP/IP и открытую архитектуру, чтобы повысить производительность и операционную совместимость.

Сложности, сопряженные с ростом

Подобно множеству крупных компаний, в XX веке Schlumberger приобрели немало меньших организаций. Но интеграция в области IT бизнес-систем после слияний – непростая задача. В Schlumberger поняли, что у них 150 разных унаследованных IT-систем, которые работают на разных типах компьютеров, с разными операционными системами, и никто не может составить цельной картины.

Они решили исправить ситуацию. Создать большую систему, которая свяжет все существующие: систему планирования ресурсов предприятия. Такие системы в современных транснациональных компаниях подобны сосудам. Они должны связывать все: средства, сырые материалы, бизнес-процессы, фонд оплаты труда, бухгалтерскую отчетность, поручения на покупки, канал поставок; список можно продолжать. Они выбрали SAP, лидера рынка в сегменте систем ERP, и начали совместную работу над системой для Schlumberger, подстраивая функции под нужды компании. Это был крупный и сложный проект.

Примерно за год до того, как стать директором по информационным технологиям, Эрик Абекассис занимался внедрением такой системы. Уже тогда это был амбициозный проект, в котором участвовали 600 человек. «Когда я вернулся обратно 15 месяцев спустя, – говорит Абекассис, – в проекте участвовало уже не 600 человек, а 1300. Невозможно координировать работу стольких людей каждый день».

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

«Нам отчаянно нужен был прорыв, который позволил бы нам работать более продуктивно», – говорит Абекассис.

Исправляем исправления

Scrum Inc. начала работать с компанией перед Днем благодарения. Первые несколько спринтов прошли не слишком гладко – было нелегко. Но Джим Брейди, вице-президент отдела архитектуры и управления IT, говорит, что вскоре ситуация изменилась. К маю продуктивность выросла на 25 %. «Изменение было очень быстрым и повлияло на компанию. Мы сократили количество внешних подрядчиков на 40 %. Пока это не вдвое больше работы силами половины сотрудников, но мы явно идем к этому».

Абекассис говорит, что они уже сократили затраты на 25 %. И это еще не конец. «Думаю, мы можем расширять свои горизонты и дальше, – говорит он. – Мы способны сократить затраты на 30–40 %, при этом повысить продуктивность на 30–40 %. Мы на верном пути».

Внедрение ERP в Северной Америке, на крупнейшем рынке компании, привело к созданию полностью готового продукта в апреле 2019 года. Только за счет изменения способов работы.

Иной способ мышления

Гуру менеджмента Питер Друкер утверждает: все противоречащее тому, что мы привыкли считать естественным, отрицается как неправильное, нездоровое и очевидно ненормальное[42]. Люди всегда будут сопротивляться изменениям. Даже перед лицом неизбежного и окончательного разрушения.

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

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

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

Абекассис утверждает: тогда им казалось, будто они упали на самое дно. «В тот момент они сделали шаг назад и сказали: “Хорошо, мы это сделаем”. И это создало ускорение, которое привело к повышению продуктивности нашей команды. Но главное – мы трансформировали нашу организацию так, что она превратилась в одну команду с общей миссией. Это было похоже на волшебство».

Как только вы начнете практиковать Scrum, ждите сопротивления. Будут силы, работающие против вас, что-то вне зоны вашего контроля: потребитель передумал, конкуренты сделали что-то иначе, появилась новая технология. Или трудности могут возникнуть в самой компании: сотрудники, производственные проблемы, объем бюджета.

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

Один из распространенных способов избежать таких атак – внедрить двойную операционную систему. С одной стороны очень яркой линии у вас находятся ваши agile-команды; с другой – традиционная иерархия. И вам нужно установить четко определенные способы взаимодействия между ними.

Приведу пример. Компания Markem Imaje производит промышленные продукты для отслеживания, определения и наклеивания ярлыков на все – от косметики до конфет и молочных продуктов. Большая часть их производственной линейки – промышленные принтеры. Высокоскоростные принтеры вроде тех, что печатают даты производства на упаковках пищевых продуктов. Компания ведет бизнес уже более ста лет. Десятилетиями каждый раз, когда они выпускали новый принтер, вместе с ним открывался специальный кол-центр и создавалась ударная группа из специалистов, которые быстро исправляли все дефекты в новом поколении устройств. Мучительный процесс. Недовольные покупатели. Ситуация изматывала всю компанию. Вдобавок это было еще и накладно: после определенного числа неудачных выпусков покупателям меньше хочется приобретать следующий продукт.

Несколько лет назад, чтобы разработать принтер нового поколения, Markem Imaje создали небольшое бизнес-подразделение, собрав вместе разные команды: программное обеспечение, электромеханику, химию, маркетинг, продажи, производство, контроль качества. Крис Салливан обратился в Scrum Inc., чтобы мы помогли командам, занимающимся ПО, перейти к новым способам работы. Он хотел быстро получить высокое качество и решил, что для этого командам нужно как минимум перейти к фреймворку Scrum. С командой разработки ПО все сложилось. Но остальные не хотели использовать Scrum.

Они не понимали преимуществ Scrum или не видели причин менять способы работы, к которым привыкли. «Хорошо, – сказал им Крис. – Тогда сделайте только одно. Я хочу каждый день по пятнадцать минут проводить встречи с представителями групп – лидерами, которые могут влиять на изменения в группе. Всего пятнадцать минут. Я хочу использовать масштабированный ежедневный Scrum, чтобы мы могли координировать наши усилия». Он сказал, что сначала процесс был очень неудобен. Люди не хотели говорить о проблемах открыто. Но само мероприятие изменило многое. Коммуникация стала быстрее, время передачи решений сократилось. Проблемы, которые раньше рассматривались месяцами, стали видны, появилась возможность решить их за несколько часов. Например, сотрудники из команды, занятой электромеханикой, могли упомянуть, что немного изменили форму печатающей головки по каким-то причинам, а специалисты-химики отвечали: «Слава богу, что вы нам об этом сказали! Мы собрались изменить вязкость чернил».

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

Впервые за сто лет в устройстве не было дефектов. Ответственный сотрудник производства Markem Imaje позже сказал Крису: «Сначала я не хотел этим заниматься, но масштабированный ежедневный Scrum оказался основной причиной появления лучшего продукта в истории нашей компании».

Проживаем изменения

Я хочу рассказать вам чуть больше об одной из команд в Schlumberger. Она отвечала за преобразование данных, полученных от этих 150 унаследованных систем в разных частях Северной Америки. Они стремились конвертировать 70 % унаследованных систем в каждой точке. Однако самый высокий их результат составлял 17 %. Можете себе представить, насколько счастливы были менеджеры.

После перехода к использованию Scrum они испытывали такие же трудности, как и многие другие команды. Они находились далеко друг от друга: члены команды жили в Техасе, Франции и Индии. У них был ограничен доступ к специалистам в предметных областях (СПО); один из СПО и вовсе должен был работать в четырех разных scrum-командах одновременно. Им не хватало людей. Было сложно.

Александра Уриарте, коуч и тренер Scrum Inc., которая работала с командой несколько месяцев, сказала мне, что ключом к решению проблемы станет выделенность и работа на полный день в команде scrum-мастера и владельца продукта. Владелец продукта Уолтер сказал, что после обучения у Алекс они приняли решение: «Мы действительно хотели использовать на практике все, что узнали за время обучения. Мы знали, что наши старые методы не работали».

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

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

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

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

Ничто не говорит за себя лучше, чем успех. Алекс говорит, что по мере расширения команды росло то, что она называет «командностью»: доверие, дружба, товарищество. Команда, которая раньше никогда не обеспечивала инкремент вовремя, стала доставлять его на неделю раньше. От 17 % готовности они перешли к 93 %. Они решили помочь тем, кто находится за пределами Северной Америки, и повысить их готовность. В свое свободное время! Они смогли делать то, что было для них мечтами всего несколько месяцев назад. И за пять месяцев они смогли доставить то, чем никогда раньше не занимались.

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

Scrum в масштабе

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

Важно установить набор известных стабильных взаимодействий между всеми компонентами во всех частях сети. Вернемся к истории команды Saab Gripen Е. Они создали соединения, чтобы все части самолета были стабильны и зафиксированы, как конструктор LEGO. Они могли демонтировать детали, не влияя на остальные части самолета. Организационная структура команд Saab была устроена так. Каждая команда или команда команд отвечала за определенный модуль: эти ребята – за радар, те – за двигатель, а вон те – за фюзеляж. Как и у отдельных деталей самолета, у команд есть известные стабильные интерфейсы взаимодействия. Закон Конвея в действии. Вам нужно, чтобы ваша компания была построена точно так же, как и продукт: из неплотно связанных элементов. Отправка отчетов, показаний приборов и обновлений с одного уровня на другой – это потеря. Любой менеджмент – на самом деле потеря. В идеальном мире у вас его не было бы – остались бы только команды, которые производят ценность. В реальности, к сожалению, вам нужна определенная структура и, как я уже сказал в главе 6, ровно столько, сколько необходимо: минимально жизнеспособная бюрократия.

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

В Schlumberger, например, цель весьма проста – сокращение затрат и быстрая доставка. Цель компании Stealth Rocket, о которой я уже говорил выше, – быстро выводить объекты на орбиту. В стартапах деньги важны, но куда важнее доставка: именно благодаря ей стартап продолжает получать средства от инвесторов. Именно поэтому они сфокусированы на инновациях и Agile.

Компания Autodesk занимает 85 % рынка систем автоматизированного проектирования и хочет стать более гибкой, перейти к использованию спонтанного проектирования и адаптивных процессов по двум причинам. Первая – чтобы Autodesk стала местом, где люди хотят работать, как Google или Saab. Несколько лет назад их руководитель сказал мне: «Существованию нашей компании угрожают вовсе не конкуренты, а четыре парня, которые засядут в гараже и не согласятся у нас работать». Желание топ-менеджеров, чтобы люди хотели работать в Autodesk. Вторая причина: компания меняет свою бизнес-модель. Годами она зависела от продаж дорогих лицензий на ее продукты, как и многие другие компании, производящие программное обеспечение. Но в 2014 году, начав ускорять переход на Scrum, она плавно перешла вот к этому небольшому образчику бюрократического языка на 40-й странице ежегодного отчета об успехах:

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

Они анонсировали переход от получения прибыли за счет продажи лицензии к получению прибыли за счет продажи подписок. Для этого есть модный термин – программное обеспечение как услуга (SaaS – Software As A Service). Идея в том, чтобы создать более устойчивые взаимоотношения с пользователями. Autodesk начала свой путь к этому и стала терять деньги. Очень много денег. Но она продолжала. Затем, в 2016-м, инвесторы поняли, зачем это нужно, и поддержали идею. За два года пакет акций компании вырос на 121 %. Соотношение рыночной цены акции к чистой прибыли на акцию выросло с 3,5 доллара в 2013-м до более 13 долларов в 2018-м.

Это действительно серьезный скачок вперед, гораздо больший, чем у их конкурентов. И они при этом по-прежнему теряли деньги. В мае 2018 года посвященный инвестициям сайт The Motley Fool опубликовал свое мнение, сказав, что инвесторы не дураки. Они видят потенциал в изменении бизнес-модели у ведущего игрока на рынке[43].

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

Майкл Хаммер и Лиза Хершман описали это в своей книге с аналогичным названием так: быстрее, лучше, дешевле.

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

Начало Возрождения

Название этому периоду европейской истории дал Жюль Мишле в своей работе «История Франции», опубликованной в середине XIX века. «Ренессанс» в переводе с французского – «возрождение». И именно таким должен быть образ мышления в компаниях. Им нужно возродиться и стать местами, где быстро выполняют задачи, быстро учатся и быстро действуют. Чтобы масштабировать Scrum, вам нужно отделить то, что вы делаете, от того, как вы это делаете. Как в отдельной scrum-команде.

Вот так это выглядит.

В Schlumberger масштабированный Scrum используют для того, чтобы распространить этот метод по всем странам, в которых работает компания. «Мы используем радикальный подход, основанный на механизмах Scrum и масштабированного Scrum, чтобы убедиться, что у нас есть должный контроль в центре и радикальная автономия на уровне страны, – говорит Джим Брейди. – Это позволит нам ускорить развертку на местах и получить максимально возможную прибыль».

Цикл действий scrum-мастера

С одной стороны рисунка показан цикл действий scrum-мастера. Он вращается вокруг команды руководства, о которой я писал в главе 6. Scrum-мастер фокусируется на постоянном улучшении как своей команды, так и команд, с которыми он координирует действия, определяя зависимости и способы совместной работы над продуктом. Он отвечает за прозрачность и успехов, и неудач, чтобы организация как целое могла обучаться и адаптироваться.

Энни Ховард, консультант в компании Bain & Company, заинтересовалась некоторыми историями Scrum Inc. о Scrum в компании Bosch и решила углубиться в эту тему, чтобы понять, что именно произошло. Bosch производит все, от посудомоечных машин до автомобильных систем безопасности, от сельскохозяйственных датчиков до электроинструментов. В компании работают сотни тысяч сотрудников. Она большая. И старая – открылась в 1886 году. Но те способы, которые они применяли тогда, не работают в XXI веке. И они это понимают. После появления интернета вещей они поняли, что будут привязаны к сети в определенный момент. Чтобы идти в ногу со временем, им нужно было использовать Scrum. В 2017 году CEO Bosch Фолькмар Деннер сказал: «Для Bosch крайне важна гибкость. Она позволяет нам отвечать на растущие темпы изменений в мире вокруг нас, оставаться лидерами инноваций».

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

Они решили полностью изменить себя и руководство компании. Деннер и совет директоров стали scrum-командой. У них появился владелец продукта и scrum-мастер, способные совмещать функции и проводить изменения каждый спринт. Также они решили создать общий бэклог для всей организации, где трудятся 400 тысяч человек.

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

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

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

«Мы работаем автономно и устраняем любые препятствия».

«Мы определяем приоритеты, упрощаем процессы, принимаем решения быстро и точно следуем им».

«Мы учимся на ошибках и считаем их частью нашей инновационной культуры».

«Мы взаимодействуем с коллегами из разных областей, отделов и структур – всегда нацелены на результат».

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

Каков был результат? Они наняли в продуктовые группы Bosch scrum-команды, которые ранее работали с производителем электромобилей Tesla. Tesla – невероятно быстрая компания, которая требует той же скорости от партнеров. Используя Scrum, Bosch сократила время разработки вдвое, адаптировав шасси и системы безопасности так, чтобы получилось то решение, которое было нужно Tesla. В сельскохозяйственном подразделении одна группа команд работала над объединенными датчиками, предназначенными для улучшения роста спаржи. Команды производили по десять инноваций каждые четыре недели вместо традиционной одной инновации раз в шесть – восемь месяцев. Подразделение дома и сада полностью перешло на agile-подходы. Это те ребята, которые производили электроинструмент. В команды вошли все необходимые специалисты – от дизайнеров до маркетологов. В них включили все навыки, необходимые для выпуска дрели на рынок.

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

Команда руководства

Когда в компании Schlumberger сформировали команду руководства, первое препятствие, которое перед ними возникло, – план рассадки.

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

«Мы заявили: “Давайте пока продолжим с тем планом рассадки, который у нас есть. И исправим его позже”, – сказал Брейди. – Это и есть природа Scrum. В том, что вы двигаетесь быстро». Быстро двигаетесь, отслеживаете препятствия, продолжаете двигаться.

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

Цикл действий владельца продукта

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

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

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

Что эта команда должна сделать в первую очередь? Какую самую маленькую задачу она может выполнить, чтобы создать ценность в свой самый первый спринт?»

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

В Schlumberger говорят, что синхронизация должна быть не только на вершине организации, но и на каждом ее уровне и в каждой совместной работе команды. «Это необходимо», – говорит Брейди. Без команды руководства, без команды владельцев продуктов на исполнительном уровне не было бы эффективности, Scrum просто не прижился бы в компании.

Искусство возможного

Когда ваша организация уже создала условия для перехода к Scrum, когда вы самоорганизуетесь, чтобы двигаться быстрее, повышать качество и оперативно отвечать на изменения в мире, вы полностью меняете траекторию движения вашей компании. Так сделала IT-команда в Schlumberger. У Эрика Абекассиса есть данные, которые подтверждают это. «Вот здесь мы. Вдвое больше работы за половину времени. И даже лучше».

«Мое намерение, – говорит Эрик с нажимом, – моя миссия – расширить концепцию “команды команд”, которая поддерживается принципами Scrum, чтобы она стала инструментом для управления бизнесом. – На секунду он замолкает. – Это мое видение. Моя цель. Над этим я работаю».

ВЫВОД

Ожидайте сопротивления до Возрождения. Изменения встретят протест. У вас должен быть план. Нужно определить, как вы будете защищать свои scrum-команды от «организационных антител», которые могут попытаться атаковать их.

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

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

БЭКЛОГ

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

2. Есть ли у менеджеров в вашей компании ясное и востребованное видение ваших продуктов? Оно верное? Им делятся эффективно и убедительно? Как, по-вашему, стоит его распространять?

3. Вы хотите меняться? Использовать Scrum? Хотят ли того же другие люди в организации? Как вы остановите «организационные антитела», которые могут мешать внедрению Scrum?

4. Если бы вы могли превратить вашу компанию в сеть команд, как бы она выглядела?

В XIX веке доминирующей теорией распространения заболеваний считалась теория миазмов. Идея заключалась в том, что разлагающаяся материя испускала «миазмы» – частицы заболевания, которые передавались по воздуху. Считалось, что плохой воздух появляется преимущественно ночью.

Эта теория была ведущей на протяжении столетий, со времен Древнего Рима. Причем не только в Европе – в Индии и Китае существовали похожие теории распространения заболеваний. Проблема в том, что если вы неправильно представляете способ передачи заболевания, то пытаетесь защищаться не от того, от чего нужно.

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

Люди жили в густо заселенных и небольших кварталах. Больше всего они боялись холеры. Эта болезнь убивала тысячи людей. Самые крупные вспышки произошли в 1841, 1849 и 1854 годах. Доктор Уильям Фарр, один из самых влиятельных специалистов по состоянию здоровья населения того времени, был убежден, что болезнь распространяется по воздуху от грязных берегов Темзы к домам бедняков и убивает их. Он внимательно изучил вспышки заболевания и пришел к выводу, что существует обратная зависимость между расположением домов и распространением холеры: если вы живете на холме, то заболеете с меньшей вероятностью. Стало очевидно, что причиной болезни были миазмы, плохой воздух.

Доктор Джон Сноу придерживался иной точки зрения, и немногие принимали ее. Доктор Сноу – интересная фигура; помимо прочего, он был пионером использования анестезии в медицине и одним из первых, кто применил ее в родовспоможении, в том числе при рождении восьмого и последнего ребенка королевы Виктории – Леопольда.

Доктор Сноу считается отцом современной эпидемиологии. Он считал, что холеру распространяет не грязный воздух, наполненный миазмами, а вызывающие заражения вещества в воде, которую пили жители Лондона. В 1849 году, после вспышки холеры, которая унесла около пятнадцати тысяч жизней, он написал работу On the Mode of Communication («О путях заражения»), сообщив о том, что, скорее всего, источником болезни стала вода. Его теория была отвергнута службами здравоохранения и общественностью.

Когда новая вспышка холеры произошла в 1854-м, он быстро приступил к действиям. О тех днях он вспоминает в обновленном варианте своего эссе, опубликованном в 1855 году.

Самая страшная вспышка в истории этого королевства – возможно, та, что произошла на Брод-стрит, Голден-Сквер в районе Сохо и на прилегающих улицах несколько недель назад. В радиусе 250 ярдов (228 м) от пересечения Кембридж-стрит и Брод-стрит за десять дней от холеры погибло более 500 человек. Показатели на такой ограниченной площади превышают совокупную смертность от всех других заболеваний, когда-либо возникавших в этой стране, даже чумы; что куда более неожиданно, в большинстве случаев летальный исход наступил в течение нескольких часов[44].

Всего за несколько часов ситуация стала такой же, как во время чумы.

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

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

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

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

Воду набрали в четверг, 31 августа, она пила ее вечером в четверг и весь день в пятницу. Она заболела холерой вечером того же дня и умерла в субботу… Племянница, которая приходила к ней в гости, тоже пила воду; она вернулась домой, в Айлингтон, расположенный на холме, но тоже заболела холерой и умерла. Ни в Уэст-Энде, ни в районе, где умерла племянница, холеры не было.

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

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

Неправда. Была еще одна эпидемия холеры. Если бы службы общественного здравоохранения признали, что Джон Сноу прав, это значило бы, что все их меры по защите здоровья нации были бесполезны. Они настаивали, что правы, а доктор Сноу – нет. Именно поэтому они вновь открыли водоколонку, как только эпидемия стихла. Так было до 1866 года – через восемь лет после смерти Сноу доктор Фарр признал, что, возможно, тот был прав.

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

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

Логически выведенный фреймворк

Как и Сноу, я не утверждаю, что у практиков Scrum есть все ответы или они знают все вопросы. Но я думаю, что у нас достаточно фактов для того, чтобы изменить свое видение мира. Достаточно закономерностей, чтобы логически вывести общий фреймворк.

Scrum развивался и рос точно так же, как и другие открытия. Сначала были отдельные случаи успешного использования. Затем в одном месте разрабатывались одни практики, в другом – другие. Годами мы продолжали учиться, открывая новые работающие методы, новые закономерности. И все их можно свести к простому, нехитрому фреймворку под названием Scrum.

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

Лучший мир

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

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

Возможно, вам известно, что Дания, вероятно, самая низкорасположенная страна в мире. А еще это родина LEGO, Maersk (крупнейшая компания по производству контейнеров для морских перевозок) и Carlsberg Group (производитель пива Carlsberg). Все они применяют Scrum. В Дании он настолько популярен, что используется почти по умолчанию, особенно в сфере технологий. «Так мне подсказывает интуиция. С программным обеспечением только так. Так и работаем», – говорит Карстен Якобсен.

Карстен начал, возможно, первую Scrum-трансформацию в Дании в компании Systematic в 2006 году. Systematic занимается производством ПО для здравоохранения, обороны, разведки, национальной безопасности и всех сфер деятельности, где люди умирают, если что-то идет не так. Карстен экспериментировал с четырьмя пилотными проектами и использовал инкрементальный итеративный подход, когда кто-то сказал ему, что этот метод называется Scrum. Именно поэтому он пригласил Scrum Inc. для тренингов. Скорость увеличилась вдвое. Количество дефектов упало на 41 %. Счастливее стали и покупатели, и команды.

«Тогда я впервые увидел, как все метрики улучшаются одновременно, – говорит Карстен. – Обычно вы пробуете что-то, и один показатель растет. Но не все сразу».

В следующие несколько лет Scrum распространился по всей компании Systematic и достиг уровня руководства. CEO компании, по словам Карстена, руководствовался только данными, и когда он увидел улучшения в работе команд, то внедрил Scrum и на уровне руководства, потребовав, чтобы все посещали ежедневный Scrum.

После этого Карстен основал свою компанию Grow Beyond и начал читать лекции в Университете Ольборга. По его словам, он был почти уверен, что во всех университетах Дании обучают Scrum. Теперь он работает с более старыми и устоявшимися компаниями – производственными, финансовыми, страховыми. Он говорит, что даже традиционный менеджмент сейчас начинает понимать agile, и причина проста. Компании начали понимать: чтобы поспеть за изменениями, они сами должны меняться. «Сделай или умри, – говорит он. – Если ты меняешь компанию должным образом, то выживешь. Если нет, то умрешь».

Этот рефрен я слышу снова и снова от топ-менеджеров. Каждая компания должна начать думать как технологическая – так быстро меняется рынок. Им нужно меняться или рисковать, что их обгонит более ловкий конкурент и они окажутся не у дел.

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

Созданная в качестве регулирующей компании в 1953 году, KDDI обеспечила с японской стороны первый прямой эфир между США и Японией. Она первой предложила услуги прокладки кабеля на тысячи километров через Тихий океан, чтобы соединить США и Азию. Сначала она работала с Intelsat. После отмены государственного контроля занялась мобильной, широкополосной и прочими видами связи. Это большая компания. Она всегда воспринимала себя как двигатель технологического прогресса.

Она обратилась в Scrum Inc. в 2016-м, чтобы научиться использовать Scrum. Руководство компании понимало: интернет вещей и 5G стали реальностью, и им нужно быстрее разрабатывать услуги и устройства для покупателей. Также они хотели, чтобы мы привнесли Scrum в японскую промышленность.

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

Нас пригласил Акихито Фудзии. Он прошел примечательный путь по карьерной лестнице, отличающийся от пути большинства японских топ-менеджеров. Он работал в японских офисах Sun Microsystems и Google, но отчитывался перед руководством в США. У него менталитет Кремниевой долины. И ему нравились открытые и инновационные атмосфера и менталитет. Но он увидел нечто более значительное. Не компанию, а страну, которой нужно было изменение менталитета. И он начал действовать, чтобы помочь Японии.

«Те способы работы: невероятная конкуренция, творческие прорывы, где важен только успех, – все это обо мне, Джей Джей, – сказал он мне. – Но как насчет других? Как помочь не только мне, но и им?»

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

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

Приумножайте любовь с пользой

Современные люди склонны всё описывать по-деловому: «Ты это сделаешь для меня, а я это – для тебя». Это подразумевает, что количество любых объектов и действий ограничено, а все взаимодействия должны быть подсчитаны, чтобы понять, справедливы они или нет. Это способствует восприятию жизни и выбора как коммерческих сделок. Очень типичный для людей подход. У меня две маленькие дочери, и, поверьте, они часто рассказывают мне о том, как важна справедливость.

Но иногда справедливость и подобное мышление не работают. Есть ли ограниченное количество добрых дел для человека? А доброты? Преуменьшает ли моя радость вашу?

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

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

Такие ресурсы не исчезают при использовании, а только растут. Если мы воспринимаем поддержку близких как коммерческую сделку, она тает; если же мы поддерживаем их, то ресурс растет. Относитесь к другим так, как хотите, чтобы относились к вам.

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

Одно из моих любимых исследований невинно называется «Социальные связи и восприимчивость к простуде»[46]. Исследователи использовали выборку из пары сотен человек, измерили их уровень одиночества, а затем, добавив эксперименту жестокости, подвергли их воздействию ОРВИ. Сначала они определили их индекс общественного взаимодействия.

[Данный индекс включает оценку] отношений с супругой(-ом), родителями, родителями супруга(-и), детьми, другими близкими членами семьи, соседями, друзьями, друзьями с работы, школьными друзьями, волонтерами (например, если человек участвует в благотворительных или общественных работах), членами группы, не придерживающимися определенной религии (например, социальной, реабилитационной, профессиональной), и членами религиозной группы. Испытуемые получали один балл за каждый тип связей (максимальный балл – 12) при условии, что респондент разговаривает (по телефону или лично) с членом группы по меньшей мере раз в две недели[47].

Я уверен, что вы сейчас подсчитали свои социальные связи. Я набрал пять баллов. Что ж, возможно, мне стоит поработать над этим. И знаете что? Чем больше у вас связей, тем ниже вероятность того, что вы заболеете. Люди, которые набрали меньше трех баллов, заболели в 60 % случаев; те, у кого четыре или пять социальных связей, болели чуть более чем в 40 % случаев; те, кто набрал шесть и более, – чуть более чем в 30 %. Если у вас шесть и больше социальных ролей, вероятность того, что вы заболеете, вдвое ниже, чем у тех, у кого их три. Другое исследование с выборкой около 7000 человек, наблюдение за которыми продолжалось девять лет, показало, что за этот период люди с наименьшим количеством социальных связей умирали в два раза чаще, чем те, у кого было больше всех социальных связей[48]. Одиночество убьет вас.

Почему? Тому есть несколько причин. Первая – в идее амортизации стресса. Если вы сталкиваетесь с напряженной ситуацией, сеть социальной поддержки поможет вам справиться с ней. Интересным способом. Значение имеет не то, есть ли у вас поддержка, а то, чувствуете ли вы ее. Совершенно верно – даже если вы не обращаетесь за помощью, важно, чтобы вы знали, что вам могут помочь. Это сохранит вам жизнь. Исследование длительностью семь лет, проведенное на группе респондентов-мужчин из Швеции, показало, что те, кто не ощущал сильной эмоциональной поддержки и сталкивался с рядом стрессовых ситуаций – развод, смерть любимого человека, потеря работы и т. п., – умирали чаще, чем те, кто ощущал поддержку[49].

Кроме того, есть влияние группы. Понимания ролей. Понимания своего места в мире. Шелдон Коэн из Университета Карнеги – Меллона в работе, озаглавленной «Социальные отношения и здоровье» и процитированной около пяти тысяч раз, писал, что понимание ролей и норм в группе – определяющий фактор ментального и физического здоровья.

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

Связи с людьми, от которых вы ожидаете поддержки. Общий набор ожиданий, согласно которому определяется, что и как делать в рамках определенной роли. Цель. Значение. Безопасность. Самоуважение. Scrum помогает создать все это. Ежедневно он обеспечивает людям фреймворк для этого. Без социальной связанности, поддержки, общих ожиданий люди страдают. Они унижены. Вместе же мы можем двигать горы и сотрясать небесные столпы. По отдельности мы угасаем; мы становимся меньше, чем потенциально способны стать. Как только вы измените свой взгляд на то, как работает мир, и поймете, что старые аксиомы уже неприменимы, вы сможете изменить границы возможного – как для себя, так и для мира. Scrum работает везде, где люди собираются вместе. Он эффективен и работает во всех возможных вселенных, а не только в той, которую мы случайно заселили. Утверждение о том, что 1 + 1 = 2, более фундаментально, чем законы движения и гравитации Ньютона (и оба эти закона играют важную роль в предсказании того, что завтра солнце снова взойдет на небосвод). В других мирах, где законы Вселенной иные, этого может не случиться. Но математика остается неизменной и может также описать те миры. Scrum произрастает из человеческой сущности, независимо от того, на каком языке люди говорят и какую работу выполняют. Это фундаментальный инструмент для раскрытия наших возможностей.

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

ВЫВОД

Пора принимать решение. Мир, как вы уже поняли, постоянно меняется. Он может подарить вам свободу или парализовать вас. То, что кажется нереальным, можно сделать. Я не могу заставить вас, могу лишь показать вам способы достичь желаемого. У вас есть инструменты, подсказки, путь. Будущее не предопределено. Не живите в дефиците – живите в изобилии. Ваши возможности безграничны.

БЭКЛОГ

Действуйте.