Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их необходимо создавать и развивать. При этом, если ваша организация – это не недавно созданный стартап, то скорее всего она жила и функционировала уже какое-то время. А значит гибкий команды, по сути, будут состоять из тех же самых людей, что поддерживали развитие бизнеса через внутреннюю разработку ИТ-продуктов всё время существования компании.

Изменения не всегда могут приветствоваться людьми, которых они затрагивают. Есть устоявшиеся процессы, в которых сотрудники чувствуют себя комфортно. Им может казаться, что организовать работу другим способом просто невозможно. Часто они полагают, что изменения только усложняют им жизнь, не принося никаких существенных улучшений в работу. Что необходимость трансформации организации выдумана какими-то топ-менеджерами, не понимающими нужды и потребности разработчиков.

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

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

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

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

Кого охватывают изменения?

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

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

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

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

Как сбалансирован переход?

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

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

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

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

Синхронизацию и отслеживание прогресса накопления зрелости гибкими командами лучше проводить на основе объективных данных – метрик, позволяющих оценить разные аспекты рабочего процесса. Иначе велика вероятность ошибиться в оценках и принять неверные управленческие решения.

Является ли рабочий процесс зрелым и управляемым?

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

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

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

Оценка состояния технической зрелости

Когда происходит определение границ ИТ-продуктов, необходимо так же провести ревизию состояния ресурсов в области охвата (технологии, инженерные практики и т.д.). Очень часто в сложном ИТ-ландшафте внутренней разработки давно существующих компаний наблюдается целый зоопарк технологий, в том числе довольно древних, на фоне отсутсвия внятной стратегии ИТ-развития.

Стек технологий и тренды в ИТ-индустрии меняются очень быстро. Наличие сложных навыков и постоянное совершенствование знаний в области разработки программного обеспечения имеет первостепенное значение для успешной работы, обеспечивающей высокий уровень качества создаваемых ИТ-продуктов и их соответствие современным требованиям пользователей.

С точки зрения Agile необходимо создать комфортную среду для работы, тогда ИТ-разработчики, являющиеся высококвалифицированными профессионалами, смогут самостоятельно организовать работу наилучшим образом. Для этого необходимо выработать ИТ-стратегию и заложить стандарты развития в соответствии с целевыми состояниями бизнеса.

Состояние стандартов работы

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

Например, наша диагностика не редко выявляет ситуацию, когда показатель от 15% до 50% дефектов в общем объёме работ у многих команд считаются нормой. То есть половина всей работы исправляется или делается заново, и в этом никто не видит проблему.

Или до 80% трудового ресурса сотрудников расходуется впустую. Этих дорогих специалистов можно было бы перераспределить между командами, традиционно испытывающими дефицит кадров, но никто не занимается оценкой эффективности ресурсов, поскольку нет соответствующих стандартов и KPI.

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

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

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

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

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Построение системы KPI для ИТ

Как обеспечить управление процессами, проектами, услугами, персоналом