Перевод статьи: http://www.poppendieck.com/lean.htm, автор: Mary
Poppendieck

Где-то в 1980
году, когда NBC писало, "Если японцы могут, почему не можем мы?", я была
системным менеджером на фабрике по производству видеокассет и наша
команда управленцев задавалась этим вопросом каждый день. Наше
соревнование с японцами было по продаже более лучших продуктов по
наименее низкой цене, и мы не могли понять как они это делают. Мы
знали, что нам нужны значительные изменения или придется закрывать
лавку, но мы не знали что менять.

Мы
делали все правильно на сколько это возможно. Мы полагались на
оптимизирующие методы прогнозирования, чтобы определить экономические
параметры и мы использовали последние разработки программного
обеспечения для MRP
(Manufacturing Requirements Planning), чтобы строить ежедневные
расписания на фабрике. Мы имели сложную компьютерную систему, которая
анализировала результаты QC (контроля качества) и параметры процесса,
чтобы определить точно причины дефектов.

Мы
имели проблемы с качеством и выполнение
большинства заказов занимало
месяц. Каждую неделю, мы могли упаковать около 60% из
запланированного производства. Но это было нормально, потому что другие
40% шли на склад готовой продукции. Обычно мы имели достаточное
количество продукции для поставки стандартных заказов. Со спец-заказами
была другая история. Подразделение вице-президента часто звонило насчет
срочных спец-заказов для важных клиентов.

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

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

Бережливое производство

В конце второй мировой войны Сакичи
Тойода, основатель компании Toyoda
Spinning and Weaving (ткацкая фабрика), мечтал производить автомобиль
для простого потребителя, так же как Генри Форд мечтал об этом в 30-х
годах. Мы
отдали права Тайчи Оно построить эффективную производственную
систему  для выпуска высококачественных автомобилей. В
следующие
три десятилетия Оно разработал систему производства Тойота ( Toyota
Production System), теперь
широко известную как бережливое производство[1]. Новая
система позволяла полностью избавиться от убытков.

Оно
изучил технологию производства в США и научился многому от Генри Форда,
пионера по внедрению сборочного конвейера. Однако конвейер производил
большое количество одинаковых машин. Оно не имел такой потребительский
спрос, чтобы повторять практику в США производства в больших масштабах.
Он был очарован американскими супермаркетами, где было небольшое
количество каждого продукта на полках. И как только покупатели брали
продукты, полки быстро заново пополнялись. Он решил использовать
принцип
супермаркета на своей фабрике и обнаружил, что такой подход значительно
уменьшает убытки от незавершенного производства. Он назвал эти
производственные супермаркеты "Канбан".

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

Чтобы
увеличить поток производства, были созданы стандартные листки учета
работы, но не те, что разрабатываются на столах инженерах. Они писались
на полу рабочими, которые знали процесс. Стандартные временные циклы и
принцип канбан для отведения места на полке для каждой единицы были
определены и поток работ стал ровным. Рабочие на производстве были как
эстафетная команда, передавая палочку (продукт) от одного к другому.
Конвейер требовал 100% качества и сжатых сроков. Если что-то тормозило,
рабочие помогали друг другу настроить машину или устранить
неисправность.

Агрессивное
избавление от расходов Оно привело его к двум вещам: быстрое
производство и неотъемлемое качество. Со временем Оно
обнаружил,
что эти две вещи ведут к высочайшему качеству, низкой цене и коротким
срокам освоения продукции.

Всеобщее управление
качеством

Примерно
в то же время Эдвард Деминг
преподавал теорию управления качеством в Японии. В действительности
теория "Всеобщее управление качеством" (TQM) не может быть отделена от
бережливого производства. Размер фотографии Деминга в головном управлении Тойота
больше, чем размер фотографии основателя — Тойоды Сакичи. Деминг не нашел слушателей в
США после второй мировой войны, потому что менеджеры в то время думали,
что плохое качество было из-за того, что люди не хотят делать свою
работу хорошо. Они не думали, что было много менеджеров, которые могли
бы улучшить качество кроме как уговаривая сотрудников делать работу
лучше.

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

В 80-х годах 14
пунктов Деминга были изучены почти каждым менеджером на
производстве.
Среди этих 14-ти пунктов хорошо известны:

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

Но
некоторые из пунктов выглядят
революционно даже сегодня:

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

Сдвиг парадигмы

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

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

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

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

Простые правила

В январе 2001 года вышла статья в Harvard
Business Review под
заголовком "Стратегия в виде простых правил". В ней Катлин
Айзенхардт (Kathleen
Eisenhardt) описывала как мощные компании преуспевают в сложных
условиях бизнеса, устанавливая набор простых правил, которые определяют
направление, не ограничивая его. [2]
Она предложила, что вместо следования сложным процессам, использование
простых правил для стратегии взаимодействия — это лучший путь дать
людям силу уловить мимолетные возможности в быстро меняющихся
рынках. 

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

Основные правила бережливого производства и TQM
в 80-х можно изложить в 10-ти простых правилах:

1. Избавляйтесь от потерь
2. Минимизируйте запасы
3. Увеличивайте поток
4. Действуйте из требований
5. Делегируйте полномочия рабочим
6. Изучайте требования клиентов
7. Сразу делайте правильно
8. Избавьтесь от локальной оптимизации
9. Сотрудничайте с поставщиками
10. Создавайте культуру непрерывный улучшений

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

Бережливое программирование

Недавние
работы в области гибких (agile) методик, адаптивной разработки и
экстремального программирования — это эффект приложения простых правил
бережливого производства для разработки программного обеспечения.
Тезисы которые мы назовем бережливым программированием также
существенны, как и улучшения в производстве, которые произошли
благодаря движению TQM в 80-х годах.

Бережливое правило №1: Избавляйтесь
от потерь

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

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

Бережливое правило №2: 
Минимизируйте запасы (Минимизируйте промежуточные артефакты)

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

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

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

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

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

Бережливое правило
№3:  Увеличивайте выпуск (сокращайте периоды разработки)

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

В недавней заметке, озаглавленной "Уменьшение
времени цикла" [3],
Дэннис Фрейли предлагал уменьшить цикл разработки ПО, используя те же
техники, что и уменьшение циклов на производстве. Он предлагал
пересмотреть и уменьшить накопления WIP (work in process — незавершенное
производство).
Прямо как на производстве, если WIP уменьшится, то время цикла тоже
уменьшится. Чтобы уменьшить WIP, Фрейли рекомендовал использовать
принцип "мелких партий" и "принцип равномерного выпуска", концепции
прямо из бережливого производства.

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

Бережливое правило №4: Отталкивайтесь
от требований (принимайте решения как можно позднее)

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

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

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

Бережливое правило №5: Дайте власть
рабочим (принимайте решения как можно ниже)

Базовый
принцип бережливого производства — это передавать решения вниз на самый
низкий уровень, обеспечивая как инструментами так и полномочиями людей,
находящихся "на полу". Когда Тойота купила фабрику GM (General Motors)
в Фримонте (Калифорния) в 1983 году, она унаследовала рабочих с низкой
производительностью и записями о прогулах. Те же самые рабочие удвоили
свое качество и производительность за два года. Это произошло через
формирование команд, которые тренировались техникам измерения и
улучшения работы. Также закладывалось  развитие и непрерывное
улучшение их собственных рабочих стандартов и практик. [4]

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

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

Бережливое правило №6:  Узнавайте
требования клиентов (сейчас и в будущем)

В книге 1979 года "Качество — это свобода"
Филип Кросби (Philip Crosby)
определил качество как "соответствие требованиям". Студия Standish
Group в 1994 году [5]
заметила, что наиболее общей причиной краха проектов было упущение,
неполнота или некорректные требования. Разработка ПО должна реагировать
на эти риски усилением работы по сбору детальных требований клиентов и
должна получать подпись клиента, прежде чем переходить к разработке
дизайна. Однако этот подход к определению требований клиента глубоко
порочен.

Я
работал над одним проектом, в котором клиент хотел создать сложную
систему за 10 месяцев. Время было существенно — 10 месяцев или провал.
И даже будучи правительственным агентством, договор требовал подписание
документов описания внешнего дизайна перед тем как создание архитектуры
и кодирование начнутся. Несколько человек, занятые этим, истерли свои
ноги, подписывая документы. Почему? Они заботились тем, чтобы им было
что сказать, если им укажут на ошибку. После этого нелегко было что-то
изменить, после того как документы по дизайну подписаны. Они взяли два
месяца на согласование дизайна. А кто им мог что-то сказать против? Их
рабочие места зависели от того, сделают ли они все правильно. В итоге
работа в условиях нехватки времени, целых два месяца и куча бумаги
потрачено, создавая документы и получая подписи на них.

Вместо
поощрения участия пользователей, подписание ведет к созданию отношений
противостояния между разработчиками и пользователями. От пользователей
требуют делать решения рано в процессе разработки, им не позволено
менять их решения, даже если они не имеют полного представления о том
как система должна работать или как состояние бизнеса может развиваться
в будущем. Разумеется, пользователи с неохотой делают такие подписи и
они инстинктивно задерживают решения на столько, на сколько возможно.
Замечу, что этот инстинкт относительно пользователей соответствует
бережливому правилу №4.

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

Бережливое правило №7:  Делайте
правильно сразу (Учитывайте отзывы)

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

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

В
1987 году Барри Боем обнаружил, что стоит в 100 раз больше обнаружение
ошибки после того как программа установлена, чем найти и исправить ее
на фазе начального дизайна.[6]
Это исследование и правило "Делайте правильно сразу" широко
используется, чтобы оправдать дополнительные расходы в разработке
подробного дизайна системы до того как код будет писаться.

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

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

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

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

Бережливое правило №8: Избавляйтесь от
локальной оптимизации
(узконаправленная оптимизация — это враг)

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

Поколение
бухгалтеров должно было уйти до того, чтобы можно было сказать "ОК"
запуску машин ниже их мощности. Создание машин с быстрой
перенастройкой, но с пониженным выпуском остается трудным даже в наши
дни. После 20-ти лет бережливого производства, все еще есть сомнения у
тех, кто не имеет глубоких понятий о предпринимательстве.

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

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

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

Бережливое правило №9: Сотрудничайте с
поставщиками (используйте эволюционные отношения)

Ленивое
производство не остановилось на фабрике. Как только идея партнерства с
поставщиками была соединена с пониманием ценности быстрого выпуска
продукции, родился Supply
Chain Management (менеджмент работы с поставщиками). Люди начали
осознавать, переводят тонны бумаги, чтобы перевезти материалы между
компаниями, и это не добавляет ценности продукту. Более того, бумага
стоит больше, чем могли предполагать, не учитывая задержки в поставках,
происходящих из-за нее. Даже сегодня предсказывают экономию миллиардов
долларов на b2b (business to business — связывающие
организации) web-порталах, основанную на снижении стоимости
транзакций, требуемых, чтобы перемещать товары между компаниями.

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

Во времена 80-х, компании, достигли высочайшего
качества и низкой цены в своих цепочках поставок благодаря уменьшению
числа поставщиков и работая с оставшимися поставщиками как с
партнерами. Качество и креативность, как результат сотрудничества с
поставщиками, гораздо более весомы, чем видимые выгоды, которые
получаем из конкуренции цен и частой смены поставщиков.
Компании-партнеры помогают друг другу улучшать дизайн продукта и объем
выпуска. Они связывают системы, позволяя быстро передвигаться товарам
через нескольких поставщиков с помощью малого количества бумаги или
вообще без оной. Долгосрочные улучшения от сотрудничества с
поставщиками хорошо описаны.

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

Бережливое правило №10: Создавайте
культуру непрерывных улучшений

Когда кажется, что разработка ПО выходит из-под
контроля, одним из решений может быть увеличение уровня "зрелости"
программного обеспечения организации. Это может показаться
соответствует практике хорошего производства, где сертификация ISO 9000
и награды Малколма
Балриджа иногда приравнивают к превосходству. Однако, эти программы
документирования процессов отражают превосходство только когда
документированный процесс превосходен в контексте его использования.

Во многих текущих проектах разработки ПО,
превосходство означает возможность адаптироваться к быстро меняющемуся
окружению. Подходы к усилению процесса такие как верхние уровни модели
CMM (Capability Maturity Model — модель
зрелости процессов создания ПО) от балуемся
Engineering
Institute (федерально поддерживаемый исследовательский центр) могут
упустить гибкость быстрого реагирования на изменения. В недавнем
рекомендательном письме от Cutter
Consortium (исследовательская компания в области IT) Джим Хайсмит
осветил противоречия между тяжеловесными методологиями и легковесными
методологиями такими как бережливое программирование. [7]

Вопрос был — урезать программу сертификации
документирования процессов, или поощрять в рамках культуры
непрерывных  улучшений? Деминг наверное вертелся в гробу от
многотомных мыслей, описывающих процессы, заменяющие его простой подход
Plan-Do-Check-Act:

Планирование
(plan): выбираем проблему, находим возможную причину.
Выполнение (do): выполняем опыты, чтобы обнаружить возможную проблему
Проверка (check): анализируем данные опыта, чтобы проверить гипотезу о
проблеме
Воздействие (act): совершенствуем и фиксируем, основываясь на
результатах

Итеративная разработка позволяет использовать
подход Plan-Do-Check-Act в проекте. Во время первой
итерации, передача эстафетной палочки от дизайна к программированию или
от программирования к тестированию может быть довольно грубой. Хорошо,
если первая итерация научит чему-то команду проекта, потому что еще
много итераций нужно сделать, таким образом команда может улучшать этот
процесс. В некотором смысле, итеративная среда проекта становится
операционным окружением, потому что процессы повторяются и метод
Деминга улучшения процесса может применяться от одной итерации к
следующей.

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

Однако, нам нужны улучшения, которые касаются
не только одного проекта. Мы должны улучшать производительность будущих
проектов, изучая существующие. И снова здесь бережливое производство
может указать путь. Во время 80-х множество практик суммировались в 10
правил бережливого производства, которые повсеместно прошли проверку
временем во многих областях деятельности.

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