Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Деминг, Шухарт и здравый смысл

Жили-были такие себе два замечательных ученых — Вильям Деминг и Волтер Шухарт.
Шухарт родился в 1891, а его основные значимые работы приходятся примерно на конец 30-х — начало 40-х годов. Крайне образованный человек, доктор наук в Беркли — физик, инженер, много самостоятельно занимался статистикой, и в итоге известен нам как отец концепции статистического контроля качества, которая в восьмидесятых вылилась в методологию «шесть сигма».

Деминг был также настоящим «человеком науки» — математик, физик, и тоже известен своими достижениями в области статистики в применении к управлению производством. Деминг был на десять лет моложе Шухарта, и основные его работы пришлись на 50-е годы.

Они познакомились в 1927 году, в легендарных Bell Telephone Laboratories, и Шухарт оказал сильнейшее влияние на Деминга свими идеями, которые в дальнейшем и развивал Деминг. Надо сказать, что развивал он их не просто так, а в Японии, где впитал также и идеи «бережливого производства» (успешно перелицованные для IT они и сейчас весьма популярны как одна из Agile методологий — Lean software development). Деминг произвел буквально революцию в управлении индустриализированными предприятиями по всему миру. За свои работы он удостоен национальной медали США в области технологий, орденом Благодатного Сокровища (в Японии), и даже — медали имени Шухарта. Впрочем, он также стал «именем» другой награды — медали имени Деминга.

В общем, я надеюсь, что это достаточно убедительно, чтобы с интересом отнестись к его работам (в частности — знаменитым «14 принципам Деминга» и «7 смертельным болезням»).

Помимо огромного количества интереснейших идей, каждая из которых достойна изучения, я хотел заострить внимание на простой, казалось бы, идее, которая сейчас называется «циклом Деминга». Ирония заключается в том, что идея изначально называлась «циклом Шухарта», но Деминг считал ее крайне важной, и всегда продвигал ее, в результате чего она «переименовалась».

Что же это за идея?

«PDCA („Plan-Do-Check-Act“) циклически повторяющийся процесс принятия решения, используемый в управлении качеством. Также известен как Deming Cycle, Shewhart cycle, Deming Wheel, или Plan-Do-Study-Act.»

Планирование — установление целей и процессов, необходимых для достижения целей, планирование работ по достижению целей процесса и удовлетворения потребителя, планирование выделения и распределения необходимых ресурсов.

Выполнение — выполнение запланированных работ.

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

Воздействие (управление, корректировка) — принятие мер по устранению причин отклонений от запланированного результата, изменения в планировании и распределении ресурсов.

Итак, это очень простая идея о том, как именно следует управлять процессом (производства). Предлагается делать это в четыре этапа: запланировать изменение (поставить цель), провести мероприятия по ее достижению, изучить полученные результаты, и на основе сделанных выводов внести коррективы (ведь результаты, вероятно, отличаются от цели), а именно — запланировать изменение...

Всем, кто слушал курс автоматизированного управления в университете в голову, конечно же, приходит концепция обратной связи, на которой и стоит все автоматизированное (да и неавтоматизированное) управление.

Искушенные в Agile-методологиях люди в этом месте могут справедливо обратить внимание на то, что это же один-в-один структура спринта в итеративной разработке — мы делаем Planning meeting, разрабатываем, делаем Demo meeting, и делаем Retrospective meeting — это ли не то, о чем говорил Шухарт и так ценил Деминг?

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

1. «Используйте опыт: Рассмотрите проблему и попытайтесь осмыслить её. Найдите известные ранее объяснения. Если это новая для вас проблема, переходите к шагу 2.

2. Сформулируйте предположение: Если ничего из известного не подходит, попробуйте сформулировать объяснение, изложите его кому-то другому или в своих записях.

3. Сделайте выводы из предположения: Если предположение (шаг 2) истинно, какие из него следствия, выводы, прогнозы можно сделать по правилам логики?

4.Проверка: Найдите факты, противоречащие каждому из этих выводов, с тем чтобы опровергнуть гипотезу (шаг 2) . Использование выводов (шаг 3) в качестве доказательств гипотезы (шаг 2) является логической ошибкой. Эта ошибка называется «подтверждение следствием»

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

Работать без цели — означает автоматически исключить также и делание выводов, если не с чем сравнивать, о чем можно говорить? И тем не менее, это происходит гораздо чаще, чем можно себе представить. Вы cами, уверен, знаете массу примеров управленческих решений, основанных не на достижении определенной цели. На чем же тогда? О, масса вариантов: «потому что это хорошо», «потому что так делают конкуренты», «потому что все так делают», «просто поверь мне — так будет лучше». В принципе — это тоже цели, только другие, слабо связанные с сутью процесса разработки. Делать так же, как конкуренты, потешить самолюбие менеджера, удержаться на этой работе подольше, получить годовой бонус... Сюда же относятся цели, сформулированные в неправильной форме, например, неизмеримые, недостижимые, неограниченные во времени, и так далее, искусство ставить цели — отдельная важная тема. Если вы не уверены, что у вас «хорошие» цели — попробуйте why/because анализ для того, что вы делаете, многие находят его крайне полезным занятием.

Что происходит, когда цель поставлена, но нет конкретных действий по ее достижению? Что ж, возможно, цель будет достигнута. Случайно — ведь в компании происходит много процессов, может быть так получится что и да. Есть же, в конце концов любители идей «материальных мыслей» и всякого прочего «транссерфинга реальности». Что ж, если всем мысленно сосредоточится на цели и думать о ее реальности каждый день — это может и приведет к ее реализации. Например, если огласить на корпоративном митинге, что «рост профессионализма сотрудников» является целью, и не предпринять никаких конкретных шагов для этого... рано или поздно многие из них поумнеют, наверное. Это вообще свойственно людям с течением времени.

Что бывает, когда нет сбора результатов? Это бывает крайне часто, кстати. KPI (Key Performance Indicator) — а именно в этом их задача, измерять результаты экспериментов над процессом, могут быть составлены неправильно, измерены неправильно, да и просто отсутствовать. Мы хотим чего-то добиться, для этого мы прилагаем такие-то усилия, но... не можем понять, приближает ли это нас к цели, как задумано? Точнее, не можем понять, как это понять. Что померять? Что свидетельствует о приближении к цели? Как понять, что вы делаете ошибку и перестать ее делать?

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

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

LinkedIn



4 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Приятно удивлен содержанию статьи.

По долгу настоящей работы мне приходится очень плотно сталкиваться со стандартами серии ISO 9000 (по сути формальные требования основанные на принципах Деминга) и мне, как человеку, который пытается перейти в IT, было обидно расходовать и без того ограниченный ресурс времени. А оно вон как оборачивается, т.е. принцип PDCA актуален и в IT. В который раз убеждаюсь, что лишних знаний не бывает.

По содержанию статьи:

Сюда же относятся цели, сформулированные в неправильной форме, например, неизмеримые, недостижимые, неограниченные во времени, и так далее, искусство ставить цели — отдельная важная тема.

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

в частности — знаменитым «14 принципам Деминга»

Ну и в заключении не могу не дать ссылку на принципы, с которыми я временами соглашаюсь.

Интересная статья, я бы мог бы её отнести в общем к теории управления будь ли чем.

Так все и работает.

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

Оценил действия, внести поправки к существующему циклу действий.

Но все сложное с опытом становится простым, количество перейдет в качество.

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

Как пишет по этому поводу доктор Голдратт — Common sense isn’t common!

Мощные идеи всегда вроде бы простые, но применять их на деле оказывается не так уж и легко...

Чернобыль не помог сделать выводы, выводы сделает Фукусима

Підписатись на коментарі