Ошибка не в проблеме, а в симптомах проблемы

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

Автор Виталий Шароватов

Перевод на русский. Оригинал статьи здесь

В IT, когда мы находим ошибку, мы ее исправляем. Исправление — это решение, поэтому кажется логичным, что ошибка — это проблема, и как только она исправлена, у нас все в порядке, верно?

Не совсем. Ошибки — это не проблемы, а скорее симптомы проблемы.

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

В ИТ-отделе исправление ошибок без понимания основной проблемы (или проблем) также может быть рискованным. Ошибки часто являются симптомами, указывающими на то, что в разработке что-то не так. Если это так, исправление ошибок только замаскирует более серьезные проблемы и потенциально может стоить компании больше денег в долгосрочной перспективе.

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

В этом сценарии распространенность ошибок является симптомом более глубокой проблемы с процессами команды. Постоянное исправление ошибок может успешно замаскировать эту проблему. Однако, если бы проблема с процессом была решена, команда не тратила бы так много времени на тестирование и исправление и у нее было бы больше времени для ценной работы.

Помните: проблема не в ошибках; Они являются симптомом. Лечение симптома без решения проблемы нелогично и рискованно.

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

В IT есть искушение сразу же перейти к варианту «обезболивающего» (исправление ошибки) и остановиться на этом. Но я считаю, что важно глубже изучить проблему, особенно когда ошибки происходят регулярно.

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

Это все случаи потери информации в коммуникации и развитии. Большинство из них можно было бы предотвратить, если бы члены команды обменивались всей необходимой информацией.

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

Ошибки должны быть собраны и классифицированы. Затем следует проанализировать наиболее заметную категорию, чтобы определить основную причину, чтобы ее можно было устранить, предотвратив в результате больше ошибок.

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

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

Например, у меня был опыт различных методов лечения проблем, связанных с «непониманием того, что нужно делать», таких как:

Все решения проблемы потери информации требуют, чтобы тестовая информация (ожидания, NFR, пограничные случаи, счастливые пути и даже сценарии тестирования) хранилась и распространялась среди членов команды. Система управления тестами, такая как Qase, — это абсолютный минимум. Точно так же и в медицине были изобретены медицинские карты пациентов, чтобы весь медицинский персонал мог записывать и обмениваться всей необходимой медицинской информацией.

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

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

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

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

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

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

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

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