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

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

 

 

 

 

* * *

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

 

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

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

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

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

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. С тех пор релизы у нас бывают не реже трех раз в год. Не так много крупных компаний могут похвастаться таким результатом».

 

 

Конец ознакомительного фрагмента — скачать книгу легально

 

[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.

 

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

1950. 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

1986. 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.