Значение стандартов над стандартизацией

Сатти Бенс, Партнер Digital McKinsey и Лидер цифровых лабораторий, и Джейк Макгуайр, Консультант, McKinsey

Недавно директор по цифровым технологиям обратился к нам за советом по поводу стандартизации единой веб-платформы. Он был обеспокоен тем, что маркетинговая команда организации недавно решила использовать React (веб-фреймворк, разработанный Facebook), в то время как несколько бизнес-подразделений были стандартизированы вокруг Angular (веб-фреймворк, разработанный Google).

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

Крупные предприятия часто испытывают фрагментацию веб-инструментов между командами.

Итак, как предприятия могут использовать несколько фреймворков?

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

С этой веб-фрагментацией предприятия сталкиваются с рядом проблем:

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

Разданный опыт. Наличие нескольких платформ приводит к тому, что опыт не может быть разбросан по всему предприятию. Узкие места возникают, когда эксперт в определенной структуре недоступен, чтобы помочь разблокировать проблему разработчика, в то время как другие эксперты в других структурах могут иметь возможности, которые можно было бы использовать, если бы они использовали те же стандартные технологии.

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

Ремонтопригодность. Множественные фреймворки создают длинный хвост приложений с устаревшими технологиями, которые все меньше и меньше разработчиков знают или хотят поддерживать. Например, современное приложение Backbone с 2011 года может оказаться невыполнимой задачей для поддержки в 2018 году.

Хотя фрагментация вызывает проблемы в масштабе предприятия, существуют также проблемы с жестким соблюдением стандартных веб-фреймворков:

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

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

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

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

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

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

(2) Постарайтесь создать глубокую арену из экспертов по JavaScript и экспертов по фреймворкам. Ожидайте, что старшие инженеры будут хорошо разбираться в JavaScript и иметь опыт работы с несколькими фреймворками. Предоставьте им право голоса в процессах выбора фреймворка и исключения. Многие из этих старших практиков будут тестировать новые фреймворки, наблюдать за тенденциями и приближаться к деталям на уровне реализации.

(3) Используйте непрерывную автоматизацию. Самое главное, встраивайте автоматические тесты во все, что команды создают или изменяют. Это критически важно для ремонтопригодности, и это особенно важно для разработчиков, которым потребуется исправлять критические проблемы через много лет в будущем, когда стандартная структура уже унаследована. Кроме того, надежный автоматизированный набор тестов служит защитой для разработчиков, выявляя непреднамеренные регрессии в режиме реального времени.

В этом подходе приоритет отдается стандартам над стандартизацией. Предприятиям следует сосредоточиться на качестве с помощью базовых стандартов - модульных компонентов, строгих автоматизированных наборов тестов, автоматизированной упаковки, DevOps и т. д. мониторинг и т. д. - а не веб-фреймворк. Выбор между Angular или React менее значим, чем приверженность базовым стандартам. Это обязательство позволит предприятиям быстро и эффективно мигрировать, когда на горизонте появится следующая инновационная веб-платформа.

Фотография заголовка Дэйн Топкин на Unsplash

Встроенный рисунок Джейк МакГуайр, Консультант, McKinsey

Особая благодарность Кристиану Лилли, Оскару Вильярреалу, Бренту Пабсту, Дэйву Керру, Айшварии Сингхал, Фархаду Гаюру и Томасу Ньютону за то, что они поделились своим опытом при написании этой статьи.