Портал №1 по управлению цифровыми
и информационными технологиями

Больше проектов хороших и разных

Опубликовано 6 декабря 2021
Рубрики: Обо всём на свете
Комментарии

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

И вроде бы уже давно разобрались и «гибкостью» и с тем, где она нужна и возможна/целесообразна. Но вопрос целесообразности итерационности при решении больших задач возникает снова и снова. Подольём маслица…

В последнем выпуске Harvard Business Review (HBR, ноябрь-декабрь 2021) в серии «Better Project Management» опубликована статья «Cделайте мега-проекты более модульными» («Make Megaprojects More Modular»). Автор статьи Бент Фливбджерг, опираясь на свой тридцатилетний опыт участия в крупных проекта выделяет два решающих фактора успеха: воспроизводимая модульность в дизайне и скорость итераций. Помимо теоретического, вполне понятного обоснования в статье приводятся интересные примеры (успешные и нет).

Завод Tesla по производству литий-ионных аккумуляторов, Gigafactory 1 (известная как Giga Nevada). Этот объект займёт более полумиллиона квадратных метров (107 футбольных полей). Но дизайн является модульным. Строительство началось в конце 2014 и мене чем за год была готова первая часть, которая производила Tesla Powerwall домашние системы хранения энергии. В июле 2016 был отпраздновано открытие завода с запуском 3 из 21 блоков (14% запланированного объёма). Мощность, на которую ориентировались при проектировании в 2014 уже достигнута несмотря на то, что объект полностью ещё не построен. Тем не менее, уже получен опыт, который может быть использован при дальнейшем развитии проекта. Высокая скорость реализации снижет риски. Кроме того, выручка начинает поступать ещё до полного окончания проекта.

Японская атомная электростанция Монджу (мы ведь упомянули в самом начале аргумент про атомную станцию — и вот подтверждение 😊). Строительство, которое было важной частью национальной программы, началось в 1984 году, тестовые запуски — в 2010. В 2013 эксплуатация в коммерческих целях была приостановлена. А в 2016 прекращена совсем — правительство закрыло станцию. Более 30 лет и 12 миллиардов долларов, и, как говорят, выработка электроэнергии в течение одного часа. В сумме. Ожидается, что вывод из эксплуатации займёт ещё 30 лет, и обойдётся в 3,4 миллиарда долларов. В отличие от примера Tesla получение какой-либо пользы в данном проекте предполагалось только после полного завершения всего проекта.

«Апгрейд» метро в Мадриде в две стадии по 4 года каждая (с 1995 по 1999: 56 километров пути и 37 станций; с 1999 по 2003: 75 километров, 39 станций). Неслыханные по тем временам темпы строительства метро. Три базовых правила.

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

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

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

Возвращаясь к энергетике, автор упоминает успешные примеры. Проект на базе малых модульных реакторов (SMR) в Вайоминге. Строительство Лондонского массива ветряных электростанций (самого большого в мире комплекса турбин, построенного на воде [341 турбина на площади около 245 кв.км]).

Разумеется, автор не мог пройти мимо космической отрасли (см. начало заметки 😊).
Илон Маск продемонстрировал невиданную до этого скорость решения задач в данной отрасли.
Возможно менее известный кейс – компания Planet Labs, основанная выходцами из NASA (разумеется, в гараже, в Купертино, Калифорния). Спутники весом до 5 кг и стоимость до 1 миллиона долларов (включая запуск и эксплуатацию) — это намного дешевле, чем у NASA. Конструкция спутников модульная, собираемая из блоков 10х10х10 см (создатели называет её «Лего»). Компоненты, включая электронику, для строительства — с массового рынка. Компания вывела на орбиту несколько сотен спутников. И даже потеря 26 спутников из-за взрыва ракеты на старте в 2014 году не привела к катастрофическим последствиям для бизнеса.

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

Тем не менее, там, где это целесообразно, имеет смысл задуматься над изменением подходов к реализации крупных проектов, как предлагает автор HBR. И в большинстве случаев скорость и модульность могут сильно помочь.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM