Справилась ли группа со своими проблемами? Скажем так: помехи, имевшие отношение к элементарному бардаку, личным конфликтам и простым сбоям в оперативном поиске информации, были устранены довольно быстро. Коллектив стал работать как отлично отлаженный механизм, который совсем не нуждался во внешнем управлении. Члены команды научились справляться с организацией своей работы самостоятельно. Бригада NPR подготовила огромное количество передач из Каира — еще несколько недель назад о таком прорыве никто даже помыслить не мог. Качество их репортажей было выше, чем у конкурентов. В итоге за свою работу команда получила ряд профессиональных наград. Это был настоящий успех. Вряд ли репортеры и продюсеры смогли бы его добиться, если бы у них не появилось, во-первых, понимание общей цели (освещать, может быть, самое большое событие, случившееся за их профессиональную деятельность), во-вторых, режима полной автономности (возможность принимать самостоятельные решения во время подготовки информационного материала и выбора сюжетов для своих репортажей).
Сегодня в National Public Radio применяют Scrum на всех уровнях работы: при проектировании веб-приложений; в журналистике данных, когда приходится прибегать к специальным программам, чтобы обрабатывать большие информационные массивы; для создания новых радиопрограмм. Методологией Scrum начали пользоваться коллективы Chicago Tribune, New York Times, Washington Post и ProPublica. Когда речь идет о жестких сроках, скорость просто необходима.
ОДНОЙ КОМАНДОЙ — ОТ НАЧАЛА И ДО КОНЦА
Осталась третья ножка нашего треногого табурета — многофункциональность великих команд, то есть укомплектованность всеми специалистами, сумма навыков которых необходима для выполнения работы. В классически организованной структуре обычно есть отделы планирования, разработки, тестирования, а также отделы производственный и транспортный, и все они наполнены сотрудниками с соответствующими квалификациями. Каждый коллектив выполняет свою часть работы, прежде чем проект переходит к следующей фазе. Ни одна из перечисленных команд не в состоянии выпустить продукт исключительно своими силами.
Классический пример представляет собой система поэтапного планирования программ НАСА — так называемая ступенчато-шлюзовая модель, которую применяли для процесса разработки и производства шаттлов и прочих космических аппаратов в 1960–1980-е годы. Сейчас в НАСА все происходит иначе, но я хочу описать, как был организован тот старый рабочий процесс.
Первая ступень — этап исследования проблемы, во время которого решалось, на что, собственно, следует замахнуться (скажем, на космический корабль, который полетит на Луну). В одной комнате собирались специалисты-теоретики и начинали вовсю предаваться мечтам. Первый шлюз — этап отмашки, когда самый главный начальник встречался с группой руководителей и вместе они подтверждали, что данный проект стоит попытаться осуществить. Вторая ступень — этап определения масштабов работ. Звали профессионалов, разбиравшихся в стандартах и требованиях к разработке, которые долго гадали, что же эта штука должна будет делать. Далее следовал второй шлюз — еще один этап отмашки, состоявший из серии совещаний. После чего огромный пакет документации передавался на третью ступень — этап возведения экономической системы модели и ее технического проекта. Наступала легкая передышка в виде третьего шлюза — этап очередной отмашки. Снова серия совещаний, на которых все планы вновь обсуждались и вновь получали одобрение. Четвертая ступень — этап разработки прототипа изделия. Потом приходила очередь четвертого шлюза — этап следующей отмашки. Проводилось немало совещаний, создавалась солидная куча документов, и продукт вручался совершенно другой группе для проведения пятой ступени — этапа испытания. Специалисты, ранее ни разу не видевшие изделия, проверяли его рабочие характеристики, подписывали бумаги, что оно исправно, и передавали всю документацию… Пятый шлюз — этап, ну конечно, отмашки. Серия бесконечных совещаний с бесконечными штабелями документов, которые никто не читал. И только тогда наступала очередь шестой ступени — этап ввода в эксплуатацию. Изделие передавалось шестой по счету группе специалистов, которым, собственно, предстояло запускать космический корабль.
Утомляет даже писать об этом. Однако дела в НАСА велись именно так.
В начале 1980-х годов кто-то из руководителей Fuji-Xerox приехал в Америку, чтобы посмотреть, как работает знаменитое космическое агентство. Когда он вернулся в Японию и ввел в производство те же бесконечные процедуры, его компания тут же выдала следующие показатели: резкое снижение качества продукции, высокий процент сбоев, существенный спад эффективности работы. Они немедленно отказались от ступенчато-шлюзовой модели. По мнению японских производителей, существовала огромная вероятность, что система поэтапного планирования привела бы их к катастрофическим результатам.
Строго говоря, случившаяся в 1986 году катастрофа при запуске «Челленджера» стала бесспорным подтверждением этому. Для расследования крушения шаттла была создана специальная комиссия под руководством Уильяма Роджерса, которая пришла к такому же выводу. В работе комиссии принял участие выдающийся физик Ричард Фейнман. Его доклад опубликован в отчете комиссии, правда, не в основном его корпусе, а в приложении. Приведу лишь несколько строк из его особого мнения:
Может оказаться, что для любой цели, для внутреннего и внешнего потребления, руководство НАСА преувеличивает надежность своего продукта до фантастических цифр4, [20].
Факт остается фактом: лучшие коллективы работают иначе. Ни в Toyota или 3M — чей пример вдохновил в свое время Такеучи и Нонаку, — ни в современных Google, Salesforce.com или Amazon мы не найдем подобного «разделения труда». В таких компаниях любая самая маленькая рабочая группа делает все от начала и до конца.
Никола Дурамбе является вице-президентом по вопросам гибкой инфраструктуры релизов Salesforce.com — компании, которая стабильно держится в списках ста лучших работодателей по версии журнала Fortune и лучших инновационных компаний мира по версии журнала Forbes. В зоне ответственности Дурамбе около двух сотен скрам-команд. Она говорит, что внедрение Scrum стало ноу-хау их компании: «Пока мы были стартапом, то выпускали крупный новый продукт три-четыре раза в год. Мы росли и расширялись, но управляли проектами стандартным каскадным методом, и показатель снизился до одного в год. С этим нужно было что-то делать. И вот мы ввели Scrum. С тех пор релизы у нас бывают не реже трех раз в год. Не так много крупных компаний могут похвастаться таким результатом».
