Привет! Мое имя Юра Гомон, яBATech Lead вNIX ивот уже 8лет занимаюсь бизнес-анализом, помогая реализовывать веб- имобильные решения для бизнеса, атакже автоматизировать бизнес-процессы. Мое имя кажется Вам знакомым, т.к. недавно я опубликовал на Хабре свой BADigest.

Цель статьи напомнить бизнес-аналитикам ометоде Root Cause Analysis (далее RCA) иподелиться опытом его применения для предотвращения багов.

В сети очень много информации по RCA, потому не хочу повторяться в отношении теории. Если Вы еще не использовали Problem-solving техники и, в частности, RCA, рекомендую ознакомиться с материалами по ссылками ниже, а уже затем переходить к статье:

• ABrief History ofRoot Cause Analysis. Истоки появления техники, описание шагов, смежные подходы.

• How toConduct aRoot Cause Analysis. Разбор техники напримере.

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

Кейс первый ополитиках

Вливной enterprise-системе на200+ пользователей все было хорошо: жили нетужили, работали три года после релиза. Новодин прекрасный день при попытке перейти поссылке всистему вместо желаемого результата пользователей ждало угрожающее сообщение

Аналог сообщения, которое увидели пользователи. Оригинал несохранился :) Источник:Bytebitebit

Разумеется, это вызвало, мягко говоря, недоумение. Вглазах пользователей работа оказалась заблокированной. Мало того, что угроза кражи паролей, так еще ипредложение продолжить, ноуже unsafe. Страшно.

Как только опроблеме стало известно, ответственные как могли успокоили пользователей ипообещали быстро все выяснить ипоправить. Первым делом, они помчались разбираться вместную поддержку, где состоялся примерно такой диалог:

Почему пользователи видят эту страницу?
Посмотрим А-а, так это заэкспайрился SSL-сертификат, продлим, ивсе будет впорядке.
Апочему это несделали заранее?
Никто непоставил напоминание, атри года быстро пролетели.
Резонно. Как думаете, почему непоставили?
Хм, по-моему, это первый проект, где была потребность виспользовании SSL. Это уже после вас стали сертификаты покупать идругим.
Так это ивдругих системах может случиться?
Пожалуй, пойдем везде проверим, поставим напоминалки ивгайдлайны внутренних систем добавим, что надо незабывать это делать.

Витоге ошибку быстро исправили иработа возобновилась. Пользователей обняли, пообещали новых вкусных фичи, отдышавшись, пошли делать обещанное.

Что изэтого стоит вынести? Ответственные, те, кто знаком сметодами RCA иFive Whys, нетолько исправили ошибку, ноначали задавать вопросы, чтобы найти истинную причину. Как только это случилось, проблему превентивно закрыли везде, где она могла произойти, тоесть предотвратили баг безопасности вдругих системах. Косвенно это привело ктому, что вкомпании стали уделять еще больше внимания безопасности.

Кейс второй олюдях

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

Менеджер вызвал человека наразговор, новсилу замкнутости последнего это непомогло докопаться досути. Максимум, что узнал нет настроения работать, сильно устаю. Чтобы все-таки разобраться сэтом ситуацией, менеджер использовал технику RCA, ивот что получилось:

1. Менеджер задокументировал ключевые поинты разговора счеловеком названные импричины.

2. Предположил варианты сосвоего опыта.

3. Собрал доказательства существованию причин, проанализировал.

4. Попытался связать разные причины водну систему, поскольку редко бывает так, чтобы причина была только вчем-то одном.

Граф причин проблемы, воссозданный сослов рассказчика

Большинство причин нижнего уровня можно было решить быстро, анекоторые догадки (овертаймы, нежелание ментора менторить) ивовсе неподтвердились. Однако глаз менеджера зацепился загипотезы, выделенные красным, так как ихнеполучилось проработать из-за скрытности человека инедостатка информации наповерхности. Менеджер продолжил изучать причины, после чего выстроил следующий таймлайн событий:

1. Сначала человек стал засиживаться вофисе после работы почти каждый день.

2. Затем примерно водно итоже время стал слишком часто залипать винстаграм ифейсбук, что было хорошо видно наего мониторе, атакже много выходить поговорить потелефону.

3. Следом вместо домашней еды онстал питаться подножным кормом.

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

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

Кейс третий оработе стребованиями

Когда БАвходит впроект, который идет уже некоторое время, первая задача разобраться стребованиями, тоесть провести аудит. Обэтом кейсе яделалдоклад наNIX Multiconfв2019году. Сегодня раскрою некоторые детали того случая сточки зрения применения RCA: как искали причины того, почему впроекте начало появляться много багов.

Впервыйже день язапросил доступ кканалам коммуникации, описанию стейкхолдеров, команд ипроцессов, покоторым жил проект, так как поопыту это места, где стоит искать корни проблемы впервую очередь. Втечение недели яполучил нужную информацию, категоризировал ееипроработал проблемы напару уровней вниз, используя Five Whys. Ниже представлен отрывок изперечня проблем, которые удалось выявить:

Коммуникация

Невозможно было найти ответ или решение через время. Обсуждение требований велось вAsana, Slack, JIRA, через почту, вонлайн- иофлайн-документах. Среди всех источников небыло единого:

• клиент писал там, где ему было удобно втекущий момент;

• остальные команды неподдержали нашу критику, поскольку имитак норм;

• бюджет наведение SRS, митинг-минуток иструктурирование информации невыделялся.

Наша команда неполучала ответов вовремя. Другие команды непонимали наших вопросов:

• трудности перевода;

• если непинговать, томогли забы(и)вать нам ответить;

• пинговать из-за большой разницы сдвумя другими таймзонами было затруднительно.

Стейкхолдеры

Наша команда получала разную информацию изразных источников.

Небыло обмена решениями сдругими командами:

• небыло четких зон ответственности вплане шаринга информации;

• структурированные минутки исинки команд требовали времени, которое нехотели выделять.

Клиент часто менял требования/ принимал решения. Настолько часто, что одна команда успевала получить одно, авторая уже другое:

• уклиента небыло четкой бизнес-идеи, онстарался быстро адаптироваться под нужды целевой аудитории;

• клиент хотел реализовать как можно больше фич, невзирая наобщий концепт приложения, атакже удовлетворить всех пользователей;

• назаказчика давили инвесторы, которые требовали постоянного увеличения аудитории ифинансовых результатов.

Уже этих причин вполне достаточно, чтобы понять масштаб трагедии, источник потенциальных дефектов. Безусловно, снашей стороны также были проблемы. Например, техлид выполнял рольБА ипытался кое-как зафиксировать требования врамках своей загрузки, азначит, недостаточно ревьювил более молодых разработчиков. Однако больше всего проблем было из-за хаоса вкоммуникации, отсутствия продуктовой стратегии, нефиксирования требований вдостаточном объеме. Все это привело кневозможности планировать архитектуру иписать код требуемого качества.

Недожидаясь правок понескольким десяткам других пунктов, ЛПРы состороны команды реорганизовали перечень каналов связи иоставили всего три: обсуждение идей велось вAsana, дизайна итребований всоответствующих каналах Slack, тамже создали канал для общих вопросов. Кроме того, все решения покаждой функции стали фиксировать вJIRA, куда перевели только тетаски, которые должны были идти вразработку. Вдополнение ввели жесткие правила понеизменности скоупа врамках спринта (либо полной приостановке ипланированию спринта снуля) идлительности спринта.

Витоге чудесным образом количество дефектов стало резко уменьшаться. ЛПРы воодушевились успехом ипродолжили вносить изменения, которые также несли положительный результат. Но, как оказалось, положительным оноказался только для нас, т.к. вскоре клиент попрощался снами под предлогом того, что небыл готов ктакому уровню бюрократии :) Если заинтриговал, товдокладе поссылке выше больше подробностей.

Ичто?

Есть вещи, которые вот уже 8лет, смомента как явошел вIT, янеперестаю евангелизировать, поскольку нахожу имприменение либо вижу отражение вокружающем мире. Среди них философияпиши-сокращай, модель Кано, принцип Парето, think out ofthe box итак далее. Как выуже догадались, RCA входит вэтот перечень. Авсе потому, что важнейшая, если непервичная задачаБА заключается втом, чтобы понять почему. Будь топроблемная функция всистеме, ошибки вбизнес-процессах, нюансы человеческого поведения, негативные события вокруг все имеет глубокие корни.

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

RCA, конечноже, несеребряная пуля, ноинструмент, который однажды сможет предотвратить очередную проблему. Многие изнас пользуются RCA интуитивно, поскольку любознательность присуща людям, работающим вIT. Однако, использование техники наполную выведет вас нановый уровень при поиске причин ошибок.