Збільшення удвічі продуктивності додатків за допомогою Lean-інструменту Kaidzen.

Члени 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 – це основна структура вебсайту, ассети – це те, що робить його красивим, наприклад, зображення, стиль, інтерактивність; дані – це те, що робить його корисним, наприклад, вміст кошика користувача на комерційному сайті.

Потік створення цінності показує всі дії, які потрібно здійснити, щоб задовольнити потребу клієнта від замовлення до постачання цінності.

Цей підхід виглядав багатонадійним, хоча у застосуванні до інших проєктів, він виявився занадто спрощеним, через те, що є ряд причин, чому етап асетів (Assets) може зайняти занадто багато часу. Потім ми збільшили масштаб. Ми закінчили з потоком створення цінності, встановивши таймінг у сумі 3 секунди.

Тепер у нас є потік створення цінності, який потенційно може виявити конкретні проблеми у вебдодатках. Ми вирішили використовувати його, щоб допомогти Theodo створювати швидші додатки.

Наші колеги звертались до нас з проханням допомогти з їхніми продуктами. Їх проблеми були майже ідентичними, хоча причини були різними, через те, що існує безліч причин повільної роботи вебсторінки. Ми навчили показувати потік створення цінності їх продуктів, щоб можна було побачити вузькі місця «bottleneck»:

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

Мінімізація втрат у вебдодатках.

Втрати в Lean – це дії, які не додають цінності клієнту та призводять до використання ресурсів, не підвищують ринкову вартість продукту, а збільшують його собівартість.

У сфері IT таких втрат достатньо, і саме Lean допоможе побачити їх та ліквідувати. Розповім вам про наш досвід.

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

Критичним з точки зору продуктивності зазвичай є шостий крок – браузер завантажує ассети. Це те місце, де важкі додатки викликають незадоволення у часі під час завантаження.

Кайдзен показав нам, що розробники часто завантажують бібліотеки (повторно використані фрагменти коду, які розроблені та розповсюджені всередині комьюніті), які не є необхідними для коду додатка. Це часто призводить до марного завантаження фрагменту коду, який ніколи не буде використано. Це і є одним із видів втрат у Lean. Одним з прикладів цього, це Lodash, популярна бібліотека Javascript, яка містить в собі більш ніж 100 часто використовуваних функцій (по суті швейцарський армійський ніж для Javascript розробника). Наприклад, розробнику необхідно використовувати метод «флаттен» бібліотеки Lodash для перетворення складних структур даних у простіші. Було б дуже наївно їх використовувати просто імпортуючи:

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

Проте це має неочікуваний побічний ефект, через те що завантажується всі 100 функцій Lodash, хоча нам потрібно використовувати тільки одну.

Щоб уникнути такої 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/