Root cause analysis что это
Root Cause Analysis. Как минимизировать затраты на оптимизацию процесса тестирования.
Как часто мы сталкиваемся с проблемой, что проведя аудит процесса тестирования наши рекомендации носят достаточно общий характер. А еще хуже, когда мы внедряем новые решения, подходы, но они не дают нужного нам результата, что приводит к появлению недоверия со стороны руководства к руководителям отделов тестирования или аудиторам.
Очень часто основной причиной таких проблем является неправильное понимание менеджером поставленной задачи, и как следствие, неправильный выбор подхода для проведения аудита.
Для начала мы немного опустимся в основы процессов и попробуем понять, как должен существовать любой процесс.
Любой процесс, неважно, разработка это или тестирование, сопровождение, управление качеством и т.д., всегда должен быть цикличен. Существуют 4 основных подхода к работе с процессами, и самый популярный из них, это уже общепризнанный цикл Демминга. Именно на его основе строится работа процесса и все другие методологии, такие как DMAIC (6 сигм), IDEAL, EFQM, которые всегда говорят нам о том, что нужно не только требовать выполнение процесса, но и постоянно его анализировать и непрерывно совершенствовать. Эти модели позволяют нам понять, как мы должны работать с процессом, и самое главное, мы должны всегда видеть проблемы нашего процесса и стараться их решить.
Говоря о тестировании, существуют 2 основополагающих подхода к совершенствованию процесса тестирования, это MBI и ABI.
MBI или Model Based Improvement – подход к совершенствованию процесса тестирования, который основан на референтных моделях совершенствования процесса тестирования. Модели могут быть процесcные, такие как TMMi, TPI и контекстные, такие как STEP или CTP. Эти модели позволяют нам на основе практик строить наш процесс тестирования по конкретным шагам, тем самым развивая процесс тестирования равномерно и последовательно.
Но подходят ли нам такие модели для аудитов уже существующих процессов?
По моей практике скажу, что нет!
И основная проблема в том, что каждый процесс тестирования различается в зависимости от организации, что ставит по сомнение применение тех практик, которые дает нам модельный подход. Ну и многие специалисты, которые проводили именно аудит процесса тестирования возможно слышали фразу, ставящую в тупик все результаты вашей работы:
“Я могу сейчас взять ваши результаты, принести их в другую компанию и они тоже там будут применимы. Нет конкретики!”
И все это потому, что многие руководители, тест-менеджеры, особенно в России, не понимают различия между аудитом и оценка уровня зрелости процесса тестирования.
Аудит – это анализ текущего состояния процесса с целью решения конкретных проблем, не позволяющих процессу выполнять поставленные задачи.
Оценка зрелости – это анализ текущего состояния процесса с целью понимания его зрелости относительно общепринятых моделей процесса тестирования. Оценка уровня зрелости зачастую может не решать вообще никаких проблем, т.к. ее задача только оценить процесс.
Поэтому, говоря о модельном подходе MBI разумно его применять только для выполнения задач по оценке уровня зрелости процесса тестирования и написанию стратегии развития процесса тестирования на длительных срок. Во всех остальных случаях, а особенно, когда вам нужно решить какую-то проблему, MBI не поможет вам.
Для это существует подход ABI.
ABI или Analytical Based Improvement – это подход к совершенствованию процесса тестирования, который основывается на аналитических подходах анализа процесса.
Главное отличие модельного подхода от аналитического в том, что когда мы анализируем процесс по MBI, то мы анализируем процесс сверху вниз, то есть, сначала мы смотрим на процесс в целом, потому делим его на области, этапы и т.д., тем самым постепенно погружаясь в детали процесса. Аналитический подход работает наоборот, мы сначала погружаемся в самые детали нашего процесса и уже потом идя, как по цепочке, вверх, доходим до решения нашей главной проблемы.
Существуют несколько аналитических подходов к совершенствованию процессов, но я ни разу не видел их применение к процессу тестирования, т.к. они содержат именно модель анализа и могут быть применимы, в том числе, и в производстве фабрики, расследовании аварий, построении мостов и многом многом другом.
Задайте себе вопрос, как часто к вам приходил ваш руководитель со словами, у нас есть такая проблема в процессе и ее нужно решить? Что выделаете? Вы ищете причину этой проблемы и пытаетесь ее устранить. Но очень часто бывает так, что вроде вы решаете причину, но процесс все равно не работает как надо. И все это потому, что вы выбрали для решения не то узкое место!
Поэтому для проведения аудита процесса тестирования, с целью решения конкретных проблем стоит обратить свое внимание на Root Cause Analysis.
Root Cause Analysis – подход для выявление скрытых (внутренних) причин, которые позволяют определить, почему произошел тот или иной инцидент (проблема).
Таким образом RCA представляет собой древовидную иерархическую структуру зависимости причин, как с проблемой, так и между собой.
Стандартно, к проблемам процесса тестирования, я отношу только те проблемы, которые связаны с классическим треугольником – цена/качество/сроки. Почему это так? Любой процесс ИТ, в том числе и тестирование, должен обеспечивать бизнес организации. ИТ – это помощник бизнеса, поэтому, когда вам бизнес говорит, что они не успевают внедрять все запланированные фичи, продукты, то это не проблема бизнеса (что они генерят много задач), а проблема тестирования. Все остальное, что не связано с этим “треугольником проблем” является причинам возникновения проблем, которые зачастую бывают непонятны и скрываются от нас.
Процесс аудита по RCA состоит из 5 этапов:
Итак, что такое проблема? Проблема – это вопрос или задача, требующая разрешения. Проблемы в нашей работе мы находим постоянно, критичность проблемы мы определяем симптомами, т.е. признаками существования проблемы.
Допустим, мы идентифицировали проблему, как постоянный сдвиг сроков внедрения релиза. Признаком существования в проблемы в данном случае может быть систематичность ее возникновения. Я думаю, вы понимаете разницу, один раз у вас произошел сдвиг за 6 релизов, или уже 6-й раз подряд. Во втором случае проблема уже начинает носить критичный характер. Решать все проблемы невозможно, поэтому если у Вас есть большое количество проблем, то вы можете выбрать наиболее важные из них по степени влияния и частоте возникновения.
Имея проблему, мы можем приступать к поиску вероятностных причин. Самый простой способ определения причин – метод брейншторма всех вовлеченных в процесс участников. Вы можете собрать со всех специалистов их мнение относительно того, какие они видят причины возникновения проблемы и после этого выбрать из них наиболее часто называемые сотрудниками.
Следующий и очень важный шаг – это анализ вероятностных причин.
Существуют несколько подходов к проведению анализа, таких как диаграммы зависимостей или рассеивания, аффинная диаграмма, но самым распространенным подходом к проведению анализа является диаграмма Парето.
Путем брейншторма мы определили 5 основных причин возникновения проблемы, связанной со сдвигом сроков внедрения. После этого наша задача понять, какие из этих причин наиболее серьезно влияют на нашу проблему. Используя принцип Парето мы определяем количество человеко-дней, которые мы теряем из-за возникновения той или иной проблемы.
В результате анализа мы видим, что только первые 2 причины на 60% влияют на сдвиг сроков внедрения, что существенно больше, чем остальные 3 причины суммарно.
Следующим этапом является проведение причинно-следственного анализа (ПСА) с целью выявления коренных причин и их зависимостей друг с другом. Для этого используется диаграмма причинно-следственного анализа, основная задача которой заключается в том, что идя от проблемы по цепочке мы погружаемся на каждом уровне в причины возникновения причин, тем самым доходя до истинной или коренной причины возникновения проблем. В результате, решив коренную причину, мы автоматически решаем все остальные наши причины, что приводит к минимизации влияния или полного устранения нашей проблемы.
Ну и заключительный этап – это выработка решений. Проведя анализ RCA решения будут уже вполне понятны, но очень важно, чтобы эти решения действительно были нацелены на конкретную причину и были выполнимы всей командой, на которую ложится их реализация.
Наиболее понятной книгой, рассматривающей модель RCA, я считаю Андерсон Бьерн — «Анализ основной причины. Упрощенные инструменты и методы», в которой на обычных жизненных примерах рассматриваются различные возможности применения модели RCA.
Поэтому, если Вам поставили задачу оптимизировать ваш процесс тестирования, но для этого вам нужно решить какие-то текущие проблемы, то вам нужен аудит с применением ABI, т.к. именно ABI позволяют точечно решать проблемы и любые ваши рекомендации будут носить не рекомендательный характер, а детальный, направленный на оптимизацию именно для вашего проекта или процесса.
5 инструментов для анализа первопричин (RCA), которые помогут вам улучшить тестирование и QA
Привет, Хабр! В рамках набора учащихся на курс «QA Lead» подготовили перевод статьи.
Приглашаем также всех желающих зарегистрироваться на открытый вебинар «Организация процесса тестирования в agile и не agile-командах». На вебинаре участники вместе с экспертом рассмотрят вопросы:
1. Организация процесса работы в waterfall проекте.
2. Организация процесса тестирования в scrum команде.
3. Организация процесса работы в масштабируемых agile-подходах.
4. Организация процесса тестирования в команде, работающей по kanban методу.
Необходим отчет о результатах RCA, чтобы найти фактическую причину проблемы, это поможет восстановить основные системы и процессы и решить проблему с помощью постоянного, а не временного решения.
Что такое RCA?
Это мера контроля качества, которая позволяет выяснить, что произошло, понять, почему это произошло, а затем начать настройку процесса так, чтобы уменьшить вероятность повторения одной и той же проблемы.
RCA работает на основе того, что все системы и события взаимосвязаны. Что-то одно в определенной области триггерит что-то другое в другой области. Способность отслеживать эти взаимосвязанные триггеры позволяет человеку видеть, с чего начиналась проблема и как она становилась системой, которая сейчас является основной проблемой. RCA ищет паттерны, находит ошибки, которые скрыты внутри самой системы. Он эффективно показывает первопричину или несколько причин существующих проблем.
RCA определяет, был ли дефект вызван ошибкой при тестировании, ошибкой при разработке или, возможно, требованием или ошибкой при проектировании.
Более того, крайне важно выяснить, чтобы релизы, выпущенные позже, были бы без дефекта. Ошибка при проектировании позволяет любому человеку просмотреть проектную документацию и внести коррективы, как если бы дефект был вызван ошибкой при тестировании. Это пример факторного анализа причинно-следственных связей.
Инструменты RCA
Наличие соответствующих инструментов RCA поможет вам следить за процессом, систематически исследуя факторы, способствующие возникновению глубинных проблем.
Поиск истинной первопричины проблем с помощью хорошего инструмента для анализа означает, что вы не просто пытаетесь «потушить пожар от первоначальных симптомов».
Вот пять методов RCA, которые можно использовать в качестве инструментов для выявления первопричины проблемы.
8D RCA
Этот процесс нацелен на поиск потенциальных первопричин. Он сужает круг причин до фактической, затем создает процессы сдерживания и использует корректирующую меру, чтобы предотвратить повторение проблем. Он способствует систематическому изменению и решает непосредственную проблему вместе с другими, которые могут возникнуть в результате систематического сбоя. Этот процесс последователен, прост для команды в изучении и очень подробен при применении.
Сосредоточение внимания на команде, а не на индивидууме также приносит пользу. Эта методология улучшает качество и надежность и работает над потенциальными проблемами будущего, прежде чем они погубят продукт. Ее следует использовать для оценки:
Безопасности и регулярных обнаруженных проблем
Поступающих жалоб клиентов
Ситуаций, когда гарантийные проблемы показывают более высокую частоту отказов, чем ожидалось.
Неприемлемых уровней внутреннего брака и низкой производительности или полных отказов при тестировании.
Инструмент Исикавы для RCA
Инструмент Исикавы — Диаграмма Исикавы или диаграмма «рыбьей кости».
Как бы странно ни звучало название, оно описывает внешний вид анализа на бумаге. В самом простом варианте, это просто причинно-следственная диаграмма. Она также называется «Диаграмма Исикавы».
Этот инструмент помогает при «брейнсшторминге» как части процесса анализа в попытке выявить элементы, которые вызвали проблему. По сути, это дерево первопричин в обратном направлении. Схема дерева используется для того, чтобы сузить список причин, а «рыбья кость» расширяет его. Диаграмма рыбной кости используется для изучения причин и следствий. Проблема помещается на «голову рыбы», а затем на маленьких костях различных категорий записываются потенциальные причины.
Она позволяет взглянуть на потенциальные причины, которые в противном случае могли бы быть упущены. После четкого определения проблемы командой создаются такие категории, как поставки, оборудование, персонал и т.п. Затем вы брейнштормите о том, почему произошло определенное событие. Диаграмма «рыбная кость» держит в центре внимания причину, а не «симптомы». Ценность диаграммы в том, что она позволяет членам команды глубоко копнуть и понять проблему, чтобы ее можно было адекватно решить в настоящем и будущем.
Техника RCA 5-Почему
Этот процесс осуществляется путем формирования межфункциональной команды для наличия различных уникальных точек зрения. Вам нужно четко определить проблему, чтобы не было сомнений в том, что исследуется. Пусть кто-нибудь возглавит команду и будет фокусировать ее на проблеме. Начните спрашивать «почему?» и анализировать ответы до тех пор, пока не найдете первопричину проблемы.
Будьте открыты к тому, что, возможно, причина будет не одна. Что возможно вам нужно будет принять определенные меры по устранению проблемы, как только будет найдена ее причина. Проверяйте, была ли устранена проблема и если нет, начните процесс заново.
5m, 6m, и E Анализ RCA
Эти инструменты для анализа первопричины очень схожи. Все эти анализы: 5М, 6М и E имеют похожие категории для анализа: Люди, Инструменты, Измерения, Материалы, Методы и Окружение. Эти элементы содержат ответы в случае возникновения проблемы или изменений в процессе.
Существуют вопросы, которые необходимо задать, на которые необходимо ответить и оценить для того, чтобы сузить область, в которой может находиться первопричина. Это может применяться к тестированию программного обеспечения, поскольку проблемы могут исходить не только от внутренней программы. Является ли это проблемой пользователя? Программирования? Аналитики? Человеческой ошибкой? Метода или это просто глюк, который каким-то образом стал частью программного обеспечения из внешнего источника?
Эти 5-6 пунктов структурированы таким образом, чтобы назвать и связать отношения между событиями, пользователями и проблемами, которые привели к сбою или инциденту.
Как и в других протоколах RCA, этот протокол используется для выяснения и устранения неисправности, которая вызвала конкретную проблему. Это протокол помогает снизить трудозатраты и экономические потери, выявляя первопричину, и таким образом, облегчая «симптомы», которые сигнализировали о проблеме. Это, в свою очередь, помогает предотвратить повторные сбои.
RCA Software
Для анализа и решения проблем имеются различные программы RCA. Эти программы собирают данные и используют их в помощь командам при проведении различных анализов, что способствует эффективному управлению качеством. Данные анализы:
Исикава ( диаграмма рыбной кости)
Gap-анализ (анализ разрывов)
Анализ случаев (accident)
Анализ причин и последствий отказов (FMEA)
Преимущества софта RCA заключаются в том, что оно может значительно упростить анализ причин, записывая любые и все инциденты и данные анализа причин в одном месте в веб-пространстве, чтобы их можно было совместно использовать в доступном виде.
После того, как софт определяет первопричину, можно приступать к корректирующим действиям, чтобы устранить основную проблему и снизить риск.
Сотрудники могут быть назначены для работы над определенными задачами, чтобы удостовериться, что все исправлено и переделано. Программное обеспечение может помочь уменьшить количество подобных инцидентов, а также снизить затраты и частоту возникновения инцидентов, устранив первопричину.
Выводы
Использование любого из вышеперечисленных инструментов RCA может обеспечить более качественное тестирование и надежную поддержку QA (обеспечения качества), когда команда сталкивается с «симптомами проблемы» и нуждается в определении первопричин для устранения проблемы.
Все эти инструменты просты в понимании и логичны в том, как они решают различные проблемные ситуации.
Очень важно знать то, как использовать один или все вышеперечисленные инструменты RCA, когда дело доходит до создания команды, которая может не только создать, но и устранить, а также минимизировать последствия. Использование этих инструментов вместе с поддержкой коллег, как часть процесса RCA, открывает дверь к получению точных ответов, улучшению процесса и общему улучшению качества продукта.
Root Cause Analysis как метод предотвращения багов
Привет! Мое имя Юра Гомон, я BA Tech Lead в NIX и вот уже 8 лет занимаюсь бизнес-анализом, помогая реализовывать веб- и мобильные решения для бизнеса, а также автоматизировать бизнес-процессы. Мое имя кажется Вам знакомым, т.к. недавно я опубликовал на Хабре свой BA Digest.
Цель статьи – напомнить бизнес-аналитикам о методе Root Cause Analysis (далее – RCA) и поделиться опытом его применения для предотвращения багов.
В сети очень много информации по RCA, потому не хочу повторяться в отношении теории. Если Вы еще не использовали Problem-solving техники и, в частности, RCA, рекомендую ознакомиться с материалами по ссылками ниже, а уже затем переходить к статье:
A Brief History of Root Cause Analysis. Истоки появления техники, описание шагов, смежные подходы.
В своей статье, планирую поделиться кейсами из практики, где RCA очень помогло не делать ошибок в будущем либо предотвратить потенциальные последствия.
Кейс первый – о политиках
В ливной enterprise-системе на 200+ пользователей все было хорошо: жили – не тужили, работали три года после релиза. Но в один прекрасный день при попытке перейти по ссылке в систему вместо желаемого результата пользователей ждало угрожающее сообщение…
Аналог сообщения, которое увидели пользователи. Оригинал не сохранился 🙂 Источник: Bytebitebit
Разумеется, это вызвало, мягко говоря, недоумение. В глазах пользователей работа оказалась заблокированной. Мало того, что угроза кражи паролей, так еще и предложение продолжить, но уже unsafe. Страшно.
Как только о проблеме стало известно, ответственные как могли успокоили пользователей и пообещали быстро все выяснить и поправить. Первым делом, они помчались разбираться в местную поддержку, где состоялся примерно такой диалог:
– Почему пользователи видят эту страницу?
– Посмотрим… А-а, так это заэкспайрился SSL-сертификат, продлим, и все будет в порядке.
– А почему это не сделали заранее?
– Никто не поставил напоминание, а три года быстро пролетели.
– Резонно. Как думаете, почему не поставили?
– Хм, по-моему, это первый проект, где была потребность в использовании SSL. Это уже после вас стали сертификаты покупать и другим.
– Так это и в других системах может случиться?
– Пожалуй, пойдем везде проверим, поставим напоминалки и в гайдлайны внутренних систем добавим, что надо не забывать это делать.
В итоге ошибку быстро исправили – и работа возобновилась. Пользователей обняли, пообещали новых вкусных фич и, отдышавшись, пошли делать обещанное.
Что из этого стоит вынести? Ответственные, те, кто знаком с методами RCA и Five Whys, не только исправили ошибку, но начали задавать вопросы, чтобы найти истинную причину. Как только это случилось, проблему превентивно закрыли везде, где она могла произойти, то есть предотвратили баг безопасности в других системах. Косвенно это привело к тому, что в компании стали уделять еще больше внимания безопасности.
Кейс второй – о людях
Мой приятель, ресурсный менеджер из одной украинской компании, поделился со мной одним любопытным случаем. Подбивая статистику в очередном проекте, он обратил внимание, что количество багов стало увеличиваться. Менеджер обратился к техлиду за деталями и обнаружил следующее: большинство ошибок сделал один и тот же Junior-разработчик. Это оказалось не случайностью, а тенденцией в последние несколько итераций. Специалист стал пропускать требования, в коде появились «детские» ошибки. При этом ранее не было никаких нареканий.
Менеджер вызвал человека на разговор, но в силу замкнутости последнего это не помогло докопаться до сути. Максимум, что узнал – «нет настроения работать», «сильно устаю». Чтобы все-таки разобраться с этом ситуацией, менеджер использовал технику RCA, и вот что получилось:
Менеджер задокументировал ключевые поинты разговора с человеком – названные им причины.
Предположил варианты со своего опыта.
Собрал доказательства существованию причин, проанализировал.
Попытался связать разные причины в одну систему, поскольку редко бывает так, чтобы причина была только в чем-то одном.
Граф причин проблемы, воссозданный со слов рассказчика
Большинство причин нижнего уровня можно было решить быстро, а некоторые догадки (овертаймы, нежелание ментора менторить) и вовсе не подтвердились. Однако глаз менеджера зацепился за гипотезы, выделенные красным, так как их не получилось проработать из-за скрытности человека и недостатка информации «на поверхности». Менеджер продолжил изучать причины, после чего выстроил следующий таймлайн событий:
Сначала человек стал засиживаться в офисе после работы почти каждый день.
Затем примерно в одно и то же время стал слишком часто залипать в инстаграм и фейсбук, что было хорошо видно на его мониторе, а также много выходить поговорить по телефону.
Следом вместо домашней еды он стал питаться подножным кормом.
Менеджер проанализировал «улики» расследования и вызвал человека на прямой разговор после работы, где уже благодаря паре бокалов виски узнал, что у специалиста дома проблемы, все идет к расставанию с девушкой, а работать в таких условиях он эффективно не может. Узнав это, менеджер предложил сотруднику отгул на несколько дней, чтобы тот имел возможность осмыслить проблему в спокойном рижиме и придумать, что делать дальше. После этого разработчик вернулся уже чуть более спокойным и положение немного наладилось.
В течение следующих пары месяцев разработчик брал отгулы еще несколько раз, а менеджер оказывал моральную поддержку. Не советом, но помогал переключаться на что-то позитивное – настолки, совместные обеды и так далее. В итоге человек получил время и внутренний ресурс для решения проблем дома, а затем вернулся в свой нормальный рабочий ритм, и более к нему вопросов не возникало.
Кейс третий – о работе с требованиями
Когда БА входит в проект, который идет уже некоторое время, первая задача – разобраться с требованиями, то есть провести аудит. Об этом кейсе я делал доклад на NIX Multiconf в 2019 году. Сегодня раскрою некоторые детали того случая с точки зрения применения RCA: как искали причины того, почему в проекте начало появляться много багов.
В первый же день я запросил доступ к каналам коммуникации, описанию стейкхолдеров, команд и процессов, по которым жил проект, так как по опыту это места, где стоит искать корни проблемы в первую очередь. В течение недели я получил нужную информацию, категоризировал ее и проработал проблемы на пару уровней вниз, используя Five Whys. Ниже представлен отрывок из перечня проблем, которые удалось выявить:
Коммуникация
Невозможно было найти ответ или решение через время. Обсуждение требований велось в Asana, Slack, JIRA, через почту, в онлайн- и офлайн-документах. Среди всех источников не было единого:
клиент писал там, где ему было удобно в текущий момент;
остальные команды не поддержали нашу критику, поскольку им «и так норм»;
бюджет на ведение SRS, митинг-минуток и структурирование информации не выделялся.
Наша команда не получала ответов вовремя. Другие команды не понимали наших вопросов:
если не пинговать, то могли забы(и)вать нам ответить;
пинговать из-за большой разницы с двумя другими таймзонами было затруднительно.
Стейкхолдеры
Наша команда получала разную информацию из разных источников.
Не было обмена решениями с другими командами:
не было четких зон ответственности в плане шаринга информации;
структурированные минутки и синки команд требовали времени, которое не хотели выделять.
Клиент часто менял требования / принимал решения. Настолько часто, что одна команда успевала получить одно, а вторая – уже другое:
у клиента не было четкой бизнес-идеи, он старался быстро адаптироваться под нужды целевой аудитории;
клиент хотел реализовать как можно больше фич, невзирая на общий концепт приложения, а также удовлетворить всех пользователей;
на заказчика давили инвесторы, которые требовали постоянного увеличения аудитории и финансовых результатов.
Уже этих причин вполне достаточно, чтобы понять масштаб трагедии, источник потенциальных дефектов. Безусловно, с нашей стороны также были проблемы. Например, техлид выполнял роль БА и пытался кое-как зафиксировать требования в рамках своей загрузки, а значит, недостаточно ревьювил более молодых разработчиков. Однако больше всего проблем было из-за хаоса в коммуникации, отсутствия продуктовой стратегии, не фиксирования требований в достаточном объеме. Все это привело к невозможности планировать архитектуру и писать код требуемого качества.
Не дожидаясь правок по нескольким десяткам других пунктов, ЛПРы со стороны команды реорганизовали перечень каналов связи и оставили всего три: обсуждение идей велось в Asana, дизайна и требований – в соответствующих каналах Slack, там же создали канал для общих вопросов. Кроме того, все решения по каждой функции стали фиксировать в JIRA, куда перевели только те таски, которые должны были идти в разработку. В дополнение ввели жесткие правила по неизменности скоупа в рамках спринта (либо полной приостановке и планированию спринта с нуля) и длительности спринта.
В итоге чудесным образом количество дефектов стало резко уменьшаться. ЛПРы воодушевились успехом и продолжили вносить изменения, которые также несли положительный результат. Но, как оказалось, положительным он оказался только для нас, т. к. вскоре клиент попрощался с нами под предлогом того, что не был готов к «такому уровню бюрократии» 🙂 Если заинтриговал, то в докладе по ссылке выше больше подробностей.
И что?
Есть вещи, которые вот уже 8 лет, с момента как я вошел в IT, я не перестаю «евангелизировать», поскольку нахожу им применение либо вижу отражение в окружающем мире. Среди них философия «пиши-сокращай», модель Кано, принцип Парето, think out of the box и так далее. Как вы уже догадались, RCA входит в этот перечень. А все потому, что важнейшая, если не первичная задача БА заключается в том, чтобы понять «почему». Будь то проблемная функция в системе, ошибки в бизнес-процессах, нюансы человеческого поведения, негативные события вокруг – все имеет глубокие корни.
Нередко вопросы «почему» спасают продукт от фичи, которая абсолютно ему не нужна, от принятия решения, которое приведет к негативным последствиям либо вызовет баг в системе. А если не спасет, то хотя бы поможет подготовиться к возможным трудностям и сделать так, чтобы больше не наступать на те же грабли.
RCA, конечно же, не «серебряная пуля», но инструмент, который однажды сможет предотвратить очередную проблему. Многие из нас пользуются RCA интуитивно, поскольку любознательность присуща людям, работающим в IT. Однако, использование техники на полную выведет вас на новый уровень при поиске причин ошибок.