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

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

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

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

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

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

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

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

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

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

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

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

ПРОВЕРЯТЬ И АДАПТИРОВАТЬСЯ

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

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

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