Привет, %username%! Книгу “Проект Феникс” я прочитал дважды: первый раз я ее читал исключительно как художественное произведение, а во второй раз – делал пометки по каждой главе. И в этой статье я постарался собрать выжимку мыслей, к которым пришел.

Введение

Книга “Проект Феникс” представляет собой довольно увлекательное повествование о преобразовании ИТ-отдела в компании, столкнувшейся с серьезными проблемами в управлении технологическими процессами. Эта книга выходит за рамки простого художественного произведения, становясь ценным руководством по управлению ИТ-процессами, внедрению DevOps-практик и построению эффективной системы управления изменениями. Прочитав ее дважды – сначала как художественное произведение, а затем с аналитической целью, я бы хотел поделиться своим пониманием тех принципов, которые делают эту книгу обязательной к прочтению для любого в ИТ: Chief Information Officer (CIO), руководителя среднего звена, менеджера проектов или рядового инженера эксплуатации (мифический DevOps-инженер или SRE) и даже разработчика.

Основные темы книги

“Проект Феникс” затрагивает несколько ключевых тем, которые формируют основу современного управления ИТ-процессами:

  1. Системное мышление – необходимость видеть всю компанию как единую систему, где каждая ее часть влияет на общую производительность;
  2. Управление ограничениями – фокус на “бутылочных горлышках” и оптимизация именно этих узких мест;
  3. Культура доверия и обучения – создание среды, где ошибки рассматриваются как возможности для роста;
  4. Прозрачность процессов – внедрение систем учета изменений и четких процедур;
  5. Баланс между запланированной и незапланированной работой – управление инцидентами без ущерба для проектов;

Разбор важных идей

Роль CIO в современной компании

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

Особое внимание уделяется моменту приема на новую должность. Автор рекомендует задать три ключевых вопроса:

  • Почему данная позиция стала вакантной? (чтобы понять историю предыдущего сотрудника);
  • Что вы хотите от меня на данной позиции? (четкие критерии успеха);
  • Что вы НЕ хотите от меня на данной позиции? (границы ответственности);

Этот подход помогает избежать многих проблем в будущем и четко определить ожидания.

Управление инцидентами и незапланированной работой

Одна из глав посвящена управлению инцидентами. На этом этапе ты узнаешь, что при расследовании инцидента критически важно:

  • Построить полную, хронологически последовательную цепь событий;
  • Не устраивать “охоту на ведьм”, а фокусироваться на восстановлении цепочки событий;
  • Учитывать все изменения, даже кажущиеся незначительными;
  • Фиксировать все изменения в общей системе учета;

Вывод: незапланированная работа тормозит все остальные категории работы – чем ее больше, тем меньше шансов достичь результатов по основным направлениям. Книга учит, что “разобраться с тем, какая работа важнее – гораздо важнее, чем впихнуть еще больше работы”.

Теория ограничений и управление “бутылочными горлышками”

Одна из центральных концепций книги – теория ограничений. Авторы утверждают: “Усовершенствование, осуществляемое где-то, кроме бутылочного горлышка – это иллюзия”. Это значит, что оптимизация процессов должна начинаться с выявления и решения проблем именно в тех местах, где они создают максимальное ограничение для всей системы.

Книга приводит важное правило: “Снизить давление на Бутылочное горлышко – одна из главных задач менеджеров”. Это достигается через:

  • Контроль общего потока изменений (чем больше изменений за единицу времени, тем выше риск проблем);
  • Правильную расстановку приоритетов (если важно всё, значит всё не важно);
  • Надежные процедуры передачи работы между командами (с чем именно работает команда, что должно прийти ей на вход и что она отдаст на выходе);

Система управления изменениями

Книга подробно раскрывает важность системы управления изменениями (Change Management). Типичная карточка изменений должна содержать:

  • Автора изменения;
  • Затрагиваемые системы;
  • Краткое описание;
  • Чек-лист с апрувами от владельцев затрагиваемых систем;

Авторы делают акцент: “При внедрении системы учета изменений и отладке процесса учета изменений нельзя откладывать предлагаемые изменения – это убьет на корню желание следовать данному процессу всем участникам”.

Особое внимание уделяется различию между стандартными изменениями (уже многократно исполнявшимися) и хрупкими изменениями (требующими авторизации со стороны CAB (Change-Advisory Board)).

DevOps и непрерывное улучшение

Книга “Проект Феникс” предвосхищает многие принципы DevOps, описывая три ключевых пути:

Первый путь: Системное мышление

  • Необходимо видеть весь рабочий процесс компании как единую систему;
  • Понимать влияние каждого участка на производительность всей системы;
  • Это касается не только продуктовых компаний, но и любых организаций;
  • Принимается и используется всем на самых разных уровнях, а не только для C-level;

Второй путь: Сокращение и усиление цикла обратной связи

  • Быстрое получение обратной связи позволяет раньше обнаруживать ошибки;
  • Чем раньше обнаруживаешь и начинаешь исправлять ошибки, тем выше качество продукта на выходе;
  • Возможность “зарепортить о баге” должна быть максимально удобной, простой и быстрой;

Третий путь: Культура непрерывного обучения

  • Ошибки необходимо воспринимать как возможность для роста;
  • Важность экспериментов, обучения и постоянного улучшения;
  • Этот путь особенно сложен в “постсоветском пространстве”, где система образования учит, что “ошибаться нельзя”;

Управление взаимодействием между командами

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

Особенно важно, что “99% маркетинговых проектов не могут быть выполнены без ИТ-отдела – высокоэффективный маркетинг требует высокотехнологичного исполнения”. Это подчеркивает критическую роль ИТ в достижении бизнес-целей.

Практические рекомендации

Книга предлагает множество практических рекомендаций, которые можно немедленно внедрить:

  1. Планирование запуска продукта: при планировании сроков запуска продукта учитывай все стадии – разработку, тестирование, исправление багов, передачу в эксплуатацию. При невозможности передвинуть сроки пропорционально урезай время каждой стадии, чтобы избежать ночных переработок.
  2. Управление ресурсами: специалист высокого уровня, решающий сиюминутно возникающие задачи, приносит больше вреда, чем пользы. Любые попытки отвлечь его от решения больших и высокоприоритетных задач должны быть пресечены.
  3. Канбан-система: любые задачи/действия, которые выполняются командой, должны проходить через Канбан-доску. Если на запрос не создана карточка на доске, значит запроса не существует.
  4. Обучение и документирование: знания по решению проблем должны быть вынесены из головы ключевого сотрудника в базу знаний. Самый сильный специалист не должен тратить время на onboarding новых членов команды.
  5. Информационная безопасность: команда ИБ не должна приходить с формулировками в духе “надо запретить”. Важно найти выгодное решение как для команды ИБ, так и для команды эксплуатации через формализованные процедуры.

Основные выводы

  1. Результат важнее процесса: “Главное результат! Ни процесс, ни контроль процесса, ни выполненная работа – а именно результат”. Все усилия должны быть направлены на достижение конкретных бизнес-результатов.
  2. Баланс между стабильностью и инновациями: ИТ-отдел должен обеспечивать стабильную работу критически важных систем, одновременно поддерживая инновации и изменения.
  3. Доверие как основа: “В идеальной команде нет места недоверию – каждый член команды доверяет друг другу и своему лидеру”. Доверие позволяет принимать более эффективные решения и быстрее реагировать на изменения.
  4. Прозрачность как инструмент управления: все изменения, процессы и задачи должны быть видимы для всех участников. Это позволяет избежать множества проблем и упрощает управление.
  5. Системный подход к управлению: “Системное мышление говорит тебе о том, что необходимо видеть весь рабочий процесс компании как единую систему и понимать влияние каждого участка на производительность всей системы”.

Заключение

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

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

Ну и да, пусть самой важной идеей будет то, что “DevOps – это про коммуникацию”, потому что без нормальной коммуникации “словами через рот” ничего не удастся построить.

Если у тебя есть вопросы, комментарии и/или замечания – заходи в чат, а так же подписывайся на канал.

О способах отблагодарить автора можно почитать на странице “Донаты”.