Привет, меня зовут Анатолий Чикирев, и сегодня я расскажу вам о Lean-практиках сокращения потерь в IT-сфере. Для начала давайте договоримся о терминологии. Lean и бережливое производство — это синонимы. Я буду использовать оба термина, но речь пойдёт об одном и том же. Но сначала пара слов обо мне и моём опыте. 

Я работаю продактом в SM Lab с 2022 года, в целом в IT пришел  в 2018 году — тогда я занимался заказной разработкой. Впервые я узнал о бережливом производстве в Высшей школе экономики, где изучил базовую теорию и основные понятия. Уже тогда мне показалось это интересным, но, разумеется, практики ещё не было никакой. Потом я пришел на свою первую работу на завод, где участвовал в пилотном проекте по внедрению Lean с привлечением консультантов. Там я руководил проектным офисом, поэтому сам проект видел больше с административной точки зрения и только несколько раз выходил «в поле» с руководителем проекта, а глубже в суть методологии погрузился уже позже.

Следующим этапом стала работа в международной FMCG-компании, где бережливое производство уже было внедрено, и я пришёл, как говорится, «на готовенькое»: моей задачей было поддерживать систему, развивать её и внедрять новые инструменты и практики, которые предлагала международная команда. Именно тогда я по-настоящему прочувствовал пользу и мощь Lean, увидев, как эти принципы работают на практике в производстве и какой эффект они могут приносить бизнесу.

Когда я перешёл в IT (сразу после той самой FMCG-компании), у меня возник большой вопрос: «А работает ли Lean здесь?». Я понимал, что теоретически — должно. Но как именно это применять? Как перенести инструменты, которые я применял на производстве, на IT-процессы? Поначалу это было неочевидно. Со временем, когда я освоился и в IT, и в роли продакта, и в самой SM Lab, всё встало на свои места. Я разобрался, как Lean может работать здесь, начал внедрять его на практике — и применяю до сих пор.

И сегодня расскажу вам, как с этим жить и внедрять у себя — без боли и с реальной пользой. 

В чём суть Lean?

Начну с самого главного — с сути Lean. И скажу сразу: всё на самом деле предельно просто. Суть Lean сводится к одному — к максимизации ценности. А это, в свою очередь, складывается из двух составляющих:

1. Увеличение действий, которые создают добавочную ценность (value-added activities)

2. Систематическое сокращение потерь

С потерями работают двумя способами. Первый — полное устранение. Если потерю можно исключить из процесса совсем — так и нужно делать. В IT самый банальный пример — это баги. Да, в реальности от них на 100% не избавиться, но в теории мы можем написать код без багов, а значит, мы должны к этому стремиться. 

Второй способ — оптимизация потерь, которые нельзя полностью убрать из процесса. Здесь задача — минимизировать затраты ресурсов на такие активности. Самый очевидный пример такого рода потерь — релизы. От них никуда не деться, они всегда будут требовать времени. Но чем лучше отлажен процесс, чем более плавно выстроены ваши CI/CD, тем меньше ресурсов будет на это расходоваться.

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

Типы потерь в IT

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

1. Перепроизводство

• Ненужные фичи, которые никто не использует

• Лишние алерты, засоряющие мониторинг

• Документация, которая пылится в базе знаний и не используется

2. Ожидание

• Простои задач в очередях

• Задержки из-за смежных команд или подрядчиков

• Ожидание ответов заказчика или согласований, необходимых для продолжения работы

3. Транспортировка

• Процесс релизов (особенно сложных)

• Перенос задач между разными трекерами (если их у вас больше одного)

• Миграция данных между средами

• Разрозненные коммуникации (когда часть обсуждений в Telegram, часть в Teams и т.д.)

4. Избыточная обработка (overprocessing)
Важно: не нужно путать с перепроизводством, здесь речь не про лишние результаты труда, а про лишние действия при создании этих результатов. Примеры:

• Излишне сложный код там, где достаточно простого решения

• Чрезмерный рефакторинг без реальной необходимости

• Избыточные этапы ревью и тестирования

5. Запасы

• Избыточные серверные мощности, неактуальные для текущих масштабов продукта

• Большие релизы

• Захламлённый бэклог, который никто не грумит и не приоритизирует

6. Брак

• Баги в коде

• «Костыли», которые гарантированно создадут технический долг. Тут важно отметить, что речь не про те «временные решения», которые потом часто работают годами, а про «часовые бомбы», которые точно нужно будет переделывать

7. Лишние перемещения

• Бесполезные совещания

• Избыточные согласования

• Сложная навигация в плохо организованном коде

8. Нереализованный потенциал (тип, особенно характерный для IT)

• Привлечение сеньоров для решения простых задач, с которыми справится миддл/джун

• Загрузка специалистов с высоким потенциалом роста рутинными, не развивающими задачами, вместо того, чтобы использовать его компетенции по максимуму

Подытожим для наглядности.

«8 типов потерь»

Все эти потери съедают ваши ресурсы — время, деньги, мотивацию. Lean учит системно выявлять и устранять их.

Цикл PDCA: как это работает на практике

Базовая теория по PDCA была придумана очень давно, и изначально она касалась не IT, а менеджмента в целом. Однако, она отлично ложится в концепцию Lean и бережливого производства.

Что такое цикл PDCA? Это, очевидно, аббревиатура, давайте разберем её по частям.

P (Plan) — запланируй

На этом этапе возможно применение типовых, но при правильном использовании гарантированно работающих инструментов, поэтому остановимся на них подробнее.

Метод «5 почему» — ключевой инструмент для поиска коренных причин. Почему он важен? Потому что очень часто коренная причина проблемы не видна сразу, а работа с причинами, лежащими на поверхности, не принесет желаемого результата, т.к. коренная причина не будет устранена. Рассмотрим пример: человек перебежал на красный свет. Почему он это сделал? Потому что опаздывал на работу. Но это лишь первый уровень, давайте посмотрим глубже. Опаздывал он потому, что проспал. Проспал — потому что будильник не сработал. Будильник не сработал, потому что сел телефон. Сел телефон, потому что не проверил его перед сном и не поставил на зарядку. В итоге получаем, что человек перебежал дорогу на красный свет, потому что не проверил перед сном телефон и не поставил на зарядку. Взаимосвязь между итогом и коренной причиной крайне не очевидна. Универсальность данного подхода, как и, в принципе, всех, описанных в статье, позволяет применять этот подход не только в IT, но и в других сферах, в том числе за пределами работы. 

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

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

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

Матрица делится на четыре квадранта:

1. Быстрые победы — высокое влияние, низкие затраты.

2. Крупные проекты — высокое влияние, высокие затраты.

3. Заполнители пробелов — низкое влияние, низкие затраты.

4. Неблагодарные задачи — высокие затраты, низкое влияние.

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

Заполнители пробелов — это задачи, которые можно выполнять по остаточному принципу, если есть свободные ресурсы. Они принесут пользу, но не являются приоритетными.

Здесь отдельно стоит обратить внимание на принцип Парето: 80% результата достигается за счёт 20% усилий. При анализе решений мы оцениваем их эффективность (в данном контексте — соотношение запланированного эффекта к затратам). Опять же, обращаю внимание на необходимость опираться на реальные данные, если есть хотя бы какая-то возможность их получить (а она зачастую есть). Также важно не переусердствовать: в какой-то момент дальнейшие улучшения станут слишком дорогими. Ресурсы ограничены, поэтому в какой-то момент вместо получения минимальной выгоды от решения лучше переключиться на другую область.

D (Do) — сделай

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

C (Check) — проверь

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

В SM Lab, например, есть отдельный портал, который автоматически собирает метрики по рабочему процессу — там можно посмотреть практически все возможные срезы данных. Если чего-то не хватает, можно выгрузить сырые данные, проанализировать их и составить нужные отчёты самостоятельно. Это большой плюс, который сильно помогает в аналитике. 

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

A (Act) — скорректируй

Переходим к последнему шагу. Здесь есть важный нюанс перевода. Дословно «Act» означает «действуй», что перекликается с «Do». Но в нашем контексте более точный перевод — «скорректируй».

Что это значит? Есть два варианта:

1. Вы достигли цели — отлично! В этом случае нужно зафиксировать результаты, внедрить их в процессы, прописать в стандартах и использовать в повседневной работе.

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

Цикл

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

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

Реальный кейс: оптимизация сопровождения

Я работаю с системой доставки коммуникаций для всей группы компаний «Спортмастер» — это высоконагруженное решение, обрабатывающее десятки миллионов сообщений ежедневно через различные каналы: Telegram, email, SMS, push-уведомления, ВКонтакте и другие. Система критически важна, поскольку через неё, в частности, отправляются авторизационные SMS и пуши для списания баллов в магазинах — это особенно чувствительный момент. Если уведомления не приходят, пока покупатели на кассе, они сильно расстраиваются и уходят.

Основная проблема заключалась в чрезмерно высоких затратах на сопровождение системы. Команда тратила около 20% рабочего времени на обработку тикетов — время, которое можно было бы направить на разработку новых функций. При этом полностью отказаться от сопровождения было невозможно. Вторая серьёзная проблема — постоянная нескончаемая очередь из примерно 15 тикетов. Мы закрывали одни задачи, но появлялись новые, создавая эффект снежного кома, который не удавалось разгрести, что приводило к деморализации команды.

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

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

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

Четвертая — высокий объём консультаций. Бизнес регулярно обращался за дополнительной аналитикой или информацией по отправленным коммуникациям. Подобные запросы также отнимали много времени.

Что сделали? (Do)

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

2. Реестр типовых инцидентов
   Для эффективной работы первой линии нужен реестр шаблонных решений. Это позволяет быстро отвечать на стандартные запросы без глубокого погружения в контекст.

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

4. Все запросы — через первую линию
   Даже если заказчик обращается напрямую, важно направлять его в первую линию поддержки. Это экономит время и обеспечивает порядок в обработке запросов.

Результат (Check)

Что получилось на выходе?

К зиме 2024–2025 года (примерно через полгода после начала работы) мы сократили долю времени команды на сопровождение до 12%. Более 65% инцидентов и запросов (то есть больше двух третей) теперь решаются на первой линии поддержки. Очередь задач для команды сопровождения стремится к нулю — тикеты поступают, но оперативно закрываются, и это не мешает аналитикам работать над новыми функциями и развитием системы.

Отдельное уточнение: да, 12% — это время именно команды аналитиков. Первая линия поддержки тоже тратит время — из тех 8%, что мы сократили, на неё приходится около 4–5%. Но первая линия сопровождения стоит значительно дешевле, чем работа аналитиков. Такие нюансы важно учитывать при оценке экономического эффекта от улучшений.

Что делаем дальше? (Act)

1. Регулярный анализ метрик
   Как я уже говорил, раз в неделю мы проводим короткий статус по сопровождению: быстро проверяем ключевые показатели, убеждаемся, что всё в порядке, обсуждаем возможные варианты улучшений.

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

Бонус: какие ещё best practices можно взять из бережливого производства?

1. Гемба (Gemba) / Муда (Muda) — обходы
   В производстве это означает выход на линию и наблюдение за процессом на месте. В IT это выглядит так: если вы столкнулись с проблемой — погрузитесь в неё. Даже если вы не разбираетесь в коде, вы можете изучить требования, тест-кейсы, поговорить с разработчиком, понять узкие места. Это помогает в анализе и поиске решений.

2. Работа с реальными метриками
   Критически важно использовать фактические данные, а не экспертные оценки. Лучше, если метрики собираются автоматически. Если нет — договоритесь о ручном сборе, но не полагайтесь на субъективные оценки: они часто ошибаются.

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

4. Стандартизация инструментов
   Навыки работы с инструментами анализа (майндмэпы, «5 почему», диаграмма Исикавы) должны быть доведены до автоматизма у всей команды. Это ускоряет процесс: собрались, быстро разобрали проблему по отработанной методике, наметили действия, разошлись делать.

Вывод

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

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

Lean работает, если применять его гибко, измерять результаты и не бояться корректировать подход на ходу. В итоге это приводит не только к экономии времени и денег, но и к более предсказуемым, управляемым и продуктивным IT-процессам.

А как в ваших командах ищут и устраняют потери?