Читаем Практика дао Toyota полностью

Как-то раз я наблюдал за работой линии окончательной сборки (иногда ее называли «денежной линией») на заводе одной из компаний «большой тройки» и заметил, что напольное покрытие в салоне автомобиля со стороны водительского места повреждено. Рядом со мной стоял мастер. У меня возникло рефлекторное стремление остановить линию. Разумеется, здесь не было андон, как в Toyota, и я показал повреждение мастеру, ожидая реакции с его стороны. Он согласился, что покрытие и в самом деле порвано, но и не подумал что-нибудь предпринять! Я пришел в смятение. Я поинтересовался, что нам делать, но он ответил, что проблему исправят на ремонтном участке. На мой вопрос, не следует ли нам найти источник проблемы, чтобы предупредить ее повторение, мастер лишь пожал плечами. «Они наверняка уже все выяснили», — ответил он.

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

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

Перейти на страницу:

Похожие книги

Философия DevOps
Философия DevOps

IT-принцип «agile» стал мантрой цифровой эпохи. С ростом проектов, переходом от монолитных приложений к системе микросервисов, увеличением и накоплением продуктов возникают вопросы, которые требуют совершенно иного подхода. Теперь наибольший интерес вызывает находящаяся на стыке разработки и операционного управления методология DevOps.DevOps – это не просто набор техник, это философия. Разработчики, зацикленные на пользователях, должны уделять внимание поддержке и ее запросам. Сисадмины должны сообщать о проблемах продукта и вносить свой вклад в улучшение процесса работы. Но налаживание связей внутри компании – это лишь первый шаг. Чтобы продукт стал простым и удобным, придется вложить время и ресурсы в его доработку. Конфигурация через центральную службу, внедрение простым копированием, отсутствие внешних зависимостей, обдуманные метрики вместо мусора в логах – вот лишь часть задач, которые придется решать на этом пути.Книга «Философия DevOps» познакомит вас с техническими, культурными и управленческими аспектами devops-культуры и позволит организовать работу так, чтобы вы получали удовольствие от разработки, поддержки и использования программного обеспечения.

Дженнифер Энн Дэвис , Кэтрин Дэниелс

Деловая литература