Управление проектами строительства «Титаника» и лайнеров класса Olympic

Идея построить R.M.S. Titanic и её систершипы — R.M.S. Olympic и H.M.H.S. Britannic — начала обретать форму в 1907 году. Эти три судна вместе составляли White Star Line's лайнеры класса Olympic — океанские лайнеры. (Для ясности далее по тексту я буду использовать слово «Олимпики» применительно к этому классу судов.) Мало какие суда в истории человечества стали столь же известными и печально знаменитыми, как R.M.S. Titanic.

Рассматривая R.M.S. Titanic с точки зрения управления проектами, важно прежде всего определить, какой тип продукта должен был создать данный проект. В отличие от многих проектов, где конечный заказчик владеет готовым продуктом, «Титаник» был создан для оказания услуги — в частности, паромного сервиса — конечным клиентам. Это создаёт интересную сложность при обсуждении «Проекта Титаник», поскольку большинство подходов к управлению проектами рассматривают проект как имеющий чёткое начало и конец, а также ясно определённых заинтересованных сторон.

В случае такого проекта, как R.M.S. Titanic, мы можем рассматривать его с двух точек зрения. С одной стороны, перед нами проект, в ходе которого три судна класса Olympic были задуманы, спроектированы, построены и переданы White Star Lines. С другой стороны, перед нами R.M.S. Titanic, доработанный за пределы возможностей своего старшего собрата — R.M.S. Olympic, завершённый в первоначальном производстве и предоставленный как услуга пассажирам, которых он должен был перевозить между Саутгемптоном и Нью-Йорком. Чтобы не выходить за рамки темы, я не буду рассматривать ещё более масштабный проект тестирования, исправления ошибок, ремонта, изменения объёма работ и усовершенствований, применённых к двум систершипам после гибели R.M.S. Titanic. Оба — и R.M.S. Olympic, и H.M.H.S. Britannic — претерпели многочисленные изменения за годы эксплуатации, включая переориентацию Britannic с роли океанского лайнера на роль главного госпитального судна Его Величества во время Первой мировой войны и оснащение Olympic двойным корпусом и дополнительными спасательными шлюпками после того, как команда отказалась выходить в море до обеспечения надлежащей безопасности. («Olympic»)

Моя цель здесь — рассмотреть «Титаник» как услугу: от замысла до предоставления и, в конечном счёте, до отказа этой услуги. С этой точки зрения «Титаник» можно трактовать примерно так же, как современный проект Software-as-a-Service (SaaS). В силу природы такого судна, как «Титаник», или SaaS-продуктов, таких как Salesforce.com или SugarCRM, необходимо учитывать предполагаемый срок службы продукта и постоянные обновления и техническое обслуживание, которые потребуются для его функционирования. «Титаник» требовал огромного штата пилотов, моряков, поваров, носильщиков, стюардов и многих других в море, а также нуждался в дооснащении, ремонте и, если бы он выжил, получил бы новый двойной корпус, как R.M.S. Olympic. Проект SaaS точно так же потребует персонала для обслуживания дата-центра и сетевой инфраструктуры, регулярных обновлений и исправления ошибок, новых функций и т. д. Как в случае «Титаника», так и в случае SaaS-проекта существует реальная возможность сбоя в обслуживании, способного обернуться огромными убытками. Поддержание стабильной и надёжной работы — важнейший фактор успеха обоих бизнес-планов.

Начнём анализ проекта воплощения «Титаника» в жизнь с изучения заинтересованных сторон. Среди них легко идентифицировать пассажиров и команду «Титаника», компанию White Star Lines, а также инженеров проекта; Harland-Wolff в роли строителей; Александра Карлайла и Томаса Эндрюса в роли корабельных мастеров и конструкторов Harland-Wolff; капитана Эдварда Джона Смита, ответственного за предоставление услуг; и наконец, директора White Star Джозефа Брюса Исмэя и его руководящий состав, выполнявших роль спонсоров проекта. В любом проекте такого масштаба будет много важных игроков, каждый из которых в той или иной мере заинтересован в проекте. Мы сосредоточимся только на этих ключевых людях как наиболее значимых заинтересованных сторонах проекта «Титаник».

Проект «Титаник» наиболее точно соответствует каскадной модели в терминологии управления ИТ-проектами. Процесс начался с концепции высокого уровня, совместно выработанной Джозефом Брюсом Исмэем, представлявшим White Star Lines, и лордом Джеймсом Пирри, представлявшим их партнёра по судостроению — Harland-Wolff. Проект был задуман совместно двумя компаниями. «Титаник» открывал перспективы большого престижа и прибыли для обеих фирм и требовал значительных инвестиций от каждой из них. Хотя оригинальный устав проекта сегодня, по всей видимости, недоступен, встречу Исмэя и лорда Пирри можно рассматривать как неофициальный устав проекта и инициацию проекта. (Sadur)

Техническое проектирование судов класса Olympic осуществлял главный корабельный мастер Harland-Wolff Александр Карлайл — после того как Исмэй и лорд Пирри разработали планы высокого уровня. Карлайл был ведущим конструктором проекта с самого его начала вплоть до 1910 года, когда он вышел на пенсию и передал руководящую роль в проектировании Томасу Эндрюсу — управляющему директору Harland-Wolff (Brander 1998). Эндрюс отвечал за финальные этапы проектирования «Титаника». Olympic, спущенный на воду осенью 1910 года, вероятно, был полностью спроектирован под руководством Карлайла. Поскольку «Титаник» разделял почти всю инфраструктуру с Olympic (конструкция корпуса, расположение компасов, спасательные шлюпки, мостик и т. д.), можно с уверенностью предположить, что вклад Эндрюса в проектирование «Титаника» был преимущественно эстетическим или, выражаясь языком разработки программного обеспечения, касался «интерфейса». (Thinkquest)

В силу строительного характера судостроения — особенно применительно к таким исполинским судам, как «Олимпики», — процесс проектирования предполагает масштабную предварительную проработку с очень ограниченными петлями обратной связи впоследствии, когда конструкторы могут физически осмотреть корабль. В терминологии программного обеспечения это называется «Большое предварительное проектирование» (Big Design Up Front, BDUF). В разработке ПО, где изменение требований — обычное явление, это, как правило, считается весьма неудачной практикой, однако в механической и строительной инженерии это попросту единственное разумное решение.

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

Первоначальный замысел и концепция «Олимпиков» предполагали применение новейших технологий безопасности. После завершения первоначального проектирования White Star Lines и особенно Дж. Б. Исмэй начали оказывать давление на архитекторов и инженеров, добиваясь замены элементов безопасности предметами роскоши первого класса. Двумя наиболее известными изменениями стали, разумеется, снятие спасательных шлюпок, чтобы не загромождать вид из кают, и модификация ряда водонепроницаемых переборок: они лишались способности герметично закрываться и были подняты лишь на три метра над ватерлинией, чтобы освободить место для расширенного парадного бального зала. Как и в ИТ-проектах, инженерные решения по ключевым системам, как правило, выходят за пределы компетенции бизнес-руководителей. Предоставление бизнес-стороне права влиять на технические решения опасно: при этом обходятся обычные меры предосторожности и мыслительные процессы, а экспертиза игнорируется. В данном случае речь шла о вопросах, касающихся жизни и безопасности людей. В программном обеспечении перед нами крайне редко стоит столь важная задача, однако участие бизнес-менеджеров, не разбирающихся в ключевых системах, в их проектировании может причинить огромный вред — даже если последствия окажутся такими безобидными, как потеря прибыли или рост операционных расходов.

Одной из наиболее серьёзных проблем, возникших вследствие поздних изменений в конструкции «Олимпиков», было то, что каждое отдельное изменение, будучи небольшим само по себе, скорее всего, никогда не рассматривалось в совокупности — так, как рассматривался первоначальный проект судна. Когда снимались спасательные шлюпки, причастные к этому инженеры исходили из того, что корабль спроектирован как плавучий спасательный плот, а назначение шлюпок — лишь переправлять пассажиров с неподвижного океанского лайнера на другое судно в «наихудшем сценарии», когда «Титаник» или Olympic потеряют ход. Даже столкновение, как ожидалось, лишь заставит их осесть ниже в воде, но не пойти ко дну. Спасательные шлюпки убирались до тех пор, пока не осталось лишь минимально допустимое законом количество — по настоянию исполнительного комитета White Star Lines. Для инженеров это был бы приемлемый, хотя и нежелательный, компромисс в вопросах безопасности. Конструкция судна такова, что наличие дополнительных спасательных шлюпок не являлось законодательным требованием, да и острой необходимости сохранять их не было, поскольку польза от дополнительных шлюпок считалась минимальной. В конечном счёте это решение зависело не от инженеров, а от White Star Lines — конечного заказчика судостроителей, от чьих решений зависело их благополучие.

Само по себе решение снять спасательные шлюпки, скорее всего, было бы второстепенным. Но одновременно было принято решение изменить ключевую конструктивную схему «Олимпиков»: вместо высоких водонепроницаемых переборок четыре из них были существенно понижены — до трёх метров над ватерлинией. Это нанесло серьёзный урон концепции судна как плавучего спасательного плота. Переборки никогда не были по-настоящему водонепроницаемыми, как утверждали маркетинговые материалы, однако были весьма высокими и очень водостойкими — и в случае даже очень серьёзного пробоя корпуса они, вероятно, смогли бы удержать воду от перетекания между отсеками. Поскольку первоначальная конструкция судна изобиловала защитными функциями, это воспринималось бы как избыточный элемент — и его устранение лишь снижало бы судно до более обычных критериев безопасности. Взятые по отдельности, изменения были в основном безобидны; но взятые вместе, они превратились в полное перепроектирование судна — с катастрофическими последствиями. Ни в какой момент квалифицированные инженеры не возвращались к комплексной оценке всех систем безопасности с учётом всех внесённых изменений.

В каком-то смысле Дж. Б. Исмэя можно назвать микроменеджером. Он не доверял решениям специалистов, нанятых именно за их техническую экспертизу, и отменял их решения — прямо или путём косвенного давления. Микроменеджмент влечёт за собой множество негативных последствий. Очевидное из них — неподготовленные и неквалифицированные менеджеры влияют на решения, которые, по мнению других, приняты квалифицированными специалистами. Среди прочего — подрыв ценности, создаваемой проектной командой, а также снижение лояльности и морального духа сотрудников.

В судостроении, когда суда строятся серийно — как в случае с «Титаником», — необходимо выделить три основные фазы проекта: проектирование и строительство прототипа — Olympic; доработка конструкции и строительство «Титаника»; и наконец, предоставление услуг и эксплуатация. В случае «Титаника» в частности видно, что принципиальные конструктивные решения и все структурные изменения были сделаны ещё до завершения Olympic. Томас Эндрюс плавал на Olympic, однако преимущественно для того, чтобы внести эстетические доработки для «Титаника» — вносить структурные изменения на том этапе было уже слишком поздно. По той же причине Эндрюс плыл на «Титанике», чтобы проделать то же самое для вскоре готовящегося к спуску Britannic (известного Эндрюсу как Gigantic).

С точки зрения объёма проекта можно констатировать, что он строго придерживался первоначально утверждённого плана. Строительство велось на основе заранее утверждённых планов с минимальными отклонениями. Наиболее существенные изменения в объёме произошли в ходе строительства «Титаника», когда проект пришлось приостановить для ремонта Olympic. Обе стороны — Harland-Wolff и White Star Lines — понимали, что «Титаник» будет задержан, однако приоритет имела готовность к эксплуатации Olympic. Важнейшим фактором в любом крупном строительном проекте является необходимость договорных соглашений на уровне контракта между фазами строительства, поскольку изменение объёма практически невозможно осуществить после начала строительства. («Olympic»)

Сложно найти программные проекты, которые точно следовали бы подобной модели — с производственным прототипом, за которым следует серия производственных реализаций, основанных на прототипе, но не идентичных ему. Наиболее близкий пример, который я могу привести, — пакет планирования ресурсов предприятия (ERP) SAP. С этим пакетом — и другими ему подобными — клиенты приобретают продукт, основываясь на его прототипической производительности и функциях, а затем, самостоятельно или через консалтинговую фирму или первоначального поставщика, глубоко адаптируют пакет под свои нужды. Как правило, преимущество такого подхода состоит в том, что ядро программного пакета — инфраструктура — очень стабильно и хорошо протестировано, используется в широком спектре ситуаций, что обеспечивает ему как проектное, так и клиентское тестирование. Разумеется, необходимо соблюдать осторожность, поскольку модификации, инициированные клиентом, не получат преимуществ глубокого тестирования, которое, будем надеяться, было проведено для базовой инфраструктуры, и не обретут пользы от «множества глаз» более широкого клиентского сообщества.

В случае судов класса Olympic серьёзные испытания проводились на пятиметровой модели судна, а также на самом Olympic после его завершения. При такой сложности, как у Olympic, критически важно проводить натурные испытания в дополнение к Unit-тестированию отдельных систем. Olympic прошёл стандартные испытания, принятые для судна такого типа. Однако когда был построен «Титаник», строители и круизная компания решили, что, поскольку «Титаник» является по сути копией Olympic, проведённые испытания и успешная эксплуатация Olympic достаточны и для «Титаника», который получил крайне мало дополнительного тестирования. Между тем это не является лучшей практикой: мореходы знают, что все суда — даже систершипы — ведут себя по-разному, и каждое судно уникально и должно проходить собственные испытания. (Kozak-Holland)

«Титанику» было отведено почти никакого времени для испытаний или ходовых проверок. Это произошло отчасти потому, что Olympic попал в серьёзную аварию и был отправлен на судоремонтные заводы в Белфасте для ремонта. Пока Olympic ремонтировался, «Титаник» вынужден был ждать, поскольку одновременно работать над судном такого размера можно было лишь с одним. Это поставило «Титаник» в жёсткие временные рамки, поскольку он был запланирован на регулярное трансатлантическое расписание и был нужен немедленно. По этой причине часть дополнительных испытаний, которые, вероятно, были бы проведены, была пропущена, и «Титаник» вышел в море, имея в качестве основного испытания переход из Белфаста в Саутгемптон — причём даже на этом участке пути на борту находился хотя бы один платный пассажир, что делало рейс скорее маловместительным настоящим плаванием, нежели полноценным испытанием. (Kozak-Holland)

По всей видимости, White Star Lines и Дж. Б. Исмэй были вполне готовы принять на себя исключительные проектные риски, чтобы как можно скорее ввести судно в регулярную эксплуатацию. В соответствии со стандартной морской практикой значительная часть их капитального риска была снижена путём страхования морских рисков. Это защищало их от многих потенциальных неизвестных.

В последней четверти XIX века среди судоходных компаний и правительств всё более распространялась тенденция рассматривать риск как второстепенный вопрос. S.S. Great Eastern, построенный в 1858 году, считался — и на практике доказал это — значительно более безопасным, чем конструкции всё менее безопасных океанских судов, последовавших за ним в течение следующих пятидесяти четырёх лет. Ситуация продолжала ухудшаться, пока компании и правительства не переосмыслили её после гибели «Титаника». Утверждается, что судоходные компании рассматривали приемлемые показатели безопасности как оправдание своего халатного отношения к безопасности на протяжении десятилетий относительно безаварийного судоходства. Давление финансовых рынков брало верх, благоприятствуя компаниям с мягкими стандартами безопасности и побуждая отрасль в целом отказываться от дорогостоящего управления рисками. (Brander 1995)

Под предлогом снижения рисков, обусловленных недостаточным тестированием и подготовкой экипажа, несколько членов команды — прежде всего капитан Смит — были переведены с Olympic для плавания на «Титанике» в его первом атлантическом переходе. Это можно рассматривать как стремление Исмэя обеспечить максимальный опыт с судна-прототипа. Вместе с тем возможно, что истинная причина выбора капитана Смита была иной, и весьма вероятно, что его взяли потому, что его положение в White Star Lines оказалось под вопросом после того, как он совсем недавно стал причиной серьёзной аварии с участием H.M.S. Hawke, из-за которой Olympic был поставлен на аварийный ремонт, а отплытие «Титаника» задержалось. Капитан Смит, вероятно, нервничал, переживал за свою карьеру и был мало расположен — и мало способен — нести последнюю ответственность на борту судна, если давление со стороны компании противоречило его профессиональному суждению. Возможно, именно этой лазейкой в оперативном управлении и добивалась White Star Lines. Ситуацию, по всей видимости, усугубило то, что капитан Смит подошёл слишком близко или слишком быстро к S.S. City of New York в Саутгемптонской гавани, в результате чего то сорвалось с причальных концов и едва не столкнулось с «Титаником». (Kozak-Holland)

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

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

На этапе предоставления услуг White Star Lines взяла на себя ответственность за любые новые проблемы, которые могут возникнуть с судном. На этом этапе традиционная система «проектирование — строительство — испытание» уже не применялась, а предоставление услуг осуществлялось в соответствии со стандартными операционными процедурами (SOP). Текущие модификации, ремонты, наладка и тому подобное по-прежнему продолжались, однако они не должны были требовать перерывов в обслуживании, носили второстепенный характер и осуществлялись без ведома конечных клиентов — пассажиров. Именно на этом этапе пассажиры становятся нашими наиболее важными заинтересованными сторонами, поскольку в данном сценарии они не просто финансово заинтересованы, но буквально ставят свои жизни на кон, доверяясь надёжности судна и действиям экипажа.

В сообществе Agile-управления проектами часто используется притча для обозначения ролей среди заинтересованных сторон. Эти роли известны как свиньи и куры. Притча рассказывает о курице и свинье, которые хотят вместе открыть ресторан. Свинья спрашивает курицу, что они будут подавать. Курица отвечает: «Ну, конечно, бекон и яйца». На что свинья отвечает: «Не думаю, что меня это устроит. Ты будешь участвовать, а я буду полностью вовлечена». (Schwaber 7)

Метафора свиньи и курицы обычно используется для выражения разницы между заинтересованными сторонами, поставившими на кон реальные деньги или карьеру, и заинтересованными сторонами, имеющими вложенный, но не критически важный интерес в проекте. Куры предпочтут не видеть провала проекта, однако для них провал не обязательно окажется катастрофой. В случае «Титаника» финансовые заинтересованные стороны — Harland-Wolff и White Star Lines — по существу играли роль кур. Они многим рисковали, однако их инвестиции были застрахованы, и позднее, как мы увидим, правительство было готово защищать компании такого рода в то время из-за надвигавшейся войны с Австрией и Германией. Ни White Star, ни Harland-Wolff не были «полностью вовлечены» — они имели определённый интерес, и успех «Титаника» был для них крайне важен, однако пассажиры и экипаж «Титаника» были здесь настоящими «свиньями», готовыми рискнуть самими жизнями. Редко метафора курицы и свиньи бывает столь уместной.

Чтобы обеспечить более высокое качество постоянного обслуживания, на борту во время первого рейса присутствовала гарантийная группа Harland-Wolff. В её состав входили многие важные члены проектного и строительного персонала Harland-Wolff, в том числе ведущий конструктор Томас Эндрюс. Такая гарантийная группа являлась обязательной частью всех крупных проектов Harland-Wolff. Её персонал должен был использовать время плавания для оценки конструкции в различных условиях, отличных от испытательных, изучения удовлетворённости клиентов и поиска возможностей для улучшения. Томас Эндрюс уже плавал на Olympic с той же целью и внёс множество мелких изменений для улучшения «Титаника». В частности, во время этого плавания он разрабатывал более дешёвые крючки для одежды в пассажирских каютах. («Guarantee Group»)

Гарантийная группа включала специалистов из многих различных технических областей Harland-Wolff. Были представлены монтажники, электрики, столяры-краснодеревщики, чертёжники, проектировщики и другие. Эта группа, объединявшая специалистов разного профиля с различным уровнем опыта — как старших сотрудников, так и учеников, — представляла собой исключительный поперечный срез проектной команды, построившей корабль. Их присутствие на борту и внимание к оценке качества работ, конструкции и прочих финальных компонентов можно рассматривать двояко.

С одной стороны, это можно расценивать как «разбор полётов» (post-mortem) по проекту «Титаник». Задачей этой команды была оценка технического успеха проекта и поиск направлений для совершенствования, а также формирование «извлечённых уроков», которые могли бы принести пользу будущим проектам. С учётом стоимости трансатлантического перехода и времени, потраченного специалистами вдали от своих обычных обязанностей, это было серьёзным инвестированием в проектные знания со стороны Harland-Wolff и заслуживает высокой оценки.

С другой стороны, гарантийная группа может восприниматься как источник обратной связи по одной из строительных итераций. Строительство Olympic — первая итерация, «Титаника» — вторая, Britannic — третья. При таком подходе мы видим своеобразное использование Agile-петли обратной связи, насколько это возможно, для получения клиентской обратной связи даже в таком масштабном проекте капитального строительства. Итерации очень длинные, однако это продиктовано необходимостью. Таким образом, «Титаник» можно рассматривать одновременно как самостоятельный проект — в качестве дискретного результата — и как часть продолжающегося проекта по предоставлению пассажирского сервиса силами семейства судов Olympic.

Присутствие гарантийной группы на борту давало техническим специалистам возможность воочию ознакомиться с реальным применением своего продукта. В 1912 году технический специалист крайне редко мог позволить себе путешествие на судне такого уровня роскоши. Без спонсорства Harland-Wolff, предоставившей своим сотрудникам возможность наблюдать за собственным мастерством в действии, они могли бы никогда не понять своей роли в предоставлении услуг конечным клиентам.

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

Наибольший сюрприз в нашем анализе «Титаника» состоит в почти полном отсутствии на борту стандартных операционных процедур. Некоторые процессы и процедуры были задокументированы, однако многие — нет. К числу нестандартизированных процессов относились ключевые коммуникационные процессы: передача сообщений из радиорубки на мостик, оповещение пассажиров о гибели судна и оповещение мостика о том, что впередсмотрящие обнаружили айсберг. (Kozak-Holland)

Стандартные операционные процедуры абсолютно необходимы в любой ситуации, связанной с предоставлением услуг. Для некоторых компаний они могут считаться настолько ценными, что представляют собой ключевую интеллектуальную собственность. Без SOP компания не более сплочённа, чем позволяет внутренняя «командность» её персонала, которая у новых сотрудников может быть минимальной. Сотрудникам придётся полностью полагаться на лучшие практики, конвенцию, неформальный инструктаж коллег или, в лучшем случае, на обучение. Но всё это не будет стандартизировано, если не зафиксировано в письменном виде, а обучение неизбежно будет варьироваться от тренера к тренеру, и ни один сотрудник не сможет запомнить все инструкции для всех возможных сценариев.

В обычных условиях отсутствие стандартных операционных процедур может иметь относительно небольшое значение. Сотрудники способны в достаточной мере выполнять большинство должностных функций — особенно при наличии подготовки — без SOP. В противном случае им пришлось бы постоянно носить SOP при себе. Стандартные операционные процедуры становятся критически важными тогда, когда «нормальные условия работы» более недоступны или, говоря современным языком, когда операции выходят за рамки BAU (Business as Usual — штатный режим работы). Для «Титаника» режим BAU был нарушен за несколько часов до столкновения с айсбергом.

В случае «Титаника» трудно обсуждать стандартные операционные процедуры, не затрагивая тему коммуникаций. Поэтому начнём с коммуникаций в режиме BAU, а затем посмотрим, как отсутствие SOP привело к стремительному ухудшению ситуации.

«Титаник» с самого начала страдал от конструктивных недостатков в системе связи. Радиорубка, ответственная за все входящие и исходящие коммуникации «Титаника», обслуживалась не White Star Lines, а сотрудниками компании Marconi, которые получали оплату прежде всего за обслуживание пассажиров и занимались нуждами судна лишь при наличии свободного времени. Радисты были перегружены работой и недооценены, и нередко не передавали сообщения на мостик, поскольку имели другие обязанности, которые Marconi — их работодатель — считал более приоритетными. По меньшей мере восемь предупреждений об айсбергах было направлено в радиорубку «Титаника», однако лишь часть из них была передана на мостик. (Kozak-Holland)

В данном случае важно подчеркнуть значение управления сторонними подрядчиками посредством соглашения об уровне обслуживания (SLA). White Star Lines, допустив компанию Marconi к обслуживанию своей радиорубки, должна была иметь чёткое SLA, требующее безусловного приоритета коммуникаций по вопросам безопасности и чрезвычайных ситуаций на судне над личными сообщениями экипажа. Также не следовало позволять Marconi извлекать дополнительную прибыль или финансовую выгоду из несоблюдения SLA. Будучи сторонним подрядчиком, Marconi должна была иметь контракт, направленный на взаимную выгоду: то есть такой, при исполнении которого всем сторонам было бы выгодно действовать надлежащим образом. Контракты с поставщиками, предоставляющие финансовые стимулы работать вопреки интересам клиента, крайне неразумны.

Наиболее важным единичным инцидентом с участием операторов Marconi стало последнее предупреждение об айсберге, направленное SS California, находившимся в непосредственной близости от «Титаника» — настолько близко, что впоследствии именно это судно увидело сигнальные ракеты «Титаника». California сообщила «Титанику» по радио, что застряла в паковом льду и не может продвигаться ни с какой скоростью из-за опасных условий. Оператор Marconi ответил: «Заткнись, заткнись, я занят. Я работаю с мысом Рейс, а ты мне мешаешь». Трудно яснее обозначить приоритеты радиорубки — даже при такой близкой опасности. Радиорубка не только не поддержала связь с California, но и отказалась передать на мостик это последнее внешнее предупреждение. В отчаянии радист California прекратил попытки предупредить «Титаник», выключил рацию и лёг спать. Операторы Marconi не только проигнорировали предупреждения, но и оттолкнули внешние каналы связи, в результате чего единственное судно, находившееся достаточно близко для проведения спасательной операции, не откликнулось, когда «Титаник» начал тонуть. (Kuntz)

Коммуникации с мостика к экипажу и пассажирам в целом не имели официального процесса, были ручными и осуществлялись в лучшем случае по принципу максимальных усилий — если вообще предпринимались. Мостик не уведомил никого о надвигающемся столкновении, и никто не был подготовлен к тому, что могло стать очень серьёзным ударом. После того как судно начало тонуть, прошло более часа, прежде чем мостик начал сообщать остальному экипажу о гибели корабля. Ключевая информация, затрагивавшая жизни пассажиров и экипажа, скрывалась и оставалась лишь у немногих офицеров мостика, которые, по всей видимости, надеялись сохранить инцидент в тайне или минимизировать огласку очевидной угрозы человеческой жизни. Поскольку не существовало ни системы, ни процедуры передачи информации с мостика на судно в целом, это не составляло труда: для того чтобы вообще проинформировать пассажиров о каких-либо новостях, требовались целенаправленные усилия. (Kozak-Holland)

Внутрикомандные коммуникации экипажа были немногим лучше. Например, вахтенный офицер находился за пределами мостика, тогда как его критически важные средства связи располагались внутри рубки мостика. Таким образом, вахта не могла оперативно связаться с другими офицерами мостика или координировать действия с впередсмотрящими и другими функциональными зонами. Впередсмотрящие и вахтенная служба были соединены односторонней колокольной системой, не допускавшей дуплексной связи и очень медленной; у вахты не было способа получить обратную связь от рулевого при подаче экстренной команды. Команды отдавались криком с открытого воздуха в сторону закрытого мостика. Вахта могла лишь надеяться, что рулевой внутри мостика услышал, понял и выполняет эти команды. Связь со стандартным компасом была столь же неудовлетворительной. Компас вместо того, чтобы располагаться над мостиком или рядом с ним, находился далеко на корме, и мостику приходилось регулярно координировать действия с компасной позицией, что вызывало постоянную неразбериху и задержки. Практически никакого внимания не было уделено обеспечению эффективности и безопасности мостика. Этот конструктивный просчёт в организации связи отнюдь не помог «Титанику» в момент, когда быстрые и точные коммуникации стали жизненно необходимы. (Brown)

Когда внешние коммуникации с офисом White Star в Бостоне наконец были установлены, переданная информация гласила, что серьёзного ущерба нет и инцидент крайне незначителен. Однако, в отличие от распространённой сегодня адресной передачи информации, эти сообщения транслировались в эфир и могли быть легко перехвачены другими судами и береговыми ретрансляционными станциями. Корабельно-береговая связь нередко использовалась для фактического передачи информации прессе под видом внутреннего коммюнике. Поэтому вместо честной и критически важной информации радиосвязь была использована как маркетинговый инструмент. Переданное сообщение было не сигналом бедствия, а по существу не более чем пресс-релизом, призванным «сгладить» ситуацию. (Kozak-Holland)

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

Пожалуй, наиболее серьёзной проблемой управления проектом, затронувшей «Титаник», было полное отсутствие стандартных операционных процедур. SOP должно было быть создано как обязательный результат проекта на поздних этапах строительства. То, что судно было признано мореходным при отсутствии SOP для его эксплуатации, поистине не поддаётся осмыслению. Даже самые гибкие методологии разработки не упускают из виду необходимость документации для конечного пользователя.

Поскольку этапы проектирования и строительства не обеспечили экипаж «Титаника» ни SOP, ни хотя бы разумным SOP (некоторые общие стандартные процедуры содержались в самом руководстве White Star Lines), не существовало чётко определённых правил или процессов для обработки коммуникаций, отслеживания предупреждений, подачи сигналов тревоги и т. д. Не было никакой аварийной процедуры, и экипаж был вынужден действовать, опираясь исключительно на опыт и общие морские знания.

Именно в этот момент — при изучении действий экипажа в чрезвычайных условиях — мы наблюдаем полный распад командной вертикали. В обычном бизнесе бизнес-руководители, как правило, признаются обладателями конечных полномочий в принятии любых корпоративных решений в пределах, установленных законом, — а нередко и выходя за эти пределы. В среднем бизнесе неверное операционное решение оборачивается потерей выручки, а не гибелью людей. Мудрый руководитель понимает, что нельзя отменять решения специалистов, нанятых именно для принятия операционных решений; либо совет директоров потребует от руководителя прислушиваться к своему персоналу. Тем не менее вмешательство бизнес-руководителей в операционные процессы проекта противоречит лучшим практикам и повсеместно признаётся неудачным курсом действий.

В случае «Титаника» капитан Смит командовал судном в море и нёс личную ответственность за судно и всех находившихся на борту. Его начальник, Дж. Б. Исмэй, возможно, и мог отстранить Смита от командования по возвращении в порт, однако в море он не имел на это права, а по британскому морскому праву — и права отдавать приказы с мостика, поскольку не имел лицензии моряка. (Kuntz)

В период, предшествовавший столкновению с айсбергом, Дж. Б. Исмэй оказывал давление на капитана Смита, добиваясь от него движения судна с безответственной скоростью — свыше двадцати четырёх узлов, или семидесяти пяти оборотов. Olympic, считавшийся «испытательным» для «Титаника», никогда не пересекал Атлантику с такой скоростью, и теперь «Титаник» работал в режиме, выходящем даже за рамки испытаний, проведённых на Olympic, — не успев совершить ни одного атлантического перехода в нормальных условиях. Исмэй и Смит гнали «Титаник» за пределы его известных рабочих характеристик и, что важнее, за пределы известных операционных параметров экипажа. Было попросту неизвестно, какие операционные риски несёт движение судна на этой скорости. Поддерживать то, что должно было считаться опасной скоростью, одновременно входя в воды, о которых было известно, что они усыпаны айсбергами, было крайне безрассудно.

Неизвестно, то ли из-за паники, то ли замешательства, то ли неуверенности, — но после столкновения «Титаника» с айсбергом капитан Смит позволил неспециалисту Дж. Б. Исмэю подняться на мостик и начать отдавать приказы в роли исполняющего обязанности командира судна — хотя капитан Смит имел право и был обязан удалить Исмэя с мостика. Исмэй принял ключевые операционные решения, в том числе касавшиеся экстренных коммуникаций, оповещения пассажиров и — самое главное — о движении «Титаника» вперёд с ледового шельфа, что, по всей видимости, и стало непосредственной причиной главного пробоя корпуса, а затем о продолжении хода судна на малой скорости — уже тогда, когда дополнительная информация о том, что судно пойдёт ко дну, уже была получена. (Kozak-Holland)

С учётом той дистанции во времени, которая сейчас отделяет нас от «Титаника», оценивать соблюдавшиеся процессы и понимать, что в проекте шло правильно, непросто — особенно когда мы так много знаем о том, что шло не так. Гибель «Титаника» столь глубоко укоренилась в нашем сознании, что воспринять её как нечто иное, нежели маркетинговая и организационная катастрофа, крайне трудно.

В конечном счёте проект «Титаник» был масштабным, но хорошо управляемым. Объём работ контролировался, а изменения при необходимости принимались. Применялось масштабное предварительное проектирование с чётко установленным договорным интерфейсом к строительной фазе; это закрепление спецификаций обеспечивало тщательное и точное планирование. Процессы строительства судов были стандартными и хорошо известными. Используя исторические строительные данные, Harland-Wolff смогла точно предсказать время, необходимое для строительства, что позволило White Star Lines начать маркетинг и продажи задолго до фактического выхода судов в плавание. «Титаник», будучи почти точной копией Olympic, преподнёс ещё меньше сюрпризов. Единственным настоящим сюрпризом стало изменение приоритетов со стороны White Star Lines, в результате чего проект «Титаник» был приостановлен примерно на один месяц.

По словам Дж. Брюса Исмэя, «она [Titanic] была построена не по контракту. Она была просто построена на комиссионной основе». Это свидетельствует о том, что Harland-Wolff были предоставлены исключительные полномочия для использования собственных процессов и надзора в целях обеспечения передачи «Титаника». Две компании работали скорее как партнёры, нежели в отношениях поставщик — клиент. (Kuntz)

Управление проектными рисками «Титаника» было выстроено плохо: в значительной мере оно опиралось на внешних страховщиков и, в конечном счёте, на британское правительство, защищавшее компанию от исков о возмещении ущерба за счёт интересов преимущественно британских и американских пассажиров. Риск считался весьма низким, и вследствие этого многочисленные безответственные решения принимались сначала применительно к Olympic, а затем, когда операционные катастрофы оказались минимальными, ещё в большей мере — применительно к «Титанику». Тщательной оценки рисков проведено не было. Опытные мореплаватели могли бы легко и быстро выявить многие зоны риска, требовавшие устранения. Такие проблемы, как отсутствие полноценных стандартных операционных процедур, были бы выявлены и могли бы быть легко устранены — поскольку ресурсы для этого не потребовались бы от текущей команды «Титаника» и не повлияли бы ни на сроки поставки, ни на какие-либо иные переменные, которые мы теперь понимаем как главный приоритет White Star Lines.

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

В основе всего лежал вопрос качества. «Титаник» был задуман и позиционировался как трансатлантические путешествия высочайшего качества. Качество провозглашалось — прямо или косвенно — в каждом слове о «Титанике». Клиентский интерфейс поддерживался максимально чистым и лаконичным. Никаких расходов не жалели, если результат оказывался перед глазами клиента. Однако базовое ядро или инфраструктура проекта (нефункциональные требования по Козак-Холланду — хотя я не согласен с их использованием в данном контексте), на которых должно было покоиться это «качество», были проигнорированы — и подлинное качество «Титаника» и операционное качество White Star Lines в итоге стало очевидным для всех.

Библиография и источники:

Schwaber, Ken. Agile Project Management with Scrum. Redmond: Microsoft Press, 2003.

Kuntz, Tom. Titanic Disaster Hearings: The Official Transcripts of the 1912 Senate Investigation, The. New York: Pocket Books, 1998. Audio Edition via Audible.

Kozak-Holland, Mark. "IT Project Lessons from Titanic." Gantthead.com the Online Community for IT Project Managers. (2003): 22 February 2008

Brown, David G. "Titanic." Professional Mariner: The Journal of the Maritime Industry. (2005): 23 February 2008

Sadur, James E. Home page. "Jim's Titanic Website: Titanic History Timeline." (2005): 23 February 2008.

ThinkQuest Library. "Designing the Titanic." (Date Unknown): 25 February 2008.

Titanic-Titanic. "Olympic." (Date Unknown): 25 February 2008.

Titanic-Titanic. "Guarantee Group." (Date Unknown): 25 February 2008.

Brander, Roy. P. Eng. "The RMS Titanic and its Times: When Accountants Ruled the Waves – 69th Shock & Vibration Symposium, Elias Kline Memorial Lecture". (1998): 25 February 2008.

Brander, Roy. P. Eng. "The Titanic Disaster: An Enduring Example of Money Management vs. Risk Management." (1995): 25 February 2008.

Дополнительные примечания:

Марк Козак-Холланд переиздал свои статьи 2003 года с Gantthead о «Титанике» в виде книги:

Kozak-Holland, Mark. Lessons from History: Titanic Lessons for IT Projects. Toronto: Multi-Media Publications, 2005.

Дополнительное чтение:

Kozak-Holland, Mark. Avoiding Project Disaster: Titanic Lessons for IT Executives. Toronto: Multi-Media Publications, 2006.

Kozak-Holland, Mark. On-line, On-time, On-budget: Titanic Lessons for the e-Business Executive. IBM Press, 2002.

Материалы слушаний и официальных расследований Сената США и британского правительства 1912 года на сайте Titanic Inquiry Project.

Впервые опубликовано на SheepGuardingLlama.