Мысли про 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) чтоб лучше продумывалась книга надо пользоваться хелперами:
- делать конспекты,
- выделять мысли и записывать их на карточки, в тетрадь.
- подчеркивать интересные, оновные, спорные мысли.
можно записывать когда и что прочитал, чтоб было легче освежить и понять что же ты прочитал.