Саммари книги «Проект „Феникс“. Роман о том, как DevOps меняет бизнес к лучшему»

Серия: CrossReads: О бизнесе – просто

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

Методология DevOps призвана в корне изменить ситуацию. Во главе системы – отладка взаимодействия между различными отделами IT-специалистов. Когда разработчики, «безопасники» и сисадмины понимают суть задач друг друга и способны оперативно действовать, время на выпуск новых обновлений, приложений и продуктов значительно сокращается.

Чтобы добиться этого, необходимо:

1. сформировать корпоративную культуру доверия,

2. наладить коммуникацию между различными сотрудниками на всех этапах работы,

3. способствовать интеграции между IT-подразделениями.

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

Parts Unlimited – один из крупнейших производителей и продавцов автомобильных запчастей. Но в условиях современной конкуренции компания проигрывает, так как не может быстро реагировать на потребительские нужды. Вернуть компании её преимущества и восстановить уровень прибыли рассчитывали благодаря проекту «Феникс». Однако запуск программы постоянно откладывался из-за различных сбоев и пропусков. Правление Parts Unlimited поставило перед генеральным директором Стивом Мастерсом задачу исправить положение за шесть месяцев, иначе организация будет разделена. Специалист в свою очередь потребовали разобраться со всеми проблемами в IT-процессах корпорации Билла Палмера, которого назначили вице-президентом отдела IT-поддержки. План практически невыполним, ведь последние десять лет директора по информационным технологиям сменяются каждые два года, а специалисты области между собой называют эту должность концом карьеры («CIO – Career is Over»).

В текущем положении внедрение методологии DevOps оказалось для Parts Unlimited единственным способом спасти ситуацию. Компании нужно было выполнить несколько шагов:

• выявить ключевые проблемы (определить препятствия, наметить основные пути реорганизации отдела и разработать стратегию улучшений);

• начать систематизацию и автоматизацию процессов (чем больше процессов в работе выполняется автоматически по строгим, простым и понятным алгоритмам, тем быстрее процесс производства, деятельность завода или IT-отдела);

• расставить приоритеты (выявить первоочередные задачи и избавиться от лишней нагрузки, что позволит сфокусироваться на проектах, которые принесут реальную пользу);

• изменить внутреннюю культуру компании (создать атмосферу взаимопомощи, доверия и понимания деятельности всей компании, а не только собственного производственного участка; такое отношение позволяет с максимальной пользой расходовать ресурсы для успеха всей системы);

• составить чек-листы проверок и оценить улучшения (разработка системы анализа и изучение полученных данных позволяют определить сильные и слабые стороны и наметить дальнейшие пути развития и исправлений).

Прежде чем что-то менять в компании, нужно определиться с фронтом работ, а именно:

• выявить особенности производственных участков, их проблемы и слабые места;

• определить роль каждого отдела в работоспособности всей компании.

В первый день назначения на должность вице-президента отдела IT-поддержки Билл Палмер столкнулся с серьёзными системными сбоями, давящими дедлайнами и отсутствием необходимой для работы информации. Его отдел работал хаотично, а руководство понятия не имело об объёмах задач и степени загруженности специалистов. Вместе с тем сотрудники не понимали собственных обязанностей.

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

• загруженность работников отдела внеплановыми задачами (специалисты выполняли неизвестные бизнес- и внутренние IT-проекты, а также попадали под влияние регулярных неконтролируемых изменений и форс-мажоров; любой сотрудник компании по желанию мог загрузить специалистов IT-отдела работой, не несущей в себе никакой пользы для организации);

• отсутствие понимания приоритетов (важность той или иной задачи определялась положением в компании того, кто продвигал проект, и уровнем громкости его голоса);

• низкий уровень коммуникации с отделами безопасности и разработчиками (разработчики часто конфликтовали с отделом IT-сопровождения, укорачивали дедлайны, не присылали полных инструкций, необходимых для успешных тестирований. Отдел безопасности без уведомления вводил бессмысленные изменения, из-за чего происходили сбои. На ранних этапах разработки ПО не прорабатывалось совместно различными специалистами);

• зависимость работоспособности отдела от одного специалиста

Конец ознакомительного фрагмента.