Всем ли доступен прогресс?

В мире ИТ происходят очень интересные события: компании отказываются от управления проектами в пользу управления продуктами, активно борются с жёсткостью ИТ-инфраструктуры, применяют принцип «инфраструктура как программный код», ускоряют всё, что только можно, снижают хрупкость ИТ, берут, наконец-то, под управление технический долг... Захватывающее время.

При этом невооружённым глазом заметно, что есть минимум два мира ИТ: тот, где всё модное и современное так или иначе становится или уже считается нормой, и тот, где всё то же самое либо не очень приживается, либо требует больших изменений, ресурсов, воли, при этом до конца непонятно, стоит ли так надрываться. Первый мир — это «единороги», «стартапы» и прочие цифровые компании. Второй — наш любимый Enterprise. Рассмотрим его немного подробнее.

Под Enterprise будем понимать бизнес, который не сводится на 100% к информационным технологиям, но очень от них зависит, потому имеет собственный ИТ-департамент. Успех бизнеса возможен только если эти технологии иметь, грамотно использовать, а ещё и развивать. Размер ИТ-департамента — сотни сотрудников, может быть даже тысячи.

Предположим, что вопросы необходимости и целесообразности как-то решены: да, мы хотим, как и все вокруг, сокращать Time to Market, непрерывно давать бизнесу новое и полезное, чтобы при этом не страдали доступность и надёжность наших решений.

Сфокусируемся на ограничениях. Что мешает обычному Enterprise успешно применять все эти модные штуки, чтобы решать новые задачи и отвечать требованиям времени?

Мы бы тоже могли как они, но есть нюансы

Известны две крайности:

1. Ничего не мешает. Имеющий желание — найдёт возможность. Бери и трансформируйся.
2. «Послушайте, мы — большая корпорация. Этого всего у нас нет и быть не может».

Эти два полюса ни один управленец всерьёз рассматривать не будет, мы тоже не станем. Попробуем порассуждать про более-менее конкретные ограничения. Откуда о них можно узнать?

Один из вариантов: от сотрудников тех самых корпораций. Например, на нашем учебном курсе «Основы DevOps» есть финальное упражнение. Группе предлагается ответить на вопрос «Почему всей этой красоты конкретно в вашей компании никогда не будет», ответы аргументировать. Обобщение часто встречающихся ответов может выглядеть вот так:

1. Идеологические. Мы привыкли работать (очень грубо говоря) «по водопаду», а тут этот Agile, который требует свой «mindset» (простите за набор слов в этой фразе, пытаюсь передать смысл). Само слово mindset непонятно, тем более непонятно, что именно нужно изменить в своём mind. Отдельные граждане на специально выделенном им этаже уже все стены обклеили стикерами, но остальные, нормальные, лишь тихонько над ними посмеиваются: известно же, что Scrum — это лучший способ угробить команду, остановить работу и демотивировать сотрудников.
2. Структурные. Как ни крути, а Enterprise — это иерархия, в ней сила, смысл и масштаб, в ней устойчивость и понятные связи, в ней целеполагание, делегирование и отчётность. Какие ещё продуктовые команды? Кому подчиняются люди в команде, ну не владельцу же продукта? Ещё трайбы нарисуйте, ага. У каждого должен быть начальник, который знает, чем именно сейчас занят его сотрудник!
3. Организационные. Есть отдел, у него есть зона ответственности. Есть сотрудник, у него есть функция. Для повышения эффективности работы и ускорения решения задач в Enterprise принято организовывать сквозные процессы, налаживать горизонтальные связи. Это понятно. Но поток создания ценности? Каденции, объединяющие сотрудников разных отделов, у каждого из которых свой руководитель? Это какая-то ерунда. «Управляйте задачами, не управляйте людьми» — вы как эту сказку себе представляете в ИТ-департаменте на 1000—3000 человек? У нас задач на два порядка больше, чем людей.
4. Финансовые. Предприятия десятилетиями выстраивали наиболее экономически эффективную схему использования ценного человеческого ресурса, основа которой — группировка этого ресурса по специализации, а выделение на задачи/работы/проекты — по запросу, по плану, на долю времени, на ограниченный срок. А тут предлагается серьёзно задуматься про запрет на совмещение и выделение 100% времени сотрудника на один продукт. ИТ-бюджет такого, очевидно, не выдержит.
5. Технологические. Конвейер развёртывания для 1С? Автоматические тесты для COTS — системы сторонней разработки, нами кастомизируемой? Виртуализация нашей основной ИТ-системы, разработанной 20 лет назад, без потери производительности? Не всё так просто, коллеги, давайте будем реалистами.
6. Связанные с компетенциями. Два наших товарища, Даннинг с Крюгером, шепчут на ушко: «Да не парься, мы всё делаем правильно, мы лучшие, все так делают!». А если у кого-то закрадывается сомнение, то оно быстро разрушается о простые прикладные вопросы, ответы на которые нам неизвестны.

И что теперь делать?

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

Мне представляется намного более интересным следующий вопрос: что из новых модных направлений, идей, инструментов и методов придётся адаптировать, и как, чтобы они давали значимый эффект в обычных корпорациях? Отдельные моменты достаточно очевидны — например, не стоит устраивать CustDev для бухгалтерии. Другие — менее понятны, например как изменяется роль владельца продукта? Третьи приводят к потрясающим открытиям — например, в корпорации вполне допустимо и разумно под продуктом понимать внутреннюю ИТ-систему (или несколько ИТ-систем), не стремясь включать внутрь продуктового контура наш собственный бизнес. И это мы ещё не затронули вопросы метрик, KPI и SLA, где, очевидно, тоже есть особенности.

Обращение к читателю: если у вас есть минута, можете ответить на следующие простые вопросы?

1. Ассоциируете ли вы себя (свою компанию) с корпорациями, о которых я пишу?
2. Знакомы ли вам приведённые классы ограничений? Насколько они существенны?
3. Интересно ли вам узнать больше о том, как учитывать особенности Enterprise, если есть задача и желание ускорения?