О логистике, поставщиках и DevOps

Идея статьи возникла из нарастающего интереса к Agile и, в частности, к DevOps в сфере производства. Несмотря на то, что сейчас любая деятельность так или иначе круто завязана на IT, людям, занимающим высокие должности в сфере производства реальных товаров, может быть трудно понять наш профессиональный язык, в котором к тому же что ни термин, то англоязычный.

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

 

DevOps: Deployment Pipeline

 

В DevOps, как и в реальном производстве, усилия направлены на изменения по трем направлениям: культура компании, процессы и инструменты. В чем цель? Быстрее выводить качественный продукт на рынок и  открыть путь инновациям. Для этого мы смотрим на производство как на целостную систему, выстраиваем непрерывный поток обратной связи, максимально размываем границы между участвующими в создании продукта сторонами, автоматизируем нудную работу и избавляемся от потерь, выстраиваем культуру экспериментов и непрерывного обучения.

В производстве оптимизируется цепь поставок, то есть цепь процессов от поставки сырья до конечного потребления изготовленного продукта. В DevOps аналогом цепи поставок служит Deployment Pipeline. Мы постепенно устраняем потери, такие как ожидание, избыточные процессы, незавершенная работа, дефекты и т.д. Для максимально эффективного устранения каждого вида потерь требуются культурные изменения, соответствующие процессы и в ряде случаев поддерживающие инструменты. Например, можно ввести проверочные списки и контроль качества на отдельных этапах производства, чтобы бракованная деталь не ушла дальше по цепи, а тем более не попала в конечный продукт, приведя к реальным потерям. В IT аналогом служат автоматизированные тесты, автоматический контроль качества кода и взаимное «code review».

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

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

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

Разобрались, что такое Deployment Pipeline/цепь поставок. И в производстве и в IT мы не только избавляемся от потерь, но и используем логистический подход для максимально эффективного и быстрого прохождения всех стадий сборки/производства/проверки — практики непрерывной интеграции и непрерывной поставки. Мы даже пытаемся найти ответы на одни и те же вопросы:

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

Все так похоже от того, что в основе лежат одни и те же принципы и подходы: бережливое производство, теория ограничений, системный подход. DevOps же в IT эти подходы объединяет и усиливает, но от собственных фундаментальных основ не отступает.

 

 

Share

Leave a Reply