Анализ процессов при помощи карт Шухарта. Синопсис вебпосиделок Клуба иФБ.

(Из ленты 255 ступеней)

“Шухарт изобрел и опубликовал это правило в 1924 г.
С тех пор никто не сделал ничего лучшего.”

Что такое карты Шухарта?

Существует множество способов описания процессов: BPML, UML, IDEF, блок схемы, EPC, забытые структурно-информационные временные диаграммы и т.д. Они очень хорошо помогают, когда надо писать софт. Т.е. Когда процессы проанализированы, улучшены и теперь остается только их описать и передать программистам. Но часто нужно именно проанализировать процессы с целью их улучшения.

Кстати, если вы не собираетесь ничего улучшать, то и анализировать ничего не надо. Очень мощными инструментами анализа являются мыслительные инструменты Голдратта: Дерево Текущей Реальности; Грозовая туча, План преобразований и т.д. К сожалению пользоваться этими инструментами довольно сложно. Есть “кирпич” од Детмера “Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию“  Но это именно кирпич. И как бы он был не посложнее курса высшей математики. Карты Шухарта проще в использовании.

Выглядят они не так круто, как диаграмма построенная при помощи BPML но при кажущейся простоте это очень мощный инструмент.

Первое для чего применяются эти карты — это для определения находится ли процесс в статистически управляемом состоянии (здесь и далее употребляются термины Деминга, изучать которые лучше по книге Генри Нива “Пространство доктора Деминга / Организация как система”). Деминг говорит, что  “перевод процесса в статистически управляемое состояние первейшая и одна из главных задач операционного менеджмента”. К мнению величайшего менеджера 20-века имеет смысл прислушаться. Другой вариант определения это: “карты Шухарта это способ отличить общую причину вариаций от особой”. Очень часто ошибки в определении типа вариаций ведут к серьезным потерям. А иногда и к катастрофе. Очень наглядно это демонстрируется в эксперименте “Воронка и мишень”.

Немного истории

Уолтер Эндрю Шухарт (18 марта 1891 — 11 марта 1967) — всемирно известный американский ученый и консультант по теории управления качеством. В начале 20-го века разработал технику контроля процесса при помощи карт.
Эту технику доработал Эдвардс Деминг (14 октября 1900 — 20 декабря 1993). И в 1946 году впервые посетил Японию. Надо сказать, что тогда Япония выпускала товары весьма посредственного качества. И карты Шухарта стали одним из главных инструментов для экономического чуда. Один из менеджеров посетивший Японию писал: “Они просто одержимые. Они все измеряют и заносят на карточки”. За несколько лет японцы кардинально уменьшили вариации и достигли потрясающих результатов в качестве своей продукции и своих услуг. По этому поводу родилось несколько историй, баек, анекдотов. Про три бракованные детали упакованные отдельно. Или история про то как отличная американская лаборатория купила, разобрала и скопировала ксерокс. И все было отлично, только аппарат не делал копии. Интересные байки. Только вот они оказались не байками.

Деминг получил признательность в Японии и был совершенно неизвестен у себя в США.
Но к концу 70-х успехи Японии стали очевидны для всех. И тут, совершенно случайно, о Деминге сняли фильм. И Деминг получил известность в США. Много лет он колесил по стране, давая семинары. Карты Шухарта были одним из элементов “глубинных знаний”. Результат известен. Много лет США лидировали в мировом рейтинге. А экономика Японии из довольно посредственной стала звездой второй величины.

А что в России? Карты Шухарта находят широкое применение в различных отраслях промышленности и сфере услуг. Но не в IT. Аналитики от IT очень мало знают об этих картах. Хотя в последнее время лед начал трогаться. В значительной степени сказались лекции Макса Дорофеева и других энтузиастов в изучении теории вариаций. Но пока это капля в море.

Что любопытно. В 1999 году вышел ГОСТ Р 50779.42-99 “Статистические методы КОНТРОЛЬНЫЕ КАРТЫ ШУХАРТА”
Так что применение этих методов в госконтрактах вполне оправдано. И рекомендуется Клубом иФБ.

Применимость в IT

Да где угодно! Можно анализировать:

  • % 404-х ошибок;
  • % ошибок ушедших на прод (с ранжированием по критичности);
  • Объем стори поинтов, реализованных за спринт;
  • % найденных дефектов на партию в сотню стрипоинтов;
  • Число сверстанных страниц за 40 рабочих часов;
  • И еще много, много чего.

Что любопытно. Подходы к написанию SLA, которые сейчас используются в IT устарели в 1924 году. Ну, нельзя писать в SLA что звонок в коллцентр не должен продолжаться более 12 минут! От такого SLA будет только хуже.

Выглядит карта примерно так:

Внимание! Сигма (?) это не среднеквадратичное отклонение. Это “разлет”. Методика расчета есть в ГОСТ-е.

Что здесь измеряется? Да какая разница! Ну пусть будет процент 404-х.
Важнее вопрос, какие группы “плохие”? Вернее не так. Какие вариации вызваны особыми причинами и должны инициировать аудиторскую проверку.

Первая группа попадает под критерий “Шесть возрастающих или убывающих точек подряд”.  Очень подозрительно.

Третья группа сразу по двум критериям “плохая”: “Девять точек подряд в зоне С или по одну сторону от центральной линии” и “Четырнадцать попеременно возрастающих и убывающих точек”. Вроде все отлично, все точки группы в зеленой зоне, разброс минимален. Совсем подозрительно… Вспоминается история еще из времен СССР. Опытный рабочий поучает молодого: “Норма в смену — 10 деталей. Сегодня среда, ты сделал 13. Вот две спрячь. А если завтра сделаешь двенадцать, то еще две спрячь. Как зачем? В пятницу получка. Придешь ты в понедельник с бодуна. Сделаешь восемь, да три из них запорешь. Вот тут то заначка и годится. Брак втихую в мусорку и доложишь нормальные детали. А ты как думал? Это тебе не шахматы, тут думать надо чтоб под раздачу на профсоюзном собрании не попасть.” Участники посидел начали вспоминать похожие ситуации из современной жизни.
— А я такую ситуацию в производстве видел!
— А я в ритейле.
Кстати. Если списанные часы совпадают с оценкой трудоемкости, то какая-то черепашка… Ну вы поняли.

Четвертая группа находится за трехсигмовым пределом. Если б это был токарный цех, можно было бы предположить неисправность измерительного механизма. А для 404-х… Вдруг инженер вместо выборки инженер удаление из лога сделал? А может во время планового обслуживания, сайт с виртуалки аж на выделенный сервер переехал, “и тут все завертелось”.

А вот со второй группой все нормально. “Выброс” в пределах нормы. Ничего делать не надо.

Проблемы внедрения этого инструмента

Пожалуй здесь множество причин:

  • Это придумано не у нас.
  • Очень мало IT-шников знакомо с теорией вариаций. Для многих теорвер так и остался “игрой в бисер”. Теория вариаций? Это про шариках в урне? Да ну, у нас же реальный проект!
  • Боязнь нового. А вдруг после внедрения этого инструмента начальник станет ненужен? Или еще хуже, инструмент покажет его некомпетентность? Ведь до карт Шухарта начальник ругал за вторую группу и хвалил за остальные. А тут выясняется, что он за свою зарплату просто вредил. Нет, пусть все останется как было.

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

И еще немного кучей
Best practice:

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

Истории внедрений

  1. Я пыталась это внедрить для метрик производительности команды в скраме. Не зашло(
  2. Я применял карты Шухарта на автозаводе, результаты шикарные были — в 4 раза индекс воспроизводимости увеличился. Есть статья где-то. В ИТ не пробовал. От имени ИТ применял для других бизнес-процессов. Один раз был толк вроде, для складского учета.
  3. Когда-то давно строил такие карты по производительности тестировщиков. Правда тогда еще не знал, что это карты Шухарта. Выяснил, что после приведения процесса в статистически управляемое состояние (обучение сотрудников, подготовка стандартов и регламентов), выработка тестировщиков очень стабильна и позволяет хорошо предсказывать дату окончания тестирования. В дальнейшем неоднократно пользовался этим и предсказывал дату выхода в промышленную эксплуатацию с точностью в 5-10%.

Дополнительные ссылки

PS. Перепосты данного синопсиса крайне приветствуются. Правила:

  • Не спрашивать разрешения на перепост.
  • Не указывать линк откуда утащили синопсис.
  • Указать, что это “Синопсис вебпосиделок Клуба иФБ”.

Источник