Джефф Сазерленд
Scrum. Революционный метод управления проектами
Не ныряйте в водопад
Я все более осознавал, каких впечатляющих результатов можно достичь, если мне удастся создать систему, которая, подобно роботу Брукса, будет координировать действия отдельных независимых в своих суждениях специалистов и обеспечивать им постоянную взаимосвязь с окружающей средой. Достаточно оптимизировать обмен информацией между «конечностями» рабочей группы, и мы добьемся эффективности, о которой раньше не смели мечтать.
Моя встреча с Родни Бруксом произошла более двадцати лет назад. На протяжении длительного времени он был главой направления робототехники и искусственного интеллекта в МТИ, а тот паукообразный робот, по кличке Чингисхан, тогда вбежавший в мой кабинет, теперь в качестве экспоната находится в музее Смитсоновского института. Вероятно, вам знакома одна из сегодняшних компаний Брукса – 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}.
Следующий занимавший меня вопрос: как удается создать команду, которая будет постоянно ставить перед собой все более высокие цели, обладать эффектом самоорганизации и поддерживать атмосферу взаимного обогащения знаниями и идеями? На выяснение этого мне пришлось потратить довольно много времени. И то сказать, каким образом добиться от людей, чтобы они сплотились в единую самоорганизующуюся группу, постоянно думающую о саморазвитии? Вряд ли в данном случае помогут муштра и окрики – ведь у каждого человека должны появиться собственные стимулы. Давление только убьет то, к чему мы стремимся. Очевидно, есть простой набор правил, при помощи которых можно творить чудеса?
