vit_r

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

Lean - это часть Toyota Production System, которую мало у кого получается повторить даже в автомобилестроении, потому что у японцев в самой базе лежит философия качества, которую европейцы не только не копируют, но и не понимают. А Lean - это перенос контроля качества к поддерживающим эту базовую философию поставщикам, массово выпускающим стандартные упрощённые компоненты. Причём, там где из-за сложности компонентов или разнообразия их номенклатуры, а ещё чаще из-за недостаточно глубокого внедрения философии качественного производства поставщики не справляются со стопроцентным отсутствием дефектов на выходе, собирающее производство начинает сразу корёжить и перекашивать, потому что внутренний контроль стопорит дефектные сборки прямо в середине процесса, вызывая дорогостоящие процедуры анализа и корректции.

Agile - это профанация в IT, когда инженерная разработка и контроль качества из процесса убираются под лозунгом "Нам не нужно заботится о багах и кривых решениях, если что не так, быстро и дёшево переделаем". Причём там, где переделки оказываются не очень дешёвыми, эти замечательные agile проекты валятся со страшным грохотом. И из-под обломков разбегаются agile-консультанты бормоча "Эта фирма не смогла правильно осознать культуру agile".

Не сложно догадаться, что представляет из себя сочетание lean agile, начинающее набирать популярновть у консультантов, менеджеров и прочих заклинатеелей-дилетантов.

Смотрим на аватар и запоминаем:

Vit minus R dot com

Там сейчас ничего нет, но если что, адрес всем известен.

Запомнить советую потому, что Гугл находить не будет, если сделаю так, как мне нравится. Судя по тестам, Империя Зла фильтрует определённые вещи из результатов поиска. Бинг и остальные в подобном не замечены.

А теперь к делу.
( Read more... )

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

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

С софтом, что завязан на мехатронику, попроще, но там свои приколы.

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

А гении не врубаются.

При этом на нуле познания не о какой-нибудь коммуникативной психологии, или псхиологии восприятия, а в самых банальных базовых принципах:

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

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

Софтописание - дисциплина гуманитарная. При этом, именно в этой области познания как у питекантропа в матанализе.

И как прикажете выражаться понятно и просто, при этом никого не обидев?

Писал одному по делу. Простое «нет» пришлось преобразовывать в набор более понятных фраз. И то, не известно, насколько будет воспринято.

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

Ниже краткий перевод существенной части.

The Joy-Factor-Problem

( Read more... )

Тема началась тут. Потом dz поднял вопрос тут. Так что, несколько замечаний на память.

Про размеры и взрыв сложности

Первым делом, аналогия. Сначала объясню, почему она правильная, а потом, почему она не работает.

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

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

Теперь, почему это всё не более, чем теории.

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

То есть, наша программистская армия сверху до низу состоит из потенциальных дезертиров-коллаборационистов с крупными вкраплениями предателей-мародёров.

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

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

Под информацией надо понимать всё: и приказы начальства, и отчёты, и просто технические подробности, и исходный код, и комментарии, и сообщения об ошибках.

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

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

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

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

При этом, в большинстве случаев нет людей, которые владеют информацией об общем состоянии дел и общем планировании, а всё превращается в «стратегическое распределение ресурсов». Кудесники гарвардской школы эффективного управления вступают в свои права.

Бывает ли наоборот? Да. Даже иногда такое видел, правда не в ИТ. Кодовое слово - Genchi Genbutsu, иначе говоря «спустись с небес и посмотри сам».

Инженеры в производстве подписывают все чертежи, чтобы в случае чего суд знал, кого сажать на скамью подсудимых. Среди подписей есть подпись главного инженера. И это тот человек, который на самом деле знает, что происходит со всем проектом. Не в мельчайших деталях, но на уровне, достаточном для понимания. И главные инженеры систем знают всё, что находится в зонах их ответственности. Естественно, за одним исключением: главного по софту.

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

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

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

Читая «The Toyota Way» всё время чувствовал, что что-то не сходится. Идея прекрасная, система замечательная. Но не должно это работать. По всей логике жизни больших корпораций не должно.

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

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

Похоже, что-то интересное нашлось в совершенно другой области. И тут имеет смысл рассказать, почему авторы упомянутого недавно The Big O испортили крутой нуарный детектив Очень Большими Человекоподобными Роботами.




Естественно, циничная отсылка к комплексу из-за роста была простым сарказмом и любви к ОБЧР не объясняет. Также, встречавшееся в этом журнале упоминание самурайских традиций верно лишь отчасти. Джедаям Лукаса хватило простых световых мечей. Американские супергерои, наследующие этику романтичных средневековых рыцарей, обходятся внутренними способностями, а, если и используют технику серьёзнее индивидуальных гаджетов, её размеры и технические характеристики не выходят за границы разумного.

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

С другим аналогично.

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

Причём, это совсем не противостояние Востока и Запада.

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

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

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

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

В истории Японии было два уникальных рывка: переход от доисторического общества к феодализму и переход от законсервированного феодализма к индустриальному обществу. В результате это единственная страна, где сохранилось язычество. Не просто сохранилось как религия, а органично на бытовом уровне входит в мироощущение.

Но погодите говорить «Ага!», вдобавок ко всему язычество это совсем не простое.

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

Японцы прекрасно уживаются со зверодемонами. Тануки может принимать образ человека, но всё равно остаётся енотовидной собакой.

Однако, всё ещё хуже. Божеством может быть и предмет. Причём, условие обретения собственного мистического «Я» совсем простое: достаточно просуществовать сто лет.

Представьте, идёте вы по музею, а с полки за вами внимательно наблюдает древнегреческий ночной горшок.

Нет, не тот из диснеевского мультфильма, что с нарисованными глазками и большим ртом, а тот, что равен богу.

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

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

Почему? Потому что для японца это не транспортное средство, не удобная связь с внешним миром, даже, не символ благосостояния, а сам бог прогресса.

Пилот ОБЧР не влезает в ходячий танк, он сливается с богом.

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

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

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

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

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

В последнее время для нетематических постов я не использую кат, чтобы люди честно видели весь объём, пугались и проматывали мимо.

Этот пост скопирован с поста в LJ вручную из-за проблем с автоматическим переносом.

---

Решил сделать движущиеся картинки. Поискал, можно ли собрать gif из командной строки. Нашёл у себя инсталляцию ImageMagick (как потом оказалось, обрезанную и кривую). Решил попробовать. Короче, в тот день я ничего не сделал. Точнее, ничего полезного.

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

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

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

Видел много чудесного и прекрасного. Но всё не решало, а чаще всего ухудшало основной принцип неопределённости умственной деятельности: «Или у нас хорошая отчётность, или у нас хороший результат»

Плюс все методики не стабильны.

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

Мы можем три года аккуратно вести проект по gnatt, точно вписываясь в дидлайны и победно отчитываясь по каждому этапу. Но за три месяца до сдачи вылезают незамеченные мелочи, и вся красота идёт в мусорное ведро, а реальность улетает куда-то в туман.

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

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

Короче, все известные методики и подходы не выдерживают требования предсказуемости, правдивости и стрессоустойчивости. Что-то полезное нашёл только у Барбары Шер и у Тойоты. (У последней, естественно, не в конвейерных сказках про lean и kanban, которые они продают миру, а во внутренних методиках, которые они тщательно прячут и упоминают лишь изредка и очень туманно.)

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

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

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

Естественно, вся красота и мощь автоматизации живёт параллельно и несколько сбоку. Иногда со ссылками из текстового лога, иногда с упоминаниями, иногда просто как свалка для отчётности. Если что-то нужно быстро понять, вспомнить или повторить, всё ищется в банальном простом текстовом файле, содержащем всё важное, и только это.

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

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

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

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

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

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

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

Это ещё не решение. И даже не направление движения. Просто проблеск идеи. Но мне понравилось. И теперь понятно, куда идти дальше.

Под катом ( семь месяцев за полторы минуты в 9 мегабайтах )

Если картинка не движется секунд 10, её надо перегрузить. FFox у меня показывает анимацию через раз.

Несколько дней нахожусь в состоянии лёгкого офигения. Даже подумывал, не отступить ли от традиции и не написать ли пост чистым матом, упомянув в заголовке северного пушного зверька. А всё от того, что свалилась рассылка одной из групп местных учёных.

Если переводить кратко и культурно написаное доктором информационных наук, получится примерно следующее:

После защиты диссертации в 2008 я четыре года занимаюсь в САП тем, что трансформирую наши 20k разработчиков [sic - да, именно это вызвало у меня приступ задумчивости] в Lean and Agile Development. Scrum уже три года как стандарт.

Вот страничка от университета Манхайма, вот профиль на Xing и на LinkedIn. Докторскую посмотреть не удалось, так как за неё просят 65 евров.

Трудовой путь:

10/1999 - 06/2004

Студент

07/2004 - 03/2008

Аспирант

03/2008 - 01/2009

Научный работник

01/2009 - и далее

Development Project Consultant, SAP AG

Сертификаты:

• Scrum Master (2009)
• Scrum Mentor / Trainer (2010)
• Scrum Trainer Instructor (2010)
• Lean Software Development Mentor (2010)
• Continuous Improvement Expert (2011)
• Agile Requirements Engineer (2011)
• Design Thinking Coach (2011)

Опыт реальной работы? Да кого интересуют такие мелочи, когда надо двадцать кило разработчиков переводить на Lean Thinking!

И не надо надеяться, что САП такой один или они нашли особого гения. Практически везде в стратегическом планировании сидят люди, свалившиеся из науки.

Насчёт же науки... Упоминания третьего уровеня по Кокбурну или тойотовского генчи генбутсу (現地現物) вызывают реакцию, будто я заговорил на марсианском. Просьба объяснить, какими метриками доказывали полезность изменений, пораждают поток чисто религиозного красноречия.

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

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

В принципе, во всём, что я видел, есть скользкие места, есть дыры, есть неувязки, но бреда относительно немного. И везде следы схем, из «Quality Is Free» (by Philip Crosby, год публикации 1979). И как в оригинале, постоянно повторяется «Поймите, качество - это не процесс, а мотивация. Запомните, качество - это не мотивация, а процесс.»

Короче, в бумагах ничего вредного и достаточно много полезного. При этом, что не реализация, то тихий ужас.

Похоже, проблема в самой структуре стандартов. Есть вещи базовые, плохо проверяемые. Есть «критерии соответствия» верхних уровней - яркие и понятные. Вот и строят замки на песке.

Или на выгребной яме.

Забавно, что мотивация в Automotive SPICE встречается. Но один раз и на пятом уровне. В контекстве «GP 5.2.2. Manage the implementation of agreed changes...»

The factors that impact the effectiveness and full deployment of the process change are identified and managed, such as:

• ...
• Human factors (job satisfaction, motivation, morale, conflict/cohesion, goal consensus, participation, training, span of control);
• Management factors (skills, commitment, leadership, knowledge, ability, organisational culture and risks);

Пятый уровень - это слишком далеко. И в подавляющем большинстве случаев - слишком поздно. В Toyota Production System это относится к базису. Правда, TPS работает только для конвейера и не то, чтобы совсем правда.

Теперь пара картинок. Опять же из Hanasaku Iroha episode 11. На этот раз два отеля.

Первый маленький частный, уютный, в старинном стиле, с открытым термальным бассейном, с традиционной едой и приветливым внимательным персоналом.



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



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

Да, правильно. Все мечтают очутиться в большой бетонной коробке.

The Soviet Union under Brezhnev, Japan under its bureaucracy - each is an example of a society that believed it had achieved eternal balance: central planners had everything under their control. Change, and all the social chaos to which it gives rise, had been banished. But alas, we can never banish change.

Можно считать первым правилом японцев Правило Отсутствия Сюрпризов. У них понятие Wa (гармонии) настолько священно, что используется как синоним к названию собственной страны. Видимо, в идеально гармоничном состоянии страна пребывала те 300 золотых лет, когда была закрыта от внешнего влияния: каждый знал своё место, свой распорядок, обязанности и возможности. Умом они может и понимают, но сердцем просто отрицают всякие нарушающие привычный ход вещей неудобства.

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