Я не очень понимаю, в какой момент произошел слом в массовом сознании, но я его наблюдаю регулярно и систематически.
Но то что слом произошел, причем совсем недавно, и не только в России, это факт. Как вам вот такие два определения качества:
1. ИСО 8402—86: Качество — совокупность свойств и характеристик продукции или услуги, которые придают им способность удовлетворять обусловленные или предполагаемые потребности потребителя.
2. ГОСТ Р ИСО 9000-2015: Качество — степень соответствия совокупности присущих характеристик объекта требованиям.
Видите разницу, под катом мои мысли на эту тему.

Ключевая разница этих определений в том, что в 86 году под качеством понимали удовлетворение потребностей потребителя, в 2015 соответствие требованиям.
И вот уже в голове голосом Райкина звучит:
-У вас к пуговицам претензии есть?
- Нет, к пуговицам претензий нет, пришиты намертво.
Аналитик отвечает только за то, чтобы в TFS (или какая у вас там система управления требованиями) появились пользовательские истории для Scrum или требования для остальных методологий. Ой, простите, Скрам это не методология, это всего лишь фреймворк, который, кстати, тоже не про удовлетворение потребностей потребителя, а про ритуальные действия, которые должны выполняться строго в соответствии с требованиями. Но не суть, аналитики написали некий текст, разработчик в соответствии с этим текстом написал функционал, инженер по тестированию проверил, все работает так, как написано в требовании. Пришиты намертво, не оторвешь. Вот только пользоваться этим нельзя. Например, по тому, что никто не подумал о реальной ситуации где это будет работать. Об обрывах связи, о больших наборах данных, о том, что пользователя выбесит вводить одно и то же значение 100 раз подряд. А это ведь я рассказываю про идеальный сценарий, с выделенной аналитикой, разработкой и тестированием.
Мы все забываем про потребителя. Причем даже не обязательно вешнего. Рассмотрим самый ужасающий пример такой забывчивости: программиста. Кто является потребителем продукта за качество которого отвечает программист? Остановитесь, подумайте. Кто? Пользователь? Отлично, если программист когда пишет код думает о пользователе, о том как будут пользоваться системой, в каком окружении она будет работать, что можно сделать, чтобы если уж не облегчить жизнь пользователю, то хотя бы не усложнить. Но в большинстве случаев нет даже этого. Ну вот в требовании написано реализовать А. Ну и что, что то что написано не удобно, ломает логику системы, да и использоваться не будет пока не сделают Б, которого даже в планах пока нет. Надо сделать А, вот и сделаю как понял, а там хоть трав.. Ну в смысле а там коммит, ревью, пуш, закрыть задачу и пойти налить кофе.
А ведь кроме несчастного пользователя потребителями труда программиста являются: инженеры по тестированию, специалисты по внедрению, специалисты технической поддержки и ПРОГРАММИСТЫ!!! И ладно, тестировщиков не жаль, админы пусть мудохаются с развертыванием как хотят, тех. поддержка? А это вообще кто такие? Но блин, как можно не думать про себя любимого? Как можно писать методы на сотни строк кода? Ты что, завтра увольняешь и больше не будешь пытаться разобраться в этом спагетти? Как можно в сложной лямбде, находящейся внутри другой лямбды, которая находится по соседству с третей лямбдой использовать имя переменной параметра i (при этом тип сущностей в итерируемой коллекции пусть будет Персона)? Ну а писать catch внутри которого ничего нет, это вообще как? Это что, желание подольше искать неуловимую ошибку?
В Кайдзен есть очень правильный постулат: "Следующий процесс – это потребитель. Вся работа представляет собой ряд процессов, и в каждом процессе имеется свой потребитель и свой поставщик. Большинство работающих в организациях людей имеют дело с внутренним потребителем. Никогда не передавайте бракованные запасные части или неверную информацию людям, участвующим в следующем процессе.".  У каждого кто занимается разработкой программного обеспечения должна постоянно в голове быть мысль: не передавать брак или неверную информацию дальше. Ведь следующий по цепочке это и ты в том числе. Сделал плохо сегодня, придется переделывать завтра. Не предусмотрел сегодня, придется переделывать завтра. Как и с любым принципом, не надо перегибать палку. Не надо доводить мысль до абсолюта, вот пока не доведу до хрустального совершенства, на следующий этап не пущу. Но надо делать максимально хорошо, уверяю вас, плохо оно само получится.
P.s. Сорри за такую сумбурную портянку текста, наболело что-то...

Я не очень понимаю, в какой момент произошел слом в массовом сознании, но я его наблюдаю регулярно и систематически.
Но то что слом произошел, причем совсем недавно, и не только в России, это факт. Как вам вот такие два определения качества:
1. ИСО 8402—86: Качество — совокупность свойств и характеристик продукции или услуги, которые придают им способность удовлетворять обусловленные или предполагаемые потребности потребителя.
2. ГОСТ Р ИСО 9000-2015: Качество — степень соответствия совокупности присущих характеристик объекта требованиям.
Видите разницу, под катом мои мысли на эту тему.

Ключевая разница этих определений в том, что в 86 году под качеством понимали удовлетворение потребностей потребителя, в 2015 соответствие требованиям.
И вот уже в голове голосом Райкина звучит:
-У вас к пуговицам претензии есть?
- Нет, к пуговицам претензий нет, пришиты намертво.
Аналитик отвечает только за то, чтобы в TFS (или какая у вас там система управления требованиями) появились пользовательские истории для Scrum или требования для остальных методологий. Ой, простите, Скрам это не методология, это всего лишь фреймворк, который, кстати, тоже не про удовлетворение потребностей потребителя, а про ритуальные действия, которые должны выполняться строго в соответствии с требованиями. Но не суть, аналитики написали некий текст, разработчик в соответствии с этим текстом написал функционал, инженер по тестированию проверил, все работает так, как написано в требовании. Пришиты намертво, не оторвешь. Вот только пользоваться этим нельзя. Например, по тому, что никто не подумал о реальной ситуации где это будет работать. Об обрывах связи, о больших наборах данных, о том, что пользователя выбесит вводить одно и то же значение 100 раз подряд. А это ведь я рассказываю про идеальный сценарий, с выделенной аналитикой, разработкой и тестированием.
Мы все забываем про потребителя. Причем даже не обязательно вешнего. Рассмотрим самый ужасающий пример такой забывчивости: программиста. Кто является потребителем продукта за качество которого отвечает программист? Остановитесь, подумайте. Кто? Пользователь? Отлично, если программист когда пишет код думает о пользователе, о том как будут пользоваться системой, в каком окружении она будет работать, что можно сделать, чтобы если уж не облегчить жизнь пользователю, то хотя бы не усложнить. Но в большинстве случаев нет даже этого. Ну вот в требовании написано реализовать А. Ну и что, что то что написано не удобно, ломает логику системы, да и использоваться не будет пока не сделают Б, которого даже в планах пока нет. Надо сделать А, вот и сделаю как понял, а там хоть трав.. Ну в смысле а там коммит, ревью, пуш, закрыть задачу и пойти налить кофе.
А ведь кроме несчастного пользователя потребителями труда программиста являются: инженеры по тестированию, специалисты по внедрению, специалисты технической поддержки и ПРОГРАММИСТЫ!!! И ладно, тестировщиков не жаль, админы пусть мудохаются с развертыванием как хотят, тех. поддержка? А это вообще кто такие? Но блин, как можно не думать про себя любимого? Как можно писать методы на сотни строк кода? Ты что, завтра увольняешь и больше не будешь пытаться разобраться в этом спагетти? Как можно в сложной лямбде, находящейся внутри другой лямбды, которая находится по соседству с третей лямбдой использовать имя переменной параметра i (при этом тип сущностей в итерируемой коллекции пусть будет Персона)? Ну а писать catch внутри которого ничего нет, это вообще как? Это что, желание подольше искать неуловимую ошибку?
В Кайдзен есть очень правильный постулат: "Следующий процесс – это потребитель. Вся работа представляет собой ряд процессов, и в каждом процессе имеется свой потребитель и свой поставщик. Большинство работающих в организациях людей имеют дело с внутренним потребителем. Никогда не передавайте бракованные запасные части или неверную информацию людям, участвующим в следующем процессе.".  У каждого кто занимается разработкой программного обеспечения должна постоянно в голове быть мысль: не передавать брак или неверную информацию дальше. Ведь следующий по цепочке это и ты в том числе. Сделал плохо сегодня, придется переделывать завтра. Не предусмотрел сегодня, придется переделывать завтра. Как и с любым принципом, не надо перегибать палку. Не надо доводить мысль до абсолюта, вот пока не доведу до хрустального совершенства, на следующий этап не пущу. Но надо делать максимально хорошо, уверяю вас, плохо оно само получится.
P.s. Сорри за такую сумбурную портянку текста, наболело что-то...

Несколько лет назад я уже писал про цикл Деминга, он же PDCA. Но т.к. улучшать хаос не получится, перед тем как его запустить, придется воспользоваться другим циклом, циклом SDCA. В котором вместо планируй будет стандартизируй. Этот цикл, как и цикл PDCA входит в систему Кайдзен, про которую мы еще отдельно поговорим. Сегодня же предлагаю обсудить стандартизацию и сам цикл SDCA.

Начну с того, что у нас очень странно понимают стандарты. Несколько лет назад шла массовая волна внедрения Кайдзен на российских предприятиях, а так как включать голову это сложно и не интересно, то вылилось это в решения вроде: на рабочем столе разметить места для калькулятора, степлера, клавиатуры, мышки и штрафовать работников, если у них вещи находятся не на тех местах. Что мало того, что противоречит здравому смыслу, это противоречит самому Кайдзен.
Что же такое стандарт? Это способ сделать работу наиболее оптимальным способом. Т.е. с наименьшими затратами усилий, с максимальным качеством, с минимальной вероятностью ошибиться. Если у вас есть три человека, которые делают одну и ту же работу, то чем дольше они работают, чем шире спектр проблем с которыми они сталкиваются, чем чаще они включают голову, тем больше у них будет ноу-хау как сделать свою работу в наименее трудозатратном режиме. Если все эти наработки собрать, проанализировать (выбрав не только по принципу наименьших трудозатрат, но и наилучшего качества результата), и сформировать на их основе стандарт выполнения это работы, то... как повезет. Но без этого шага все остальные шаги будут бессмысленны. Пока у вас нет стандарта, вы не можете понять то что делает человек правильно или нет. Может он супер и делает все лучше всех, а может вы не можете его сравнить с остальными работниками и не понимаете его эффективность (см. картинку в начале поста).
Но ок, мы разработали стандарт, что дальше? Дальше необходимо его внедрить. Вспоминая, что любые изменения это для их участников всегда тяжело (нет возможности работать на автомате, надо включать голову, пока новый тип действий не войдет в привычку), необходимо разъяснять нужность стандарта, обучать людей работать в соответствии со стандартом, выявлять тех кто работает не по стандарту и выяснять с чем это связано. Т.е. после того как стандарт готов, начинается самая главная часть работы, добиться того, чтобы работа выполнялась в соответствии с ним.
Только после того как работа начинает выполняться в соответствии со стандартном, переходим к объективному контролю, что у нас произошло после внедрения стандарта. Улучшились ли показатели работы, уменьшилась ли вариабильность этих показателей, повысилась ли эффективность работы?
Последним шагом будет продолжение воздействия на наш стандарт. Обнаружилось падение качеств, смотрим кто отклонился от стандарта или в чем корневая причина и как мы можем изменить стандарт, чтобы такого падения избежать в будущем. Кто-то работает лучше чем все остальные, начинаем разбираться какое ноу-хау он внедрил в свою работу и вносим ее в стандарт. Выбираем в каких работах у нас еще наблюдается разброс показателей или запускаем цикл SDCA для них.
Ну и к нашему примеру с калькуляторами и наказаниями... Я не пользуюсь калькулятором, т.к. мне удобнее считать в редакторе электронных таблиц (сохраняются все промежуточные результаты, вбивая формулы, я могу в случае ошибки поправить входные данные и получить новый результат не перевводя все заново, возможность повторного использования и т.д.). Т.е. у меня есть ноу-хау которое повышает эффективность моей работы. Ко мне приходит специально обученный человек и размещает у меня на столе (скорее всего в зоне максимальной доступности, Кайдзен же борется с потерями, и время на то, чтобы достать калькулятор из стола, это потери) калькулятор. И вот лежит этот калькулятор, мешает мне, но я им не пользуюсь от слова совсем, при этом делаю свою работу быстрее и качественнее (меньше ошибок, за счет готовых формул и удобного контроля входных данных). И вот, вместо того, чтобы быть инструментов повышения эффективности, стандарт становиться средством позволяющим менеджеру пользоваться своей властью в вопросах в которых он не разбирается. А Кайдзен по поводу того, на кого надо ориентироваться в вопросах принятия решений как правильно ставит во главу не менеджера, а гембо (то где создается полезность для потребителя). И даже если внедрением практик Кайдзен достигается повышение эффективности достаточное для того чтобы убрать сотрудника из цепочки создания ценности, надо его не увольнять, а задействовать в других процессах, чтобы увеличивать возможности компании по удовлетворению внешнего спроса.

Несколько лет назад я уже писал про цикл Деминга, он же PDCA. Но т.к. улучшать хаос не получится, перед тем как его запустить, придется воспользоваться другим циклом, циклом SDCA. В котором вместо планируй будет стандартизируй. Этот цикл, как и цикл PDCA входит в систему Кайдзен, про которую мы еще отдельно поговорим. Сегодня же предлагаю обсудить стандартизацию и сам цикл SDCA.

Начну с того, что у нас очень странно понимают стандарты. Несколько лет назад шла массовая волна внедрения Кайдзен на российских предприятиях, а так как включать голову это сложно и не интересно, то вылилось это в решения вроде: на рабочем столе разметить места для калькулятора, степлера, клавиатуры, мышки и штрафовать работников, если у них вещи находятся не на тех местах. Что мало того, что противоречит здравому смыслу, это противоречит самому Кайдзен.
Что же такое стандарт? Это способ сделать работу наиболее оптимальным способом. Т.е. с наименьшими затратами усилий, с максимальным качеством, с минимальной вероятностью ошибиться. Если у вас есть три человека, которые делают одну и ту же работу, то чем дольше они работают, чем шире спектр проблем с которыми они сталкиваются, чем чаще они включают голову, тем больше у них будет ноу-хау как сделать свою работу в наименее трудозатратном режиме. Если все эти наработки собрать, проанализировать (выбрав не только по принципу наименьших трудозатрат, но и наилучшего качества результата), и сформировать на их основе стандарт выполнения это работы, то... как повезет. Но без этого шага все остальные шаги будут бессмысленны. Пока у вас нет стандарта, вы не можете понять то что делает человек правильно или нет. Может он супер и делает все лучше всех, а может вы не можете его сравнить с остальными работниками и не понимаете его эффективность (см. картинку в начале поста).
Но ок, мы разработали стандарт, что дальше? Дальше необходимо его внедрить. Вспоминая, что любые изменения это для их участников всегда тяжело (нет возможности работать на автомате, надо включать голову, пока новый тип действий не войдет в привычку), необходимо разъяснять нужность стандарта, обучать людей работать в соответствии со стандартом, выявлять тех кто работает не по стандарту и выяснять с чем это связано. Т.е. после того как стандарт готов, начинается самая главная часть работы, добиться того, чтобы работа выполнялась в соответствии с ним.
Только после того как работа начинает выполняться в соответствии со стандартном, переходим к объективному контролю, что у нас произошло после внедрения стандарта. Улучшились ли показатели работы, уменьшилась ли вариабильность этих показателей, повысилась ли эффективность работы?
Последним шагом будет продолжение воздействия на наш стандарт. Обнаружилось падение качеств, смотрим кто отклонился от стандарта или в чем корневая причина и как мы можем изменить стандарт, чтобы такого падения избежать в будущем. Кто-то работает лучше чем все остальные, начинаем разбираться какое ноу-хау он внедрил в свою работу и вносим ее в стандарт. Выбираем в каких работах у нас еще наблюдается разброс показателей или запускаем цикл SDCA для них.
Ну и к нашему примеру с калькуляторами и наказаниями... Я не пользуюсь калькулятором, т.к. мне удобнее считать в редакторе электронных таблиц (сохраняются все промежуточные результаты, вбивая формулы, я могу в случае ошибки поправить входные данные и получить новый результат не перевводя все заново, возможность повторного использования и т.д.). Т.е. у меня есть ноу-хау которое повышает эффективность моей работы. Ко мне приходит специально обученный человек и размещает у меня на столе (скорее всего в зоне максимальной доступности, Кайдзен же борется с потерями, и время на то, чтобы достать калькулятор из стола, это потери) калькулятор. И вот лежит этот калькулятор, мешает мне, но я им не пользуюсь от слова совсем, при этом делаю свою работу быстрее и качественнее (меньше ошибок, за счет готовых формул и удобного контроля входных данных). И вот, вместо того, чтобы быть инструментов повышения эффективности, стандарт становиться средством позволяющим менеджеру пользоваться своей властью в вопросах в которых он не разбирается. А Кайдзен по поводу того, на кого надо ориентироваться в вопросах принятия решений как правильно ставит во главу не менеджера, а гембо (то где создается полезность для потребителя). И даже если внедрением практик Кайдзен достигается повышение эффективности достаточное для того чтобы убрать сотрудника из цепочки создания ценности, надо его не увольнять, а задействовать в других процессах, чтобы увеличивать возможности компании по удовлетворению внешнего спроса.