Projekt Phoenix: Der Roman über IT und DevOps

Интересный роман, однако практическая польза от прочтения выглядит сомнительной. Дело в том, что в книге описывается компания, в которой вообще не было никакой автоматизации внутри IT: ни системы контроля версий, ни TFS, ни confluence, ни сборочного конвейера, ни непрерывной интеграции. В таких условиях, конечно, легко проводить революцию. Практически любые адекватные изменения будут приводить к существенному росту производительности IT-подразделения, потому что, как еще говорят, с нуля расти легко, показывая невероятные проценты роста.

В современном мире сложно найти компанию, которая работала бы в таких первобытных условиях.

Сюжет романа неоднократно перекликается с некоторыми моментами из книги Цель Голдрата. В этом плане книга позволяет закрепить знания по теории ограничений, поэтому читать ее конечно лучше после Целей.

Наконец-то я дочитал книгу Проект Феникс – книгу, которая по мнению комьюнити должна дать ответы на какие-то сакральные вопросы. Среди окружающих меня людей достаточно много кто ее рекомендовал к прочтению с формулировками в духе “она тебе даст понимание того, что же такое DevOps на самом деле” – я же DevOps-инженером никогда не работал.

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

Для меня лично книга Проект Феникс, в очередной раз, стала подтверждением того, чем для меня и являлся этот ваш DevOps. А DevOps для меня как был так и остался – не столько методологией, сколько “коммуникацией и взаимопониманием”. Да, я даже после повторного прочтения этой замечательной книги говорю снова то же самое. DevOps – это про коммуникацию и взаимопониманием. Тут довольно большое количество тех, кто работал и работает DevOps-инженерами и они могут начать кидать в меня свои тапки, но пусть мне хоть один DevOps-инженер попробует доказать, что описанное в книге (достижение показателей бизнеса и разрушение барьеров между эксплуатацией, разработкой, тестированием, инфобезом и бизнесом) возможно без соблюдения двух важнейших идей – коммуникация и взаимопонимание – комментарии открыты.

Если проследить сюжетную линию, то DevOps (который внедрил главный герой) был достигнут благодаря следующему (крупными мазками) – разрушение барьера между разными подразделениями (между эксплуатацией, разработкой, тестированием, инфобезом и бизнесом) с уточнением основных болей (которые причиняют коллеги друг другу) и ожиданий друг друга, а так же совместное нахождение решений (которые устроят всех ключевых участников) для упомянутых болей и глобальное (по меркам компании) переосмысление значимости ИТ-подразделений в структуре компании. Исключительно и благодаря попыткам разобраться задавая вопросы (коммуницируя) и понимая чужие точки зрения (не принимая, а именно понимая их) был достигнут огромный результат.

Я как человек, который занимается именно эксплуатацией уже более десяти лет, могу сказать только одно – ваш DevOps это не про CI и CD, не про пайплайны и релизы. DevOps – это куда большее! DevOps – это про открытость, коммуникацию, взаимопонимание, взаимовыручку! А называть это DevOps’ом или как-то еще – какая разница?! Пойми, что и ты и “эти долбанные разрабы” вместе с “ничего не понимающими менеджерами” и “специалистами по безопасности” – вся эта толпа чтобы добиться общего успеха должна научиться разговаривать на одном языке, должна уметь общаться, делиться знаниями и опытом, слышать и слушать друг друга, выручать друг друга и помогать друг другу.

Эта книжка — яркий представитель одного из любимых мною жанров — бизнес-роман. Читается легко, как художественная книга (по сути и есть сказочка для взрослых), при этом относится к бизнес-литературе и содержит некоторое количество полезных мыслей. Концентрация этих мыслей не велика, но зато они разжовываются и доносятся на примере, хоть и выдуманном.

Основа сюжета навеяна «Целью» Голдратта (к ней, кстати, есть прямые и весьма хвалебные отсылки) — также есть главный герой-руководитель подразделения, которому в решении возникших на работе проблем помогает внешний «гуру».

Красной нитью проходит мысль, что не стоит воспринимать ИТ — только как обеспечивающую функцию. Сказать, что информационные технологии проникли во все сферы нашей жизни и в т.ч. в производство — это не сказать ничего. Уже сейчас ИТ стали их основой. Любой CEO должен прекрасно понимать все ИТ-системы, за счёт которых работает их бизнес. А лет через 10, по мнению того самого «гуру», на должность CEO будут приходить люди именно из функции ИТ.

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

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

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

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

Руководителям тоже будет полезна, в отличии от многих книг по бизнесу, тут более ориентировано на ИТ и разработку продуктов, и в разы актуальней и взрослее чем "Дедлайн".

Предлагаемое решение по обязательному планированию работ, мне кажется очевидным, но если у кого то ещё не используется, очень рекомендую.