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

Продаём DevOps высшему руководству

В последние месяцы в общении с коллегами, клиентами и партнёрами регулярно наблюдаю примерно такой диалог:

— Эх, всё так стремительно меняется! Конкуренты запускают новые продукты, клиенты становятся всё более придирчивыми и продвинутыми. Прямо чувствуется, как мы всё больше и больше отстаём.

— Что же мешает вам двигаться быстрее? Есть же новые подходы, успешно применяемые в разных организациях. Тот же DevOps, к примеру.

— Это да, было бы круто. Но это же большая перестройка!

— Разумеется. Но ведь дорогу осилит идущий. С чего-то надо начинать.

— Нет, у нас не выйдет, руководство не поддержит. То, которое в бизнесе. Ведь им тоже придётся меняться, какой уж там Agile!

Дальше разговор, как правило, переходит в цикл "конкуренты подступают, меняться надо → руководство не поддержит → придётся подождать, пока оно осознает → но меняться-то надо → …", далее по кругу.

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

Видимо, обычные страшилки из серии "конкуренты съедят наш рынок" работают так же результативно, как любимые пугалки "ну это же риски, мы их должны минимизировать, а то мало ли что". То есть – работают не очень.

Похоже, необходимо найти более системный подход к начальству.

Так случилось, что недавно я наткнулся на один очень интересный труд, содержащий некоторые соображения по данному вопросу. Представьте: порядка пятидесяти DevOps-экспертов (не столько консультантов, сколько практиков) собрались вместе, в одном помещении, на три дня. Закрылись – и давай обсуждать вопрос "Что же, по нашему опыту, мешает проводить трансформацию больше всего?". Получившиеся заметки инициативная группа из дюжины товарищей обрабатывала ещё полгода. В той группе встретились вместе сотрудники, скажем так, не самых низких должностей из компаний Starbucks, Verizon, Columbia Sportswear, Chef Software, IBM, Microsoft, HP… Лично по мне – представительное сообщество. Вот что оно советует по нашему вопросу.

С высшим руководством нужно правильно работать. Правильно означает: понимать к чему оно стремится и понимать что ему мешает в этих стремлениях.

К чему же стремится высшее руководство? Всего четыре пункта:

  1. Достижение бизнес-целей или миссии компании. Это может включать в себя:

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

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

    • внимание инновациям
    • внимание найму и удержанию талантливых сотрудников
    • фокусирование на технических, архитектурных и культурных практиках для большего вовлечения персонала
  4. Избегание риска, включая вопросы безопасности и соответствия:

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

Мешают же им следующие основные препятствия:

  1. Работа занимает слишком много времени и обходится слишком дорого
  2. Приходится искать компромиссы, в том числе для противоречащих друг другу приоритетов (развитие – стабильность, много идей – мало ресурсов, и так далее)
  3. Скорость необходимых изменений слишком высока
  4. Компетентных и заинтересованных сотрудников всё сложнее находить и удерживать

Теперь, когда с желаниями и сложностями высшего руководства нам всё стало понятно, остаётся лишь сопоставить верхние два списка с теми преимуществами, которые нам обещает применение DevOps. Это ведь не так сложно, верно?

 

«Трансформация ИТ в традиционных компаниях»
Учебный курс о кратном ускорении за счёт новой организации работы

Комментариев: 2

  • Олег, не нашел в заметке ссылки на первоисточник. Что это за труд? 

    По теме — не очень понятно, почему поиск ответа на вопрос "Как обосновать DevOps руководству?" привел экспертов к списку вполне себе общих целей бизнеса без сопоставления с преимуществами, которые дает DevOps. Зачем вообще нужны были "DevOps-эксперты" в этой рабочей группе?

    Может быть, я что-то упускаю, но в подобных перечнях дефицита вроде бы нет: например, авторы COBIT5 давно предложили то же самое (цели предприятия в COBIT5) и пошли значительно дальше (маппинги на ИТ-цели и ИТ-процессы). Чем именно показался примечательным еще один список?

    • Павел, ссылки под рукой нет, есть только сам документ.

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

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

      Что, в общем, только помогает решать задачу изменения уже сложившейся работы ИТ-подразделения.


Добавить комментарий для Олег СкрынникОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM