Root cause analysis — когда его нужно делать? Как получить максимальный эффект от этой практики? Как делать анализ?
Root cause – основная (главная) причина, причина проблемы/ошибки такая, что если ее устранить, то проблема/ошибка устранится или ее последствия уменьшатся.
Root Cause Analysis (RCA) – процесс нахождения основных причин. Это структурированная пошаговая технология для нахождения настоящих причин проблем/ошибок и решений для них. Целью RCA является найти такие решения, которые предотвратили бы появление подобных проблем/ошибок в будущем. Процесс анализа должен основываться на фактах, цифрах, изменениях, а не на ощущениях, чувствах, эмоциях.
Примеры случаев, когда необходимо инициировать RCA:
- Серьезная ошибка/дефект в продукте
- Повторяющаяся ошибка/проблема
- Заказчик недоволен и явно запрашивает RCA
- Проблема найдена на стороне заказчика и пропущена всеми нашими Quality assurance процедурами
- Faulty fix (своим фиксом внесли новую багу)
- Большой lead time или cost per TR (больше таргета от заказчика)
Важно следовать следующим принципам: принять тот факт, что люди совершают и будут совершать ошибки, необходимо построить устойчивый к ошибками процесс. Когда ошибка случилась, не пытаться искать виноватого, попытаться найти ошибку в процессах.
Необходимо задавать правильные вопросы:
- Что позволило ошибке случиться?
- Что может предотвратить ее в будущем? (а не «кто виноват?»)
Ниже описан процесс RCA:
Очень важно опираться на факты, а не на домыслы и ощущения, поэтому, первый большой этап — это сбор фактов. Сначала необходимо описать весь процесс, в ходе которого была совершена ошибка. Например, бага пропущена всеми Quality assurance процедурами и найдена на стороне заказчика, описываем все стадии, через которые проходят изменения кода (см. картинку ниже). Ищем, в какой момент, в процессе чего (решения бага, имплементации фичи) бага была внесена в код. Привлекаем к RCA всех людей, которые участвовали в процессе.
Вторая часть процесса — проанализировать каждый этап и понять, где проблема случилась и на каком этапе ее можно было предотвратить или обнаружить. В нашем примере, анализируем все этапы изменения кода: анализ, review, различные уровни тестирования. Процессы делятся на preventive, когда проблему можно было предотвратить (в примере это этап анализа, когда еще не была внесена в код) и corrective, когда проблема уже внесена, и мы могли ее обнаружить и поправить (в примере это код ревью и различные уровни тестирования). Эффективнее находить импрувменты на preventive шагах, придумать импрувменты, которые помогут предотвратить появление/внесение подобной проблемы в будущем.
По каждому шагу задавайте вопрос «почему?» до тех пор, пока не найдете настоящую причину проблемы. Проверочный вопрос: если бы тогда, когда проблема была внесена, этой причины бы не было, проблема случилась бы или нет? Если нет, то поздравляю, вы нашли root cause. Далее необходимо придумать решение.
- Фокусируйтесь на предотвращении подобных проблем в будущем, а не на поиске виноватых или на решении конкретной проблемы
- Ищите проблемы в процессах
- Автоматизируйте по максимуму
- Должно быть понятно, как решение помогло бы предотвратить проблему
- Всегда есть несколько причин, фокусируйтесь на основных, а не второстепенных
- Из предложенных решений выберите Quick wins
- Определите ответственного и срок выполнения
- Как можно увеличить эффект от решения? (применить в другой области, в другом отделе, в другом процессе)
- Сделайте причины и решения видимыми, чтобы можно было их учесть при последующих анализах
Обязательно фиксируйте результаты RCA в реестре. И регулярно обсуждайте статус предложенных и взятых в работу импрувментов. Иначе процесс не заработает. Помните plan–do–check–act цикл: планируйте, внедряйте, проверяйте результат, если результат не устраивает — действуйте, проводите анализ заново. И так далее, до тех пор, пока результат вас не устроит.
