Сроки против Процессов
Предисловие
Эту мысль-статью я вынашивал более 6 месяцев. В разный промежуток времени, я то хотел ее оформить, то нет.
Почему нет? — Мне казалось, что это моя личная рефлексия. Все всё понимают без меня. Зачем писать то, что итак очевидно?
Почему да? — Чем чаще я возвращаюсь к этой рефлексии, тем чаще я думаю, что это не только моя личная проблема. Но и проблема большинства участников команд, открывающих новый путь внутри стандартных процессов.
dalle
Введение
Чем крупнее компания, тем больше инвестиций она направляет на развитие процессов внутри себя.
Инвестиции — это команды, которые выделены на определенный процесс.
Команды — это зарплаты, которые компания выплачивает на создание процессов. Итого, всё это ресурсы.
Процессы — это регламент, сформированный иногда кровью, как например, падение сервиса 30 декабря, после незначительных изменений конфигураций в проде. Как результат, запрет на внедрение в прод после 20 декабря из-за высокого сезона — это результат прошлого негативного опыта.
Иногда ПОтом, как например, систематический онбординг новых сотрудников в один и тот же процесс. Как результат: документация, обучение, вводный курс. Всё это — процессы, которые созданы для того, чтобы новичок быстрее влился в команду. Однако, такая унифицированная система обучает его унифицированному подходу, готовя таким образом унифицированного участника команды, который сможет решать унифицированные задачи. И будет подчиняться унифицированным процессам. Таких участников большинство, как следствие, это — стандартизация работы большинства команд.
Например, все команды перед внедрением проходят примерно одинаковый путь: документация (бесконечный процесс с бесконечными разветвлениями), разработка, тестирование, релиз.
Парадокс
Парадокс заключается в том, что процессы, в которые компания вкладывает огромные ресурсы, созданные для уменьшение рисков, быстрый онбординг сотрудников, сокращения сроков разработки, начинают всё сильнее ограничивать скорость выполнения работ по мере накопления экспертизы участников команды.
Все команды — срадни локомотиву, идущему по рельсам процессов. Что будет стоить поменять инертное движение годами набирающего скорость сотню тонного локомотива? В какой то момент времени, Вы не сможете резко остановиться или изменить вектор.
Почему это важно?
В любом крупном интерпрайзе существует определенный процент микрокоманд, которые должны находить новые пути — это естественный жизненный цикл развития.
Аллегория: если ходить только по проторенным дорожкам, ничего нового не откроется. Но в мире ИТ, нужно уменить меняться.
Возникает противоречие: унифицированные процессы, созданные для большинства команд, действуют деструктивно на команды-первопроходцы. Формально все понимают проблему, но никто не создает систему исключений для инноваторов. В результате эти команды вынуждены одновременно и прокладывать новые пути, и соответствовать существующим процессам.
Заключение
В результате, таким командам приходится искать компромисс: либо отказаться от инноваций, либо жертвовать процессами. Поскольку следование процессам часто не несет бизнес-ценности, команды вынуждены их обходить. Это создает дополнительную нагрузку на всю вертикаль менеджмента: руководители всех уровней тратят время на согласование исключений из правил. Так возникает противостояние «сроки против процессов» — конфликт между стандартизированными процессами и потребностями команд, идущих по инновационному пути.
Вопрос
Что с этим делать? =)
