Choose your location to get a site experience tailored for you.

Remember my region and language settings

СКОРОСТЬ БЕЗ КОМПРОМИССОВ

Ханно Кеттерер, старший партнер и управляющий директор, BCG Амстердам
Беньямин Реберг, партнер и управляющий директор, BCG Нью-Йорк
Кристиан Н. Шмид, директор, BCG Мюнхен
Джон Клейне, консультант, BCG Мюнхен

КРАТКИЙ ОБЗОР

Концепция «двухскоростных ИТ» получила поддержку BCG в 2012 году, когда крупные устоявшиеся компании начали активно развивать цифровые технологии. Она стала своеобразным компромиссом, и очень полезным. Поддержка цифровых инициатив традиционными ИТ-организациями большей гибкости, большей скорости, большей готовности к сотрудничеству. Однако менеджменту компаний эти методы, основанные на принципах, изложенных в 2001 году в agile-манифесте разработки программного обеспечения (Agile Manifesto), казались непроверенными, а возможно, даже и не очень надежными. Идея работы на двух скоростях как бы подчеркивала: не беспокойтесь, вы можете применять новые методы в новых областях, таких как цифровые технологии, а традиционный подход оставить для жизненно необходимых функций компании.

На тот момент это была хорошая идея, но времена изменились. Сегодня двухскоростные ИТ — компромисс, который компании больше не могут себе позволить. Будущее ИТ — за одной скоростью: только agile. Не только потому, что гибкая разработка зарекомендовала себя в бесчисленных и крупных технологических компаниях, причем для всех типов программного обеспечения — на основе как цифровых, так и нецифровых технологий. Не только потому, что гибкая разработка проникает в такие отрасли, как банковское дело и страхование (см.: Ensuring Digital readiness in Financial Services, BCG, апрель 2016 г.). И не только потому, что сегодняшние компании при внедрении методов гибкой разработки могут обращаться к опробованным руководствам (см.: Five Secrets to Scaling Up Agile, BCG. февраль, 2016 г.). А в первую очередь потому, что двухскоростные ИТ создают — или в будущем создадут — существенные трудности для компаний, которые продолжат их применять. Двухскоростные ИТ были замечательным промежуточным этапом, но их время прошло.

Недостатки двухскоростных ИТ

Благодаря итеративным циклам разработки, междисциплинарным рабочим группам и постоянному тестированию гибкая разработка представляет собой громадный шаг вперед по сравнению с традиционным подходом (его называют «каскадным»), при котором каждый этап разработки от концепции до тестирования выполняется отдельной рабочей группой. Учитывая разницу между этими моделями — а также процессами и корпоративной культурой, которые для них требуются, — легко понять привлекательность двухскоростного режима. Но работа на двух скоростях, насколько мы видим, создает три проблемы.

Трудности с привлечением и удержанием ценных кадров.

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

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

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

Неровный темп работы.

В современных ИТ-средах agile-инициативы зачастую реализуются на основе проверенных временем традиционных систем. В качестве примера можно привести разработку цифровых пользовательских интерфейсов (digital front end) для традиционной ИТ-инфраструктуры (back end). В этом случае двухскоростной режим означает, что вы постоянно «бьете по тормозам». Реализация динамичных проектов зависит от медленных традиционных циклов «тестирование — релиз», которые будут задерживать реализацию проекта. То, что могло бы заработать завтра, теперь заработает только, например, к осени. По мере того как цифровые приложения постепенно занимают одно из главных мест в бизнесе компании и должны тесно взаимодействовать с основными системами, проблема «самого медленного общего знаменателя» становятся ещё более острой.

Крупным организациям сложно воспользоваться преимуществами гибкой разработки.

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

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

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

В мире, где потребителям предлагается столь беспрецедентно широкий выбор, решающее значение приобретает способность более быстро и гибко разрабатывать системы, относящиеся к ядру. Как отметил Петер Якобс, директор по ИТ ING Bank Netherlands: «Я бы предпочел применять гибкую разработку в ядре системы, а не в каналах взаимодействия».

Полный переход на методики гибкой разработки

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

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

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

Добиться еще большей эффективности можно с помощью самых современных технологий и подходов. Если архитектура информационной системы предполагает взаимодействие приложений, инфраструктуры и данных через стандартизированные интерфейсы (например, API или микросервисы), то и рабочие группы могут действовать независимо друг от друга. Теперь они сами контролируют скорость разработки (и если что-то не в порядке с одним сервисом, то не работает только он, а не вся система). Компании также могут повысить скорость и эффективность — зачастую в несколько раз, — сочетая agile с такими методами, как continuous delivery и continuous deployment (непрерывное обновление и непрерывная сборка) приложений. Это уменьшает количество задач, которые требуется выполнять вручную, а также объем требуемых ресурсов. Подобные меры компаниям следует принимать в любом случае для ускорения перехода на новые цифровые технологии и повышения скорости реагирования.

Гибкий подход к внедрению гибкой разработки.

Внедрение методологии agile в крупной устоявшейся компании, вероятно, будет осуществляться совсем иначе, чем в стартапе. В конце концов, более крупные и более старые организации должны учитывать сложившуюся за прошедшие годы многослойность процессов и уровней иерархии. Кроме того, agile может принимать различные формы даже в рамках одной организации. Одна рабочая группа может посчитать оптимальными двухнедельные «спринты», а другая может решить, что лучше подходят периоды в четыре или шесть недель. Вместе с тем гибкая разработка применительно к старому мейнфрейму не будет похожа на гибкую разработку мобильного приложения. И поскольку некоторые проекты — такие, как масштабная реорганизация ERP-систем — практически невозможно реализовать по небольшим частям, гибкая разработка может означать ежедневный выпуск кода в тестовую среду (но не в среду выпуска готового ПО). Методика agile — это гибкий набор принципов, а не жесткая доктрина. И именно в таком духе ее следует использовать.

Новая система стимулов для руководителей среднего звена.

Роль руководителей среднего звена в случае перехода на гибкую разработку существенно изменится. В конечном счете, многие из координационных задач, которые они традиционно решали, исчезнут. В agile-командах руководители оказываются гораздо ближе к технологиям и содержательной части работы. Они по-прежнему выполняют традиционные менеджерские обязанности — такие, как подбор кадров и их оценка, — но теперь они сами работают в составе групп. И в рамках этих групп они равны всякому другому участнику — выступая, к примеру, в роли разработчика. Вместо того, чтобы давать инструкции другим, они выступают в качестве наставников и советников. Несложно понять, почему руководители среднего звена сопротивляются переходу на гибкую разработку: они видят в этом угрозу потери контроля, а значит и власти. Как избежать такого восприятия? Один способ — обучать и привлекать таких сотрудников к участию в работе, начиная с конференций и неформальных сообществ, или, другими словами, выводить их на «передовую». Ключевые показатели эффективности (КПЭ) руководителей тоже следует пересмотреть. Они должны поощрять быструю разработку и реализацию нужных функций, однако допускать возможность некоторых сбоев, при условии, что система в целом остается стабильной. Это в гораздо большей степени соответствует логике agile.

Развитие цифровой культуры.

Полный переход от двухскоростных ИТ к agile — дело не одного дня. Поскольку война за таланты не прекращается, важно донести до нынешних и потенциальных сотрудников мысль о том, что будущее компании неразрывно связано с agile. Для популяризации динамичной культуры нестандартного мышления проводятся «хакатоны» — соревнования, на которых команды меряются силами в разработке оборудования и программного обеспечения. (Собственно, вездесущая кнопка «нравится» в Facebook возникла в результате подобного «хакатона».) Идея заключается в том, чтобы предпринять шаги, благодаря которым эксперты по технологиям будут знать, что они могут оставаться — и успешно оставаться! — экспертами по технологиям. Карьерный рост в компании не обязательно должен быть связан с переходом на административную работу.

Формирование совместных групп из специалистов по бизнесу и ИТ.

Один из замечательных элементов методологии гибкой разработки — многофункциональные рабочие группы, в которых совместно работают специалисты по бизнесу и ИТ. Переход на принципы agile означает устранение организационных барьеров и развитие коммуникации и взаимодействия между участками, которые когда-то были изолированы друг от друга (см.: The Power of People in Digital Banking Transformation, BCG Focus, ноябрь 2015 г.). Гибкость здесь также имеет решающее значение. Основополагающий принцип agile заключается в том, что в роли владельца продукта выступает представитель бизнес-функций. Но для продуктов и инструментов, предназначенных для использования ИТ-службами, более целесообразно, чтобы владельцем продукта выступал представитель функции ИТ. Повторим: подходы и опыт, наработанные ранее специалистами по гибкой разработке в рамках «двухскоростной» ИТ-организации, могут оказаться бесценными.

Дальнейшие пути развития agile

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

Уже сейчас мы видим, что методология гибкой разработки из области ИТ пришла в управление продуктами и маркетинг, а также в такие функциональные направления, как кадровые ресурсы и управление рисками (см.: The Agile Marketing Organization, BCG Focus, октябрь 2015 г.). Spotify и ING представляют собой замечательный пример компаний, применяющих принципы гибкой разработки как в сфере ИТ, так и в бизнесе (см.: Building a Cutting Edge Banking IT Function An Interview with Ron van Kemenade the CIO of ING Bank, BCG, декабрь 2015 г.).

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

BCG Review
Previous Page