?

Log in

No account? Create an account

Entries by category: авто

Мои профили в соцсетях



Краткое резюме есть здесь


А еще я написал книгу


Если у вас есть вопрос, то его можно обсудить в форуме

Ссылки на все мои слайдкасты перехали сюда

После чтения "Шкуры на кону" Талеба у меня появился термин - «заземлении». ЗАземлять можно то или иное высказывания. Заземлить, значит  привести точное и конкретное описание непосредственных явлений, которые скрываются за той или иной фразой.

Что происходит здесь, на уровне земли, когда я говорю «мне не хватили времени»? Мне не хватило бензина – это когда я ехал на автомобиле в сторону заправки и тут двигатель заглох, а датчик уровня топлива показал ноль. Мне не хватило терпения – это когда я стоял в очереди в магазине, мне надоело, я бросил свою тележку, где стоял и пошел домой без молока. Как выглядит «мне не хватило времени»? Мы часто употребляем это словосочетание, что уже не очень понимаем тех явлений, которые оно описывает. Ведь может быть по-разному:

  1. Я делал задачу X и когда ее завершил уже было время спать, чтобы завтра с утра вставать и приступать к задаче Y, поэтому я так и не смог приступить к задаче Z. Ведь задачи X и Y нужно обязательно сделать до того, как я приступлю к Z. В ином порядке эти задачи делать нельзя потому что …

  2. Я делал задачу X, после которой планировал приступить к задаче Z, но тут прилетела задача X2, за ней X3, за ней X4…, я старательно выполнял их одну за другой, так как каждая из них была важнее Z и обязательно должна ныла быть выполнена раньше, но потом наступил вечер и так как мне требовался отдых я пошел спать.

  3. Я пришел делать задачу Z, только взялся за нее… Как отвлекся на X. Но вовремя себя отдернул и вернулся к Z. Но буквально через несколько минут меня переключили на задачу Y. Я приступил к ней, но понял, что Z все же важнее, вернулся к ней, но тут прилетела задача Y2…

Каким еще бывает "не хватило времени"?

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

Примерно такое же упражнение может оказаться полезным для словосочетания «найти время». Не сложно представить как ищут ключи от квартиры (ругаясь начинают запускать руку в каждый карман каждой куртке, висящей на вешалке), как ищут второй носок (открывают все ящики комода сверху вниз, а потом спрашивают у супруги или родителей). Как ищут работу (пишем резюме, идем на сайт hh.ru, рассылаем резюме знакомым), даже жену (опять резюме, сайт, знакомые)...

А кто и как ищет время?...
Изначально эта тема появилась у меня на форуме. Комментировать можно и тут и там.

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

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


Буду рад, если у вас будет что добавить.

Еженедельный обзор

Так можно:

  • «Размазать» выполнение еженедельного обзора по неделе. Например, приводить в порядок список задач по понедельникам, а просматривать список проектов по средам

Так нельзя:

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

  • Забивать на обзор со словами "а список задач я и так каждый день проглядываю". Еженедельный обзор это не только обзор списка задач


Ежедневный обзор

Так можно:

  • Проводить обзор более одного раза в день

  • Проводить утром, вечером, днем...

  • Часть обзора (например, техника гвоздодера» проводить вечером и часть с утра


Так нельзя:

  • Проводить обзор в режиме «как получается» и называть обзором спонтанные заглядывания в список задач


Формулировки задач

Так можно:

  • Вместо инфинитива использовать повелительное наклонение (вместо «Написать» - «Напиши»)

  • В формулировке использовать идентификатор проекта или имя человека. Например: "Вася Иванов: позвонить и спросить про отчет"


Так нельзя:

  • Использовать глаголы, подразумевающие неопределенные затраты мыслетоплива (придумать, проанализировать, изобрести)

  • Использовать формулировки без глаголов (даже если и «так понятно»)


Список задач

Так можно:

  • Два списка задач (личный и рабочий). Можно, но должной осторожностью. Ситуация двух списков задач тем безопаснее, чем более явно в какой момент и каким списком надо пользоваться. Идеальны вариант: с 9:00 – 17:00 мы работаем в подземном бункере без доступа к домашним делам, а на поверхности у нас нет доступа к рабочим.

  • Использовать для списка задач не смартфон, а в блокнот

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


Так нельзя:

  • Список задач в голове

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

По наводке kakadusha посмотрел доклад Адлера Юрия Павловича о том, как устроена производственная система Тойоты.

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


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

Еще одна очень глубокая мысль: "Решение проблемы - это попытка изнасиловать процесс. Задача кайдзен - не изменить процесс и не вмешаться в управление, а изменить пониманием того, как процесс устроен. Когда все понимают, как процесс устроен, его физическое изменение становится тривиальной задачей и не требует никаких специальных методов"

Tags:

Большое спасибо Сергею Мартыненко за наводку на статью Элии Годратта "Стоя на плечах гигантов".

Статья очень интересная, в ней рассмотрен пример Hitachi Tool Engineering, где Lean в том виде, в котором он живет в Toyota ведет к ухудшению ситуации. Все потому, что Lean - это конкретное прикладное решение ...

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

В отличии от Toyota, производственная система Hitachi Tool Engineering не является стабильной, что естественным образом ставит под сомнение применимость методов Toyota. Однако в статье рассказывает о другом прикладном решении, построенном на тех же самых фундаментальных концепциях. Это решение показало свою эффективность в условиях нестабильной производственной системы Hitachi Tool Engineering. Этим прикладным решением является метод ББК (барабан-буфер-канат) - на самом высоком уровне абстракции это та же система канбан, в которой триггером, запускающем производство, служит не понижение уровня запасов, а время.

Очень понравилась зависимость "Management attention" от размера буфера времени на заказ. Если буфер маленький, то манагерского внимания требуется очень много из-за того, что даже малейшие случайности приводят к срывам сроков. С другой стороны, очень большой размер буфера также приводит к "затыкам" и уменьшению эффективности производства. Вот и перезакладывайся после этого на проекты...

И еще... Системы производства Таичи Оно и Генри Форда основаны на одних и тех же фундаментальных концепциях... Но это так, к слову.

Ну и совсем под занавес... Даже после этой статьи мне кажется, что в разработке ПО производственная система все же стабильна, но в ней канбан может не приживаться по другим причинам...

Tags:


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

Не скрою, эта книга определила ход моего доклада на SoftwarePeople'11. Книга очень интересна и рассказывает как создаются новые автомобили в Тойота. Изучая бережливое производство я пытаюсь найти новые эффективные пути работы в нашей индустрии - разработке программного обеспечения. Скептически настроенный человек может аргументированно заметить, что система производства Тойоты (TPS) придумывалась для управления "конвеером", где вариабельность задачи от раза к разу минимальна. Это так. С одной стороны, этот факт не мешает использовать определенные элементы TPS в разработке ПО. С другой стороны, в разработке ПО неопределенности и вариабельности на много больше, что заставляет усомниться в применимости ДАО Тойоты в этой области.

На самом деле вариабельность и неопределенность не помеха ДАО Тойоты. Задача разработки нового автомобиля на много ближе (если вообще не то же самое) к разработке ИТ-системы. И там и там есть неопределенность, нечеткость требований в самом начале проекта, много рисков и всякого непонятного. И Тойота с этим справляется...

В книге подробно и с примерами разбираются 13 основных принципов разработки продукции в Тойота (эти принципы отличаются от рассмотренных в 14 принципов ДАО Тойота). 13 основных принципов объединены в 3 группы:

Процесс
  1. Определить, в чем ценность продукта для потребителя, что бы отличать добавление ценности от потерь. В нашей индустрии имеет смысл добавить еще и принцип 0 - определить, кто является нашим потребителем. Команда по разработке может считать своим потребителем того, кто платит деньги; владельца продукта или customer proxy; команду аналитиков/тестировщиков (если оргструктура в компании выделяет аналитиков/тестировщиков в отдельные единицы); ген. директора фирмы (той, которая платит деньги за разработку или зарплату) и т.п. В зависимости от этого понятие ценность будет иметь различные значения.
  2. Обеспечить правильный старт процесса разработки, чтобы на ранней стадии проектирования досконально изучить все альтернативные варианты. При разработке продукции в Тойота используются практики параллельного проектирования на базе альтернатив. В качестве примера, Лайкер дает ссылку на историю разработки силовой установки Приуса, когда с самого начала команда рассматривала 80 различных вариантов. Этот же принцип уходит корнями в основную практику Lean - "Deffer Commitment", подразумевающую, что всякое необратимое решение мы принимаем на столько поздно, на сколько это возможно, что бы не было потом мучительно больно, за "поторопились и получилось как всегда".
  3. Обеспечить выровненный поток процесса производства продукции. Это достаточно важно. Очереди - зло. Теория очередей гласит, что как только загрузка команды превышает определенный порог, время выполнения "заказа" начинает экспоненциально расти вместе с ростом загрузки. Еще раз, очереди - зло. Что бы избежать очередей в высоковариабельной среде, нужно либо иметь избыточную пропускную способность (чем выше вариабельность - тем выше избыток. А в разработке вариабельность ой как высока...) либо... не создавать очередей. Дробить все на кусочки и пропускать через систему кусочками. Если мы передаем ИТ-систему в поддержку, то не обязательно приходить к команде поддержки только когда все на 100% готово (и функционал и документация). Если выдавать все маленькими порциями, то перевариваться оно будет на много быстрее. Тут же используются принципы вытягивания для обеспечения "точно вовремя" и принципы синхронизации параллельных потоков. В общем, очень похоже на TPS.
  4. Применять жесткую стандартизацию, что бы снизить вариацию, повысить гибкость и обеспечить предсказуемость. Стандартизация - отдельная тема системы разработки продукции в Тойота. До недавнего времени стандарты у меня ассоциировались с чем-то неизменным, тяжелым, неэффективным и ненужным. Признаюсь, сейчас я радикальным образом изменил свое мнение. Мало того, начал замечать, сколько возможностей упускается из-за отсутствия стандартизации. Например, есть 4 команды и в каждой из них свой собственный скрам (специально для скептиков - скрам эволюционирует и это нормально. В разных командах по-разному...) Если бы скрам был бы менее "разный", то результаты ретроспектив можно было бы шарить между командами, в результате чего быстрее эволюционировать.
Люди
  1. Развивать систему главных инженеров для интеграции всего процесса разработки. Система главных инженеров в Тойота - отдельный разговор. Идея такого человека мне очень понравилась. Во-первых, главный инженер отвечает за новый продукт от и до. От разработки концепции нового автомобиля, до послепродажного обслуживания проданных тачек. И он единственный, кто отвечает за все это. Есть еще и другое приключение в должности главного инженера - группы разработки формально не подчиняются ему. И руководство производится исключительно за счет годами заработанного авторитета и доверия (что бы стать главным инженером в Тойота, зарабатывать доверие нужно 10-15 лет!!! Это явно не спроста). 
  2. Создать организационную структуру, которая позволяет сочетать функциональную компетентность и межфункциональную интеграцию. В Тойота используют матричную структуру! Я был удивлен. Настоящая матричная структура, в том виде, как оно описывается в классических книжках. Каждый центр разработки состоит из "функциональных шахт" - групп, специализирующихся на определенной функции. Есть мнение, что такая структура может эффективно работать только благодаря опытному и уважаемому главному инженеру.
  3. Повышать уровень технических знаний всех инженеров. Здесь стоит акцент на слове "технический". Тойота делает ставку на углубление, а не расширение знаний своих инженеров. В итоге в Тойота есть множество людей, знающий практически все, про практически ничто. Кто-то посвящает свою жизнь разработке ручек стеклоподьемников... Или кнопок аварийки... Для западных компаний (где принято инженерам через курсы МВА уходить в менеджеры) это кажется дикостью. Но в совокупности с предыдущими двумя принципами этот подход Тойоты реально работает.
  4. Сделать поставщиков составной частью системы разработки продукции. Про это читал у Вуммека... В какой-то момент Lean-компания обнаруживает, что большая часть ценности добавляется уже за пределами компании. Что бы продолжить борьбу с потерями, необходимо сделать поставщиков своим собственным продолжением, включить их "в семью". Ровно это и происходит в Тойота.
  5. Создать систему обучения и непрерывного совершенствования. Способность учиться позволяет Тойоте без опаски обучать принципам своей работы даже прямых конкурентов: "пока они освоят то, о чем мы им рассказали, мы уже будем далеко впереди". Кстати, а сколько в вашей команде прочитано книг по специальности за последний месяц? ;)
  6. Сформировать культуру постоянного стремления к совершенству. Это немного ассоциировалось у меня с самобичеванием. Культура Тойоты - это постоянный акцент на собственных недостатках. Именно это заставляет их все двигаться и двигаться вперед. Именно по этой причине TPDS нельзя внедрить, это можно только выращивать.
Технологии
  1. Адаптировать технологию к потребностям людей и процесса. Тойота достаточно консервативная организация, и не торопится внедрять очередное красивое ИТ-решение, о котором совсем недавно только услышали на конференции. Технологии не относятся к конкурентному преимуществу ни разу - их легко копировать. В отличии от ДАО.
  2. Координировать работу организации с помощью простых средств визуальной коммуникации. Здесь возникают мои любимые канбаны, и отчет формата А3. Отчет формата А3 - такой же просто инструмент как и метод "5 почему". Просто напишите отчет на листе А3. Не хватает листа А3, тогда используйте А4. ("5 почему" - тоже достаточно простой метод. Видите нежелательное явление? Спросите себя "почему?" 5 раз и с очень хорошей вероятностью вы доберетесь до корневой причины. Правда!)
  3. Использовать эффективные инструменты стандартизации и организационного обучения. Опять стандарты. Если у вас нет стандартов - у вас не будет кайдзен. И это правда. Если какое-то дело вы каждый раз выполняете будто впервые, то как можно это улучшить? В качестве стандартов в Тойота очень любят чек-листы, за которые отвечают те, кто их использует (а не служба качества или еще кто бы то ни было)
Книга дала очень много поводов подумать и оставила после себя ряд идей, которые скоро пойдут во внедрение...

Рекомендую.

Tags:


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

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

Понравилось:
  • Отличные иллюстрации понятий ценность и потери (хороший пример с баночкой кока-колы. Кусочек боксита ставшей банкой на полке в магазине был выкопан более чем год до того, как вы взяли эту банку в руки. За это время кусочек боксита испытал множество превращений, но реально полезные с нашей точки зрения процессы длились в общей сложности не более нескольких часов)
  • Обилие примеров из реальной жизни и из реальных компаний: Wiremold, Lantech, Pratt & Whitney, Porsche
  • Наличие пусть очень общего, очень высокоуровнего, но все же плана преобразований к бережливому предприятию (особо врезались в память таймлайны: если через 3 месяца после начала преобразований вы не видите резкого улучшения, то что-то идет не так и редко кому удается дойти до настоящего уровня бережливости менее, чем за 5 лет)
  • Четкие и понятные пояснения, что бережливым нельзя быть в одиночку. Так или иначе в какой-то момент вы поймете, что основная добавочная стоимость продукта создается за пределами компании, где бережливости может и не быть. Именно по этой причине Тойота так плотно занимается своими поставщиками как первого уровня, так и второго и даже третьего.
Особо хочу отметить пример с Porsche. В этом примере нашлось очень много общего с программной инженерией:
  • Прошло 45 лет с момента основании компании, как с конвейера сошел первый автомобиль без багов (производственная система была построена так, что после финального этапа сборки автомобиль поступал в распоряжение опытным "багфиксерам", занимающимися поиском и устранением всех найденных дефектов. И в тот великий момент первого безбажного автомобиля вся команда доводчиков была ошеломлена, так как твердо верила в то, что автомобиля без багов не бывает и быть не может по своей природе)
  • В Porsche вся система производства была очень близка к ремесленной: больше всего ценилось индивидуальное мастерство (наглядной демонстрацией была подпись мастера на крышке мотора, который он собрал), основное знание было неявным и требовало много времени на его передачу, да и сам процесс обучения был неформальным и преимущественно от мастера к помощнику (в Тойоте такое тоже есть, но это далеко не единственный способ обучения)
  • Они тоже не думали про техподдержку, уделяя первостепенное внимание крутости используемых технологий. В результате чего в 70-х была даже отдельная профессия - механик автомобилей Porsche (т.к. обычному автомеханику под капотом вообще было делать нечего)
  • Их продукция производилась на одном континенте, когда основной рынок сбыта располагался на другом
Тем не менее за десятилетие Porsche очень сильно изменилась, стала эффективнее, быстрее, прибыльнее и до сих пор сохранила независимость. А самое главное - они таки научились делать автомобили без багов, хотя изначально были убеждены, что это невозможно. Может, и у нас это получится?

Tags:

По наводке dumtest -а начал слушать аудиокнигу Генри Форда "Моя жизнь и мое дело" Книга обалденная, особенно понравится тем, кто сам в молодости за рюмкой пива перебирал карбюратор на восьмерке, или перетряхивал волговскую подвеску...

Но главное не в этом. Помните фразу, приписываемую Генри Форду: "Автомобиль может быть любого цвета, если этот цвет черный"? Редкая бизнес-книга не глумилась над стариной Генри, пытаясь показать этой цитатой до чего доводит отсутствие забоды о клиенте и все такое...

Однако как и учение Уинстона Ройса, эта фраза была исковеркана. В оригинале она звучит как: "Покупатель мог перекрасить свой автомобиль в любой цвет, так как все наши автомобили были черными". Наоборот! Это потрясающая забота о клиенте! Хочешь крась (на тогдашний черный любая краска ложилась без вопросов), хочешь оставь как есть. Для 20-х годов прошлого века это невиданная клиентоориентированность!

Генри молодец! И книжка очень интересная, при чем большая ее часть (из той, что я успел прослушать) так и не утратила актуальности.

Tags:


Коллеги,

18-19 сентября в Киеве будет проходить знаменательное событие - конференция Agileee.

В рамках конференции будет проходить серия мастер-классов, в частности, приедет Mary Poppendieck - идеолог применения подходов Toyota Production System для разработки ПО. Не знаю кто как, а я бы только ради нее отъявился на этом мероприятии
Больше подробностей о конференцииCollapse )

Profile

Cartmendum
cartmendum
cartmendum

Latest Month

September 2019
S M T W T F S
1234567
891011121314
15161718192021
22232425262728
2930     

Syndicate

RSS Atom
Powered by LiveJournal.com
Designed by Tiffany Chow