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

Посвящается v*

• За уверенность в том, что краеугольный камень этой книги – радость,
• За уверенность в том, что полярной звездой ее всегда будет надежда,
• За то, что согласилась выйти замуж за меня, автора этой книги,
• Чтобы снова влюбиться в меня,
• За напоминание во всем видеть свет.
• Я благословен и благодарен за то, что ты есть в моей жизни.
• Эта книга не стала бы такой без тебя

Глава 1. Выбор

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

Все это напоминает мне историю создания революционной книги Антуана Лавуазье 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. Оцените способность вашей компании адаптироваться и внедрять инновации. Насколько вам сложно держать темп в условиях меняющихся спроса, желаний и требований? Вы разрушитель или ждете дня, когда окажетесь за бортом? Что благоприятствует и вредит вашей способности реагировать на изменения?

Глава 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. Именно тут владелец продукта приносит все свои идеи для будущих спринтов команде и обсуждает с ней, как воплотить их в жизнь. Вместе они четко очерчивают, что включает каждый элемент и, главное, какие критерии использовать для определения его готовности.

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

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

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