Лекарство от всех болезней

Современные организации — сложные организмы. В них одновременно протекает множество процессов, взаимодействует бесчисленное число субъектов. Как и в любом сложном организме, в них возникают сбои — что-то идёт не так, как положено, или не идёт вовсе. Какой-то участок работ или некоторая зона ответственности, как теперь часто говорят, «подвисает».

Когда затевается действительно большая перестройка, очень часто возникает соблазн явно или не очень, но расширить область охвата проводимых изменений. Явно — когда руководители пытаются воспользоваться случаем. Неявно — когда при проработке управленческих решений участники затрудняются пояснить, почему то или иное решение именно таково. После погружения в детали выясняется, что решалась-то уже совершенно иная задача, нежели чем исходная.

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

Однако не всё так просто. Мир ведь не чёрно-белый. Было бы здрово взять и заявить: простите, есть цели нашей трансформации, этот ваш вопрос в них не вписывается, всего вам доброго, удачи в поиске решений. Но так не выйдет. И проблема никуда не денется, и новая система управления может/должна быть подстроена в некоторой, неопределённой пока степени. Загвоздка в том, что не всегда сразу понятно нужно ли подстраивать и в какой степени.

Поясню на примерах. Начнём с простой ситуации: один наш клиент приложил много усилий, чтобы некоторую команду, или даже несколько команд, организовать по Scrum. Всем казалось, что методология полезная. Потратили несколько месяцев, результаты были так себе. Заглянувший консультант (не из Cleverics) посоветовал: ребята, переезжайте на Канбан-метод, и всё будет намного лучше, кстати вот обоснование, и все проблемы решатся. Было потрачено ещё некоторое количество усилий, равно как и месяцев, но лучше не стало. Когда меня попросили посмотреть на команду и поговорить с сотрудниками, выяснилось, что Канбан не работает по очень простой причине — аналитики не считали нужным брать в работу новые задачи, когда завершены взятые ранее. Банально — зачем работать, если можно не работать? Таким образом, вход в поток отсутствует, а потому отсутствует и всё остальное. Оставим за скобками вопрос как так получилось, и как можно так позволить работать. Однако понятно же, что никакой Канбан-метод (равно как и Скрам, равно как и что угодно другое) не дадут результата, пока не решены ключевые вопросы мотивации отдельных сотрудников. Этот пример показывает один из полюсов, когда систему управления (в данном случае — Канбан-метод) не следует подстраивать в попытке решить другую болезнь (решаемую хорошо известным менеджерским способом).

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

Прочие примеры, которые можно было бы привести далее, расположились бы аккуратно между обозначенными полюсами. Вопросы подбора и найма персонала, построения центров компетенций по технологиям, обеспечения методологической поддержки новых принципов работ, качество и кругозор компетенций сотрудников, технические практики, автотестирование — в управлении ИТ вопросов миллион. Почти ни в одном случае не будет так просто, как в двух рассмотренных — сразу да, либо сразу нет. Нужно смотреть внимательнее и аккуратнее.

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

Но искать универсальное лекарство от всех болезней — точно путь в никуда.

DevOps Основы DevOps

Популярный трёхдневный учебный курс
 

Проект Феникс — DevOps на практике

Полезная деловая игра для вашей команды
 

Узнайте больше!

Комментарии и мнения

  1. Константин

    Подпишусь абсолютно.

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

    То там бежали в ITIL — типа он нас спасет, теперь управление изменениями по водопаду это плохо, срочно AGILE трансформация, она нас спасет. Или давайте обязательно купим этот софт — он решит все наши проблемы... Услышали новое модное слово и побежали.

    А то, что разные методологии надо применять для разных задач никто не слышит. О том, что изменение процесса не ограничивается написанием нормативного документа и установкой KPI на руководителей никто и не задумывается.

Добавить комментарий

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний: