Есть такие термины как статус-кво, территориальные границы, и доминирующие принципы лидеров местного сообщества. Таким образом не злые, а принципиально охраняющие «местную экосистему от загрязнения нежелательной деятельностью не местного контингента». Если в других дружелюбных сообществах перейдете неизвестную вам границу, то и там наверняка объяснят кто есть кто или не объяснят в черный список и точка.
Парето — это методика анализа сложных систем, которая предполагает что сложные системы неоднородны и в виду этого различные части системы имеют различную степень влияния на общий результат работы системы. В частности утверждается что примерно 20% системы производят около 80% результата.
Согласитесь чтобы уметь вывести систему на оптимум необходимо проверить и уточнить данное утверждение в конкретной рабочей системе и применить полученное знание для недопущения локальной оптимизации.
это не недостаток метода, а недостаток системы целеполагания т.к. если цель общая (генеральная) неизвестна или известна, но заменена на личную (локальную).
Иными словами классическая ошибка руководства если управление ориентировано на общую (генеральную) цель через декомпозицию на личные (локальные) цели при отсутствия понимания того что сумма результатов по личным (локальным) целям ни в коем случае не равно результату по общей (генеральной) цели.
Экспоненциальный (степенной) закон (Power law) = Эффективность (оптимальность) по Парето (Pareto Efficiency) т.е. про одно и тоже разными словами, ну самое животрепещущее Системный подход (Systems Thinking) под номером в списке моделей поглощает практически без остатка все модели те что ниже по списку.
Клиента нужно приучить к вилкам и к тому, что в них заложена подстраховка. Это не обман, а реальность. Мы можем быть уверенными только в одном: здесь работает закон Мёрфи. Если он бьёт часто, буферы должны быть больше. Проверить частоту Мёрфи можно итеративно.
Если клиент категоричен и не хочет видеть вилки — просто уберите нижнюю границу. Но важно не только закладывать адекватные буферы, но и пристально контролировать их расход.
Если буфер съеден на треть, а работа еще не готова — это повод начать экспедирование и проталкивание. В сфере веб-разработки мы используем burndown chart, чтобы визуализировать расход.
Экспедирование и проталкивание при отлаженных процессах должны занимать не более 5% всей работы. Если меньше — значит, у вас есть запас мощностей. Если больше — у вас проблема.
На сложных проектных цепочках наибольший контроль должен быть на выявлении бутылочного горлышка проекта и контроле его питающих буферов.
Если горлышком являются различные согласования в проекте, то в этом случае контроль буферов может не помочь. С такой ситуацией не сталкивались?
Вот случай устроился так недавно на промышленное предприятие, а там такое: реальные попытки внедрения более 2 лет (следы первых попыток уходят аж в 2009 год) + регулярный аудит (1-2 раза в год) + чудная методика вышестоящей компании + фрагментарно-поэтапный подход к достижению критериев = сильно удручающая картина; примерно также как тут https://habrahabr.ru/post/308024/#comment_9763332 только ручки (внедряемой системы) до сих пор как не было так и нет.
Вот сижу теперь и думаю, как из руин замок построить, точнее фундамент в порядок привести… с одного края водопад размывает, с другого обрыв, а вокруг безлюдная пустыня с редкими оазисами.
этот случай когда человеческая речь является языком «программирования» с многоуровневой абстракцией, или другими словами понимание данного термина у 10 разных человек может и будет разным, а в дословном переводе всего лишь: изменения к лучшему. Но правильное понимание данного слова как айсберг, всего самого основного смысла в нем заложенного по самому слову не видно. Считайте его ссылкой на базовую концепцию, знание которой подразумевается как само собой разумеющееся в диалоге.
Описываемый вами случай подходит к ситуации когда начальник говорит подчиненному: внедри мне систему, а подчиненный либо не знает либо боится сказать что эта систему должен сам начальник применить на своем уровне полномочий к своим принципам работы, а молоток тут и не причем.
«кайдзены» со стороны ваших заказчиков — это изменения и настройка их процессов (от заказа до исполнения) иногда они не требует изменений со стороны IT систем, а иногда требует. Будут ли новые требования серьезными или нет вопрос каждого конкретного случая в отдельности.
«кайдзены» для вашей компании очень трудный пример, т.к. в IT компаниях наверное проектные принципы работ, с которыми системный подход к улучшению процессов может быть связан очень специфически. Вопрос очень интересный, но ответа удовлетворительного у меня нет.
«Без казуистики и не туда и не сюда», если заранее не договариваться об определениях, как «дедушка Бекон советовал». А также без привязки к реально существующему объекту изменений, который известен обоим сторонам диалога в одинаковой мере хорошо.
В понимании тех же самых японцев идеальный вариант никогда не достижим, то есть если что-то вы достигли чего-то на пути к идеалу это может быть что угодно, но не сам идеал. Все изменения с системе производимые будь то попыткой «инновации» или попытками «кайдзен» не всегда приводят к позитивному результату, но неудача отдельной инновации более чувствительно отражается на финансовом состоянии компании, чем неудача отдельного «кайдзена».
Принципы самих подходов несовместимы, но методы и инструменты могут одинаковые применяться как при «кайдзен»-ориентированном подходе, так и при «инновационно»-ориентированном. На картинке с графиками мы наблюдаем не «Кайдзен» vs «Инновации», но «Инновации» vs «Инновации + Кайдзен». Собственно из-за этого и вопрос то был: «Кайдзен» == «Инновации + Кайдзен» или нет?!
Важен ваш взгляд на данный вопрос и ваше мнение, а казуистику можно смело в топку. С уважением, Артур
Если «инновации» — это новшества привносимые в систему для ее улучшения, а «кайдзен» — это постоянные улучшения системы, — то напрашивается вывод что «инновации» это составная часть «кайдзен», верно?!
Согласитесь чтобы уметь вывести систему на оптимум необходимо проверить и уточнить данное утверждение в конкретной рабочей системе и применить полученное знание для недопущения локальной оптимизации.
Иными словами классическая ошибка руководства если управление ориентировано на общую (генеральную) цель через декомпозицию на личные (локальные) цели при отсутствия понимания того что сумма результатов по личным (локальным) целям ни в коем случае не равно результату по общей (генеральной) цели.
Если горлышком являются различные согласования в проекте, то в этом случае контроль буферов может не помочь. С такой ситуацией не сталкивались?
Вот сижу теперь и думаю, как из руин замок построить, точнее фундамент в порядок привести… с одного края водопад размывает, с другого обрыв, а вокруг безлюдная пустыня с редкими оазисами.
Описываемый вами случай подходит к ситуации когда начальник говорит подчиненному: внедри мне систему, а подчиненный либо не знает либо боится сказать что эта систему должен сам начальник применить на своем уровне полномочий к своим принципам работы, а молоток тут и не причем.
«кайдзены» для вашей компании очень трудный пример, т.к. в IT компаниях наверное проектные принципы работ, с которыми системный подход к улучшению процессов может быть связан очень специфически. Вопрос очень интересный, но ответа удовлетворительного у меня нет.
В понимании тех же самых японцев идеальный вариант никогда не достижим, то есть если что-то вы достигли чего-то на пути к идеалу это может быть что угодно, но не сам идеал. Все изменения с системе производимые будь то попыткой «инновации» или попытками «кайдзен» не всегда приводят к позитивному результату, но неудача отдельной инновации более чувствительно отражается на финансовом состоянии компании, чем неудача отдельного «кайдзена».
Принципы самих подходов несовместимы, но методы и инструменты могут одинаковые применяться как при «кайдзен»-ориентированном подходе, так и при «инновационно»-ориентированном. На картинке с графиками мы наблюдаем не «Кайдзен» vs «Инновации», но «Инновации» vs «Инновации + Кайдзен». Собственно из-за этого и вопрос то был: «Кайдзен» == «Инновации + Кайдзен» или нет?!
Важен ваш взгляд на данный вопрос и ваше мнение, а казуистику можно смело в топку. С уважением, Артур