Сущность ступенчато-шлюзовой модели управления проектами

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

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

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

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

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

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

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

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

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

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