Сроки против процессов

Предисловие

Эту мысль‑статью я вынашивал более 6 месяцев. В разный промежуток времени, я то хотел ее оформить, то нет.

Почему нет? — Мне казалось, что это моя личная рефлексия. Все всё понимают без меня. Зачем писать то, что и так очевидно?

Почему да? — Чем чаще я возвращаюсь к этой рефлексии, тем чаще я думаю, что это не только моя личная проблема. Но и проблема большинства участников команд, открывающих новый путь внутри стандартных процессов.

Введение

Чем крупнее компания, тем больше инвестиций она направляет на развитие процессов внутри себя.

Инвестиции — это команды, которые выделены на определенный процесс.

Команды — это зарплаты, которые компания выплачивает на создание процессов. Итого, всё это ресурсы.

Процессы — это регламент, сформированный иногда кровью, как например, падение сервиса 30 декабря, после незначительных изменений конфигураций в проде. Как результат, запрет на внедрение в прод после 20 декабря из‑за высокого сезона — это результат прошлого негативного опыта.

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

Например, все команды перед внедрением проходят примерно одинаковый путь: документация(бесконечный процесс с бесконечными разветвлениями), разработка, тестирование, релиз.

Парадокс

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

Все команды — сродни локомотиву, идущему по рельсам процессов. Что будет стоить поменять инертное движение годами набирающего скорость сотню тонного локомотива? В какой то момент времени, Вы не сможете резко остановиться или изменить вектор.

Почему это важно?

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

Аллегория: если ходить только по проторенным дорожкам, ничего нового не откроется. Но в мире ИТ, нужно уметь меняться.

Возникает противоречие: унифицированные процессы, созданные для большинства команд, действуют деструктивно на команды‑первопроходцы. Формально все понимают проблему, но никто не создает систему исключений для инноваторов. В результате эти команды вынуждены одновременно и прокладывать новые пути, и соответствовать существующим процессам.

Заключение

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

Вопрос

Что с этим делать? =)