Обзор Искусства Управления IT-проектами (Making Things Happen) Скотта Беркуна.

Во время прочтения этой книги выработал для себя новый критерий качества чтива: через 5-10 минут продолжения\начала чтения судорожно ищешь карандашь, чтоб подчеркнуть полезную и интересную мысль, а карандашь превращается в закладку, чтобы потом долго его не искать =)

(Да и во время ее, чтения очень пожалел, что не знаю(или даже не существует) ни одной электронной читалки, где можно бы было подчеркнуть или выделить мысль как карандашом в книге =))

И да книжка не про ажайл\лин, а просто про управление проектами =)

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

Все написано простым и понятным языком с необходимым минимумом теории и максимальным количество практики и подходов. И включает наверно самое важный пункт, который следует развивать пму:  главу "Как не раздражать людей на работе, в ходе электронной переписки, на совещаниях" =)

Удивительным образом во время чтения замечаешь, что несмотря на то, что описываемые события 90-х годов и во многих повествованиях проскальзывает явная ватерфольщина =), но все актуальные идеи лидерства, постоянного улучшения, ориентации на бизнес и команду и тонна других вещей удивительно актуальны и сродни текущим гибким течениям.
А во время чтения, того как делать НЕ НАДО, и в описании мест совершения самых частых ошибок с удивлением обнаруживаешь свой прошлый опыт работы(и возникает такой Ага-эффект) =)

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


Маленький перечень, того, что особо хотелось отметить и не забыть потом во время чтения:

Цели и концепция проекта:

1)Наиболее распостранненные просчеты в определении конечной цели проекта:
 - мы будем делать то же , что и в прошлый раз
 - мы будем делать, то чем принебрегли в прошлый раз
 - мы будем делать то же самое, что и наш конкурент
 - мы будем делать, то что отвечает модным тенденциям (сделаем веб-два(три)-нольно и стартап !)
 - если мы сделаем этот продукт, он обязательно найдет своего покупателя

2) При формулировке цели можно воспользоваться таким приемом - отнеситесь к ней максимально придирчиво и задатьяс вопросом, не провалиться проект, если его цель будет достигнута в точном соответствии с его формулировкой. Затем нужно подумать, а нельзя ли более точно сформулироваться цель, нет ли какой-нибудь дополнительной, уточняющей информации.

3) Если вы не в состоянии найти какое-нибудть визуальное представленеи того, что изменится в этом мире под влиянием проекта, стоит задуматься не направлен ли этот проект на создание бесполезных вещей. или достаточно ли он понятен, чтобы быть успешно притворенным в жизнь.
3.1) Что концепция всегда была на видном месте, несколько ключевых целей проекта должны быть оформлены в виде плакатов, расположенных в наиболее людных местах (визуальный менеджмент в стиле Лин !)

Выбор Идеи:
 - Какую именно проблему мы пытаемся решить ? (При возникновении споров о том, что и как делать.)

Информированность: 
 - По возможности старайтесь избегать информации из 2-х, 3-х и 4-х рук. Во время разговора часто вскрываются детали и нюансы по тем или иным причинам не попавшие в отчет или презентацию.
 - Люди ценятся выше информации. Человек пишущий отчет, изучил 1000 разных веещй и узнал массу полезной информации, которую невозможно втиснуть целиком в этот отчет, но который он с радоситью поделиться с теми, кто проявит достаточное любопытство.
 - Хорошие решения могут давать плохие результыта.

Общение: 
 - Базовая модель общения:
- Передача
- Получение
- Усвоение
- Согласие
- Превращение в полезые действия
Не факт, что ваше сообщение не остановилось на уровне передачи или получения ! То, что вы что-то сказали\написали ничего не говорит о его усвоении, или о том. что с вашим сообщением согласны.

Почему люди раздражаются: 
 - Не считайте меня идиотом.
 - Доверяйте мне.
 - Не тратьте мое время попусту.
 - Не распоряжайтесь мной без должного уважения.
 - Не заставляйте меня слушать или читать всякие глупости.

Формула хорошего процесса:
Полная стоимость процесса:

• время на выработку замысла процесса(DT),
• время на его освоение командой(LT)
• фактическое время выполнения работы при применении процесса, помноженное на частоту его применения (ATxN)

= DT + LT + (AT x N)
Суммарная выгода процесса:

• стоимость провалов, которые процесс позволяет избежать(FC),
• помноженную на показатель вероятности возникновения провалов(FP) без внедрения процесса в пределах определенных временных единиц
• и помноженное на количество таких единиц в проекте (T). 

 =   (FC x FP) x T
А ценность процесса равна:  ((FC x FP) x T) - (DT + LT + (AT x N))

Итого:
Не зря она занимает свое место а бест-селлерах О`рейли и для всех кто интересуется разработкой ПО должна находитсья в разделе must have & must read.
Думаю перечитаю ее еще не раз через месяц-другой, чтобы освежить в памяти и найти какие-то новые моменты .

Комментарии по книжке Деминга "Выход из Кризиса"

Решил написать обзор очередной книги, пара недель прошла, как прочитал, но с переездами в москву, поисками квартиры и прочим геммороем было не до того)
Отрабатываю долг перед собой)
Это наверно последняя из запланированных книжек из серии agile/lean/etc на ближайшие пару-тройку месяцев.
И она оказалось самой талмудистой =)

Читал и осозновал я соответственно "Выход из крисиза. Новая парадигма управления людьми системами и процессами" Эдвардса Деминга.

Об авторе и книге:
Товарищ Деминг можно сказать является родителем agile & lean подходов по той простой причине, что это он ездил распостранять свои идеи японцам, когда в америке продвинуть их не слишком удалось. И потом уже рекурсивно на волне подъема японской промышленности эти идеи вернулись в америку и добрались в том числе и до разработки ПО.

Автор достаточно скромен и честно признается в свой книге, что на самом деле он не автор всех этих идей, а развивал идеи и мысли Шухарта, и цикл Деминга должен быть не циклом Деминга, а циклом Шухарта =)

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

Книга опять же большая(~300-400 страниц) и потому с наскока не береться, потому лучше конспектируйте ее походу иначе есть вероятность после 2-3х дневного возврщанения к чтению забыть о чем же шла речь.
Одним из самых интересных моментов, книги являеться, то что она написана во первых тем, кто создавал эту теорию, а так же она написана уже ПОСЛЕ того, как теория подтвердилась на практике.
И, благодаря этому, у автора была возможность уточнить и отполировать теорию нового менеджмента и производства во время ее внедрения.

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

Что запомнилось:

1) В кратце книгу можно пересказать, как "Стремитесь к максимальному качеству, и вот как это сделать".
Только под качеством надо понимать не только отсутствие ошибок, переделок и лишней работы, но и производство именно того, что нужно потребителю (хинт: делайте прототипы, и тестируйте их в реальных условиях), ведь в конце концов какая разница что предмет не ломается, если он не делает того, что надо или делает это не так.
А уже повышение качества приведет,
к снижению себестоимости(меньше переделок, брака, ошибок)
-> больше производительность
-> предлагаете лучшее качество по тойже или более низкой цене
-> захватываете рынок
-> ПРОФИТ!
-> повторять до бесконечности.

2) Для этого Деминг предлагает 14 пунктов менеджмента (почти теже, что описаны в Дао Тойота +/- пункт-другой, так что опущу сами прочитаете).
И называет "смертельные болезни менеджмента", т.е. то как делать не надо, например : "аттестация и ранжирование персонала" или "нацеленость на сиюмитный результат".
Кстати в книжке встречается, довольно много эдаких вопросников или чеклистов и если есть вопросы а стиле "что я(мы) делаем не так", то можно поробовать пробежаться через вопросник и станет понятно в какую сторону надо копать)

3) Кроме таких философско-менеджментско-общечеловеческих советов Деминг так же расписывает, как понять встали ли вы на путь улучшения: т.е. улучшаете процесс (и всю систему) - исправляете "общие" причины (вариабельности\ошибок), например отсутствие единой системы документации. Или постоянно фиксите "особые" причины (т.е. следствия системных ошибок, или единичные случаи), например некомпетентность отдельного человека (и это скорее следствие системной ошибки системы отбора персонала), либо завышенная сложность, или запутанность определенной процедуры.

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

4) Кроме того, контроль качества не должен быть бездумным, тюею стремиться к идеальному процессу на каждом этапе, если проверка + исправление потенциальной ошибки на этапе А, добавляет 10$ (5 - проверка, 5 - исправление) к себестоимости товара(надо кстати не забывать, что проверка качества тоже стоит денег), а проверка и исправление на этапе Б(этап А входит в него как одна из деталей) стоит 1000$ (10$ проверка + 990$ исправление), то если вероятность ошибки на этапе А - 0.000000001, а вероятность ошибки на этапе Б - 0.00001, то проверяя на этапе А мы добавляем к себестоимости каждого продукта стоимость его проверки на этом этапе, а на этапе Б проверять скорее всего все равно придеться т.к. стоимость нахождения дефекта пользователем обычно гораздо выше проверки и починки у производителя.

Стоит ли почитать:
Книжку можно почитать ВМЕСТО Дао Тайота, чтобы понять все идеи `японского` менеджмента, кроме того более научный стиль изложения создает неявное ощущение верности всех этих идей. Если вы уже знакомы с идеями lean, то стоит читать только отдельные главы + смотреть главы по вариабельность и типы ошибок.

Мысли про Lean/Six Sigma/TOC: Versus или And ?

Намедни, дочитал Leaning into Six Sigma, до этого имел довольно расплывчатое представление что же это за зверь "Six Sigma" и с чем его есть =). Просветился)

Краткая историческая справка:

Six Sigma - метод управление зародивший от Lean в Мотороле:

Если Lean это такой процесс улучшения потока создания добавочной ценности , то Six Sigma - это процесс уменьшения вариабельности отклонений этого процесса, т.е. уменьшение среднеквадратичного отклонения (сиречь сигмы) до 6, попытка достичь 3.4 бракованных изделия на миллион (3 бага на миллион готовых фич, эх нам в разработке ПО о  таком только мечтать =)).

Коротко о самой книге:
Что хорошо - книга короткая (~95 страниц), после 300-400 страничных читается за пару заходов.
Написана от первого лица и в этом чем-то напоминает Deadline.
Очень краткий пересказ:
Консультант пришел на проект и начал вытягивать его из болота, т.е. :

• пришел и научил всех, как жить,
• разъяснил про методы работы: 
• идеологию Six Sigma + Lean, 
• 5S, 
• (D)MAIC (переделанный цикл Деминга-Шухарта PDCA под более статистический подход), 
• сделал рабочих довольными и гордыми за свою работу, 
• менеджмент понимающим и слушающим рабочих,
• и научил людей решать их проблемы/видеть пути улучшения производства/устранять потери.
• + дал статистический мат-аппарат, как следить за отклонениями от идеального процесса.

Итого по книге:
В общем книга дает такое достаточно облегченное понимание Lean-подхода, идеологии SS и как их применять вместе.
Порекомендовал бы пробежать глазами книгу + прочитать key points в конце глав, если вы знакомы с Lean, или почитать, как краткое ознакомление, если не сильно знакомы.

Ах, да чуть не забыл в книге описан очень прикольный подход SS типа, восточных единоборств  есть -  орки, тролли, эльфы 80го уровня, зеленые пояса, черные пояса, чемпионы по степени понимания и умения применять SS.


Мысли по теме:
* Знакомство с темой ОЧЕНЬ желательно, хотя бы прочитайте статью в Википедии. TOC, Lean, Six Sigma.

Lean is Art. Six sigma is Science

LEAN...It is art.  Six Sigma is STATS on STEROIDS 

Сравнивать их между собой в данном посте смысла не вижу (да и лишь перепечатаю пдфку), т.к. самые основные и рабочие подходы и там и там подозрительно похожи.

Если их пересечь то за пределами пересечения останется небольшой кусочек, как в Лине, так и в SS.

TOC правда с людьми вообще особо не считается, потому стоит немного особняком, но в принципе его можно считать частью Lean, ради простоты, т.к. выравнивание работы неявно предполагает применение TOC.

По поводу Versus/And мнения  разнятся от:

1) Только этот метод истинный, а остальные - его потомки/обрезки/мутанты.

2) Выберите тот, который больше всего подходит именно вам из этих 3-х.

3) Все три метода бред - скоро появится новый метод Х, который зажжет.

4) Используйте все - по сути они одно и тоже.

По моему скромному мнению, последнее и есть тру-подход. 

И тут даже следует не смотреть в сторону их объединения, а смотреть от обратного: вся цель любого производства/дела - сделать (пиздато) приятно своему пользователю - предложить наилучшее, бесконечно-полезное и качественно-вечное нечто, будь то услуга/товар/идея/что-угодно. Соответственно можно надергать из кучи возможных подходов - только то, что нужно и применимо в данной ситуации. 

Есть потери - задействуй Lean и постарайся сделать процесс исключительно выполняющим полезную работу .

Есть измеримые данные + неравномерность - натрави SS: что можно померить - можно улучшить.

Есть где-то боттлнек/не хватает ресурсов - примени туда TOC: сделай предложение = спросу (если боттлнек в спросе =)) на всех этапах, либо используй критический ресурс по максимуму.

В разработке ПО на самом деле, все тоже самое: все народившиеся методологии получаются тот-же конструктор:

хочется быстрых релизов - сделай Agile с итерациями, 

хочется кристальной видимости, что делается и не хочется планировать на годы вперед - построй value map и введи Канбан и т.д.

Осталось только понять какие же составные кубики разработки ПО есть, и останется только повторить "Верной дорогой идете, товарищи" =)

Полезные ссылки:
Архи-полезный тред, которое многое прояснил в голове:
http://www.isixsigma.com/index.php?option=com_k2&view=item&id=1511:six-sigma-versus-lean&Itemid=111

Пара пдфок от туда же:
http://asq.org/pub/qualityprogress/past/0302/qp0302nave.pdf
http://asq.org/pub/qualityprogress/past/0403/qp0403smith.pdf

Agiledays: ретроспектива

Буквально пару  дней назад закончился мартовский Agiledays`11, комьюнити активно делиться впечатлениями, выкладывает фотки, обсуждает как прошло - по-участвую то же)

Что понравилось: 

• Комьюнити =) Познакомился не с таким большим количеством люде, как хотелось бы, но тоже не плохо, люди говорили, что не хватает общения, надо как-то двигать народ к активному сотрудничеству и разговорам, может в рамках всей конференции игру какую проводить, чтоб народ узнавал друг-друга.
• Организация, блокнотики, еда были хороши (хотя пакетики со спонсорским спамом можно бы сделать и поменьше, лучше пусть стенды свои развешивают).
• Мастер-классы - были отменны, хочется побольше:
• Командный старт: интересный и позитивный ведущий, интересная тема, достаточно четкий план проведения и желающие слушать и воспринимать участники - бесценно(ц)
•  Agile-игры: Business Value Game  - игры это хорошо=) Почувствуй себя частью команды, зарабатывающей деньги для фирмы: небольшой соревновательный момент и самоорганизующаяся команда => и все нацелены на получение фирмой прибыли/выигрыш. Заняли с командой 2-ое место, эх знать бы раньше на каких условиях вступит в силу ROI). Илье (Кирову) Ириске, Артему Аутентичному, Семену(Молотову) Супермену и паре других чуваков (всех все таки не запомнил) из Скб-контура, привет =)
• Agile-Learning Стаса Фомина: не совсем мастер-класс, но тоже происходил в такой достаточно-интерактивной форме с квестом для тех, кто взял с собой ноутбуки. Стас вообще интересный и умный и сильно ответственный чел, узнал, что практически все, что он записывает он делает по своей инициативе, за свой счет и своими силами.  Рассказывал о том как организовывать обучения и передачу знаний: о тулзах, средствах и подходах. Запомнилось: "Парное программирование оно же от отчаяния, потому что не умеем лучше передавать знания." Большущее ему спасибо за проводимую работу.
• Были интересные доклады:
• Запомнился Евгений Кривошеев с его моделью принятия инженерных решений. все кто учился на инженера помнят, что надо подумать, измерить какие последствия своих решений ты хочешь получить: например: гибкое, но сложное, или топорное, но простое из из этого исходить при проектировании и разработке, но в процессе разработки некоторые вещи переходят в привычку, некоторые просто забываются и получается, что зачастую программа пишется, как придется. Напомнил, для чего инженеру голова нужна)
• Очень хорошо отзывались о докладе Хенрика Кенинберга, но к сожалению я его пропустил.
•  Экстремальнйы Аджайл: танцуют все, от разработчиков "электронного бугалтера Эльбы". Интересно узнать, что у нас есть прям молодые продуктовые команды, которые успешно применяют аджайл во всей компании, в разговоре за обедом выяснилось, что работает это у них просто прекрасно, инвесторы/стейкхолдеры странными идеями их не душат, да и работа у Евгения, чтоб такого как раз не случалось. Докладчики жгли перлами и напалмом, и кажется разошлись на цитаты: "клизма для вдува таска в итерацию", "тз - хз", "разработчики делают маркетинг!" и другие, фишечка на финальном слайде с конец - "конь" была неочевидной! =). В кулуарах заслужили звание "наших" ажайл-гуру.
• Доклад Бориса Вольфсона (Softline) "Масштабируем скрам", оказалось интересным узнать, что подход Scrum of Scrums (описан в книге Кенинберга, полистайте рсс ScrumTrek`a, там есть ссылка) они развили аж до 3х уровней, с product owner`ами & chief product manager`ами.
• Доклад Кирилла Климова, про кунгфу - канбан вс скрам, хотя это только название, что от Скрама они перешли к канбану, т.к. у них была специализация, ретроспективы особо перестали приносить полезные идеи, и они решили преобразить свой процесс в канбан-стайл поток. В общем-то идеи все из тех, же книг, что я читал, а интересным оказалось, что люди смогли применить подход на практике успешно.
• Доклад Александра Лесневского и Никиты Филлипова про то как перевод проекта на ажайл-рельсы помог понять инвестору, что продукт будет убыточным. Оказывается и такое бывает) После того, как agile-подход сделает процесс боле прозрачным ВНЕЗАПНО можно узнать, что он особо то и не нужен.

Было нормально, доклады:

• Доклад Сергея Андржневского об инженерных практиках в принципе ничего особо нового сказано не было, можно любую книжку почитать по тему и там это будет, но и народ откровенно не скучал задавал вопросы, и у них вроде бы почти все (парное, тдд, бэклоги, ...) используется по прямому назначению и вроде хорошо получается. Запомнилось. что сейчас без парного программирования докладчик себя чувствует уже как-то не так)
• Доклад Романа Юферова (http://a-jail.blogspot.com/ ) про поиск гибких разработчиков. В общем-то рассказал верные и интересные вещи: про то, что надо искать кого-то кто не гнушающегося кросс-функциональности, людей которые делают, то что нужно сейчас, умеющих принять помощь и вообще командных). 
• Интересным было замечание, что есть смысл брать либо: 
• сильно молодых, т.к. у них еще взгляд не зашорен собственной крутость,
•  либо зубров, то есть тех, кто уже понял, что разработка ПО, это вообще не главное в жизни.
•  а миддлы-сеньоры - они как дети: 
• эгоцентричны, 
• полируют торпеды (т.е. доводят свой код до совершенства), 
• сомневаются, что кто-то им поможет (т.к. очень круты в своей области) 
• и избалованы своей крутостью.
• Доклад Никиты Филлипова про Lean Startup, идеи были изложены в определенной степени для меня новые, но создалось ощущение, что пересказ пары книжек. Частично подпортило впечатление, что он быстренько пересказал предыдущий доклад из-за того, что докладчик не пришел, который полностью пересказывал "Дао Тойота". Примеров из жизни и какого-то реального опыта применения не хватает, чтобы этот доклад можно было считать True.

Что не понравилось/Хотелось бы поменять:

• Тезисов не хватает, чтоб сделать выбор, и наперед не скажешь будет интересный доклад или нет. Может быть слайды + предполагаемую стенограмму еще стоит выкладывать заранее
• Программа конференции на сайте не удобно работает с тач-пада =)
• Было бы неплохо если б слайды опять же были доступны централизованно: а то получается, что сейчас кто у кого успел спросить контакты или визитку дать, или в твиттер вовремя заглянул - успел получить слайды, неудобно-с. 
• Лично мне показалось, что слишком много обзоров инженерных практик, послушать про чужой опыт применения философии гораздо интереснее, чем про: а вот мы юзаем: это, это и это - у нас работает.
• Люди (за обедом) задавались вопросом: "я, как разработчик/пм понимаю профиты аджайла, но как подойти с этим к руководству - не понятно" или "мы попробывали - натолкнулись на грабли, руководство решило, что это все фигня". Неплохо бы увидеть такие доклады/мастер-классы.
• Не интересные доклады, определенно стоили бы послушать лекцию Стаса Фомина, о том как делать доклады =):
• Доклад Заходяйченко Андрея про ALM системы, народ сидел вялый, людей было мало, докладчик что-то спрашивал, а народ тупил и стремался отвечать, откровенно не зажигающий доклад.
• Борис Вольфсон, Гибкая теория ограничений, предварительно смотрел его вебинар, а цель Голдарата читал до этого, для меня не было чего-то нового и насколько я понимаю доклад то же был такой скорее теоритический, чем практический(не дослушал до конца).
• Николай Гребнев (Custis), DDD в распределенных приложениях, суть доклада сводиться к простому: "в DDD надо вводить распределенность в доменную модель, либо не делать распределенным", довольно очевидная вещь, и я все ждал, что вот сейчас то он расскажет ка-же это правильно делать, оказалось - нет. Откровенно слабый доклад, спросил за обедом у чуваков: как он так выступил выступил, сказали ну вот дали попробовать: не получилось.
• Дмитрий Лайер, Стратегическое планирование через инновационные игры, тема интересная но подана, была как-то уныло, докладчик бубнил про себя и народ в зале чатился в твиттере, смотрел хабру и вобще не был заинтересован. Не слушающий докладчика народ - довольно неплохой показатель интересности доклада. 

Упомянутые книги, названия которых я успел записать =):

Лайкер, Дао Тайота

Luke Hohmann, Innovation Games

Succeding with Agile,

Fearless Change,

Agile Product Managment

и куча других, но буду ждать видимо слайдов, чтобы найти их.

P.s. Следующий Agiledays, планируется в Самаре в июне (приблизительно в числах 9-12х), если есть желание поучаствовать или выступить с докладом, то велкам!
Борис Вольфсон(http://borisvolfson.moikrug.ru/, http://twitter.com/#!/_blv_) выступил с инициативой сбора докладов, либо же пишите и джоиньтесь в группу (https://groups.google.com/group/Agiledays-speakers?hl=ru).

Обзор Бережливого производства Вумека.

Данная книга(http://www.ozon.ru/context/detail/id/3823594/) продолжает и раскрывает идею бережливого производства, расписанный на примере TPS в предыдущей прочитанной мною книге.

Теория:

Для создания бережливого производства вам необходимо:

Определить какую ценность создает ваш продукт для потребителя, например:
производство автомобилей, самолетов - доставка себя из точки А в точку Б, перевозка грузов .

Составить карту потока создания ценности(понять какие действия добавляют для пользователя ценность), например: ожидание регистрации на самолет - например очевидная потеря при покупке авиабилета, досмотр - необходимая потеря(добавляет ценность безопасности).  

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

Использовать вытягивание, т.е. теоретически никто выше по потоку создания ценности (если считать, что поток стекает к потребителю) не должен ничего делать до тех пор пока не придет заказ от потребителя.
Т.к.иначе вполне может оказаться, что когда потребителю что-то понадобиться вы будете заняты, чем-то другим, или не будете иметь ресурсов на выполнение его заказа, из-за того что они были потрачены на то что ему не нужно.

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

Практика:
В книге приводиться 5-ок примеров внедрения бережливого производства в больших и маленьких компаниях, занимающихся производством от кабелей(Wiremold) и упаковочного оборудования(Lancaster) до производства авиационных двигателей(Pratt) и автомобилей(Porshe).

В принципе процесс везде похож:
1) найдите "агента перемен"(того кто будет гореть идей и двигать ее)
2) раздобудьте знания (найдите того, кто вас научит)
3) создайте/используйте кризис, которые будет рычагом перемен
4) используйте стратегию: даже если вы можете производить продукт бережливым образом, на него может пропасть спрос, умейте отказатсья от продукта если он не приносит прибыли)
5) опишите поток создания ценности
6.1) как можно быстрее, начните с доступной, но важной и видимой всем деятельности(чтобы показать что есть таки профит в процессе)
6.2) требуйте немедленных результатов, бережливое производство настроено на немедленную обратную связь, если за неделю нет результатов - вы либо наняли не того учителя, либо не готовы к изменениям.
6.3) как тока, будет первые успехи - продолжайте дальше, не расслабляйтесь, трансформируйте не только производство но и поддержку, офисную работу, поддержку заказов и т.д.
7) Постройте организационную структуру вокруг семейств продуктов и потоков создания ценности
8) Создайте отдел обучения бережливому производству(он будет служить как кайдзен-команды + продвигать философию)
9) Процесс можно улучшать до бесконечности, не останавливайтесь.
10) Используйте развертывание политики(хосин канри). Ставьте цели по улучшению производительности, оборачиваемости запасов, уменьшению брака и делайте, так чтоб они спускались вниз до непосредственных работников.
11) Убедите поставщиков и потребителей следовать тем же курсом
12) Перейдите от лидерства сверху вниз к инициативе снизу вверх.
Т .е поощряйте инициативу подчиненных/непосредственных работников, а менеджеры больше должны быть помощниками/учителями, чем командирами.


Итоги:

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

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

После прочтения добавилось понимания про процесс создания ценности.

Обзор Dao Toyota Лайкера(краткий пересказик).

Намедни прочитал Дао Тайота (http://www.ozon.ru/context/detail/id/5076780/) и Бережливое производство (http://www.ozon.ru/context/detail/id/3823594/).

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

Система бережливого производства родилась из системы TPS (Toyota Production System), которая в свою очередь вобрала идеи Деминга, Голдрата и прочих теоретиков(по большой части,  американцев).

Первая книга рассказывает о TPS/Toyota и 14 принципов, которые помогли выстроить эту систему и создать то предприятия, что есть сейчас Toyota, именно благодаря им фирма когда, то занимавшаяся созданием прядильных станков (Toyoda Automatic Loom Works) превратилась в 1го  из лидеров автомобильной автоиндустрии, потеснив американскую 3й-ку. Именно систему управления производством (а не инновации/лучший персонал/что-то другое) отмечают, как сами руководители, так и остальные, как причину феноменального успеха Toyota в своей области.

Базовая идея TPS - непрерывный поток единичных изделий (а не стандартный способ работы массового производства -  партиями и очередями), который позволяет видеть потери, получать мгновенный фидбэк от улучшения процесса, и делать высококачественные вещи.

14 принципов TPS это:

Главное правильная философия.

1) Принимай управленческие решения с учетом долгосрочной перспективы, даже в ущерб краткосрочным целям.

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

Правильный процесс дает правильный результат.

2) Процесс в виде непрерывного потока способствует выявлению проблем.

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

3) Используй систему вытягивания, чтоб избежать перепроизводства.

Перепроизводство - это потери, т.к. она тратит ресурсы на производство, того - что не нужно.

• Работай по системе "точно вовремя"(just in time - JIT). Каждый потребитель(включая внутреннего - т.е. того кто потребляет результаты работы твоего процесса) должен получать ровно столько ему и тогда он сказал.
• Сведи к минимумы запасы и обьем незавершенного производства. Держи в запасе малое количество изделий и пополняй их по мере их забора потребителем.
• Будь восприимчив к колебаниям спроса.

4)Распределяй обьем работ равномерно(хейдзунка).

Не надо чередовать периоды авралов и отдыха, просто работай равномерно.

• Это устранение потерь, т.к. перегрузка людей и оборудования тоже потеря и ведет к проблемам с качеством, переделкам и т.д. 
• Сглаживай производственный график (т.е. управляй так же и спросом), чтобы объем нагрузки был одинаков.

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

• Качество определяет цену на твой товар для потребителя.
• Обеспечивай качество всеми возможными способами.
• Создавай оборудование/процессы, которые способны распознать проблемы и остановиться. Разработай визуальную систему оповещения(андон) о проблемах. (пишите Unit/Integration/*-тесты для IT :) )
• Позаботься чтоб существовала система поддержки, готовая оперативно решать проблемы и принимать корректирующие решения.
• Данный принцип должен обеспечивать получение качества "с первого раза" и являться неотъемлемой частью культуры компании, что повысит качество и производительность в перспективе.

6) Стандартные задачи - основа непрерывного совершенствования и делегирования полномочий сотрудникам.

• Используй стабильные, воспроизводимые методы работ. Это основа потока и вытягивания.
• Фиксируй накопленные знания о процессе, стандартизируй лучшие на данный момент методы. Не препятствуй (и поощряй) творческому выражения направленному на повышение стандартов, закрепляй достигнутое новым стандартом. Тогда возможна передача положительного опыта между сотрудниками и тому, кто приходит на его смену.

7) Используй визуальный контроль, чтобы проблемы не оставались незамеченными.

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

8) Используй только надежную, испытанную технологию.

• Новые технологии не всегда можно стандартизировать, и они часто ненадежны и могут поставить под угрозу весь процесс.
• Проверь технологию в реальных условиях, прежде чем вводить ее процесс(PDCA принцие деминга ?)
• Отклони или измени технологию, которая идет в разрез с твоей культурой.  

Развивай своих сотрудников и партнеров

9) Воспитывай лидеров, которые досконально знают и исповедуют твою философию и могут научить этому других.

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

10) Воспитывай людей и формируй из них команды, исповедующие твою философию.

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

11)Уважай своих партнеров и поставщиков, ставь перед ними трудные задачи и помогай им совершенствоваться.

12) Чтобы разобраться в ситуации, надо увидеть все своими глазами(генти генцубу)

• Решая, проблемы надо самому проверять, что происходит а не слушать других людей или читая отчеты.
• В основе твоих решений должны лежать проверенные тобой данные.
• Чтобы доподлинно понять проблему ее надо увидеть своими собственными глазами.

13) Принимай решения не торопясь, тщательно все всзвесив; внедряя его, не медли(немаваси)

В общем-то "7 раз отмерь - 1 раз отрежь".

14) Становись обучающейся структурой за счет неустанного самоанализа(хансей) и непрерывного совершенствования(кайдзен).

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

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

Как читать книги.

Прочитал замечательную книгу
Поварнина "Как читать книги"http://reader.boom.ru/povarnin/read.htm

в общем-то суть такова:
1)

• читать надо
• читать надо с умом
• читать надо с какой-то целью

2) книгу надо читать, чтоб впитать ее идею
3) надо продумывать/прокручивать книгу в уме чтоб ее лучше понять, и досконально разобраться в вопросе.
4) книги бывают разные(кэп стайл): развлекалово, вдохновляющие, исскуство,  самообразование.
4.1) искусство - надо перечитывать, годные книги - тоже.

5) книгу лучше сначала просмотреть вдоль, т.е. введение, предисловие, содержание, заключение и пробежать взглядом название глав и тем, чтоб вобще понимать о чем оно, т.к. сразу станет видна какая-то более-менее общая картина и по мере чтения углубишь ее.

6) соответственно книгу надо прорабатывать, чтобы:
1) понялось именно то что надо
2) улеглось в голове
3) чтоб могли оценить - полезно/безполезно, правильно/неправильно.

7) надо читать книгу по прараграфам и связывать их вместе, что за мысль несет автор. по идее после прочтения книги у тебя должна в голове сложиться структура похожая на осодержание книги. после этого сложив все содержание должна опять же получиться главная мысль книги(что обычно изложена в введении).

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

9) чтоб лучше продумывалась книга надо пользоваться хелперами:
- делать конспекты,
- выделять мысли и записывать их на карточки, в тетрадь.
- подчеркивать интересные, оновные, спорные мысли.
можно записывать когда и что прочитал, чтоб было легче освежить и понять что же ты прочитал.