Root Cause Analysis как метод предотвращения багов
Привет! Мое имя Юра Гомон, я BA Tech Lead в NIX и вот уже 8 лет занимаюсь бизнес-анализом, помогая реализовывать веб- и мобильные решения для бизнеса, а также автоматизировать бизнес-процессы. Сообщество DOU может знать меня как автора BA Digest.
Цель статьи — напомнить бизнес-аналитикам о методе Root Cause Analysis (далее — RCA) и поделиться опытом его применения для предотвращения багов.
Поскольку в 2017 году на DOU выходила обзорная статья о техниках Problems solving (в том числе об 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. Однако использование техники на полную выведет вас на иной уровень поиска причин ошибки.
Что еще почитать по теме RCA
- A Brief History of Root Cause Analysis. Истоки появления техники, описание шагов, смежные подходы.
- How to Conduct a Root Cause Analysis. Разбор техники на примере.
