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

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

Об этой проблеме все очень хорошо осведомлены в компании Theodo. В начале 2018 г., 80% приложений над которыми мы работали, считались слишком медленными. Это было «болевой точкой», проблемой для наших клиентов и пользователей.

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

Кайдзен – это один из инструментов Lean-методологии, комплексное мероприятие, основанное на совместной работе. Его цель быстрое улучшение и сокращение потерь в конкретном процессе с применением Lean-инструментов. Буквально в течение одной недели организованная команда определит и локализирует проблему, выявит причину, примет эффективное решение и разработает план его реализации.

Изучение ситуации

Нашим первым шагом было исследовать то, чего уже достигли лучшие компании с точки зрения веб-производительности. Первая компания, на которую мы обратили внимание была Uber. Они столкнулись с быстрорастущей пользовательской аудиторией в развивающихся странах. Uber встретился с проблемой предоставления упрощенного обслуживания пользователей на устройствах начального уровня в плохих условиях сети. Они разработали сайт m.uber.com, который объединяет основной поток клиентов Uber в невероятно легкое приложение.

Команда Uber использовала умелые техники, чтобы уменьшить размер приложений до 50 килобайт, что на 97% меньше среднего размера. Более легкое приложение дает более короткое время загрузки, что в свою очередь означает, что пользователь может быстрее взаимодействовать со страницей. Это достижение стало для нас главным источником вдохновения.

Определение потока создания ценности

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

Таким образом, мы начали думать о системе анализа, которая могла бы нам помочь проанализировать любой веб-сайт, не только наш. Мы пытались представлять веб-сайт, как фабрику. Фабрика принимает заказ клиента, производит его и доставляет готовую продукцию. Веб-сайт тоже принимает взаимодействие с клиентом (кликая на ссылку), обрабатывает его и предоставляет результат (home page). Наша проблема с производительностью превратилась в проблему времени выполнения заказа.

Чтобы определить время выполнения заказа, мы начали с потока создания ценности: какие шаги выполняет веб-браузер, чтобы перейти от кликанья на веб-страницу. Мы начали с разделения этого процесса на 3 главных шага: HTML, ассеты (Assets) и данные (Data). HTML – это основная структура веб-сайта, ассеты – это то, что делает его красивым, например, изображения, стиль, интерактивность; данные – это то, что делает его полезным, например, содержимое пользовательской корзины на коммерческих сайтах.

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

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

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

Минимизация потерь в веб-приложениях.

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

В сфере IT таких потерь предостаточно. Расскажу о нашем опыте.

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

Критическим с точки зрения производительности обычно является шестой шаг – браузер загружает ассеты. Это то место, где тяжелое приложение вызывает неудовлетворенность времени загрузки.

Кайдзен показал нам, что разработчики часто загружают библиотеки (повторно используемые фрагменты кода, разработанные и распространённые внутри комьюнити), которые не являются необходимыми для кода приложения. Это часто приводит к бесполезной загрузке фрагмента кода, который никогда не будет использован. Это и есть один из видов потерь в Lean. Один из примеров такого, это Lodash, популярная библиотека Javascript, которая инкапсулирует в себе более 100 часто используемых функций (по сути это швейцарский армейский нож для Javascript разработчика). Например, разработчику необходимо использовать метод флаттен, библиотеки Lodash для преобразования сложных структур данных в более простые. Наивно было бы использовать его просто импортируя:

import { flatten } from 'lodash'; // weighs 71Kb

Однако это имеет неожиданно побочный эффект, так как загружаются все 100+ функций Lodash, хотя нам нужно использовать только 1 функцию.

Чтобы избежать такой Lean потери, есть менее известный подход к загрузке только необходимой функции:

import flatten from `lodash/flatten`; // weighs 2.8Kb

Этот простой трюк позволяет уменьшить размер на 68 КБ, этого достаточно, чтобы ускорить время загрузки на 1 секунду для пользователя 3G.

Сегодня 60% веб-приложений Theodo загружается менее чем за 3 секунды. Мы создали базу знаний из более чем 10 стандартов, покрывающие большинство проблем производительности.

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

https://planet-lean.com/doubling-performant-apps-using-kaizen/