В последние месяцы в общении с коллегами, клиентами и партнёрами регулярно наблюдаю примерно такой диалог:
— Эх, всё так стремительно меняется! Конкуренты запускают новые продукты, клиенты становятся всё более придирчивыми и продвинутыми. Прямо чувствуется, как мы всё больше и больше отстаём.
— Что же мешает вам двигаться быстрее? Есть же новые подходы, успешно применяемые в разных организациях. Тот же DevOps, к примеру.
— Это да, было бы круто. Но это же большая перестройка!
— Разумеется. Но ведь дорогу осилит идущий. С чего-то надо начинать.
— Нет, у нас не выйдет, руководство не поддержит. То, которое в бизнесе. Ведь им тоже придётся меняться, какой уж там Agile!
Дальше разговор, как правило, переходит в цикл "конкуренты подступают, меняться надо → руководство не поддержит → придётся подождать, пока оно осознает → но меняться-то надо → …", далее по кругу.
Видимо, в части компаний есть задача "продажи" новых идей высшему руководству, без помощи которого, разумеется, в таких вопросах никак не обойтись.
Видимо, обычные страшилки из серии "конкуренты съедят наш рынок" работают так же результативно, как любимые пугалки "ну это же риски, мы их должны минимизировать, а то мало ли что". То есть – работают не очень.
Похоже, необходимо найти более системный подход к начальству.
Так случилось, что недавно я наткнулся на один очень интересный труд, содержащий некоторые соображения по данному вопросу. Представьте: порядка пятидесяти DevOps-экспертов (не столько консультантов, сколько практиков) собрались вместе, в одном помещении, на три дня. Закрылись – и давай обсуждать вопрос "Что же, по нашему опыту, мешает проводить трансформацию больше всего?". Получившиеся заметки инициативная группа из дюжины товарищей обрабатывала ещё полгода. В той группе встретились вместе сотрудники, скажем так, не самых низких должностей из компаний Starbucks, Verizon, Columbia Sportswear, Chef Software, IBM, Microsoft, HP… Лично по мне – представительное сообщество. Вот что оно советует по нашему вопросу.
С высшим руководством нужно правильно работать. Правильно означает: понимать к чему оно стремится и понимать что ему мешает в этих стремлениях.
К чему же стремится высшее руководство? Всего четыре пункта:
-
Достижение бизнес-целей или миссии компании. Это может включать в себя:
- достижение финансовых целей, например по росту выручки, контролю и снижению затрат, прибыльности
- увеличение доли рынка компании как с помощью расширения самого рынка, так и вытесняя с него конкурентов
- привлечение и удержание клиентов с помощью качественного сервиса и продуктов/услуг
-
Получение результатов, которые можно измерить или наглядно продемонстрировать, в том числе:
- сбор и анализ бизнес-метрик на постоянной основе
- демонстрация измеримых улучшений в достижении целей или миссии
- предоставление метрик, показывающих возврат инвестиций
-
Построение здоровой и счастливой компании (именно так написано в оригинале)
- внимание инновациям
- внимание найму и удержанию талантливых сотрудников
- фокусирование на технических, архитектурных и культурных практиках для большего вовлечения персонала
-
Избегание риска, включая вопросы безопасности и соответствия:
- управление рисками с помощью соответствующих уровней отслеживаемости и прозрачности
- подключение мер безопасности во все процессы, включая аудиты и контроли
- запись и анализ всех подозрительных взаимодействий и аномалий
Мешают же им следующие основные препятствия:
- Работа занимает слишком много времени и обходится слишком дорого
- Приходится искать компромиссы, в том числе для противоречащих друг другу приоритетов (развитие – стабильность, много идей – мало ресурсов, и так далее)
- Скорость необходимых изменений слишком высока
- Компетентных и заинтересованных сотрудников всё сложнее находить и удерживать
Теперь, когда с желаниями и сложностями высшего руководства нам всё стало понятно, остаётся лишь сопоставить верхние два списка с теми преимуществами, которые нам обещает применение DevOps. Это ведь не так сложно, верно?
Олег, не нашел в заметке ссылки на первоисточник. Что это за труд?
По теме — не очень понятно, почему поиск ответа на вопрос "Как обосновать DevOps руководству?" привел экспертов к списку вполне себе общих целей бизнеса без сопоставления с преимуществами, которые дает DevOps. Зачем вообще нужны были "DevOps-эксперты" в этой рабочей группе?
Может быть, я что-то упускаю, но в подобных перечнях дефицита вроде бы нет: например, авторы COBIT5 давно предложили то же самое (цели предприятия в COBIT5) и пошли значительно дальше (маппинги на ИТ-цели и ИТ-процессы). Чем именно показался примечательным еще один список?