«Scrum»

Scrum (fb2) - Scrum [Революционный метод управления проектами] (пер. Мария Гескина) 2145K скачать: (fb2) - (epub) - (mobi) - Джефф Сазерленд

Джефф Сазерленд Scrum. Революционный метод управления проектами

Jeff Sutherland

SCRUM

The Art of Doing Twice the Work in Half the Time

Издано с разрешения Scrum, Inc. c/o The Ross Yoon Agency

Правовую поддержку издательства обеспечивает юридическая фирма «Вегас-Лекс»

© Jeff Sutherland and Scrum, Inc., 2014

© Перевод на русский язык, издание на русском языке, оформление. ООО «Манн, Иванов и Фербер», 2016

* * *

Эту книгу хорошо дополняют:

Управление проектами

Вадим Богданов

Бизнес-процессы

Владимир Репин

Deadline

Том Демарко

Предисловие партнера к российскому изданию

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

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

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

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

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

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

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

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

Ульяна Самолова,президент Samolov Group

Введение

Почему Scrum?

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

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

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

С момента своего возникновения концепция Scrum легла в основу проектирования новых программных продуктов для технологических отраслей. Однако, снискав признание и успех в Кремниевой долине среди руководителей проектов по созданию программного обеспечения и нового оборудования, в общей деловой практике Scrum остается еще малоизвестной методологией. Именно ради этого делового сообщества – людей, не связанных напрямую с миром высоких технологий, – я задумал написать книгу, в которой собираюсь раскрыть и разъяснить преимущества Scrum как системы управления в бизнесе. Я расскажу о первоистоках методологии Scrum: производственной системе компании Toyota и концепции, созданной для задач боевой авиации, – цикле OODA[1]. Рассмотрю вопрос, почему организация проектов силами небольших команд является более эффективным способом работы. Остановлюсь на следующих моментах: как правильно расставлять приоритеты в работе над проектом; как организовывать спринты, то есть короткие этапы разработки проекта (от одной недели до одного месяца), – причем делать это таким образом, чтобы каждый член команды отвечал за свою часть работы, а результат последующего этапа вбирал в себя функции проекта, реализованные на предыдущих этапах; как проводить ежедневные короткие обсуждения задач проекта, чтобы быть не только в курсе сделанного, но и тех трудностей, с которыми неизбежно приходится сталкиваться. Кроме того, я объясню, как методология Scrum объединяет концепцию непрерывного совершенствования и концепцию реализации продукта с минимальным функционалом, что позволяет не ждать завершения всех работ, а оперативно удовлетворять требования заказчика на каждом этапе проекта. Вы узнаете, что мы применяли Scrum при проектировании абсолютно всего: от создания дешевых автомобилей с расходом топлива четыре литра на сто пятьдесят километров до разработки современных, на уровне XXI века, баз данных ФБР.

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

Джефф Сазерленд

Глава первая Привычное мироустройство дает трещину

Джефф Джонсон был заранее уверен, что денек выдастся нелегким. Тогда, 3 марта 2010 года, Федеральное бюро расследований решило приостановить свой крупномасштабный и многообещающий план модернизации управления информацией. Воплотив его, ФБР смогло бы предотвращать события, подобные 11 сентября. Однако разработка проекта потерпела фиаско – одно из самых грандиозных, которое знавала история развития программного обеспечения. В Бюро пытались обновить свою компьютерную систему уже более десяти лет, и похоже, их постигла катастрофа. Опять провал.

Но на сей раз – с детищем Джеффа Джонсона – все пойдет иначе.

Семь месяцев назад он появился в ФБР и заинтересовал своим предложением директора по информационному обеспечению Чеда Фулгэма – когда-то они вместе работали в банке Lehman Brothers. Джеффа назначили помощником начальника управления информационных разработок и дали офис на верхнем этаже здания имени Эдгара Гувера, то есть в штаб-квартире ФБР, расположенной в центре Вашингтона, округ Колумбия. Из его просторного кабинета открывался вид на монумент Вашингтона. Вряд ли Джефф предполагал, что ближайшие два года ему предстоит провести в бетонном подвале, в каморке без окон, где он будет пытаться исправить проект, который, по общему мнению, считался безнадежным.

Джефф Джонсон и его босс сочли правильным заявить о поражении и закрыть программу, работа над которой длилась без малого десять лет и обошлась ФБР в сотни миллионов долларов. Настал момент признать, что больший смысл имело бы забрать ее себе и трудиться над ней самостоятельно внутри отдела. «Решение далось нам нелегко, – сказал Джефф. – Но проект требовалось сделать, и сделать хорошо».

Столь долгожданная электронная система была призвана помочь ФБР вступить в новую эпоху – эпоху Facebook, Twitter, Amazon и Google. Шел 2010 год, а большинство документации хранилось в бумажном виде. Программная система, когда-то созданная для нужд Бюро, называлась «Автоматизированная поддержка следственных дел» (Automated Case Support, ACS) и работала на гигантских ЭВМ – последнем слове техники далеких восьмидесятых. Многие спецагенты предпочитали ею не пользоваться. Слишком она была громоздкой и медленной для эпохи терактов и стремительно перемещающихся преступников.

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

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

Комиссия 11 сентября[2] – в попытках установить внутренние факторы, позволившие произойти тому, что произошло, – детально изучила все обстоятельства террористических атак. По мнению членов комиссии, аналитики не могли получить доступа к информации, которую должны были исследовать. «Плачевное состояние информационных систем ФБР, – гласит отчет, – привело к тому, что получение такого рода доступа в большей степени зависело от личных отношений аналитика с сотрудниками оперативных команд и подразделений, располагавших информацией».

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

Когда сенаторы начали задавать ФБР некоторые неудобные вопросы, представители Бюро в основном отделывались фразой: «Не беспокойтесь, мы уже разрабатываем план модернизации». На этот проект под названием «Виртуальные следственные дела» (Virtual Case File, VCF) возлагали большие надежды. В желании извлечь максимальную выгоду из любого кризиса отвечавшие за разработку чиновники заявили о необходимости добавить всего лишь 70 миллионов долларов к имеющимся 100 миллионам, которые были предусмотрены в бюджете. Если вы почитаете публикации того времени, рассказывавшие о новом программном обеспечении для ФБР, то обнаружите, что никто не скупился на слова вроде революционный и преобразование.

Спустя три года проект закрыли. Программа была непригодна для работы. Ни на йоту. ФБР потратило 170 миллионов долларов из кармана налогоплательщиков на покупку компьютерной системы, которой никто никогда не будет пользоваться – ни единой строчкой кода, ни одним приложением, ни малейшим кликом мыши. Проект в целом оказался полностью провальным. И это нельзя считать простым недоразумением – неудачей IBM или Microsoft. Ведь на кону без преувеличения стоял вопрос о человеческих жизнях. На страницах Washington Post появилось признание Патрика Лехи, сенатора-демократа от штата Вермонт, председателя юридического комитета сената:

Мы располагали информацией, которая могла бы предотвратить 11 сентября. А они там сидели, и никто не принял никаких мер… Я до сих пор не вижу, что они устраняют проблему… Пока мы дойдем до технологии XXI века, уже наступит XXII столетие{1}.

Довольно показательно, что после провала программы «Виртуальные следственные дела» многие сотрудники ФБР перестали быть таковыми.

К следующему проекту, названному «Страж» (Sentinel), ФБР приступило сразу, в 2005 году. Программа обязательно начнет работать. В данном случае все будет иначе: в Бюро примут необходимые меры, проведут надлежащие бюджетные процедуры и организуют правильные средства контроля. Они как следует выучили урок. Цена вопроса? Сущий пустяк – 451 миллион долларов. И система «Страж» будет полностью работоспособной в 2009 году.

Что на этот раз могло пойти не так? Ответ появился в марте 2010 года и лежал на столе Джеффа Джонсона. Компания Lockheed Martin, подрядчик, которого наняли для разработки новой системы, опаздывала на год, осуществив лишь половину проекта и потратив 405 миллионов. Для завершения программы, по оценкам независимых экспертов, ей потребовалось бы еще от шести до восьми лет, а налогоплательщикам пришлось бы раскошелиться дополнительно на 350 миллионов долларов минимум.

Разбираться с проблемой пришлось Джонсону.

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

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

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

Каскадная модель

Такие графики называют диаграммами Ганта, по имени их создателя Генри Ганта. С распространением в 1980-е годы персональных компьютеров стало проще создавать разные затейливые диаграммы – и делать их по-настоящему комплексными – они превращались в подлинные художественные произведения. Весь ход проекта детально размечен. Каждый отдельный шаг. Любая стадия. Всякая дата поставки. Действительно, диаграммы Ганта производят глубокое впечатление. Существует лишь единственная проблема: они всегда неправильны – без исключения.

Генри Гант придумал свои знаменитые диаграммы в 1910 году. Впервые ими начал пользоваться генерал Уильям Крузер, начальник артиллерийско-технической службы вооруженных сил США в Первую мировую войну. Каждый, кто изучал историю этой войны, знает, что ни подготовка кадровых ресурсов, ни система организации никогда не были ее сильными сторонами. Мне не дано понять, почему концепт времен Первой мировой войны становится де-факто аналитическим инструментом проектирования и применяется даже в XXI веке. Мы отказались от принципов позиционной войны, но каким-то образом ее «окопные» организационные идеи остаются популярными и по сей день.

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

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

В бытность свою кадетом Военной академии США, более известной как Вест-Пойнт, я спал в бывшей комнате Эйзенхауэра. По ночам уличные огни, отражаясь в висевшей над камином золотой табличке, иногда будили меня. Табличка гласила: «Здесь спал Дуайт Эйзенхауэр». Я вспомнил об этом президенте, поскольку он однажды заметил, что планировать сражение очень важно, но стоит прогреметь выстрелам – и твоя схема действий развеивается вместе с первым дымом. По крайней мере, Эйзенхауэру хватило здравого смысла не использовать диаграммы Ганта.

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

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

Чед доложил генеральному инспектору Министерства юстиции[3], что завершить систему «Страж» Бюро сможет только в том случае, если возьмет на себя управление проектом: они сократят количество разработчиков, выполнят наиболее трудную часть плана в пять раз быстрее и истратят менее одной десятой бюджетных денег. В докладах генерального инспектора Конгрессу, обычно сухих и официальных, явственно звучали скептические нотки.

Представители финансового контроля, регулярно проводившие по распоряжению генерального инспектора проверку хода работ над проектом, в октябре 2010 года представили очередной отчет, в котором выразили серьезную озабоченность по поводу предложения ФБР; свои основные соображения они изложили в девяти пунктах, после чего следовало их заключение:

В общем и целом у нас есть существенные опасения в отношении предложенного нового подхода; остается немало вопросов по поводу способности исполнителей обеспечить завершение проекта «Страж» без дополнительных расходов, без нарушения сроков и при сохранении в новой системе функциональности старой системы управления следственными делами…{2}

Новое мышление

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

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

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

Почему для названия эффективной групповой работы я выбрал спортивный термин, я объясню в следующих главах. Слово scrum («схватка»)[4] взято из регби и обозначает метод командной игры, позволяющий завладеть мячом и вести его дальше по полю, а для этого нужны слаженность, единство намерений и четкое понимание цели. «Схватка» представляет собой идеальную модель полного взаимодействия игроков – именно то, что я хотел бы видеть в командной работе.

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

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

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

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

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

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

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

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

Результаты бывают настолько впечатляющими, что, по мнению лидеров на рынке исследований и аналитических услуг, таких как Gartner, Forrester Research и Standish Group, испытанный подход себя изживает. Компании, которые продолжают упорно пользоваться старыми, но отнюдь не добрыми концепциями контроля и управления, опирающимися только на прогнозирование, обречены на поражение в битве с конкурентами, перешедшими на методику Scrum. Разница слишком велика. Например, в бостонской фирме с венчурным капиталом OpenView Venture Partners – одной из компаний, где я являюсь консультантом, – утверждают, что методология Scrum обеспечивает слишком серьезным конкурентным преимуществом, чтобы пренебрегать ею. А предпринимателей, имеющих дело с рисковым капиталом, никак не назовешь белыми и пушистыми – эти толстосумы видят всех насквозь. И они без затей заявляют: «Эффект бесспорен. Все компании стоят перед выбором: изменись – или умри».

ФБР устраняет препятствия

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

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

«Там было тысяча сто запросов. Груда в несколько десятков сантиметров», – вспоминает Джонсон. Сама мысль о таком количестве бумаги вызывает во мне чувство сострадания ко всем, кто потратил, должно быть, многие недели своей жизни на подготовку документов, не содержащих никакого смысла. Ни ФБР, ни Lockheed Martin в этом не одиноки – подобную картину я наблюдал практически в каждой компании, с которой имел дело. Эти высоченные бумажные штабели, воплощающие тщету человеческих усилий, отлично демонстрируют, как сильно Scrum может изменить жизнь людей. Никто не должен тратить свое существование на бессмысленную работу. Такая практика вредна не только для дела – она опустошает душу.

Итак, распечатав кипу документов, Джонсон и Фулгэм прошлись по ним, стараясь выяснить, какие задачи сложнее других и особенно важны для дела. Определить приоритет каждого запроса было необходимо, поскольку часто утверждается, будто существенно все. При таком подходе не мешало бы задать себе вопрос, который поставила перед собой команда проекта «Страж»: что сможет повысить эффективность работы и ее ценность? Найдя, что именно, этим и следует заняться в первую очередь. В сфере разработки программного обеспечения есть правило, подкрепленное десятилетиями исследований: восемьдесят процентов успеха и ценности любой программы заложены в двадцати процентах ее функциональных возможностей. Вспомните, когда в последний раз вам понадобилась в Microsoft Word функция Visual Basic? Возможно, вы даже не знаете, что есть такой редактор, как Visual Basic, не говоря о том, чтобы им пользоваться. Тем не менее эта функция есть, и кто-то потратил время на ее разработку. Уверяю вас, она не слишком сильно увеличивает ценность текстового редактора Word.

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

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

В ФБР утверждают, что для завершения проекта «Страж» они прибегнут к «гибкой методологии разработки», то есть будут использовать меньшее количество сотрудников самого ФБР и Lockheed Martin, а также компаний, поставляющих основные стандартные компоненты для системы «Страж». В общей сложности ФБР планирует сократить число привлеченных по контракту специалистов, задействованных в разработке «Стража», приблизительно с двухсот двадцати человек до сорока. В ФБР сообщили, что количество сотрудников ФБР, принимающих участие в работе над проектом, тоже уменьшится с тридцати до двенадцати… ФБР уверило нас, что предполагает завершить проект за двенадцать месяцев с момента внедрения нового подхода, не выходя за рамки оставшихся в бюджете проекта двадцати миллионов{3}.

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

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

Прежде всего, крайне важно, чтобы участники группы выяснили причину, мешающую ускорять процесс разработки. Как выразился Джефф Джонсон, «Я разобрался с устранением препятствий». Представление о «препятствии» зародилось в Toyota – компании, в которой впервые были сформулированы многие идеи, заложенные потом в основу Scrum. Строго говоря, я имею в виду Производственную систему «Тойоты», созданную Тайити Оно.

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

Не будет преувеличением сказать, что в периоды медленного роста потери являются в большей степени преступлением перед обществом, чем просто коммерческими потерями. Устранение потерь должно быть первой целью бизнеса{4}[6].

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

Джефф Джонсон осознавал, что препятствия станут его проблемой.

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

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

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

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

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

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

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

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

В конечном счете, прежде чем удалось внедрить «Страж» – систему управления базами данных – в работу ФБР, понадобилось восемнадцать месяцев на кодирование программы и доводку программного обеспечения. Еще два месяца ушло на то, чтобы ею начали пользоваться все сотрудники Бюро. «На нас невероятно давили сроки. И вы должны понимать: система охватывает абсолютно все. Оплата осведомителей. Архивы данных. Материалы следственных дел. Графики мероприятий. Нашу с вами встречу тоже внесли в систему “Страж”», – сказал Джонсон в интервью.

– Что, на ваш взгляд, является наиболее сильной стороной в методологии Scrum? – поинтересовался я у него.

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

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

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

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

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

Джефф рассказал своей команде, что когда он учился в Аннаполисе[8], то их, морских кадетов, заставляли учить наизусть отрывок из речи Теодора Рузвельта «Позиция гражданина республики», произнесенной им в 1910 году в Сорбонне. Возможно, эта речь вам знакома, так как ее часто цитируют:

Наши симпатии принадлежат не скептику, который вновь и вновь просчитывает варианты; не тому, кто указывает нам, где оступился герой, или рассказывает, где лидер мог бы сделать лучше. Наша вера и хвала возносится к тем, кто действительно в центре событий, чье лицо обезображено грязью, потом и кровью; кто храбро сражается и по-настоящему страдает; кто, ошибаясь, вновь и вновь преодолевает преграды и приближается к истине; потому что не может быть попыток без ошибок и препятствий; но именно такой человек искренне страдает ради свершения; он обладает потрясающим энтузиазмом, рвением и способностью жертвовать собой; он не жалеет себя и тратит свою жизнь на то, что стоит таких усилий; кто в случае победы удостоится славы и почестей высших достижений, а в случае поражения по крайней мере проиграет храбро и бесстрашно, и его место будет никак не среди тех холодных и робких душ, не знающих ни побед, ни поражений{5}[9].

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

«Все получилось в одночасье, – вспоминает Джефф Джонсон. – Любое преступление, совершенное в Лос-Анджелесе, могло оказаться связанным с чем-то произошедшим в Чикаго. И так по любому уголовному делу, любому расследованию террористической деятельности. Мы не могли допустить ни одной потерянной ориентировки. По всем пунктам мы должны были отрабатывать гарантированно чисто и без просчетов».

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

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

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

Группа, обслуживающая систему «Страж», до сих пор сидит в подвале здания ФБР, только убрали перегородки между столами, чтобы можно было видеть друг друга. На стене висит огромный плакат с текстом «Манифеста гибкой методологии» – принципов, в создании которых я участвовал и посвятил всю свою жизнь их реализации во многих странах. Рядом с входом под лампой дневного света стоит горшок с лавандой – странно видеть ее буйное цветение в комнате без окон. «Лаванда» было кодовым названием прототипа программного обеспечения системы управления следственными делами. Разработчики и по сей день трудятся над созданным ими «Стражем», вносят исправления и дополнительные новые функции.

Среди адептов методологии Scrum весьма распространен старый анекдот о курице и свинье.

Курица и свинья идут по дороге.

– Слушай, Свин, я тут подумала, не открыть ли нам с тобой ресторан? – говорит курица.

– А какое название дадим? – спрашивает свинья.

– Как тебе «Яичница с беконом»?

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

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

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

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

Мы это знаем – и каждый обыватель в отдельности, и общество в целом. Мы видим, как наша реальная жизнь эхом отзывается в произведениях на «офисную тему», будь то рожденный из комикса мультфильм «Дилберт» (Dilbert) или комедия «Офисное пространство» (Office Space). Мы все, приходя домой, рассказываем своим близким, каким безумием оборачивается эта хваленая современная «корпоративная культура». Нам всем твердят, что оформление документов важнее, чем выполнение работы, что необходимо собрать заседание для подготовки предварительного совещания, на котором будет обсуждаться, как проводить основное собрание. Это ли не помешательство? Тем не менее мы продолжаем так трудиться. Даже в предчувствии грандиозного провала.

Наглядный тому пример – история ресурса Healthcare.gov, на котором каждый американец мог бы выбрать из множества предложений удобную для себя программу медицинского страхования. Фасад проекта был прекрасен. Пользовательский интерфейс – умный, удобный, с отличным дизайном. При помощи Scrum работу завершили за три месяца. Начинка – вот в чем таилась угроза. Серверное приложение просто не работало. А ему полагалось служить для связи базы данных Министерства здравоохранения и социальных служб США с базами данных самых разных государственных учреждений и страховых компаний. Это очень сложная часть проекта, на которую задействовали более двадцати подрядных организаций, причем каждый коллектив разработчиков трудился над отдельной задачей, а общее планирование всей работы осуществлялось каскадным методом. Апробацию сайта отнесли на несколько последних дней работы над проектом, вместо того чтобы регулярно по ходу работ проводить инкрементальное тестирование[10].

Несчастье в том, что все исполнители, боясь рисков, проявляли крайнюю осторожность. Специалистов, работавших на подрядчиков, нельзя назвать ни бестолковыми, ни необразованными; но они были осмотрительными и просто перестраховывались. Без исключения каждый из них думал: «Не мое дело», – именно в этом я вижу суть проблемы. Нанятые организации передавали заказчику свою часть работы и на этом успокаивались. Они оценивали сайт с точки зрения профессионалов, ни разу не взглянув на него глазами простого пользователя. Причина такой несогласованной работы в том, что они не были охвачены единой целью. Специалисты должны трудиться сплоченным коллективом, только тогда они смогут осуществлять грандиозные проекты. Ради этого Scrum объединяет рабочие группы. Причем важно не только общее видение конечной цели, но и наличие интенсивного поступательного продвижения к ней. Среди тех, кто отвечал за ресурс Healthcare.gov, не нашлось никого, кто настоял бы, чтобы программа тестировалась в процессе ее создания. Ошибки накапливались, и, к сожалению, сайт не избежал общей участи. Однако появились профессионалы, устранившие все препятствия, мешавшие проекту Healthcare.gov. Кто они? Люди, использовавшие Scrum.

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

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

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

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

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

Подведем итоги

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

• Проверять и адаптироваться. Регулярно наблюдайте за ходом работ и последовательно выясняйте: справляетесь ли вы с заданием; можете ли вы выполнять его лучше и интенсивнее.

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

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

Глава вторая Истоки и рождение Scrum

Для американских военных летчиков срок службы во Вьетнаме отмерялся ровно сотней выполненных боевых вылетов. Над вражеской территорией была сбита половина нашего летного состава. Некоторых удавалось спасти, но большинство так никогда и не вернулись домой. Через несколько лет после начала войны, в 1967 году, меня, еще совсем неопытного пилота, перевели из Маунтин-Хоум, авиационной базы военно-воздушных сил в штате Айдахо, в Северный Таиланд, на авиационную базу Удорн Королевских военно-воздушных сил Таиланда. Мне пришлось выполнять самые опасные задания ВВС США – разведывательные полеты.

Это было задолго до появления беспилотников Predator и надежных спутниковых снимков. На своем самолете RF-4C Phantom, лишенном какого-либо вооружения и оснащенном лишь камерами и дополнительным топливным баком, я пролетал над территорией противника до и после наших бомбардировок, чтобы штурман мог делать сравнительные фотоснимки. Вылеты в основном проходили ночью; в тропической темноте мой самолет стремительно шел над землей – так низко, что чуть не срезал верхушки деревьев. В тот момент, когда я пересекал границу с Северным Вьетнамом, индикатор на лобовом стекле начинал мигать, словно игровой автомат для пинбола, тут же раздавалось яростное пищание и свист системы предупреждения. Небо вспыхивало от яркого свечения трассирующих зенитных снарядов, и я понимал, что через считаные минуты ракета с радиолокационной системой наведения обнаружит мой самолет, если только высота в полторы сотни метров не окажется достаточно малой, чтобы нам оставаться в зоне помех от земной поверхности.

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

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

В те годы я был всего лишь молодым военным летчиком, мечтающим налетать свою «сотню» и умудриться уцелеть. Полученная подготовка, летный опыт и профессиональный навык молниеносно принимать решения в смертельно опасных ситуациях – я понятия не имел, что все это в будущем сформирует мой подход к работе, которого я буду придерживаться всю свою жизнь. Я прибыл во Вьетнам в 1967 году вместе с двумя эскадрильями истребителей F-4 и двумя разведывательными самолетами RF-4C. Наша группа сменила две эскадрильи RF-101, в которых за год из пятидесяти самолетов остались несбитыми четыре машины. Правда, фюзеляжи последних были так изрешечены пулями и осколками, что летать на них уже никто не решался. Не представляю, как летчики вообще смогли посадить их. Истребители RF-4C оказались более жизнестойкими и надежными, однако и мы в течение года потеряли пятьдесят процентов своих машин. Наша выживаемость в воздушных боях имела хорошие показатели, но все равно половина летчиков, приехавших вместе со мной, не вернулись на базу. Кого удалось найти в джунглях и спасти прежде, чем они попали в тюрьму к вьетнамцам, – те были счастливчиками.

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

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

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

Когда во времена Рейгана правительство США резко сократило финансирование научных исследований, пострадала исследовательская программа, которая проводилась несколькими Национальными онкологическими центрами, в том числе Онкологическим центром Колорадского университета, где я, согласно своему гранту, был главным исследователем, то есть отвечал за сбор и анализ данных для клинических испытаний и эпидемиологических обследований[11]. Пока я гадал, что делать дальше, мне позвонили из MidContinent Computer Services – компании, обслуживающей 150 банков по всей Северной Америке. Они слышали обо мне как о ведущем эксперте именно в той области новых технологий, которой они занялись. Свежайшим направлением MidContinent стала разработка сети устройств, названных ими банкоматами. Происходило описываемое событие в 1983 году, когда снять деньги со счета можно было только следующим образом: выстоять очередь в банке или подъехать на машине к специальному уличному окошку, выписать чек на получение нужной суммы наличных, вручить чек кассиру.

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

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

Чтобы разобраться в положении дел, пришлось потратить некоторое время. Можете представить, как высшее руководство относилось к тем парням, ставшим теперь моей командой. Было много крику, попыток контролировать каждый шаг, проявлений пассивно-агрессивного поведения[12], требований проявлять максимум усердия и отдавать проекту еще больше личного времени. Но как бы ни давило руководство, разработчики неизменно затягивали сроки сдачи, продолжали непомерно расходовать бюджетные средства – и не достигать желаемых результатов.

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

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

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

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

Берите пример с робота

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

Я получал подлинное удовольствие от работы в MidContinent, но на этапе решения новых задач мне не терпелось испытать давно приобретенные навыки. В течение последующих двух десятилетий, где бы мне ни приходилось занимать пост технического директора: в больших корпорациях или маленьких фирмах, – я старался сделать так, чтобы группы начинали сотрудничать наиболее эффективным способом. Одна из таких компаний, в которой я работал, находилась в городе Кембридже штата Массачусетс, буквально в паре кварталов от МТИ – Массачусетского технологического института[13]. В описываемое время несколько его ученых и преподавателей создали фирму по производству роботов, но в университетской лаборатории для них не хватило места. В результате они стали арендовать помещение у нашей компании.

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

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

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

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

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

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

– Не знаю. Почему бы не попробовать? Потом расскажете, что из этого вышло, – ответил он.

Не ныряйте в водопад

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

Моя встреча с Родни Бруксом произошла более двадцати лет назад. На протяжении длительного времени он был главой направления робототехники и искусственного интеллекта в МТИ, а тот паукообразный робот, по кличке Чингисхан, тогда вбежавший в мой кабинет, теперь в качестве экспоната находится в музее Смитсоновского института. Вероятно, вам знакома одна из сегодняшних компаний Брукса – iRobot, которая выпускает пылесосы Roomba. Для чистки ваших полов используется тот же принцип адаптивного интеллекта, что заставлял Чингисхана гонять меня вокруг стола. Новейшая разработка Брукса – производственный робот Бакстер, созданный в компании Rethink Robotics, – может взаимодействовать с людьми и трудиться с ними в одном пространстве.

Меня всегда вдохновляла работа Брукса. Поэтому, когда в 1993 году я был приглашен в компанию Easel на должность вице-президента по объектной технологии, то решил руководствоваться его идеями. Управляющие хотели, чтобы моя группа разработала абсолютно новую линейку программных продуктов, ориентированных на самых крупных клиентов, таких как, например, Ford Motor Company, покупавших программное обеспечение Easel, чтобы проектировать и производить собственные приложения. На весь проект нам выделили шесть месяцев. Я собрал своих компьютерщиков и заявил им, что, без всяких сомнений с моей стороны, они не справятся с заданием, если начнут старым путем управлять разработкой программного обеспечения.

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

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

– Со сколькими диаграммами Ганта вы сталкивались за свою профессиональную деятельность? – спросил я.

– С сотнями, – сказал он.

– Сколько из них соответствовали действительности?

– Ни одна, – ответил он, на минуту задумавшись.

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

Мы потратили не одну неделю, чтобы просмотреть сотни статей и книг по организации работы в команде. И вот однажды один из моих разработчиков принес статью, опубликованную в Harvard Business Review в 1986 году двумя японскими преподавателями экономики – Хиротака Такеучи и Икуджиро Нонакой. Статья называлась The New New Product Development Game («Разработка нового продукта. Новые правила игры»). Такеучи и Нонака проанализировали инновационную деятельность крупнейших транснациональных компаний, таких как Honda, Fuji-Xerox, 3M, Hewlett-Packard и некоторых других. Они утверждали, что традиционный последовательный подход к работе над проектами – так называемый каскадный тип процесса разработки, – в основе которого лежит система поэтапного планирования программ НАСА[14], безнадежно устарел. Ведущие компании мира, отказавшись от линейной модели, перешли на метод параллельных процессов разработки, который требовал скорости и гибкости исполнения. Многофункциональные проектные группы обладали полной автономностью и свободой принимать самостоятельные решения. Целеустремленность людей была связана с чем-то большим, чем просто с личными интересами. Они старались выйти за границы собственных возможностей. Над ними не довлел тотальный контроль руководства. Специалистам никто не диктовал, что делать и как поступать при разработке нового продукта. Напротив, управляющие высшего звена относились к своему лидерству как к служению, поскольку считали, что их основная задача – быть помощниками и устранять с пути своих команд все препятствия. Авторы сравнивали рабочий процесс при новом подходе с игрой в регби, где лучшие команды всегда выбирают тактику «схватки», группируясь вокруг мяча: «…Мяч передается внутри команды, в то время как она движется по полю словно единое целое»{6}.

Появление статьи «Разработка нового продукта» стало настоящей сенсацией, но она вышла за семь лет до того, как мы собрались в компании Easel. Тогда, семь лет назад, прочитав ее, все пришли в восторг, но никто ничего не предпринял. Среднестатистический руководитель американской компании не сумел должным образом ни оценить ее, ни даже постичь ее смысл; вряд ли на его косное сознание могли повлиять даже блестящие показатели Toyota, увеличившей свою долю на рынке за счет целостного подхода в духе тактического приема схватки в регби. Нам в Easel терять было нечего. Мы решили рискнуть, несмотря на то что концепция авторов была рассчитана на производственный процесс, а не на разработку программного обеспечения. Однако я сразу понял: принципы Такеучи и Нонаки предназначены для чего-то более фундаментального: с их помощью можно выстроить оптимальную модель совместного труда при любом начинании в любой области человеческой деятельности. Метод, предложенный японскими учеными, носил скорее дескриптивный характер[15], поэтому он идеально подходил ко всем экспериментам, которые мне предстояло проводить в будущем, и возвращал меня мысленно к компании MidContinent Computer Services – моему первому опыту работы в частном секторе.

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

Я загорелся возможностями новой формы управления проектами до такой степени, что вся моя будущая работа сконцентрировалась на доработке Scrum для внедрения этой методологии в различных компаниях. Через несколько лет, в 1995 году, на научной конференции Ассоциации вычислительной техники мы с Кеном Швабером представили доклад SCRUM Development Process («SCRUM – методология процесса разработки»), в котором постарались систематизировать основные правила нашего нового подхода к работе{7}. Позже мы отказались от прописных букв в названии и внесли некоторые поправки в концепцию, но основные принципы остались неизменными. Компании, которые решаются применять их в своей практике, обычно незамедлительно извлекают максимальную выгоду.

Проверять и адаптироваться

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

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

Как мы поняли, методология Scrum берет начало в организационных приемах, которые впервые были применены на японских предприятиях, поэтому имеет смысл выяснить, как сами японцы научились так работать. По иронии судьбы обучал их американский ученый. Уильям Эдвардс Деминг был приглашен в послевоенную Японию генералом Дугласом Макартуром, занимавшим пост главнокомандующего союзными оккупационными войсками. Подход Макартура к переустройству японской экономики заключался в том, чтобы очистить большие компании от старых руководителей, выдвинуть молодых и привести в экономику таких американских специалистов, как Деминг. Влияние Деминга на японское производство было огромным. Он обучил сотни инженеров системе статистического управления процессами. Приведу несколько основных положений философии Деминга: точно измерять объем всего, что делается; контролировать, насколько хорошо все делается; стремиться к непрерывному улучшению. Причем недостаточно единожды изменить процесс в лучшую сторону – следует безостановочно улучшать систему и совершенствоваться самому. Постоянно искать то, что нужно корректировать. Никогда не останавливаться на достигнутом. Добиться этого можно только одним путем: неутомимо экспериментировать, опробовать разные подходы. Станет ли лучше, если я применю такой способ? А как насчет этого? Что будет, если я изменю лишь одну деталь?

В июле 1950 года прозвучала одна из самых блестящих его лекций, обращенная к сидевшим в зале руководителям ведущих японских компаний; например, среди слушателей был основатель Sony Акио Морита. В частности, Деминг сказал:

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

Американский ученый предложил свою модель управления качеством, которую в итоге восприняла вся японская экономика, – это цикл Деминга, или цикл PDCA (Plan–Do–Check–Act «Планировать, действовать, проверять, корректировать»). Этот метод можно применять к производству абсолютно всего – будь то автомобили, видеоигры и даже, черт побери, бумажные самолетики.

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

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

Пройдите эти циклы трижды, и я вас уверяю: чем бы вы ни занимались – складыванием бумажных самолетиков или конструированием космических кораблей, – вы будете выполнять свою работу значительно лучше (в два-три раза быстрее и как минимум в два раза качественнее). Цикл PDCA – наиболее прогрессивная модель управления в те времена, когда американский ученый внедрял ее в экономику Японии, – в итоге привел к тому, что Toyota стала выпускать лучшие автомобили в мире. На принципах Деминга построены такие управленческие схемы, как производственная система компании Toyota, как концепция бережливого производства, которая является американским аналогом японской модели, и конечно, наша методология Scrum.

Измениться или умереть

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

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

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

Сюхари

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

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

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

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

Состояние Ри («отделяться») – третья ступень, когда вы настолько овладели мастерством, что освобождаетесь от приемов и движений; теперь вы выше всех правил и способны беспрепятственно созидать. Айкидо или танго стали вашей сутью, и в каждом вашем шаге заложен их смысл.

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

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

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

Подведем итоги

• Сомнение смерти подобно. Наблюдать, ориентироваться, решать, действовать. Определите, где вы находитесь, осознайте имеющиеся варианты, сделайте выбор и действуйте!

• Искать ответы вокруг себя. Сложные адаптивные системы следуют нескольким простым правилам, ориентируясь на окружающую среду.

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

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

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

Глава третья Команды

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

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

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

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

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

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

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

Я вырос недалеко от Бостона и живу там по сей день, поэтому, когда завожу разговор о легендарных коллективах, на ум сразу приходят две великие команды: «Бостон Селтикс» эпохи восьмидесятых и «Нью-Ингленд Пэтриотс» поколения Тома Брэди[16]. Когда спортсмены этих двух клубов выходили на поле, складывалось впечатление, будто они ведут какую-то другую игру – не ту, в которую играют все остальные. Скорость летящего мяча, напор атаки, мощность защиты – весь стиль игры, раньше казавшийся немыслимым, становился общей стратегией поведения на поле. Выглядело так, словно на игроков снизошла благодать и они просто не имеют права на ошибку. Лари Бёрд двигался по баскетбольной площадке и передавал мяч не глядя – туда, где, казалось, никого не было; но стоило мячу отправиться в свободный полет, как Кевин Макхейл буквально возникал из ниоткуда именно там, где он должен был быть, и выполнял передачу вбок, тоже, казалось, не глядя куда; его мяч брал Роберт Пэриш, оказавшись именно там, откуда лучше всего было делать решающий бросок[17]. Абсолютная уверенность игроков друг в друге, полная согласованность действий и целей – вот что представляет собой величие.

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

Выясняется, что ответ положительный.

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

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

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

3. Многофункциональность. В лучшие команды входят специалисты по планированию, разработкам, производству, продажам и распространению, поэтому группы обладают всем необходимым, чтобы трудиться над проектом от первого до последнего этапа. В командах культивируется атмосфера взаимодействия, поддержки и понимания. Вот как описал такую обстановку участник проектной группы компании Fuji-Xerox, работавшей над принципиально новой моделью ксерокса: «Когда все члены команды находятся в одной большой комнате, то вам дана возможность без всяких усилий пользоваться знаниями и информацией, которыми владеют коллеги. Тогда вы начинаете мыслить совсем другими категориями. Вас волнует работа не только в том случае, когда она касается непосредственно ваших интересов, нет, вы думаете, что пойдет на пользу всей группе и общему делу – причем и в первую, и во вторую, и прочую очередь»{9}.

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

Серая шеренга

Мысленно возвращаюсь в прошлое, к началу 1960-х годов, когда мне выпало счастье быть в такой команде. Меня, кадета последнего курса Вест-Пойнта, назначили офицером-инструктором моей роты L2, мы ее еще называли «свободной парой»[18]. В тот год в Вест-Пойнте было двадцать четыре роты: от A1 до M1 и от A2 до M2. Три раза в неделю все роты выходили на плац и маршировали. Парадная форма с белым ремнем, полная амуниция, с одной стороны винтовка, с другой – сабля. Эти парадные построения были в академии настоящим состязанием с почти двухсотлетней традицией, и к 1963 году наша рота L2 вот уже больше ста лет плелась в самом хвосте.

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

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

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

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

Наиболее чтимым выпускником Вест-Пойнта считался генерал Дуглас Макартур. У него были самые высокие оценки за всю историю академии, он прошел обе мировые войны, причем первую закончил в звании бригадного генерала, а вторую – в звании генерала армии.

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

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

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

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

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

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

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

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

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

– Та рота. Она еще шла предпоследней… Чем-то она отличалась от остальных. Все маршировали, а эти как будто парили. Кто они такие? – спросил меня мой будущий тесть.

– Моя рота. Эти люди недавно хоронили генерала Макартура, – ответил я.

Моя рота достигла совершенства.

Scrum на площади Тахрир

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

Площадь Тахрир, ставшая синонимом революции в Египте и дальнейшей борьбы, продолжающейся и поныне, до января 2011 года была всего лишь одной из площадей центрального района Каира – грязной, людной и перегруженной транспортом из-за круговой развязки. Вы найдете к северу от нее розовое здание Египетского музея, к югу – стены Американского университета Каира и знаменитое правительственное здание «Могамма»[19], к востоку – штаб-квартиру Национальной демократической партии египетского диктатора Хосни Мубарака и здание Лиги арабских государств. По причудливому стечению обстоятельств там же, в восточной части площади, расположился, кто бы мог подумать, «Жареный цыпленок из Кентукки» – кафе, которое станет тылом для протестующих, теснящих полицию и бросающих в нее камни.

В конце января 2011 года небольшая группа активистов решила устроить на островке безопасности в центре кругового движения демонстрацию против жестокого убийства египетской полицией молодого человека по имени Халид Саид. Очередная маленькая акция протеста против режима стал искрой, воспламенившей умы египтян, и в результате на площадь вышли миллионы. В следующем месяце произошло то, чего никто не мог вообразить: из-за того что люди пришли и сказали «нет», пала одна из старейших и мощных диктатур Ближнего Востока. Протестующие собирались изо дня в день, ночь за ночью, заполняя собой площадь, и создавали новую страну, которой не правит диктатор Хосни Мубарак и где граждане смогут свободно говорить все, что думают. Эти люди изменили свой мир.

Происходящее в Египте имело грандиозное историческое значение и привлекло внимание всего журналистского сообщества. Среди приехавших в Каир была и бригада National Public Radio («Национальное общественное радио») – одного из ведущих американских средств массовой информации. На первом этапе группа с трудом удовлетворяла требованиям своего вашингтонского руководства. Ситуация развивались так стремительно, что слегка оторопевшие продюсеры и репортеры не успевали подготавливать материалы в срок и упускали нужные сюжеты. Дабы исправить ситуацию, в Каир отправился Джей Джей Сазерленд, кстати, мой сын. Выбор пал на него, поскольку у Джей Джея был многолетний опыт работы продюсером и корреспондентом в зонах боевых действий. События приобрели слишком большие масштаб и значимость, чтобы не быть в ежедневном эфире и не присутствовать в каждой новостной программе. Джей Джей попал в страну, в которой были закрыты аэропорты, откуда тщетно пытались уехать иностранцы, где не работали сотовые телефоны и интернет. Он был назначен старшим продюсером, то есть являлся, по сути, посредником и организатором, как и я когда-то в должности офицера-инструктора в Вест-Пойнте. Продюсер NPR – не управляющий в буквальном смысле слова, он скорее помощник и снабженец. Задача Джей Джея заключалась в том, чтобы помогать команде трудиться как можно лучше. Не указывать им, что делать, а поддерживать их и снабжать всем необходимым для работы. Команда должна была по приказу руководства собирать информацию и выходить в эфир несколько раз в день, однако могла на месте решать, каким образом выполнять задачи, самостоятельно выбирать сюжеты и формат вещания.

Как ни странно, но группе удалось успешно работать благодаря отсутствию прямого управления из Вашингтона. Специалисты NPR оказались полностью предоставлены самим себе. Поскольку события развивались с огромной скоростью, а мобильной связи с руководством компании установить не удавалось, поэтому – чтобы работа шла безостановочно – участникам группы пришлось научиться самоорганизовываться. Один из основных принципов Scrum гласит, что члены команды самостоятельно решают, как они будут выполнять свое дело. Руководитель отвечает за постановку стратегических целей, но решение, каким путем достигать этих целей, принимает команда. У тех, кто не находился в Каире на месте событий, не было ни одной возможности даже просто следить за происходящим. В ежедневном режиме команда NPR анонсировала сюжеты на следующий день вещания, но их информация, как правило, моментально устаревала. На площади происходило крупное столкновение, кто-то выступал с неожиданным заявлением, кто-то подавал в отставку, кто-то бежал из страны – и оказывалось, что вся работа проделана впустую. Они судорожно старались передать в эфир вовремя хоть какую-нибудь информацию. Вечная спешка диктовалась еще и сжатыми сроками подготовки. Группа должна была подавать материал дважды в день с разницей в двенадцать часов: к передачам «Утренний выпуск» (Morning Edition) и «Принимая все во внимание» (All Things Considered).

Все пошло легче, когда команда обратилась к методологии Scrum. В ходе каждого цикла подготовки информации Джей Джей совещался с членами группы и задавал им три очень простых вопроса: «Чем вы занимались с момента нашего прошлого разговора?», «Что вы собираетесь делать до нашего следующего разговора?» и «Что вам мешает в вашей работе?». Эти вопросы – представляющие собой стандартную процедуру Scrum – заставляли корреспондентов делиться друг с другом информацией. Главная задача Джей Джея, фактически выступавшего как скрам-мастер, состояла в том, чтобы все помехи, о которых говорилось на последней встрече, к следующей были устранены. Препятствием могло быть абсолютно все: египетская бюрократия; невозможность получить безопасный номер в гостинице; отсутствие водителей; нехватка переводчиков; необходимость вытаскивать корреспондентов из застенков «Мухабарата» – печально известной Службы общей разведки Египта.

Справилась ли группа со своими проблемами? Скажем так: помехи, имевшие отношение к элементарному бардаку, личным конфликтам и простым сбоям в оперативном поиске информации, были устранены довольно быстро. Коллектив стал работать как отлично отлаженный механизм, который совсем не нуждался во внешнем управлении. Члены команды научились справляться с организацией своей работы самостоятельно. Бригада NPR подготовила огромное количество передач из Каира – еще несколько недель назад о таком прорыве никто даже помыслить не мог. Качество их репортажей было выше, чем у конкурентов. В итоге за свою работу команда получила ряд профессиональных наград. Это был настоящий успех. Вряд ли репортеры и продюсеры смогли бы его добиться, если бы у них не появилось, во-первых, понимание общей цели (освещать, может быть, самое большое событие, случившееся за их профессиональную деятельность), во-вторых, режима полной автономности (возможность принимать самостоятельные решения во время подготовки информационного материала и выбора сюжетов для своих репортажей).

Сегодня в National Public Radio применяют Scrum на всех уровнях работы: при проектировании веб-приложений; в журналистике данных, когда приходится прибегать к специальным программам, чтобы обрабатывать большие информационные массивы; для создания новых радиопрограмм. Методологией Scrum начали пользоваться коллективы Chicago Tribune, New York Times, Washington Post и ProPublica. Когда речь идет о жестких сроках, скорость просто необходима.

Одной командой – от начала и до конца

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

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

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

Утомляет даже писать об этом. Однако дела в НАСА велись именно так.

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

Строго говоря, случившаяся в 1986 году катастрофа при запуске «Челленджера» стала бесспорным подтверждением этому. Для расследования крушения шаттла была создана специальная комиссия под руководством Уильяма Роджерса, которая пришла к такому же выводу. В работе комиссии принял участие выдающийся физик Ричард Фейнман. Его доклад опубликован в отчете комиссии, правда, не в основном его корпусе, а в приложении. Приведу лишь несколько строк из его особого мнения:

Может оказаться, что для любой цели, для внутреннего и внешнего потребления, руководство НАСА преувеличивает надежность своего продукта до фантастических цифр{12},[20].

Факт остается фактом: лучшие коллективы работают иначе. Ни в Toyota или 3M – чей пример вдохновил в свое время Такеучи и Нонаку, – ни в современных Google, Salesforce.com или Amazon мы не найдем подобного «разделения труда». В таких компаниях любая самая маленькая рабочая группа делает все от начала и до конца.

Никола Дурамбе является вице-президентом по вопросам гибкой инфраструктуры релизов Salesforce.com – компании, которая стабильно держится в списках ста лучших работодателей по версии журнала Fortune и лучших инновационных компаний мира по версии журнала Forbes. В зоне ответственности Дурамбе около двух сотен скрам-команд. Она говорит, что внедрение Scrum стало ноу-хау их компании: «Пока мы были стартапом, то выпускали крупный новый продукт три-четыре раза в год. Мы росли и расширялись, но управляли проектами стандартным каскадным методом, и показатель снизился до одного в год. С этим нужно было что-то делать. И вот мы ввели Scrum. С тех пор релизы у нас бывают не реже трех раз в год. Не так много крупных компаний могут похвастаться таким результатом».

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

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

Scrum во время боевых действий

Пожалуй, самое убедительное доказательство того, насколько необходима многофункциональность коллективов, дает нам пример службы в армии. Cилы специального назначения Армии США могут действовать только на основе принципа универсальности. Стандартная боевая единица армейского спецназа – оперативный отряд «Альфа» (команда «А»). В его состав входит двенадцать военнослужащих: командир в звании капитана, назначаемый командованием; уоррент-офицер – заместитель командира; сержант, руководящий повседневной деятельностью отряда; сержант – специалист по разведке; два сержанта – специалисты по вооружению специального назначения; два сержанта – инженеры-саперы; два сержанта медицинской службы; два сержанта – специалисты по связи. Каждая команда «А» сформирована таким образом, чтобы все ее члены были разносторонними мастерами боевой подготовки, что позволяет им выполнять операции от начала до конца. Бойцы спецназа постоянно проводят обучение взаимозаменяемости по нескольким специальностям. Команда должна быть уверена, что если убьют обоих медиков, то, скажем, специалист по связи сможет оказать первую медицинскую помощь раненому товарищу. Существенная особенность, отличающая работу спецназа от действий «обычных» армейских сил, заключается в том, что «зеленые береты» самостоятельно выполняют и сбор разведывательных данных, и планирование операций. В их практике не допускается передача эстафетной палочки от одного подразделения другому – ведь именно в таких «швах» таится слабое место, из-за которого возникают ошибки. А спецназу не нужны поражения вроде катастрофы «Челленджера». Между всеми членами команды – теми, кто собирает разведывательные данные, кто разрабатывает план операции и кто, рискуя собственной жизнью, будет ее проводить, – налажен непрерывный обмен информацией. В результате отряд «Альфа» работает как одно взаимосвязанное целое.

Во время войны в Ираке армейский спецназ доказал, что действует как абсолютно слаженный и совершенный механизм, предназначенный убивать. «Зеленые береты» за 2003–2007 годы осуществили тысячи успешных операций, целью которых было подорвать иракское сопротивление, особенно деятельность «Аль-Каиды». И в оперативно-тактическом отношении они почти всегда успешно выполняли свои задачи: выслеживали группировки боевиков и в ту же ночь устраняли их. Универсальные, блестяще обученные подразделения «зеленых беретов» вошли в число наиболее смертоносных сил, когда-либо существовавших в мире. Но ни отличная подготовка, ни изощренное мастерство, ни высокий профессионализм спецназа не оказали стратегического влияния на ведение войны. За первые четыре года боевых действий и по американским войскам, и по мирному населению неослабно наносились удары, причем количество их возрастало с каждым днем. В самые тяжелые периоды можно было насчитать более ста ежедневных столкновений – и даже всесокрушающая сила американского спецназа не могла сдерживать атак боевиков. Голоса, раздававшиеся против войны, особенно усилились к концу 2006 года, а в начале следующего практически каждый, кто разбирался в ситуации, считал Ирак безнадежным делом. Любая очередная смерть американского солдата воспринималась обществом как бессмысленная жертва. Поэтому в 2007 году США выработали новую стратегию своего пребывания в Ираке, которая получила название «Большая волна».

Осуществлять военный план назначили генерала Дэвида Петреуса. В Ирак был введен дополнительный контингент войск, исчислявшийся десятками тысяч военнослужащих, которые теперь должны были надолго оставаться рядом с местным населением в очищенных районах. Новая стратегия существенно повлияла на обстановку в стране. Во-первых, иракцы поверили в поддержку США, так как американская армия продолжала вести борьбу с теми, кто взрывал их мирные дома и проводил этнические чистки. Во-вторых, американское командование, заключив договор с племенными вождями о совместном противостоянии «Аль-Каиде», в коалиции с повстанческими движениями создало организацию «Сыны Ирака» для обеспечения безопасности в отдельных районах силами местного населения. В это ополчение, теперь регулярно получавшее деньги от США, вошли, по сути, десятки тысяч бывших повстанцев. В-третьих, у США имелось свое «секретное оружие», которое, по мнению Боба Вудворда[21], представляло собой совершенно революционное решение, по своему значению сопоставимое с изобретением танка и самолета.

Мы говорим не о хитроумной штуковине вроде электронного прицела или дрона новейшего поколения. Речь идет о методе ведения боевых действий. По словам генерала Стэнли Маккристала, в то время возглавлявшего Командование совместных (межвидовых) специальных операций, это «совместное ведение войны». Чтобы выявить и уничтожить сеть «Аль-Каиды» в сотрудничестве с силами самоообороны Ирака, США решили использовать всю мощь универсальных частей и подразделений спецназа, помноженную на могущество своего государственного аппарата. Для ясности приведу небольшой отрывок из статьи, написанной в сентябре 2008 года двумя старейшими журналистами Washington Post Джоби Уорриком и Робин Райт:

Центральное разведывательное управление – его специалисты по анализу разведывательных данных работают с информацией, собранной беспилотными летательными аппаратами, оснащенными датчиками и оптическими приборами; эти роботы-шпионы способны вести слежку за людьми, транспортными средствами и боевой техникой на протяжении четырнадцати часов. Федеральное бюро расследований – его эксперты-криминалисты препарируют любые данные, полученные в результате всех видов слежки за экстремистами: от их разговоров по сотовым телефонам до содержимого их карманов и бумажников. Министерство финансов – его аналитики отслеживают движение капитала, связанного с террористическими организациями и правительствами поддерживающих их стран. Агентство национальной безопасности – его сотрудники отвечают за сбор информации из коммуникационных сетей средствами радиотехнической и электронной разведки: они перехватывают телефонные разговоры, личную переписку и компьютерные данные. Национальное агентство геопространственной разведки – его специалисты благодаря высокотехнологичному оборудованию могут точно определить местонахождение подозреваемых в экстремистской деятельности по их сотовым телефонам и компьютерам{13}.

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

Прежде было так: от разведывательной организации требовалось установить объект, и только после его нахождения определяли конкретную задачу, которую ставили перед бойцами сил специального назначения; отряду спецназа в свою очередь полагалось передавать все собранные ими данные сторонней команде аналитиков. Работая по принципу «эстафетной» модели, разведывательные ведомства неизбежно сталкивались все с той же проблемой. Помните, как несколькими десятилетиями раньше Fuji-Xerox попробовала перенять систему поэтапного планирования программ НАСА и сразу категорически отказалась от нее? Именно тогда была впервые осознана необходимость создания новой методики, получившей чуть позже название Scrum. В любых коллективах, где практикуется подобная передача эстафетной палочки от одной команды к другой, возникает вероятность катастрофы. Об этом предупреждали в 2008 году авторы статьи Employing ISR: SOF Best Practices («Разведка, наблюдение и рекогносцировка в практике спецназа»), вышедшей в журнале Министерства обороны США Joint Force Quarterly:

Создание межведомственных групп особого назначения помогло устранить организационные «швы», существовавшие в деятельности разрозненных сил коалиции в Ираке[22]… Мы справились главным образом благодаря тому, что наш «немигающий глаз»[23] был нацелен на исключительно приоритетную цель… Распределение обязанностей между разными управлениями и организациями, перекладывание ответственности с ведомства на ведомство – все это приводит к появлению «слепых зон». В результате такой организационной несогласованности неизбежно падает динамика наблюдения – и объект может уйти от преследования{14}.

При любых обстоятельствах совсем непросто делиться человеческими ресурсами и осуществлять обмен информацией. Мне случалось видеть руководителей, которые буквально впадали в ступор, когда передавали специалистов в команду, не находящуюся под их прямым управлением. Добровольно отказаться от повседневного контроля над собственным коллективом, от постоянного вмешательства в мельчайшие детали выполнения работы – задача не из легких. В диверсионно-разведывательном сообществе, традиционно замкнутом на себе и скрытом от глаз, делать это оказалось особенно сложно – настолько, что, несмотря на эффективность групп особого назначения, действовавших в Ираке, их расформировали сразу, как политика «большой волны» была признана успешно завершенной. Суть дела изложена в блестящем труде Кристофера Ламба и Эвана Мансинга Secret Weapon: High-value Target Teams as an Organizational Innovation («Секретное оружие. Группы особого назначения как организационная инновация»):

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

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

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

Размер имеет значение – но это не то, о чем вы подумали

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

Всем, кто когда-либо занимался разработкой программного обеспечения, хорошо знаком принцип, впервые сформулированный в 1975 году в эпохальной книге Фреда Брукса The Mythical Man-Month («Мифический человеко-месяц»[24]) и потому названный «законом Брукса». Вот его крайне упрощенное изложение:

Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше{16}[25].

Истинность этого положения подтверждалась каждым последующим исследованием. Соотношение между сроком работы, ее объемом и количеством исполнителей – изучение этого вопроса стало делом жизни Лоуренса Путнэма, настоящей легенды в мире разработчиков программного обеспечения. Его исследования неизменно показывали, что проекты, на которых было задействовано двадцать и более человек, всегда требовали больших усилий, чем те, над которым работало меньше людей. Причем «больших» не чуть, а существенно. Многочисленной группе понадобится в пять раз больше времени, чем малочисленной. Получая одни и те же результаты, Путнэм в середине 1990-х годов решил провести всеобъемлющее исследование, чтобы окончательно определить, какой размер группы является оптимальным. Он проанализировал около пятисот небольших проектов (точное число – 491) в сотне с лишним компаний. Это были проекты, направленные на разработку новых программных продуктов или новых функций, а не на переориентирование уже существующих решений. Путнэм разделил проекты на категории в зависимости от размера групп разработчиков и сразу заметил одну вещь. С увеличением размера группы от девяти человек и выше возрастал как срок, так и объем работ. При одинаковом объеме работы для групп размером от трех до семи человек требовалось около 25 процентов усилий, которые затрачивали группы размером от девяти до двадцати человек. Подобная модель повторялась при разработке многих сотен проектов. Неопровержимость того, что многочисленный коллектив выполняет меньший объем работы, представляется чуть ли не железным законом человеческой природы.

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

Нельсон Коуэн из университета штата Миссури в 2001 году задался вопросом, на самом ли деле магическое правило семи соответствует действительности, и тщательно изучил новые изыскания на эту тему. Оказалось, что число объектов, которые человек может удерживать в краткосрочной памяти, не семь – четыре{17}. Люди часто думают, что могут запомнить больше, используя мнемонические приемы или просто сильнее сконцентрировавшись. Но исследования неуклонно показывают, что мы в состоянии запомнить за один раз лишь четыре фрагмента информации. Классический пример – предложить запомнить последовательность из двенадцати букв: fbicbsibmirs. Обычно людям удается удержать в памяти где-то не больше четырех букв – если только они не догадаются, что эту последовательность можно «разрезать» на четыре хорошо известные аббревиатуры: FBI, CBS, IBM, IRS[26]. Вы запоминаете больше, когда удается вытянуть из долгосрочной памяти соответствующие ассоциации. Но часть памяти, связанная с центром внимания, то есть ее сознательная часть, может удерживать единовременно не более четырех объектов.

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

Если вам нужно вычислить, как влияет размер группы, нужно взять число людей в ней, умножить его на «это число минус один» и разделить на два. Коммуникационные каналы = n (n – 1) / 2. Например, если в группе пять человек, то у вас десять каналов. Шесть человек – пятнадцать каналов. Семь человек – двадцать один канал. Восемь человек – двадцать восемь каналов. Девять человек – тридцать шесть каналов. Десять человек – сорок пять каналов. Наш мозг не в состоянии успевать за таким количеством людей. Мы не можем уследить, чем занимается каждый человек. Начинаем разбираться в этом – и теряем скорость работы.

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

Не поступайте так. Пусть ваши группы остаются малочисленными.

Скрам-мастер

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

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

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

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

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

Вините не игрока, а игру

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

Несколько замечательных исследований в этой области приведены в книге Induction: Processes of Inference, Learning, and Discovery[28] («Индукция. Процессы умозаключения, обучения и исследования»). Одна из таких работ была опубликована в начале 1970-х годов, так что идея не нова. Это старая история, которая повторяется снова и снова. Какова мотивация человеческих поступков?

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

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

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

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

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

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

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

Почти все продолжали и наносили последний удар током тому, кто кричал за стеной. После этого наступала тишина. Милгрэм подвел итог своих наблюдений в 1974 году в статье Perils of Obedience («Опасности повиновения»):

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

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

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

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

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

Первый пример – автомобильный завод компании New United Motor Manufacturing, Inc. (NUMMI), расположенный в городе Фримонте, штат Калифорния. Это было совместное предприятие General Motors и Toyota. Завод был закрыт GM в 1982 году. Руководство считало его работников худшими в США. Люди не являлись на работу, пили на рабочих местах и постоянно намеренно портили машины (например, оставляли внутри двери банку из-под кока-колы, которая громыхала и мешала покупателям). Toyota вновь открыла завод в 1984 году. Компания GM предупредила, что рабочие завода ужасны, но управляющие отличные и их стоит нанять снова. Вместо этого Toyota не спешила приглашать на работу старое руководство, а вот рабочих вернула почти всех, некоторых даже отправила в Японию изучать производственную систему Toyota. Завод NUMMI практически сразу стал собирать автомобили с той же точностью и таким же низким уровнем брака, как и в Японии. Люди остались теми же – поменялась система.

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

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

Достигнуть величия

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

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

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

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

Подведем итоги

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

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

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

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

• Побеждать малым количеством. Малочисленные команды работают быстрее, чем многочисленные. Правило номер один – семь участников плюс-минус два. Довольствуйтесь малым.

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

Глава четвертая Время

Время – главный ограничитель всех человеческих устремлений. Время имеет отношение ко всему: сколько мы работаем; как долго приходится заниматься разными вещами; насколько мы успешны. Неумолимый и необратимый ход времени формирует наше видение мира и нас самих. Британский поэт XVII века Эндрю Марвелл писал:

Коль Божий мир на больший срок

Нам щедрый выделил бы рок…

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

…Солнце сим Остановить нам не дано, Но пусть побегает оно{20}[29].

Однако как это сделать? Легко, зажигая толпу, кричать с трибуны: Carpe diem![30] – но как на практике осуществлять такой призыв? Огромный объем работы диктует людям, что надо сесть, согнуться в три погибели и приготовиться трудиться день и ночь. «Не думайте о внешнем мире, – говорят нам наши боссы. – Забудьте о детях, серфинге, кстати, и об ужине тоже, – просто работайте, работайте еще усерднее, и будет вам вознаграждение. Вы продвинетесь по службе. Заключите блестящую сделку. Завершите свой проект».

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

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

Спринт

В начале 1990-х годов Media Lab постоянно предлагала разнообразные интересные продукты. В те времена, когда зарождался интернет, они делали все: от роботов до электронных чернил, благодаря которым стали возможны современные электронные книги. Это была потрясающая эпоха. Я старался брать на работу студентов, прошедших эту лабораторию, поскольку они фонтанировали идеями, были способны делать невероятно крутые вещи, но самое главное – могли создавать их очень быстро.

Скоростью они были обязаны стратегии, которую Media Lab применяла ко всем своим проектам. Каждые три недели любая рабочая группа должна была демонстрировать коллегам, над чем она сейчас работает. Это был открытый показ, прийти посмотреть мог любой. И если выяснялось, что пробная версия не отличалась ни эффективностью, ни особой крутизной, руководство лаборатории проект закрывало. Немедленная критическая оценка работы была особенно важна – именно она заставляла студентов работать еще быстрее и создавать невообразимые вещи.

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

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

– Ладно, – сказал он. – А что тогда вы мне покажете?

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

– Отлично. Давайте так и сделаем, – ответил он.

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

Команда WIKISPEED – это группа компаний, основанная человеком по имени Джо и с удивительной фамилией Джастис[31]. Они производят автомобили. Машины, проезжающие более ста километров и тратящие менее трех литров топлива, допущенные к эксплуатации на автодорогах, получающие пять звезд на аварийных испытаниях, развивающие скорость до 225 километров в час и стоящие при этом дешевле Camry. WIKISPEED продолжает постоянно улучшать свой автомобиль. Если вам захочется его приобрести, то нужно лишь перечислить на их счет через сайт wikispeed.com двадцать пять штук – и через три месяца машина ваша. Как они достигла всего этого? Они освоили Scrum. Как многие лучшие на сегодняшний день команды, WIKISPEED работает, идя от одного недельного спринта к другому. Команда собирается каждый четверг. Разработчики просматривают объемный «бэклог спринта», то есть список отобранных задач, которые нужно решить: от разработки дизайна панели приборов до проверки работы поворотников. Они определяют приоритетность задач, а потом говорят, глядя на этот список: «Ну ладно, и сколько задач мы можем выполнить за эту неделю?» Под «выполнить» подразумевается действительно сделать – как следует и до конца. Новые функции работают. Машина ездит. Каждую неделю. Каждый спринт.

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

Впереди, в первом отсеке, стоит первый автомобиль, созданный командой WIKISPEED, – машина, принимавшая участие в конкурсе XPrize с призовым фондом в десять миллионов долларов, проводящемся среди автомобилей, расходующих на сто километров не более трех литров топлива. Команда WIKISPEED вошла в первую десятку, выиграв у сотни соперников из крупных автомобильных компаний и университетов. В результате они были приглашены в 2011 году на автосалон Detroit Auto Show, где их продукция была выставлена в первом ряду, между автомобилями Chevrolet и Ford. Теперь эта машина – их испытательный полигон для новых идей.

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

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

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

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

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

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

Ежедневные собрания на ходу

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

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

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

1. Что ты делал вчера, чтобы помочь команде завершить спринт?

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

3. Какие препятствия встают на пути команды?

Всё. Я хочу сказать, что на этом собрание заканчивается. Если на него уходит более пятнадцати минут, вы неправильно его проводите. Задача таких встреч в том, чтобы вся группа была в курсе, кто чем занимается в этом спринте. Все ли задачи будут выполнены вовремя? Есть ли возможность помочь участникам группы преодолеть помехи? Команда работает автономно – никто не распределяет задания сверху; они всё делают сами. Нет подробных отчетов руководству. Любой руководитель или член другой группы может зайти, взглянуть на скрам-доску группы, занимающейся авиационным оборудованием, и увидеть, что к чему.

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

Одним из таких людей, проведших годы в попытке разобраться, как все устроено в области разработок программного обеспечения, был Джим Коплиен, работавший в корпорации AT&T, в легендарном исследовательском центре Bell Labs. Коплиен, более известный как «Коп», на протяжении нескольких лет анализировал сотни программных проектов, выясняя, почему лишь небольшая их часть заканчивалась успешно, а большинство разработок оказывалось на грани провала. В начале 1990-х годов его пригласили в компанию Borland Software Corporation для экспертизы проекта по разработке новой версии под Windows офисной программы, редактора электронных таблиц, Quattro Pro. Для проекта уже создали миллион строчек кода. На это у группы из восьми человек ушел 31 месяц. То есть каждый член команды выдавал по тысяче строк в неделю. Это абсолютный рекорд среди программистов, и Джим хотел понять, как им это удалось. Первым делом он нарисовал схему всех коммуникационных связей в группе: кто с кем говорил, к кому от кого поступала информация, а если не поступала, то почему. Такая схема позволяла выявить узкие места и сотрудников, сидящих на нужной информации, но скрывающих ее от других. Чем выше уровень коммуникационного шума, то есть когда все обо всем знают, тем быстрее работает группа. В сущности, при таком аналитическом подходе удается измерить, насколько хорошо все осведомлены, что должен делать каждый участник группы, чтобы задание было выполнено. Компания Borland держала самый высокий рейтинг – девяносто процентов. Большинство компаний оставались на уровне двадцати процентов.

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

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

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

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

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

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

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

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

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

В компании Easel в моей первой скрам-команде мы ввели ежедневные собрания в третьем спринте. На тот спринт мы запланировали четыре недели работы – объем приблизительно такой же, как в прошлом месяце. Мы выполнили ее за неделю. Улучшили результат на четыреста процентов. В ту первую пятницу все члены группы, переглянувшись, дружно сказали: «Ну ничего себе!» В тот момент я понял, что, похоже, приблизился к разгадке.

Раз за разом

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

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

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

Мы все посмеялись и завалили Элко собственными печальными рассказами о ремонте.

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

– А вот и нет, – ответил он. – Все будет вовремя и в рамках бюджета. Я собираюсь применить Scrum.

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

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

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

Когда он рассказал мне все это, я был удивлен и поздравил его с тем, что у него работали отличные мастера. «Погоди, – сказал он мне, – это еще не вся история».

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

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

Подведем итоги

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

• Демонстрируйте или умрите. В конце каждого спринта у вас должно быть что-то сделано – что-то, что можно использовать (чтобы летать, ездить, вычислять).

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

• Все всё знают. Информационная насыщенность ускоряет работу.

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

Глава пятая Потери – это преступление

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

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

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

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

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

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

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

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

Но я хочу сказать, что в этом нет ничего забавного. Нам всем должно быть не смешно, а стыдно. Нам следует оплакать растраченные впустую годы нашей жизни и свой потенциал. В первой главе я приводил мнение Тайити Оно о потерях, повторю его слова еще раз: «…Потери являются в большей степени преступлением перед обществом, чем просто коммерческими потерями»[32]{21}. Анализ потерь Тайити Оно оказал огромное влияние на мое собственное отношение к ним, поэтому я хотел бы уделить его точке зрения некоторое внимание.

Тайити Оно, выделяя три вида потерь, использовал японские термины: мури (потери из-за неблагоразумного обращения с ресурсами); мура (потери из-за неравномерного обращения с ресурсами); муда (любые потери, связанные с производственным процессом). Эти идеи тесно связаны с циклом Деминга, о котором я писал ранее: планировать, действовать, проверять, корректировать. Планировать означает «избегать мури»; действовать означает «избегать мура»; проверять означает «избегать муда»; корректировать означает «воля, стимул и решимость воплотить все это». Я рассмотрю каждую из этих ступеней. Укажу, каких потерь следует избегать в первую очередь, – потерь, связанных с нанесением ущерба имуществу; потерь, вызванных неправильным выполнением задания с первого раза; потерь от чрезмерного усердия; эмоциональных потерь, связанных с завышенным ожиданием.

Не беритесь за все сразу

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

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

Вот какое наследство оставила нам хваленая «многозадачность».

Приведу выдержку из статьи, опубликованной в моем любимом журнале Human Factors:

…Даже если участники дорожного движения, говорящие в этот момент по телефону, удосужатся взглянуть на дорогу, они чаще всего «не видят» объекты вокруг себя, поскольку их внимание не воспринимает внешнего окружения – оно направлено на внутренний когнитивный контекст, связанный с темой телефонной беседы{22}.

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

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

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

Профессор психологии Дэвид Санбонмацу, руководитель исследования, разместил в блоге Shots радиостанции NPR (24 января 2013 года) заметку об этом эксперименте:

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

Другими словами, люди, делающие много дел одновременно, в большинстве случаев просто не могут сосредоточить внимание на чем-то одном. Кстати, при таком импульсивном поведении они не в состоянии сами себе помочь.

Пожалуй, не следует мне говорить «они». Лучше всего – «мы». Так поступаем мы все. Заставить вести себя иначе очень непросто. Главное – помнить, что подобное поведение довольно глупо. Мне хотелось бы, чтобы вы сделали небольшое упражнение. Я всегда прошу его выполнить участников своих семинаров. Оно простое, но показывает огромное значение концентрации внимания и потокового состояния, то есть полного вовлечения в процесс деятельности. Кроме того, оно, убеждает, что ваша якобы способность к многозадачности крайне болезненна для сознания, что она замедляет ваши действия, даже если вам кажется обратное. Упражнение демонстрирует, насколько ваше поведение нерационально.

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

Мы делаем это ряд за рядом. Засеките время. У меня получилось 39 секунд. А теперь мы делаем это по столбцам. Сначала мы пишем все арабские цифры, потом – римские, затем – буквы. Засекаю. У меня – 19 секунд. Выполняя однородное задание, вместо того чтобы переключаться из одного контекста в другой, я вдвое сократил потребовавшееся мне время.

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

Снова весьма кстати придется огромная библиотека на тему проектов по разработке программного обеспечения. Вы ведь помните, зачем исследователи занимались этой проблемой, зачем многие программисты стали изучать данные проектов и сопоставлять самые разные показатели? Потому что ежегодно тратились сотни миллионов долларов, а программные продукты устаревали, не успев выйти на рынок. Джеральд Вайнберг в одном из своих трудов Quality Software Management («Управление качеством программного обеспечения»){24} приводит таблицу, которая говорит о многом:

Колонка «Потери при переключении на другой контекст» – это потери в чистом виде. Все верно. При пяти параллельных проектах целых 75 процентов вашей работы уходит в никуда – три четверти рабочего дня коту под хвост. Именно поэтому вы не могли писать ряды и столбики с одинаковой скоростью. Сказываются ограничения возможностей нашего мозга. В начале 1990-х годов психолог Гарольд Пашлер показал, что когда люди выполняют одновременно две задачи, их мыслительные возможности снижаются. Он назвал это явление «столкновением двух задач». Пашлер провел несколько простых экспериментов. Одну группу испытуемых он просил производить совсем простое действие, например нажимать на кнопку, когда загорался свет. Другой группе он давал такое же задание и еще одно в дополнение, скажем, нажимать на другую кнопку в зависимости от цвета загоревшейся лампочки. Стоило добавить вторую задачу – неважно, насколько простой она была, – и необходимое время увеличивалось вдвое. Пашлер предположил, что есть некое узкое место в обработке информации – на самом деле люди способны одновременно думать только об одной вещи. Чтобы прервать один мыслительный процесс, обратиться к памяти, выбрать нужную ассоциацию, связанную со вторым процессом, а затем начать осуществлять новую работу – для всего этого требуются определенные усилия. Каждый раз, когда мы переключаемся на другое задание, требуется дополнительное время{25}.

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

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

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

Расстановка приоритетов

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

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

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

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

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

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

Сделанное наполовину – не сделано никогда

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

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

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

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

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

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

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

Позвольте мне привести немного конкретных цифр. В декабре 2012 года General Motors начала увольнять людей с некоторых своих заводов в США. Почему? Компания произвела слишком много автомобилей. К концу ноября того же года в автосалонах по всей стране у нее стояло 245 853 полноразмерных пикапа. Это количество соответствовало 139 дням производства такого рода автомобилей. По средней цене эти непроданные пикапы стоили 7,5 миллиарда долларов. Не миллиона, а миллиарда! Все эти деньги – в данном случае в виде пикапов, но все равно деньги – так и не получены, потому что автомобили не проданы. Вот причина, по которой компания стала закрывать заводы перед самым Рождеством, оставляя людей без работы.

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

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

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

Получайте результат с первого раза

Джеймс Вумек – основатель организации Lean Enterprise Institute при МТИ и автор большого количества книг по бережливому производству. В своем классическом труде The Machine That Changed the World («Машина, которая изменила мир»[33]) он рассказывает удивительные истории об опасностях переделок, доработок и исправлений. Вумек вместе со своей исследовательской группой на протяжении многих лет колесил по миру, изучая автомобилестроение – одно из крупнейших промышленных достижений человечества. Он хотел понять, почему одни компании создают и собирают автомобили быстро и с небольшими дефектами, а другие – долго и с большим процентом брака. Сегодня любой разумный производитель использует то, что Вумек когда-то назвал бережливым производством. Но в те далекие времена дело обстояло иначе. Наиболее заметными оказались различия на рынке автомобилей класса люкс.

В Японии на сборку фешенебельного автомобиля компании Toyota, Honda и Nissan тратили в среднем 16,8 часа. На завод поступали запчасти, и спустя 17 часов появлялся, например, Lexus. На 100 автомобилей приходилось всего 34 дефекта. Недурно.

В Европе наблюдалась совсем другая традиция. На производство автомобиля высшего класса компании Mercedes-Benz, Audi и BMW тратили 57 часов. На 100 автомобилей приходилось 78,7 дефекта.

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

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

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

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

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

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

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

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

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

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

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

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

Напряженный труд порождает еще больше работы

Когда основатель OpenView Venture Partners Скотт Максвелл сотрудничал в начале 1990-х годов с McKinsey & Company, он получил от Джона Катценбаха одно напутствие, показавшееся ему тогда довольно странным. В те годы Джон Катценбах возглавлял McKinsey, в настоящее время он руководит Центром Катценбаха, действующим в рамках компании Booz Allen Hamilton; он известный автор множества статей и бестселлеров. Именно этот опытный эксперт в области управления дал Максвеллу совет, который тот запомнил на всю жизнь.

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

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

Скотт и другие молодые консультанты тогда посмеялись над ним: «Работать меньше часов? Кажется, это называется “сачковать”». И все-таки идея Джона Катценбаха запала Скотту в душу, поселившись там на многие годы, пока он продвигался по карьерной лестнице. Основав OpenView Venture Partners и став ее руководителем, он начал вкладывать деньги в технологические компании, причем некоторые из них уже использовали Scrum. От кого-то он услышал мое имя как создателя методики. Выяснил, что я живу с ним в одном городе, – и однажды утром пригласил меня позавтракать вместе. За кофе и круассанами Скотт рассказал мне историю одной компании, в которую он инвестировал. Команда разработчиков, применяя Scrum, улучшила свою продуктивность сначала на 25 процентов, а потом дошла до 35. Скотт находился под большим впечатлением. Моя мгновенная реакция несколько охладила его: «Как?! Двадцать пять?! Тридцать пять?! Да они что-то делают не так!!!»

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

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

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

При уменьшении рабочей нагрузки выработка увеличивается в два раза

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

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

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

«Многие фирмы такого [сокращение рабочих часов] не практикуют, – рассказывал Скотт. – Но есть прямая связь. Получается, что вы делаете больше. Вы становитесь счастливым человеком. И качество повышается». Это очевидно. Трудясь меньше часов, можно успевать делать больше, поднимая качество работы.

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

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

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

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

В апреле 2011 года группа израильских ученых опубликовала в американском научном журнале статью Extraneous Factors in Judicial Decisions («Внешние факторы при принятии судебных решений»), в которой показаны результаты их исследования механизмов принятия решений. Авторы рассмотрели более тысячи решений суда, принятых израильскими судьями, возглавлявшими две различные комиссии по условно-досрочному освобождению. Решения касались преступников-израильтян еврейского и арабского происхождения мужского и женского пола. Преступления были самые разные: кражи, угрозы, изнасилования, убийства. Большинство решений, принятых судьями, касалось досрочного освобождения{29}.

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

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

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

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

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

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

Приведу еще один удивительный эксперимент. Группа исследователей хотела разобраться, каким образом принятие решений влияет на самоконтроль. Для этого они собрали студентов университета – традиционных для психологических исследований подопытных кроликов – и попросили часть из них принять некоторое количество решений. А именно: студентам были продемонстрированы различные товары и предложено выбрать один из них. Им было сказано, что нужно выбирать тщательно, так как в конце эксперимента им вручат выбранные товары и от их предпочтений будет зависеть, что они получат в подарок. Другой группе студентов не нужно было принимать решения{30}.

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

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

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

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

Будьте благоразумны

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

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

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

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

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

Не будьте засранцами сами и не позволяйте этого другим – не поощряйте и не закрывайте глаза на подобное поведение.

Поток

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

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

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

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

Подведем итоги

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

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

• Делайте все правильно с первого раза. Совершив ошибку, исправляйте ее сразу. Отложите все другие дела и займитесь ею. Устранение дефекта спустя некоторое время займет в двадцать раз больше сил и часов, чем немедленное исправление ошибки.

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

• Не будьте неразумны. Амбициозные цели – лишь мотиваторы, которыми пользуются ваши руководители. Недостижимые цели только вызывают депрессию.

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

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

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

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

Глава шестая Планируйте реальность, а не пустую мечту

«Привет, Джефф, у нас проблема…»

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

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

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

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

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

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

Сказать, что на Уолл-стрит идею приняли, – значит ничего не сказать. Последовала бурная реакция типа «Классно! Круто! Сильно!» – приблизительно так. А как иначе? Мало того что предлагалось поднять медицинские услуги на более высокий уровень, но еще и давалось обещание существенной экономии денег. Что не могло не привлечь людей, особенно пожилых. Больше клиентов – больше продаж. Беспроигрышный вариант. Была лишь одна загвоздка. Обсуждая со своими управляющими, насколько в принципе воплотима его идея, Клеппер не уточнил одну деталь: сколько времени уйдет на ее осуществление. Специалисты, которым непосредственно предстояло воплощать высокую мечту в жизнь, узнали о ней уже после того, как их президент дал обязательство на Уолл-стрит, что новая система заработает 7 июля 2007 года, – мол, нам по плечу любые трудности.

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

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

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

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

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

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

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

Когда Марк объяснил мне всю ситуацию, мне оставалось только вздохнуть: «Да, вы влипли». Подумав секунду, я сказал: «Уверен, выход есть».

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

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

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

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

– Кто из вас действительно прочитал все это? – спросил я.

Тишина.

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

Неловкое молчание.

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

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

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

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

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

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

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

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

– Отлично, – сказал Брент. – С чего начнем?

Около пяти человек высказали свои предложения.

– А потом?

Еще пять человек поделились своими идеями.

– А потом?

Чего мы добивались от участников проекта? Чтобы они расставили приоритеты. Чаще всего люди отвечают на вопрос «что дальше?» довольно однозначно: важно все. Тогда Брент решил сформулировать более четко: «Что принесет проекту наибольшую ценность?» Вот с этого и начнем.

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

Планирование свадьбы

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

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

КОНУС НЕОПРЕДЕЛЕННОСТИ

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

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

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

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

Давайте посмотрим, как это делается. Для этого вернемся к свадьбе.

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

• жених и невеста;

• цветы;

• приглашения;

• церковь;

• зал для приема гостей;

• угощение;

• священник;

• платье невесты;

• обручальные кольца;

• музыка (диджей или «живая» группа).

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

• жених и невеста;

• священник;

• обручальные кольца;

• зал для приема гостей;

• приглашения;

• угощение;

• музыка;

• платье невесты;

• цветы;

• церковь.

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

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

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

Размер имеет значение, но только относительное

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

Например, видеть разницу между футболками размеров S, M и L. Мой любимый пример определения относительных размеров – это измерение «в собачьих баллах». Мой друг и один из ведущих представителей принципа гибкого подхода Майк Кон, как и я, всю жизнь борется с этой проблемой, пытаясь «уложить» проекты во временные, бюджетные и оценочные рамки. Большой любитель собак, хотя жена так и не дала ему завести пса, он придумал измерять объем той или иной работы по проекту «в собаках». Чтобы его разработчикам было удобнее ориентироваться в «собачьей» системе, он составил для них список пород:

• лабрадор-ретривер;

• терьер;

• немецкий дог;

• пудель;

• такса;

• немецкая овчарка;

• ирландский сеттер;

• бульдог.

Теперь его вопросы звучали примерно так: «Эта проблема – такса или дог? Последняя была таксой, значит сейчас мы имеем дело с лабрадором, да?» Участники группы просматривали все элементы, которые нужно было разработать, и определяли их размер «в собаках». Позже Майк предложил присвоить каждой породе числовое значение. Так было проще. «Такса – единица; дог – тринадцать; лабрадор стал пятеркой, а бульдог – тройкой»{31}.

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

Это и есть относительное определение размера, сравнение задач друг с другом. К сожалению, не все пользуются такой единицей измерения, как «собака». Однако вы, наверное, обратили внимание, что в числах, которые я вроде бы произвольно присваивал разным пунктам из списка, есть некая последовательность: 1, 3, 5, 8, 13. Каждое число в этой последовательности является суммой двух предыдущих. Это называется «последовательность Фибоначчи», и мы ее неспроста используем. Она повсюду.

Последовательность Фибоначчи – повсюду вокруг нас

Последовательность Фибоначчи – это порядок чисел, при котором каждое последующее число является суммой двух предыдущих: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55…

Последовательность Фибоначчи присутствует повсеместно в природных системах, так что у человечества были миллионы лет на то, чтобы привыкнуть к ней.

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

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

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

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

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

Дельфийский оракул

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

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

В литературе это явление описано как информационный каскад, о нем писали в своей статье A Theory of Fads, Fashion, Custom, and Cultural Change as Informational Cascades («Теория моды, обычаев и культурных изменений как информационных каскадов») Сушил Бикчандани, Дэвид Хиршлейфер и Иво Уэлш:

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

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

Еще одна известная проблема – эффект ореола, или гало-эффект, когда мы составляем общее мнение о человеке согласно восприятию какой-либо одной его черты. Это явление было впервые эмпирически изучено в 1920 году Эдвардом Ли Торндайком. В его статье A Constant Error in Psychological Ratings («Постоянная ошибка в психологических оценках») Торндайк попросил военных офицеров оценить своих солдат по различным качествам: физическим, интеллектуальным, лидерским, личностным. Затем он смотрел, как один набор качеств влияет на оценку других качеств, и обнаружил довольно сильную взаимосвязь. Если чья-то физическая подготовка получала высокую оценку, то так же высоко оценивались и лидерские качества этого человека. И интеллект. И характер. Результаты исследования Торндайка подтвердились данными последующих экспериментов, которые он проводил на протяжении многих лет. Например, если кто-то хорош собой, то все охотно признают за этим человеком и ум, и порядочность{33}.

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

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

Но вы можете переиграть воздействие этих эффектов. Корпорация RAND[34] в 1950-е годы инициировала ряд экспериментов, во время которых задавались нарочито пугающие вопросы, которые были особенно популярны во времена холодной войны. В ходе этих исследований был разработан дельфийский метод[35] (название восходит к Дельфийскому оракулу, чья жрица предсказывала будущее), авторами которого были Норман Далки и Олаф Хелмер, опубликовавшие в 1963 году статью, аккуратно озаглавленную An Experimental Application of the Delphi Method to the Use of Experts («Экспериментальное применение дельфийского метода для экспертной оценки») с полезной ссылкой – «Меморандум RM-727/1 – сокращенная версия». В статье они заявляли о своем намерении задавать вопросы так, чтобы мнение одного человека не влияло на остальных. Для этого они собрали группу экспертов: четырех экономистов, специалиста по анализу физической уязвимости, системного аналитика и инженера-электротехника.

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

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

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

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

Далки и Хелмер взяли эти данные и передали их всем экспертам и еще раз спросили о количестве бомб. Теперь разброс мнений был от 89 до 800 боеголовок. Они снова повторили всю процедуру. А потом еще раз. Разброс мнений постепенно сужался. В конце концов он сократился и составил от 167 до 360 ядерных боеголовок.

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

Покер планирования

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

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

Идея проста. Каждому участнику дается колода карт с числами Фибоначчи – 1, 3, 5, 8, 13 и так далее. Каждая единица работы, которая должна быть оценена, выкладывается на стол. Затем каждый участник группы берет ту карту, число на которой, по его мнению, соответствует объему необходимых усилий, и кладет ее на стол рубашкой вверх. Затем все одновременно открывают карты. Если расхождение не больше чем на две карты (скажем, пятерка, две восьмерки и тринадцать), команда просто их складывает, берет среднее арифметическое (в данном случае 6,6) и переходит к следующей задаче. Помните, мы говорим об оценках, а не о жестких планах. И оценках небольших фрагментов проекта.

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

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

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

Я научился всему этому на собственном горьком опыте, когда работал в Пенсильвании в GSI Commerce, занимавшейся интернет-продажами. С тех пор их купила компания eBay. GSI специализируется на создании онлайн-магазинов для таких компаний, как Levi’s, Toys “R” Us, Major League Baseball и Zales Diamond. Это не мелкие проекты. И GSI с ними очень неплохо справляется.

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

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

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

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

Никаких заданий. Нам нужны истории и факты

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

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

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

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

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

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

Мой любимый пример связан с интернет-мемом, который был популярен несколько лет назад. Это картинка с изображением капитана Жана-Люка Пикара[37] в знаменитом звездолете «Энтерпрайз» с подписью: «Как капитан космического корабля я хотел бы, чтобы в бортовом журнале автоматически использовалась сегодняшняя звездная дата…» Это высказывание приобретает некий смысл, только если задуматься. Вас никогда не удивляло, что в далеком будущем капитану космического корабля приходится в ручном режиме вводить дату, когда он заполняет бортовой журнал? «Дневник капитана. Звездная дата 4671.7. Планета Марс так хорошо смотрится с орбиты…» Даже нам не приходится делать так, когда мы оставляем запись у себя в блоге. Так почему же это делает он? Но ключевой вопрос, который остается без ответа на этой картинке, – зачем? Зачем ему нужна такая функция? Для какой цели? Чтобы отслеживать порядок записей? Или что-то более серьезное? Должны ли эти записи исключать возможность внесения изменений в целях проверок и расследований криминалистами Звездного флота? Две совсем разные цели. Одна – бытовая, другая – имеет весьма вескую причину. Команде нужно разобраться, что капитан на самом деле хочет делать, при этом они могут найти совершенно иной подход к выполнению задачи, так что капитан будет получать гораздо более важную информацию, о которой он, возможно, даже и не задумывался, но которая была бы ему очень полезна.

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

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

Короткие истории

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

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

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

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

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

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

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

«В спецназе, – рассказывает он, – мы не называем это историей. Мы говорим: “план действий”. Но суть та же». Вот одна из немногих историй из практики спецназа, которые Тим может рассказывать открыто, – медицинская миссия в Лаосе. «У нас было два своих “эпика”. Первый эпик – по курсу медицинской подготовки, поскольку мы обучали отряды самообороны навыкам тактической медицины. Второй – по операциям по разминированию неразорвавшихся боеприпасов на освобожденных территориях».

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

Готовность и выполненность

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

Возьмем в качестве примера историю Тима.

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

Есть мнемоническое правило, которое я всегда использую, когда нужно определить, готова ли история. Придумал его вдумчивый исследователь и серьезный программист Билл Уэйк. Билл говорит, что любая история, чтобы считаться готовой, должна соответствовать определенным критериям. Он назвал их критериями INVEST (Independent. Negotiable. Valuable. Estimable. Small. Testable).

• Завершенность, выполнимость, независимость (Independent). История должна быть: абсолютно завершенной; осуществимой на практике; независимой от разных обстоятельств.

• Открытость (Negotiable). История до своего завершения должна быть открыта для общего обсуждения; любой участник группы должен иметь возможность внести в нее свои поправки.

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

• Оценочность (Estimable). История должна быть удобна для оценки объема работы.

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

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

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

Любая пользовательская история, которую мы внедряем в практику, должна отвечать двум условиям: «готовность» – то есть соответствует ли она критериям INVEST; «выполненность» – то есть соответствует ли она тем критериям, по которым мы можем судить, что задача выполнена. При работе над реальными проектами мы видим, что если история действительно готова, команда удваивает скорость ее реализации. Когда в конце спринта история выполнена, команда в два раза увеличивает темпы работ в начале следующего спринта. Это один из ловких приемов Scrum, дающий возможность в два раза быстрее выполнить двойной объем работы.

Планирование спринта

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

Быстро решив все вопросы, команда дружно произносит: «Вперед!» – и приступает к работе.

Узнайте динамику производительности

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

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

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

– Вы уложитесь в заявленные сроки? – спросил старший вице-президент, хлопнув рукой по столу.

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

– Этого недостаточно! Вы уложитесь в первоначальные сроки?

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

– Препятствия! Не вопрос, Джефф. Я работал в Toyota, – рассмеялся он.

– Этот проект начинает мне нравиться, – рассмеялся я в ответ.

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

Прошло три спринта, и по результатам измерения их динамики выяснилось, что группы повысили скорость работы с 20 очков до 60. Тогда я прикинул с довольно большой вероятностью срок, за который можно завершить проект. Учитывая динамику всех групп, разработчикам понадобится еще 19 двухнедельных спринтов. Сейчас начало марта – получается 1 декабря.

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

Многие перечисленные в списке препятствия могли казаться непреодолимыми. Как часто вам случалось, оглянувшись вокруг себя, задуматься: «Мы работаем безответственно сегодня, мы работали безответственно все годы, и все понимают, как это глупо». Поэтому сотрудникам кажутся нереальными изменения в корпоративной культуре. Когда-то я соглашался с ними, особенно если речь шла о больших компаниях с их душной атмосферой и косными принципами. Сегодня мне не хотелось бы поощрять такого рода мысли, поскольку Medco доказала, как я был неправ. Мой постоянный оппонент, старший вице-президент, работавший раньше в Toyota, в понедельник разослал наш список всем сотрудникам. Рядом с каждым препятствием было указано имя руководителя. К четвергу все пункты были решены, препятствия устранены. Поистине иногда, чтобы подтолкнуть людей к переменам, им нужно приставить пистолет к виску. Эта ситуация стала ярким примером, чего можно добиться, если есть воля к победе – или если за все отвечает парень из Toyota. Нет правил, начертанных на камне. Поэтому не бойтесь все ставить под сомнение. К концу следующего спринта динамика групп увеличилась на пятьдесят процентов. Новая дата сдачи была назначена на 1 сентября. Теперь на три месяца позже заявленного. Однако мы все равно не успевали, даже несмотря на ускорение темпа с 20 до 90 очков за спринт, более чем на 400 процентов!

Но и этого было недостаточно.

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

1. Можем ли мы начать делать что-то иначе, чтобы еще ускорить темпы?

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

– Вот те раз! Мы не в состоянии это уладить, нет? – в недоумении спросил я.

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

2. Можем мы вычеркнуть что-то из списка заданий? Распределить часть заданий по разным группам?

Ни у кого не было никаких идей.

3. Может, найдем что-то, что мы могли бы не делать? Можем мы каким-то образом уменьшить объем работ?

– Нет, ни в коем случае, мы и так урезали требования как могли.

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

На это ушло несколько часов, но мы отбили еще один месяц.

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

– Нет! Нас всех уволят. Давайте еще разок взглянем на те три вопроса.

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

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

На той встрече старший вице-президент спокойно заметил: «Давайте признаем свою победу. Если у вас возникнут какие-либо проблемы – звоните».

Было любопытно наблюдать за ценами на акции Medco в то лето. Когда мы только начали создавать инфраструктуру проекта, цены уже пошли вверх, и когда мы сдали готовый проект, они продолжили расти. Как сильно? Ну, на многие миллиарды долларов, за год цена одной акции взлетела с 25 долларов до 50. На Уолл-стрит успокоились: компания продолжит привлекать новых клиентов и будет сохранять лидерские позиции в своей отрасли. Оглядываясь назад, я понимаю, что надо было просить не гонорар, а процент от дохода.

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

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

Подведем итоги

• Карта – еще не живая местность. Не обольщайтесь своим планом. Почти наверняка он неверен.

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

• Какая это собака? Не оценивайте в абсолютном выражении, например в часах, – уже не раз доказано, что люди не умеют этого делать. Оценивайте относительно, например в собако-единицах или по размеру футболок (S, M, L, XL, XXL), либо – что самое надежное – используйте последовательность Фибоначчи.

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

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

• Работа – это история. Сначала подумайте о человеке, который получит пользу от той вещи, которую вы делаете; потом подумайте о том, что это такое и, наконец, зачем им это нужно. Люди мыслят сюжетами и фактами, так дайте им их историю. Будучи X, I хочет Y, так что Z.

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

• Динамика × время = результат. Узнав, насколько быстро вы продвигаетесь, вы сможете понять, когда окажетесь на финише.

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

Глава седьмая Счастье

Люди хотят быть счастливыми. Не тупо счастливыми, прозябая как овцы, а ведя активную и насыщенную жизнь. По мнению Томаса Джефферсона, чем больше человек работает, тем он счастливее. Похоже, так оно и есть: созидательное отношение к окружающему миру делает нас счастливыми. Scrum, если использовать методику правильно, сделает счастливыми весь круг заинтересованных лиц – а это непосредственные исполнители, заказчики, руководители и акционеры (обычно в таком порядке).

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

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

В большинстве культур такое достижение счастья не вознаграждается и даже не приветствуется. Профессор Тал Бен-Шахар, преподающий в Гарвардском университете популярнейший курс по позитивной психологии, в своей книге Happier («Быть счастливее»)[38] пишет:

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

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

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

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

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

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

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

Счастье – это успех

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

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

Счастье приводит к успеху практически в любой сфере нашей жизни, в том числе в браке, здоровье, дружбе, общественной деятельности, творчестве и особенно в профессиональной сфере – карьере и бизнесе{35}.

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

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

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

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

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

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

Количественная сторона счастья

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

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

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

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

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

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

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

Вот как функционирует этот способ: в конце спринта каждый участник группы должен ответить на несколько вопросов.

1. Оцените свою роль в компании по шкале от одного до пяти.

2. Оцените компанию в целом по той же шкале.

3. Почему вы так считаете.

4. Назовите вещь, которая может сделать вас счастливее в следующем спринте.

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

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

Несколько лет назад я захотел расширить свою компанию Scrum. и сделать ее консультационным агентством, предоставляющим полный цикл обслуживания по методологии Scrum. Мы проанализировали динамику своей производительности и выяснили, что за недельный спринт у нас получается сорок очков осуществленных историй. Когда я ввел индекс счастья, первое, что мы обнаружили, – наши пользовательские истории выглядели недостаточно правильными. Они были слишком расплывчатыми, а значит не готовыми перейти в колонку «Сделано». Мы их еще раз проработали и получили вроде бы качественные истории. Но во время следующего спринта они все-таки оказались недостаточно хорошими. Этот недостаток отражался на нашем индексе счастья. В третьем спринте появилась другая проблема. Мы решили ее. И так далее. За считаные недели мы улучшили показатели динамики с 40 баллов за спринт до 120. Всего лишь поинтересовавшись, что делает людей более счастливыми, мы умудрились втрое улучшить свою производительность. В результате счастливее стали не только мы, но и наши клиенты, а прибыль компании просто взлетела до небес. Еще раз повторю: чтобы достичь таких результатов, нужно было только задать вопрос коллективу: «Что сделает вас счастливее?» – и всем вместе выполнить это.

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

Делать все в открытую

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

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

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

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

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

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

Проект и группа – чумовая скрам-команда

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

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

В компании PatientKeeper принцип прозрачности, который сначала так испугал разработчиков, вполне оправдал себя. С его помощью мы могли координировать задачи, перераспределяя их между многочисленными командами. Каждый всегда знал точно, над чем работают остальные. Сотрудники могли поддерживать друг друга, если кто-то заходил в тупик. Разработчики помогали другу в решении проблем, даже если они были из разных команд! Производительность в компании PatientKeeper возросла более чем в четыре раза. За год мы сорок пять раз обновили выпускаемые версии программ компании. И это не игра Angry Birds («Сердитые птицы»). Речь шла о программном обеспечении, установленном в крупнейших больницах, – от его правильной работы зависела жизнь людей. Но благодаря открытости всех процессов разработки мы могли выводить продукцию на рынок быстрее любой подобной нам компании в мире. Вот на что способен «солнечный свет». После того как закончился мой контракт с PatientKeeper, новое руководство решило, что Scrum больше не является оптимальным подходом к работе. Каков результат? Выход продукции сократился с сорока пяти до двух раз в год, доходы упали с 50 до 25 миллионов долларов в год, а издержки, составлявшие меньше десяти процентов, достигли более чем тридцати. Отличная компания превратилась в посредственную, вернувшись к традиционной корпоративной политике.

Доставляя счастье

Zappos – одна из компаний, которая считает состояние счастья ключевым аспектом своей корпоративной культуры. Их невероятно успешный сайт убеждал людей поступать так, как, по мнению многих, поступать неразумно: покупать обувь через интернет. Генеральный директор Тони Шей написал об этом книгу Delivering Happiness («Доставляя счастье»)[40], в которой рассказывает об уникальной корпоративной культуре, основанной на «вау-эффекте», созданном специально для клиентов Zappos. Вау-эффект стал абсолютным правилом в современном мире маркетинга и рекламы. Оказывается, чтобы собрать целую армию довольных клиентов, достаточно сделать счастливыми людей, находящихся на другом конце провода.

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

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

Результаты, по словам Фоли, впечатляют: «Контакты, которые сотрудникам удавалось завязать во время “курса молодого бойца”, сохранялись на протяжении всей их карьеры». Для «курса» была разработана специальная довольно суровая дисциплина: новобранцам следовало являться на работу к семи часам утра, усердно трудиться, укладываться в сроки и успешно выдерживать испытания. Однако, несмотря на все трудности, эти меры имели успех. Люди, прошедшие «курс молодого бойца», сохраняли приятельские отношения не только в первые месяцы, но и на протяжении многих лет, встречаясь за пределами компании в барах, у кого-нибудь в загородном доме или на пикниках. «Они были как одна большая семья. Ходили друг к другу в гости. Проводили много времени вместе вне работы», – говорит одна из управляющих Zappos Рейчел Браун.

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

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

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

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

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

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

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

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

«Пузырь счастья» должен лопнуть

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

В этом они не одиноки. Журнал Harvard Business Review посвятил целый выпуск за январь – февраль 2012 года проблеме счастья.

…Единственный путь к счастью сотрудника, которое будет на пользу и другим заинтересованным лицам, лежит через чувство самореализации, возникающее от хорошо выполненной важной работы. Мы должны стремиться к тому, чтобы не просто сделать сотрудников «счастливыми», но к тому, чтобы сделать это, помогая им совершать великие дела. Проще говоря, компания должна заработать приверженность своих сотрудников ее миссии и успеху и помогать им, в свою очередь, заработать лояльность клиентов{36}.

У данной приверженности есть ощутимые преимущества. Такие сотрудники с радостью приходят на работу, трудятся не жалея сил, у них никогда не возникает желания перейти в другую компанию, напротив, они приводят таких же людей – тех, кто разделяет их устремления. Авторы статьи в HBR решили не называть этих людей счастливыми из-за коннотации со словом удовлетворенность. Они называют свой объект исследования процветающими людьми. Было обнаружено, что эти люди показывали результаты на 16 процентов лучше, чем остальные сотрудники их уровня; демонстрировали на 125 процентов меньше усталости и равнодушного отношения к работе; на 32 процента более преданы своей работе и на 46 процентов более довольны ею. Они реже брали больничный, реже обращались к врачу и увереннее своих коллег продвигались вверх по карьерной лестнице{37}.

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

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

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

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

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

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

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

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

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

Уильям Шекспир. Король Лир (акт 1, сцена 4, реплика шута)[41]

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

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

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

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

Счастливы сегодня, счастливы завтра

Психологи, в том числе и профессор из Гарварда Тал Бен-Шахар, утверждают, что один из способов проанализировать отношение человека к миру – задать ему вопрос, делает ли его счастливым то, чем он сегодня занимается, а также сделает ли это его счастливее завтра. Мне их совет показался полезным. Через призму этих вопросов и ответов на них можно взглянуть на людей в их рабочей обстановке.

По Бен-Шахару люди делятся на четыре типа.

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

Так появляется второй тип – нигилисты, в которых превратились наши гении.

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

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

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

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

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

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

Подведем итоги

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

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

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

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

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

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

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

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

Глава восьмая Приоритеты

Со Скоттом Максвеллом я впервые встретился в кафе Johnny’s Luncheonette в городе Ньютоне пару лет назад. Я уже рассказывал вам о нем. Он основатель OpenView Venture Partners, и именно ему когда-то пришла в голову светлая мысль, что изнурительный многочасовой труд лишь создает больше дополнительной работы, но не приводит к реальным результатам, не повышает производительности и не приносит прибыли.

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

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

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

Я люблю диаграмму Венна и всегда стараюсь демонстрировать такой ее вариант.

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

По словам Скотта Максвелла, самой сильной и привлекательной составляющей Scrum стал заранее подготовленный бэклог проекта, в котором перечислены все задания, отсортированные по их приоритетности. Наличие такого документа окончательно повлияло на решение Максвелла внедрить Scrum в OpenView; и по сей день он считает нашу методику залогом своей конкурентоспособности.

Бэклог. Что и когда делать

Первое, что полагается делать, когда приступаешь к проекту по методике Scrum, – создать список требований к функциональности продукта; список должен быть упорядочен по степени важности задач, подлежащих реализации. Традиционно такой список называется «бэклог»[42]. Иногда он содержит сотни заданий, иногда – всего несколько задач, о которых нужно думать в первую очередь. Само собой, требуется иметь четкое представление, что вы хотите получить в конце своего проекта. Задание может быть любым: программное обеспечение; свадебная церемония; услуга, новая вакцина, перекрашенный дом. Желательно без промедления – едва только сложится концепция замысла – детально продумать все, что потребуется для нормального хода работ.

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

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

Основной момент, нас интересующий, – принцип расстановки приоритетов. Для этого нужно выяснить, какие пункты списка:

• имеют самое большое значение для хода работ над проектом;

• важнее всего для заказчика или будущего потребителя;

• принесут максимальный доход;

• проще всего осуществить.

Следует сразу уяснить простую вещь: в списке полно заданий, до которых у вас никогда не дойдут руки, но вам требуется выбрать те, что принесут наибольшую пользу при наименьшем риске. Поскольку Scrum придерживается поступательной модели разработки и поставки – на языке программистов эта модель называется инкрементальной, – надо начать с такого набора возможностей продукта, который немедленно принесет доход; тем самым вы снизите риски, связанные с проектом. Потому сначала советую отбирать основные функциональности. Хотите оказать быструю услугу заказчику? Тогда берите требование с наивысшим приоритетом, выполняйте его – и, полностью сделав, демонстрируйте клиенту. Это может быть лишь небольшая часть крупного проекта, но ее нужно исполнить до готовности, чтобы не было стыдно показать всем заинтересованным лицам. Перекрашивая дом, начните в первую очередь с обновления гостиной и доведите работу до конца (вплоть до того, что уберете оттуда грязные тряпки и банки с краской) – это будет часть вашего проекта, выполненная целиком.

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

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

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

Владелец продукта

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

Когда я начинал работать со своей первой скрам-командой в 1993 году, роль владельца продукта мною еще не была сформулирована. Я входил в группу управления проектом, и помимо принятия решений, что делать команде в процессе каждого спринта, у меня было множество других обязанностей. Передо мной стояли и организационные, и маркетинговые задачи, я поддерживал отношения с заказчиками и продумывал стратегию работ. Когда наступил первый спринт, у меня возникла мысль заняться и бэклогом. Требовалось лишь написать достаточное количество потребительских историй и идентифицировать основные функции проекта – то, что будет выполнять команда в следующем спринте. Проблема возникла во время второго спринта, когда мы ввели ежедневные собрания на ходу. Динамика производительности увеличилась на 400 процентов, и команда за неделю выполняла тот объем работ, на который, как мы предполагали, уйдет месяц. Естественно, они выбрали все задания из составленного мною списка. Они лишились своего бэклога, а ведь с его помощью так удобно было работать! Честно говоря, я надеялся, что у меня в запасе еще целый месяц для создания новых историй. Перед нами выросла огромная реальная проблема, и ее следовало немедленно решить. Именно в тот момент пришло осознание: нужен отдельный человек, который возьмет на себя ответственность за ведение бэклога. Я серьезно задумался над тем, какова будет его роль в скрам-команде, какими качествами он должен обладать и как мы его назовем.

Вдохновение я черпал все в той же Toyota – великой компании, давшей миру лучшие образцы такого действующего лица, как главный инженер. В корпоративной культуре Toyota решающая роль отводится главному инженеру, поскольку он полностью отвечает за процесс создания новой модели автомобиля: от разработки до ее выпуска. Он работает в теснейшем контакте с управляющими, ведущими специалистами, талантливыми инженерами и дизайнерами, принимающими непосредственное участие в конструировании и сборке очередной модели. Опираясь на основных участников проекта – специализированные технические группы, он выстраивает многофункциональную команду, способную создавать лучшие автомобили. Главные инженеры Toyota (в прошлом их величали сюса[43]) стали для всего мира легендарными фигурами как всесильные лидеры Dao Toyota (Путь Toyota) – особой системы управления и производства. Отчасти так оно и есть, хотя в контексте системы принципов компании подобное определение не очень уместно. «Всесильный» главный инженер Toyota ни в коей мере не является абсолютным властителем, более того – его статус руководителя крайне низок. Огромный коллектив ему не подотчетен, главный инженер не руководит теми, кто непосредственно участвует в реализации проекта, – скорее, он сам служит их интересам. Главные инженеры обязаны всегда быть на высоте и соответствовать строжайшим требованиям, поскольку любой специалист компании может сказать им в глаза, что они не правы. Они не дают никаких аттестаций сотрудникам, не оценивают эффективность деятельности производственного персонала, никого не поощряют и не повышают. Однако главные инженеры отвечают за составление концепции проекта – основного документа, в котором изложена идея нового автомобиля, и управляют – не принуждением, а убеждением – многоуровневой системой всего производственного процесса. Именно этот замысел я решил воплотить в Scrum.

Джон Шук из Lean Enterprise Institute (Институт бережливых предприятий) открывает свою статью о роли главного инженера в производственном процессе Toyota одним постулатом, почерпнутым из весьма неожиданного источника. Это «Руководство для командного состава Корпуса морской пехоты США»:

Личная ответственность командира не зависит от его звания, то есть от степени его узаконенной власти…

Далее Шук пишет:

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

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

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

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

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

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

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

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

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

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

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

Наблюдать, ориентироваться, решать, действовать

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

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

Летчики-истребители, тем более побывавшие в боях, не отличаются особой скромностью. К тому моменту, когда их переводят на базу Неллис, они уже считаются в ВВС США лучшими, потому и ведут себя довольно высокомерно. Бойд, имея под рукой надежный способ обращения с такими курсантами, быстро сбивал с них спесь, и они осваивали все, чему хотел обучить их инструктор. Вместе с Бойдом шесть истребителей поднимались в воздух, и он тренировал их летать единым авиазвеном ровно по курсу вслед за ведущим – лучшая позиция в воздушном бою. Затем он давал команду открыть огонь. Но у курсантов не было шансов. Бойд успевал менее чем за сорок секунд выйти на нужную позицию и из всех шести пулеметов[44] поразить по очереди каждый самолет звена, при этом непрерывно выкрикивая отсчет по радио: «Удар! Удар! Удар!» – и так шесть раз. Это было задолго до появления лазеров, компьютеров и симуляторов. По этому крику курсант понимал, что убит. Неизменная победа в учебных боях принесла Бойду второе прозвище, так и закрепившееся за ним до конца жизни, – Сорокасекундный Бойд.

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

Бойд обладал способностью видеть все пространство боя. Вот его устный рассказ:

Я видел себя в огромном шаре – я был внутри этого шара – и мог фиксировать все, что происходило вокруг него, [при этом] я все время совершал маневры… мог видеть все с двух точек. Во время воздушного боя, кроме того что я видел вокруг, я мог наблюдать за самим собой, словно со стороны{39}.

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

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

Однако Бойду не давала покоя загадка прошлых лет. Теоретически МиГи должны были стереть «Сейбров» с лица небес. Тогда почему американские истребители удерживали паритет в воздухе? Какая-то бессмыслица. Бойд, если верить написанной Робертом Корамом биографии[45], в своих попытках найти разгадку нередко впадал на несколько дней в состояние оцепенения. Он был уверен, что его теория маневренности верна, но отчего тогда в корейском небе на один сбитый американский истребитель приходилось десять советских? Хорошая летная подготовка? Это могло служить объяснением, но лишь отчасти. Тактика? Возможно, но и этот фактор не должен был бы привести к таким ошеломительным результатам. Наконец до него дошло. Американские летчики лучше видели и из-за этого быстрее действовали. Не благодаря каким-то тайным качествам, свойственным военным летчикам, а за счет конструкции кабины самолета. У F-86 был каплевидный фонарь, в то время как у МиГ фонарь состоял из нескольких стеклянных панелей с перемычками, которые блокировали видимость. К тому же F-86 был оснащен полностью гидравлическими системами контроля полета, в то время как на МиГ-15 они были установлены только частично. Американцы знали, что советские летчики-истребители специально накачивают мышцы туловища и рук, чтобы лучше маневрировать тяжелыми МиГами. Американские летчики могли действовать быстрее еще по одной существенной причине: они хорошо знали особенности советских МиГ-15, тогда как F-86 «Сейбр» был совершенно новой моделью. Случаи сбитых МиГов, когда их пилотировали китайские и особенно северокорейские летчики, можно не принимать во внимание по причине низкого качества их летной подготовки.

Победа в воздухе зависела не от тех или иных характеристик машины. На исход битвы влияло основное обстоятельство: большой обзор кабины давал преимущество американскому летчику действовать не только максимально быстро, но и адекватно поведению более медленного противника. Пока МиГ-15 совершал маневр, F-86 успевал сделать свой, перестроиться и начать атаку. Американский летчик настолько быстро реагировал на любое действие МиГа, что более технически совершенный самолет становился легкой добычей.

Подобное явление наблюдалось и во Вьетнаме, где я служил. К тому времени воевали на других самолетах: с вьетнамской стороны были советские МиГ-21, а с нашей – истребители F-4, но снова лучший обзор кабины F-4 брал верх над технически совершенным МиГ-21, который отличала высокая маневренность. Как сказал бы сам Бойд в полном соответствии со своей знаменитой концепцией, американского пилота поместили «внутри цикла принятия решений противостоящей стороны».

Идея Бойда понимать, как поведет себя противник в той или иной ситуации, легла в основу ведения современных войн. Именно этот принцип, заложенный мною в основу методологии Scrum, дает возможность владельцу продукта быстро принимать решения согласно информации, полученной благодаря обратной связи с потребителем. Постоянно взаимодействуя с теми, кто больше других заинтересован в полезных функциях продукта, который создается вашей командой, – любитель Amazon, постоянно кликающий мышкой на кнопку «Купить»; прихожане церковного прихода; учащиеся средней школы; женщина, примеряющая новое платье, – у вас появляется неоспоримое преимущество. Зная ожидания клиента, вы можете регулярно вносить изменения в свою стратегию и очень быстро добиться успеха.

Концепция Бойда называется цикл OODA (звучит странно, если не знать, о чем идет речь). OODA – аббревиатура от наблюдать, ориентироваться, решать, действовать, и хотя название немного забавное, но модель действует безотказно – что на войне, что в бизнесе. Проникнуть внутрь чьего-то цикла принятия решений означает обречь противную сторону на волнение, замешательство и сомнение; у противника возникает на ситуацию или слишком острая, или слишком вялая реакция. Как сказал Бойд на презентации одной из множества своих теорий, «выживает тот, кто быстрее всех справляется со изменением скорости полета»{40}.

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

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

• Решать – к этому этапу приводит комбинация положений наблюдать и ориентироваться.

• Действовать – говорит само за себя.

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

Цикл OODA

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

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

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

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

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

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

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

Милый маленький тесный мир, где ничего не меняется… [существа, живущие в этом мире] – динозавры, они вымрут. Суть дела в том, чтобы не стать динозавром. Если вы находитесь в состоянии равновесия – вы мертвы… Подтекст прост: выхода нет… Вот как обстоят дела, парни{41}.

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

И опять обратимся к Бойду: «Что я хочу сделать со своим противником? Загнать его внутрь его самого… Тогда я смогу привести его в замешательство, расстроить его планы и полностью парализовать его действия». Не знаю, как вы, а я предпочел бы быть тем, кто так действует, а не тем, над кем эти действия производят.

Сначала о главном

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

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

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

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

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

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

Выпуск продукта

Итак, приоритеты расставлены. Вы знаете, где у вас находится 80 процентов ценности. Когда вы выпустите продукт? Методология Scrum поможет вам существенно ускорить достижение результата. Всегда, когда вы что-то делаете, необходимо, чтобы ваш продукт как можно быстрее оказался в руках тех, кто им будет пользоваться. Лучше сделать это еще до того, как будут готовы 20 процентов функций, – за счет той части продукта, которая принесет хотя бы крупицу ценности. Назовем эту часть минимально жизнеспособным продуктом. Это то, что вы в первый раз показываете людям. Насколько он должен быть эффективен? Он действительно должен работать, несмотря на то что человеку, создававшему его, может быть даже неудобно демонстрировать такой продукт. Минимально жизнеспособный продукт следует представить публике как можно раньше! Это даст вам обратную связь, которая необходима для поддержания вашего цикла принятия решений и расстановки приоритетов. Версия 0.5. Фотоаппарат, который умеет снимать, но еще не научился фокусироваться. Набор мебели для столовой, состоящий из двух стульев. Вакцина, которой хватит лишь на пятерых пациентов, а всего у вас сто африканских селений, которым вы пытаетесь помочь. Все эти версии до нелепости недоделаны.

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

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

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

Ускоренный выпуск продукта. Кривая ценности

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

Лучшее качество. Составная стоимость

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

Еще один момент, который стоит обсудить, – это раньше срока завершенный проект. Скажем, вы делаете будильник нового поколения для Alarm Clock. У вас список из многих десятков характеристик: часы, кнопка сброса, таймер, громкий сигнал, радио, док-станция для iPhone, GPS – да мало ли что еще. Но будучи здравомыслящим владельцем продукта, вы расставляете приоритеты в соответствии с тем, что люди на самом деле хотят: будильник, который легко устанавливается, достаточно громкий, с радио и хорошим ярким дисплеем, который будет видно независимо от того, светло в комнате или темно. Когда ваша команда его создала, вы понимаете, что это самый элегантный будильник из когда-либо существовавших. Настоящий Apple iPod среди будильников. Он красив и свою основную функцию выполняет весьма качественно. Вместо того чтобы поручать команде работать над дополнительными функциями, вы выпускаете этот будильник и начинаете работу над новым проектом. Команда может произвести больше ценности, работая над чем-нибудь другим.

Деньги ни за что и изменения бесплатно

В начале книги я рассказывал историю проекта «Страж» в ФБР. Если вы помните, привлеченный подрядчик потратил сотни миллионов долларов, чтобы создать программное обеспечение, которое не работало.

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

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

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

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

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

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

Давайте посчитаем, чтобы увидеть, кто остался в выигрыше. На самом деле и заказчик, и исполнитель. За первые три месяца контракта клиент заплатил команде полтора миллиона долларов. Приостановив контракт раньше времени, он обязан был выплатить 20 процентов от остававшихся 8,5 миллиона – это 1,7 миллиона. Заказчик заплатил 3,2 миллиона долларов за программное обеспечение, которое, по его ожиданиям, должно было обойтись в десять миллионов долларов, а исполнитель получил свои деньги на семь месяцев раньше.

И они были не единственными, кто остался в выигрыше: компания взялась за проект с ожидаемой маржей прибыли в 15 процентов. Поэтому за первые три месяца на разработку они потратили 1,3 миллиона долларов. Но в результате получили 3,2 миллиона долларов. Их маржа прибыли выросла с 15 до 60 процентов. То есть увеличение дохода на 400 процентов. К тому же теперь, когда разработчики освободились, они могут браться за новые проекты. Это не просто хороший бизнес. Это стратегия раннего выхода на пенсию.

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

Риск

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

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

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

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

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

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

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

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

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

Что нужно сделать завтра

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

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

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

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

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

Подведем итоги

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

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

• Лидер не босс. Владелец продукта решает, что должно быть сделано и почему. Каким образом достичь этого и кто будет это делать – команда решает сама.

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

• Наблюдать, ориентироваться, решать, действовать (OODA). Вы должны видеть всю стратегическую картину, однако действовать тактически и быстро.

• Страх, неуверенность и сомнения. Лучше давать, чем получать. Проникните внутрь цикла принятия решений вашим конкурентом.

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

Глава девятая Изменить мир

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

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

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

Образование

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

Алфен-ан-ден-Рейн – именно такой, довольно типичный, маленький городок. Он находится в западной части Нидерландов между Лейденом и Утрехтом, всего в 45 минутах на машине от Амстердама. Если приближаться к Алфен-ан-ден-Рейну в будний день, то все машины будут ехать вам навстречу – на работу. В окрестностях – молочные фермы и ветряные мельницы, старые и новые.

В самом городе в основном ездят на велосипедах. Многие сотни жителей отдают своих детей в местную среднюю общеобразовательную школу, носящую название «Убежище» (Ashram College). Вполне стандартная для Голландии школа, как, собственно, и весь город. В ней учатся около 1800 ребят от двенадцати до восемнадцати лет. В Голландии рано начинают думать о будущем своих детей. Поэтому во многих школах действуют программы начальной профессиональной подготовки – программы неодинаковые, ориентирующие учащихся на виды работ, относящихся к самым разным социальным направлениям. Как правило, все программы делятся на три уровня: низший – для детей, планирующих стать парикмахерами, механиками, секретарями; средний – для детей, желающих работать медицинскими сестрами, администраторами, инженерами, то есть выбравших такие профессии, которые требуют дальнейшего специального образования; высший – для детей, мечтающих изучать медицину или юриспруденцию или думающих о фундаментальной науке, то есть детей, готовящих себя к поступлению в университеты. Учащиеся, остановившиеся на первом уровне, станут трудиться уже в шестнадцать лет; те, кто выбрал более продвинутые программы второго и третьего уровня, пойдут учиться дальше и получат среднее специальное или университетское образование. Школьники, проходя профессиональную подготовку, все равно в обязательном порядке изучают общеобразовательные предметы, набор которых и степень сложности зависят от уровня программ.

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

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

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

Лист разделен на несколько больших колонок, слева направо шли заголовки: «Все задания» (Alle items), «Нужно выполнить» (Te doen), «В работе» (In uit voering), «Выполнено» (Klaar). Внизу колонок были еще четыре надписи: «Характеристики сделанного»; «График» – явно напоминающий диаграмму выгорания задач, обычно в деловом мире иллюстрирующую продвижение команды к цели; «Взгляд в прошлое» – слегка напоминает ретроспективное собрание смарт-команд; «Динамика» – в этой колонке измеряется количество баллов, которые они получают за урок. Учебный процесс разбит на спринты длиной в четыре или пять недель; в конце каждого спринта ученики сдают тест.

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

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

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

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

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

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

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

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

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

– Если я вешу пятьдесят баллов, то сколько баллов весишь ты? – говорит он, обращаясь к худенькой старшекласснице.

– Хм. Сорок? – предполагает она.

– Польстила. Спасибо, конечно. Правда, я сказал бы, что где-то двадцать.

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

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

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

Надо заметить, что Scrum не является очередным подходом-однодневкой, которым кто-то попользовался ради моды и забыл. Наша методика создавалась в расчете не на одного человека и на долгий срок. В голландских школах применение eduScrum тоже не зависит от желания одного человека, даже если он такой замечательный преподаватель, как Вейнандс. Хотя, конечно, началось все с Вилли, а потом он убедил нескольких коллег «Убежища» последовать его примеру, сейчас Scrum используют довольно широко. Благодаря поддержке делового сообщества в Голландии теперь существует специальный фонд eduScrum, который информирует учителей и школы об этой методологии. На сегодняшний день обучение новому методу прошли 74 учителя – преподаватели по разным дисциплинам из двенадцати школ. Планируется через год увеличить их число до шестидесяти учителей из пятнадцати школ. Через пять лет их будет более трехсот из 75 школ. Для начала неплохо. Я ездил по стране и встречался с разными преподавателями, говорившими мне, что по своему значению Scrum не уступает системе Монтессори[47]. Они считают нашу методику настоящим движением.

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

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

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

Нищета

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

Фонд «Грамин» был создан банком Grameen Bank, принадлежащим нобелевскому лауреату Мухаммаду Юнусу, для микрофинансирования и микрокредитования самых бедных жителей Бангладеш. Основная деятельность фонда направлена на помощь, которая оказывается беднейшим слоям населения всего мира, чтобы доведенные до отчаяния люди могли вырваться из нищеты не за счет подачек, а благодаря сильным сторонам своего характера. Свою модель фонд решил опробовать в Уганде, дав бедным возможность нарабатывать собственные знания и умения. Для этого были наняты 1200 человек в бедных сельских регионах. Их назвали общественными информационными работниками. Фонд уже разработал мобильные приложения для своих программ по микрофинансированию и для осуществления кредитных выплат, поэтому было принято решение снабжать информационных работников не просто банковскими данными, но и информацией, которую они могли бы использовать в повседневной жизни, – что в случае Уганды означает ежедневный труд на земле. Фонд выдал местным работникам смартфоны, и таким образом людям обеспечили доступ к лучшему мировому опыту в области сельского хозяйства.

Стив Белл, сотрудник Lean Enterprise Institute и сертифицированный скрам-мастер, недавно посетил две удаленные деревни и описал, как это работает.

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

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

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

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

1. Насколько функции важны для нашей миссии по помощи бедным?

2. Как функции помогут работе информационных сотрудников?

3. Есть ли партнерская поддержка на будущее? (Фонд предпочитает работать не в одиночку, а с партнерами, такими как Фонд Билла и Мелинды Гейтс.)

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

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

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

Меня иногда изумляет, как методология возвращается к своим истокам. Когда я только начинал разрабатывать Scrum, меня вдохновляла деятельность Grameen Bank и других организаций, занимавшихся микрофинансированием. Банк использовал систему «солидарных групп». Это неформальные объединения бедняков-фермеров, собравшихся вместе, чтобы сообща подать заявки на кредитование, сообща получить мизерную, но спасительную для них сумму; сообща трудиться на клочках земли и сообща возвращать кредиты. Каждый участник такой группы предлагал свой план действий из расчета полученных от банка 25 долларов. Один высказывался за покупку тележки, чтобы торговать фруктами на городской площади. Другой предлагал замахнуться на швейную машинку, чтобы шить одежду на продажу. Следующий кредит эта группа получала, только возвратив предыдущий. Они встречались каждую неделю и обсуждали, как могут поддержать друг друга. Результаты потрясали воображение. Женщина, предлагавшая купить швейную машинку, так и поступила. Сначала ее заработка хватало лишь на то, чтобы прокормить детей. Спустя несколько недель она смогла позволить себе купить им ботинки. Через какое-то время она уже отправляла их в школу. Через пару циклов у нее будет свой маленький бизнес, и она начнет строительство настоящего дома. Когда мне стало понятно, как действует схема микрокредитования, я сказал своим разработчикам: «Видите, у этих бедняков нет даже ботинок, и все-таки они вытаскивают себя из нищеты. У вас есть все, даже ботинки, но нет программного обеспечения. Они смогли найти способ работать сообща, чтобы преодолеть безвыходное положение. Не собираетесь ли и вы сделать то же самое?» – так появился Scrum.

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

Правительство

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

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

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

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

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

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

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

Обратим внимание на город, расположенный в нескольких тысячах километров западнее Вашингтона, – Олимпия, столица штата Вашингтон. В этом городе за последние два президентских срока – и когда у власти были республиканцы, и когда теперь правят демократы – внедряли так называемое бережливое правительство. Нынешний губернатор Джей Инсли, занявший свой пост в январе 2013 года, в интервью, которое он дал в рамках предвыборной кампании осенью 2012 года, заметил: «Государство только и занимается тем, что принимает решения. Мы хотим найти способ сократить бумажную волокиту»{42}.

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

1. Система образования – от подготовительного класса до последнего курса университета – должна быть на уровне мировых стандартов.

2. У нас будет процветающая экономика.

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

4. Мы за здоровый образ жизни и безопасные условия проживания.

5. Эффективное, рациональное и ответственное управление.

Это не революционные идеи. Это все лишь то, что каждый нормальный человек ждет от любого правительства. Уже сам факт, что они воспринимаются как набившие оскомину штампы, свидетельствует об их неоспоримой значимости. По сути своей что такое клише? Это истинная правда, повторенная столько раз, что стала банальностью. Смею утверждать, действия администрации губернатора Исли не выглядят банальными. Заслуга принадлежит системе SMART[48], которая гласит: перед собой надо ставить задачи конкретные (specific), измеримые (measurable), достижимые (achievable), актуальные (relevant), ограниченные во времени (time-bound). На самом деле они явно хотят использовать Scrum. По сути, они уже его используют.

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

Для того чтобы справляться со столь огромным объемом работ, в информационной службе штата используют методику Scrum. Были сформированы скрам-команды и даже снесены внутренние стены в помещении. Майкл де Анджело, заместитель директора информационной службы, говорит, что они стараются каждую неделю снабжать учреждения штата пригодными для использования практическими директивами:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Изменись или умри.

Как мы станем работать в один прекрасный день

Во второй главе этой книги я уже говорил о взятом из боевых искусств понятии сюхари (Shu Ha Ri). В состоянии Сю человек четко следует правилам, таким образом знакомясь со стоящими за ними идеями. В состоянии Хa человек начинает создавать собственный стиль, но при этом остается в границах обозначенных правил, лишь адаптируя их под свои потребности. В состоянии Ри человек окончательно избавляется от правил и создает самою идею. Смотреть на настоящего мастера в состоянии Ри – все равно что смотреть на воплощенное произведение искусства. Его действия кажутся невозможными – мастер превратился в философскую идею. Идею, ставшую реальностью.

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

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

Фирма Valve была основана в 1990 году и занималась созданием компьютерных игр, именно здесь были разработаны такие революционные хиты, как Half-Life и Portal. Valve самостоятельно себя финансирует и полностью владеет своей интеллектуальной собственностью. Почти все триста с лишним сотрудников фирмы сидят в одном офисном здании в Бельвю, штат Вашингтон. У нее более пятидесяти миллионов клиентов, а годовой оборот составляет сотни миллионов долларов. По сути, фирмой никто не руководит.

Valve вышла из Microsoft. Сегодня Microsoft – совсем другая компания, а когда-то, в 1990-е годы, она являла собой образец иерархической структуры. Каждый должен был понимать, какую ступень корпоративной лестницы он занимает; более того, каждый должен был осознавать, сколько таких ступеней отделяет его от основателя и главы компании Билла Гейтса – на то время самого богатого человека в мире, а на сегодняшний день одного из самых богатых.

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

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

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

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

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

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

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

Вы подумаете про себя: «О, так это огромная ответственность», – и будете совершенно правы{43}.

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

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

Грег описывает, как это происходило с продуктом Big Picture. Один из крупнейших продуктов Valve – это игровая платформа Steam. Через нее пользователи получают доступ к играм и программам. На платформе представлены как игры Valve, так и игры других разработчиков. На сегодняшний день это стало стандартным способом распространения компьютерных игр. Но по воспоминаниям Грега, на каком-то этапе он и еще несколько его коллег опасались, что Valve достигла максимума клиентов – более пятидесяти миллионов.

[Мы] начали думать, как развивается фирма и как растет Steam, и то, что мы увидели, нам казалось пределом. Это был наш потолок клиентов. А нам хотелось оказаться в доме каждого человека, прямо в кресле у него в гостиной, нам хотелось попасть в каждый сотовый телефон. Да где и куда угодно – лишь бы быть с клиентом.

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

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

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

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

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

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

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

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

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

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

Он делает небольшую паузу, а потом уверенно заявляет:

Через год мы с этим разберемся.

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

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

Используют ли они Scrum? Если послушать Грега, то у них в фирме множество офисных досок на колесиках и все они покрыты стикерами. Но в Valve не заставляют людей применять Scrum. Люди сами выбирают, какой процесс им больше всего подходит. Как и во всем остальном, Грег и другие основатели фирмы воздерживаются от того, чтобы указывать другим, что им делать. Но очень многие сотрудники Valve, имея возможность выбирать собственный путь, останавливаются на методике Scrum. А мне и этого достаточно.

Пока таких компаний немного. Но с каждым днем их становится больше. И не только в области разработки программного обеспечения. В Morning Star, мировом лидере в области обработки томатов, нет начальников. Каждый сотрудник сам обговаривает с остальными свою роль и зону ответственности, будь то продажа, вождение грузовика или высокотехнологичная инженерная работа. В любой компании сначала нужно дать сотрудникам почувствовать себя свободными, а потом приучить их к ответственности, которая следует из этой свободы. Или, как пела в семидесятые группа Funkadelic: «Освободи свою голову, и тогда задница последует за нею»[49].

Что мы не можем?

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

Циники понимающе вздохнут: «Так уж устроен мир. Люди от природы испорчены и эгоистичны. Делать вид, что все обстоит иначе, довольно наивно». Таким образом они оправдывают насилие и стараются дать разумное объяснение запрету на личную свободу. Последние два десятилетия я изучал литературу об истоках величия. Поразительно, но люди стремятся стать великими. Они хотят совершать что-то важное. Пусть на чуть-чуть, но мир станет лучше. Важно уметь избавляться от всего, что стоит на пути к величию. Люди сметают преграды, мешающие им стать теми, кем они могли бы быть. В этом им помогает Scrum. Методология Scrum учит ставить цели и систематично, шаг за шагом, приближаться к результату. Самое главное, что, применяя Scrum, вы знаете, как выявлять препятствия на пути к желаемому.

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

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

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

Все люди видят сны, но по-разному. Сны, которые приходят ночью из отдаленных пыльных уголков разума, тают с наступлением дня и превращаются в ничто. Те же, кто видит сны наяву, с открытыми глазами, – опасные люди. Они могут превратить сны в реальность{45}.

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

Подведем итоги

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

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

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

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

Приложение Внедряем Scrum. С чего начать

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

1. Выберите ВЛАДЕЛЬЦА ПРОДУКТА. Это человек, обладающий видением того, что вы собираетесь делать, производить, достигать. Он принимает во внимание риски и выгоды, что нужно выполнить, что может быть сделано и что вас воодушевит.

Глава 8. «Приоритеты»

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

Глава 3. «Команды»

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

Глава 5. «Потери – это преступление»

4. Создайте БЭКЛОГ ПРОДУКТА. Это список абсолютно всех требований, предъявляемых к продукту и расставленных по их приоритету. Бэклог существует и развивается на протяжении всей жизни продукта, чьим ориентиром он является. Бэклог продукта – единственная и однозначная концепция «всего, что команда в принципе может сделать, в порядке приоритетности». Существует только один бэклог продукта. Это означает, что владелец продукта должен принимать решения о приоритетности на основе всего спектра задач. Владелец продукта должен беседовать со всеми заинтересованными лицами и командой, чтобы гарантировать всю полноту обратной связи и отображать в бэклоге все требования и пожелания потребителя.

Глава 8. «Приоритеты»

5. Уточните и оцените БЭКЛОГ ПРОДУКТА. Крайне важно, чтобы участники группы, которые будут выполнять задания из бэклога, оценили, сколько усилий это потребует. Команда должна взглянуть на каждую задачу и определить, выполнима ли она в принципе. Достаточно ли информации, чтобы выполнить задачу? Достаточно ли она обозрима, чтобы ее можно было оценить? Есть ли общее понимание, каким стандартам и критериям она должна соответствовать, чтобы быть выполненной? Создается ли при этом действительная стоимость? Должна быть обеспечена возможность продемонстрировать результат выполнения каждой задачи. Не оценивайте задания бэклога в часах, поскольку люди плохо с этим справляются. Оценивайте в относительных размерах: «малый», «средний», «большой». Лучше использовать последовательность Фибоначчи и присваивать каждой задаче количество баллов: 1, 2, 3, 5, 8, 13, 21.

Глава 6. «Планируйте реальность, а не пустую мечту»

6. ПЛАНИРОВАНИЕ СПРИНТА. Это первое скрам-собрание. Команда, скрам-мастер и владелец продукта планируют спринт. Спринты всегда имеют фиксированную продолжительность, которая должна быть меньше месяца. Как правило, выбирают спринты длиной в одну или две недели. Команда смотрит в верхнюю часть бэклога и прогнозирует количество заданий, которое возможно выполнить за этот спринт. Если команда уже прошла пару спринтов, ей следует учитывать то число баллов, которое было в прошлом спринте. Количество баллов мы называем ДИНАМИКОЙ ПРОИЗВОДИТЕЛЬНОСТИ. Скрам-мастер и команда должны в каждом спринте наращивать динамику.

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

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

Глава 6. «Планируйте реальность, а не пустую мечту»

7. РАБОТА ДОЛЖНА БЫТЬ ВИДИМОЙ. Прозрачность всех действий и процессов обеспечивает скорейшее достижение цели. Наиболее распространенный способ добиться этого – завести СКРАМ-ДОСКУ с колонками: «Нужно сделать, или бэклог»; «В работе»; «Сделано». Стикеры – это пользовательские требования, которые нужно реализовать; по мере того как они выполняются, команда перемещает стикеры из одной колонки в другую.

Еще один способ сделать работу видимой – создать ДИАГРАММУ ВЫГОРАНИЯ ЗАДАЧ. На одной оси – количество баллов, которое команда взяла в этом спринте, на другой – количество дней. Каждый день скрам-мастер подсчитывает количество баллов за выполненные задачи и отражает это на графике. В идеале к концу спринта должен быть резкий спад до нуля.

Глава 7. «Счастье»

8. ЕЖЕДНЕВНОЕ СОБРАНИЕ НА ХОДУ, или ЕЖЕДНЕВНЫЙ SCRUM. Это пульс всего процесса Scrum. Каждый день в одно и то же время не более чем на пятнадцать минут команда и скрам-мастер встречаются и дают ответы на три вопроса.

1. Что ты делал вчера, чтобы помочь команде завершить спринт?

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

3. Какие препятствия встают на пути команды?

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

Глава 4. «Время»

Глава 6. «Планируйте реальность, а не пустую мечту»

9. ОБЗОР СПРИНТА. Это встреча, на которой команда рассказывает, что сделано за спринт, и демонстрирует готовые части продукта. Присутствуют владелец продукта, скрам-мастер, команда и любые заинтересованные лица: заказчик, представители руководства, потенциальные потребители. Это открытая встреча, где команда демонстрирует, что удалось переместить в колонку «Сделано» за время спринта.

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

Глава 4. «Время»

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

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

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

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

Глава 7. «Счастье»

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

Благодарности

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

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

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

Мне несказанно повезло сотрудничать с Риком Хоганом из Crown Publishing Group – не так часто случается работать с настоящим мастером своего дела. В его умелых руках материал сразу становится лучше. Благодаря ему всегда казалось, что все очень просто. Снимаю шляпу и выражаю самую искреннюю благодарность.

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

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

Благодарю своего товарища и соавтора в создании методологии Scrum Кена Швабера, чье неистовое упрямство помогло придать Scrum форму и сделать той силой, в которую она превратилась сегодня.

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

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

Об авторе

Джефф Сазерленд – советник венчурного фонда OpenView Venture Partners и глава компании Scrum.

В 1993 году он создал методику Scrum и в 1995-м формализовал ее вместе с Кеном Швабером. Сегодня эта методология используется во всем мире.

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

Сноски

1

Цикл OODA (OODA loop), или петля OODA, или петля Бойда, включает в себя четыре составляющих: observe («наблюдать»), orient («ориентироваться»), decide («решать»), act («действовать»). См. подробно в главе 8. Здесь и далее примечания редактора.

(обратно)

2

Комиссия 11 сентября (The 9/11 Commission), полное название – Национальная комиссия по террористическим атакам против Соединенных Штатов; сформирована 27 ноября 2002 г. – Здесь и далее прим. ред.

(обратно)

3

Чед Фулгэм отчитывался перед генеральным инспектором, поскольку ФБР, представляя собой подразделение не только разведывательного сообщества США, но и Министерства юстиции США, подчиняется одновременно директору Национальной разведки и генеральному прокурору. Служба генерального инспектора занимается ревизией и аудиторскими проверками с целью контроля за расходованием средств. Во время описываемых событий генеральным инспектором был Гленн Файн (2000–2011).

(обратно)

4

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

(обратно)

5

Тайити Оно. Производственная система Тойоты. Уходя от массового производства. М.: Институт комплексных стратегических исследований, 2008.

(обратно)

6

Тайити Оно. Производственная система Тойоты…, с. 176.

(обратно)

7

Единица работы (work item) – задача процесса разработки, состоящая из запроса и получения результата его обработки.

(обратно)

8

Аннаполис (Annapolis) – разговорное название Военно-морской академии США, где готовят офицеров для ВМС и Корпуса морской пехоты; расположена в г. Аннаполисе.

(обратно)

9

Перевод Е. Трибушной; цит. по книге: Джефри Пфеффер. Власть, влияние и политика в организациях. М.: Манн, Иванов и Фербер, 2014, с. 404.

(обратно)

10

Инкрементальное (инкрементное) тестирование (incremental testing) – согласно «Стандартному глоссарию терминов, используемых в тестировании программного обеспечения», это тестирование, при котором компоненты или системы интегрируются и тестируются по одному или вместе до тех пор, пока все компоненты или системы не интегрированы и не протестированы.

(обратно)

11

Обычно при проведении многоцентровых исследований главный исследователь (principal investigator) – это представитель одного из центров, принимающий участие в разработке протоколов, рецензирующий и подписывающий заключительный отчет и координирующий работу всех исследовательских центров; в рамках программы одного центра главный исследователь возглавляет данную исследовательскую группу.

(обратно)

12

Пассивно-агрессивное поведение (passive-aggressive behavior) характеризуется прежде всего скрытой враждебностью, подавлением проявления гнева и напряженным образом общения.

(обратно)

13

Массачусетский технологический институт, МТИ (Massachusetts Institute of Technology, MIT) по статусу считается университетом и исследовательским центром; другие названия на русском языке: Массачусетский институт технологий (МИТ) и Массачусетский технологический университет.

(обратно)

14

НАСА (NASA) – аббревиатура от National Aeronautics and Space Administration (Национальное управление по воздухоплаванию и исследованию космического пространства).

(обратно)

15

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

(обратно)

16

Обе спортивные команды базируются в Бостоне. «Бостон Селтикс» (Boston Celtics) – американский профессиональный баскетбольный клуб; в 1980-е гг. «Бостон» три раза выигрывал титул чемпиона НБА. «Нью-Ингленд Пэтриотс» (New England Patriots – «Патриоты из Новой Англии») – профессиональный клуб по американскому футболу, выступающий в НФЛ; Том Брэди (Tom Brady) – бессменный квотербек «Патриотов» с 2000 года, признанный одним из лучших игроков в истории американского футбола.

(обратно)

17

Лари Бёрд (Larry Bird), Кевин Макхейл (Kevin McHale), Роберт Пэриш (Robert Parish) – автор вспоминает знаменитых баскетболистов, известных как «Большая тройка “Бостона”», которая вывела в 1980–1992 гг. свою команду на уровень одной из сильнейших в истории НБА.

(обратно)

18

Свободная пара (Loose Deuce) – пара истребителей из группы резерва (как правило, и ведущий, и ведомый – оба опытные пилоты), которая, выполняя задачу охранения, следит за ходом боя и уничтожает отдельные оторвавшиеся самолеты противника.

(обратно)

19

Это административное здание знаменито тем, что является подарком СССР Египту и построено в стиле сталинского ампира.

(обратно)

20

Перевод Т. Ломоносовой; цит. по книге: Ричард Фейнман. Радость познания. М.: АСТ, 2013, с. 32.

(обратно)

21

Боб Вудворд (Bob Woodward) – американский политический журналист, бессменный редактор Washington Post (с 1971 года); один из самых известных журналистов не только в США, но и в мире. Вместе с Карлом Бернстайном в 1972 году стал инициатором политического расследования, получившего в дальнейшем известность как «Уотергейтский скандал»; в фильме «Вся президентская рать» (1977) молодого Вудворда сыграл Роберт Редфорд.

(обратно)

22

Имеются в виду силы иракской самообороны – коалиция «Сыны Ирака».

(обратно)

23

«Немигающий глаз» (Unblinking Eye) – так называлась одна из первых операций по выслеживанию руководителей «Аль-Каиды», предпринятая Объединенным командованием специальных операций США еще в 2002 году; в данной статье это выражение употребляется метафорически.

(обратно)

24

Фредерик Брукс. Мифический человеко-месяц, или Как создаются программные системы. СПб.: Символ-Плюс, 2010.

(обратно)

25

Фредерик Брукс. Мифический человеко-месяц…, с. 22.

(обратно)

26

FBI (Federal Bureau of Investigation) – Федеральное бюро расследований; CBS (Central Bureau of Statistics) – Центральное статистическое управление; IBM (International Business Machines) – американская компания; IRS (Internal Revenue Service) – Налоговое управление.

(обратно)

27

«Олл Блэкс» (All Blacks букв. «Полностью в черном») – прозвище сборной Новой Зеландии по регби.

(обратно)

28

John H. Holland, Keith J. Holyoak, Richard E. Nisbett, Paul Thagard. Induction: Processes of Inference, Learning, and Discovery. Massachusets Institute of Technology: A Bradford Book, 1989.

(обратно)

29

Эндрю Марвелл. «Застенчивой возлюбленной», пер. Иосифа Бродского.

(обратно)

30

Carpe diem (лат. досл. «лови день») – фраза из Горация («Оды», I, 11, 7–8), ставшая крылатым выражением «лови момент».

(обратно)

31

Justice означает «справедливость, законность».

(обратно)

32

Тайити Оно. Производственная система Тойоты…, с. 176.

(обратно)

33

Джеймс П. Вумек, Дэниел Т. Джонс, Дэниел Рус. Машина, которая изменила мир. М.: Попурри, 2007.

(обратно)

34

RAND – аббревиатура от Research and Development (американская корпорация, являющаяся стратегическим исследовательским центром; некоммерческая организация).

(обратно)

35

Дельфийский метод, или метод Дельфи (Delphi Method) – метод экспертного оценивания; разработан в 1950–1960-е гг. в RAND для прогнозирования влияния будущих научных разработок на методы ведения войны.

(обратно)

36

Намылить, смыть, повторить (Lather, rinse, repeat) – стандартная инструкция по применению любого шампуня; используется как клише в айтишной профессиональной среде, когда речь заходит о неправильно сформулированном техническом задании или бессмысленности повторения циклов.

(обратно)

37

Жан-Люк Пикар (фр. Jean-Luc Picard) – персонаж кинофраншизы «Звездный путь».

(обратно)

38

Tal Ben-Shahar. Happier: Learn the Secrets to Daily Joy and Lasting Fulfillment. McGraw-Hill, 2007; перевод на русский язык: Бен-Шахар Тал. Быть счастливее. М.: Манн, Иванов и Фербер, 2012.

(обратно)

39

Бен-Шахар Тал. Быть счастливее…, с. 40.

(обратно)

40

Tony Hsieh. Delivering Happiness: A Path to Profits, Passion, and Purpose. New York: Business Plus, 2010; перевод на русский язык: Тони Шей. Доставляя счастье. От нуля до миллиарда. История создания выдающейся компании из первых рук. М.: Манн, Иванов и Фербер, 2015.

(обратно)

41

В переводе Т. Л. Щепкиной-Куперник.

(обратно)

42

Бэклог (backlog – букв. «большое бревно для камина»; «запас; резерв») – в американской деловой лексике обычно означает «портфель, или журнал, заказов; портфель нерассмотренных заявок».

(обратно)

43

Сюса – статус главного монаха в монастырях школы дзен.

(обратно)

44

Стандартное боевое оснащение истребителя F-86 «Сейбр» – шесть крупнокалиберных пулеметов M2 системы браунинг.

(обратно)

45

Robert Coram. Boyd: The Fighter Pilot Who Changed the Art of War. New York: Back Bay Books, 2004.

(обратно)

46

«Во все тяжкие» (Breaking Bad) – американский телесериал (2008–2013) о скромном преподавателе химии, волею судьбы ставшем воротилой в наркобизнесе; работал в паре со своим бывшим учеником.

(обратно)

47

Система Монтессори – методика воспитания, предложенная в первой половине XIX века итальянским педагогом Марией Монтессори; основана на индивидуальном подходе педагога к каждому ребенку.

(обратно)

48

Впервые предложена Питером Друкером в 1950-е годы.

(обратно)

49

Free your mind… and your ass will follow.

(обратно)

50

Томас Эдвард Лоуренс. Семь столпов мудрости. М.: Терра – Книжный клуб, 2001.

(обратно)(обратно)

Комментарии

1

Dan Eggen, Griff Witte. The FBI’s Upgrade That Wasn’t. $170 Million Bought an Unusable Computer System // Washington Post, 2006, August 18, p. A1.

(обратно)

2

Status of the Federal Bureau of Investigation’s Implementation of the Sentinel Project. US Department of Justice, Office of the Inspector General. Report 11–01, October 2010.

(обратно)

3

Status of the Federal Bureau of Investigation’s Implementation of the Sentinel Project. US Department of Justice, Office of the Inspector General. Report 11–01, October 2010.

(обратно)

4

Taiichi Ohno. Toyota Production System: Beyond Large-Scale Production. Cambridge, MA: Productivity Press, 1988, p. 129.

(обратно)

5

Theodore Roosevelt. Citizenship in a Republic. Speech at the Sorbonne, Paris, France, 1910, April 23.

(обратно)

6

Hirotaka Takeuchi, Ikujiro Nonaka. The New New Product Development Game // Harvard Business Review, 1986, January/February, p. 285–305.

(обратно)

7

Ken Schwaber. Scrum Development Process // D. Patel, C. Casanave, G. Hollowell, J. Miller. Business Object Design and Implementation: OOPSLA’95 Workshop Proceedings / Eds. J. Sutherland, D. Patel. London: Springer, 1997.

(обратно)

8

W. Edwards Deming. To Management. Speech at Mt. Hakone Conference Center, Japan, 1950.

(обратно)

9

Hirotaka Takeuchi, Ikujiro Nonaka. The New New Product Development Game // Harvard Business Review, 1986, January/February, p. 285–305.

(обратно)

10

Douglas MacArthur. The Long Gray Line. Speech at West Point, New York, 1962.

(обратно)

11

Douglas MacArthur. The Long Gray Line. Speech at West Point, New York, 1962.

(обратно)

12

R. P. Feynman. Personal Observations on Reliability of Shuttle // Report of the Presidential Commission on the Space Shuttle Challenger Accident, vol. II, Appendix F. United States Government Printing, 1986.

(обратно)

13

Joby Warrick, Robin Wright. U.S. Teams Weaken Insurgency in Iraq // Washington Post, 2006, September 6.

(обратно)

14

Michael Flynn, Rich Jergens, Thomas Cantrell. Employing ISR: SOF Best Practices // Joint Force Quarterly, iss. 50, 2008, 3rd Quarter, p. 60.

(обратно)

15

Christopher Lamb, Evan Munsing. Secret Weapon: High-value Target Teams as an Organizational Innovation. Series «Institute for National Strategic Studies, Strategic Perspectives, no 4. Washington: National Defense University Press, 2011, p. 53, 54.

(обратно)

16

Frederick P. Brooks. The Mythical Man-Month: Essays on Software Engineering. Reading, MA: Addison – Wesley, 1975, p. 25.

(обратно)

17

Nelson Cowan. The magical number 4 in short-term memory: A reconsideration of mental storage capacity // Behavioral and Brain Sciences, 2001, vol. 24, no 1, p. 87–185.

(обратно)

18

Richard E. Nisbett, Craig Caputo, Patricia Legant, Jeanne Marecek. Behavior as Seen by the Actor and as Seen by the Observer // Journal of Personality and Social Psychology, 1973, vol. 27, no 2, p. 154–164.

(обратно)

19

Stanley Milgram. The Perils of Obedience // Harper’s Magazine, 1974, December.

(обратно)

20

Andrew Marvell. To His Coy Mistress (1681).

(обратно)

21

Taiichi Ohno. Toyota Production System: Beyond Large-Scale Production. Cambridge, MA: Productivity Press, 1988.

(обратно)

22

David Strayer, Frank Drews, Dennis Crouch. A Comparison of the Cell Phone Driver and the Drunk Driver // Human Factors, 2006, Summer, vol. 48, no 2, p. 381–391.

(обратно)

23

David M. Sanbonmatsu, David L. Strayer, Nathan Medeiros-Ward, Jason M. Watson. Who Multi-Tasks and Why? Multi-Tasking Ability, Perceived Multi-Tasking Ability, Impulsivity, and Sensation Seeking // PLoS One, 2013, vol. 8, no 1, e54402.doi:10.1371/journal.pone.0054402.

(обратно)

24

Gerald M. Weinberg. Quality Software Management: Systems Thinking. New York: Dorset House, 1991.

(обратно)

25

Harold Pashler. Dual-task Interference in Simple Tasks: Data and Theory // Psychological Bulletin, 1994, September, vol. 116, no 2, p. 220–244.

(обратно)

26

Sylvain Charron, Etienne Koechlin. Divided Representation of Concurrent Goals in the Human Frontal Lobes // Science, 2010, vol. 328, no 5976, p. 360–363.

(обратно)

27

Glenn Wilson. The Infomania Study. Issue brief ().

(обратно)

28

James P. Womack, Daniel T. Jones, Daniel Roos. The Machine That Changed the World: The Story of Lean Production. New York: Harper Perennial, 1991, p. 91.

(обратно)

29

Shai Danziger, Jonathan Levav, Liora Avnaim-Pesso. Extraneous Factors in Judicial Decisions // Proceedings of the National Academy of Sciences of the United States of America, 2011, vol. 108, no 17, p. 6889–6892.

(обратно)

30

Kathleen D. Vohs, Roy F. Baumeister, Jean M. Twenge, Brandon J. Schmeichel, Dianne M. Tice, Jennifer Crocker. Decision Fatigue Exhausts Self-Regulatory Resources – But So Does Accommodating to Unchosen Alternatives, 2005 ().

(обратно)

31

Mike Cohn. Agile Estimation and Planning. Upper Saddle River, NJ: Prentice Hall, 2005.

(обратно)

32

Sushil Bikhchandani, David Hirshleifer, Ivo Welch. A Theory of Fads, Fashion, Custom, and Cultural Change as Informational Cascades // Journal of Political Economy, 1992, October, vol. 100, no 5, p. 992–1026.

(обратно)

33

Edward Lee Thorndike. A Constant Error in Psychological Ratings // Journal of Applied Psychology, 1920, vol. 4, no 1, p. 25–29.

(обратно)

34

Norman Crolee Dalkey, Olaf Helmer-Hirschberg. An Experimental Application of the Delphi Method to the Use of Experts // Management Science, 1963, April, vol. 9, iss. 3, p. 458–467.

(обратно)

35

Sonja Lyubomirsky, Laura King, Ed Diener. The Benefits of Frequent Positive Affect: Does Happiness Lead to Success? // Psychological Bulletin, 2005, November, vol. 131, no 6, p. 803–855.

(обратно)

36

Gretchen Spreitzer, Christine Porath. Creating Sustainable Performance // Harvard Business Review, 2012, January/February, p. 3–9.

(обратно)

37

Gretchen Spreitzer, Christine Porath. Creating Sustainable Performance // Harvard Business Review, 2012, January/February, p. 3–9.

(обратно)

38

John Shook. The Remarkable Chief Engineer // Lean Enterprise Institute, 2009, February 3.

(обратно)

39

Daniel Ford. A Vision So Noble: John Boyd, the OODA Loop, and America’s War on Terror. CreateSpace Independent Publishing Platform, 2010.

(обратно)

40

John Boyd. New Conception for Air-to-Air Combat. 1976, 4 August.

(обратно)

41

John Boyd. New Conception for Air-to-Air Combat. 1976, 4 August.

(обратно)

42

Brad Shannon. McKenna, Inslee Outline Plans to Bring Efficiency to Government // The Olympian, 2012, October 6.

(обратно)

43

Valve Handbook for New Employees. Bellevue, WA: Valve Press, 2012.

(обратно)

44

Valve Handbook for New Employees. Bellevue, WA: Valve Press, 2012.

(обратно)

45

Thomas Edward Lawrence. Seven Pillars of Wisdom: A Triumph. London: Cape, 1973.

(обратно)(обратно)

Оглавление

Эту книгу хорошо дополняют:

Предисловие партнера к российскому изданию

Введение

Глава первая Привычное мироустройство дает трещину

  Каскадная модель

  Новое мышление

  ФБР устраняет препятствия

Глава вторая Истоки и рождение Scrum

  Берите пример с робота

  Не ныряйте в водопад

  Проверять и адаптироваться

  Измениться или умереть

  Сюхари Глава третья Команды

  Серая шеренга

  Scrum на площади Тахрир

  Одной командой – от начала и до конца

  Scrum во время боевых действий

  Размер имеет значение – но это не то, о чем вы подумали

  Скрам-мастер

  Вините не игрока, а игру

  Достигнуть величия Глава четвертая Время

  Спринт

  Ежедневные собрания на ходу

  Раз за разом Глава пятая Потери – это преступление

  Не беритесь за все сразу

  Сделанное наполовину – не сделано никогда

  Получайте результат с первого раза

  Напряженный труд порождает еще больше работы

  Будьте благоразумны

  Поток Глава шестая Планируйте реальность, а не пустую мечту

  Планирование свадьбы

  Размер имеет значение, но только относительное

  Последовательность Фибоначчи – повсюду вокруг нас

  Дельфийский оракул

  Покер планирования

  Никаких заданий. Нам нужны истории и факты

  Короткие истории

  Готовность и выполненность

  Планирование спринта

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

  Счастье – это успех

  Количественная сторона счастья

  Делать все в открытую

  Доставляя счастье

  «Пузырь счастья» должен лопнуть

  Счастливы сегодня, счастливы завтра Глава восьмая Приоритеты

  Бэклог. Что и когда делать

  Владелец продукта

  Наблюдать, ориентироваться, решать, действовать

  Сначала о главном

  Выпуск продукта

  Деньги ни за что и изменения бесплатно

  Риск

  Что нужно сделать завтра

Глава девятая Изменить мир

  Образование

  Нищета

  Правительство

  Как мы станем работать в один прекрасный день

  Что мы не можем?

Приложение Внедряем Scrum. С чего начать

Благодарности

Об авторе

Fueled by Johannes Gensfleisch zur Laden zum Gutenberg