Внешние факторы и собственные прогнозы: почему мы ошибаемся и что с этим делать

Часто причины ошибок связаны с физиологическими факторами — недосып, головная боль — и организацией процесса: сжатые сроки и вынужденный кодинг по 36 часов подряд. По данным НАФИ, компании теряют миллиарды долларов в год из-за недосыпа сотрудников и тех ошибок, которые они совершают.

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

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

• Медицинский аппарат Therac из-за ошибки в коде выдал повышенную дозу облучения пациентам.
• Электронный стояночный тормоз с дефектом привёл к тому, что Toyota отозвала с рынка 84 тысячи автомобилей.
• Отключение электроэнергии в США, одной из причин которого стало отсутствие оповещения, обошлось в шесть миллиардов долларов.

Почему мы ошибаемся: прогнозирующее кодирование и шум

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

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

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

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

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

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

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

На появление ошибок влияют:

• отличительные черты восприятия, памяти;
• общественная сторона оценки выбора и принятия решений;
• стереотипные ситуации.

Плохая новость: если верить этим двум теориям, полностью избежать ошибок никому не удастся.

Хорошая новость: можно свести повторение ошибок к минимуму, а случившуюся — исправить.

Как не допускать ошибок: старые добрые методы и протокол непосредственных оценок

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

Таким образом, получаем первое и основное правило при написании кода или в целом при создании продукта: привлекать экспертов для тестирования. Второй важный момент — системный подход к анализу и проверке на качество.

Чтобы использовать эти правила для принятия решений, обратимся к Канеману и его «Протоколу опосредованных оценок», описанному в книге о несовершенстве суждений:

 Выявляем самые важные составляющие для проверки кода: скорость написания, безопасность, быстродействие, надёжность. Стоит различать понятия «надёжность» и «качество». В сфере кибербезопасности, даже если ПО проработало несколько лет, это не говорит о его качестве. Всегда есть вариант новой угрозы.

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

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

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

Не стоит быть слишком уверенными в программном обеспечении — если происходят инциденты, лучше всегда перепроверить самостоятельно, протестировать через другие системы, пригласить экспертов для анализа. При обнаружении масштабной катастрофы можно обратиться к коллегам, пережившим подобный опыт, чтобы узнать, в чём была проблема и как удалось её решить. После утечки данных Яндекс Еды произошла аналогичная ситуация в Delivery Club. Во втором случае компания приняла те же меры, что и руководители Яндекс Еды, а именно сократила количество лиц, которым доступна персональная информация.

Система стандартов применима не только к людям, но и к компаниям. Можно задать её самостоятельно, а можно — пользоваться тем, что уже есть. Кому-то будет проще изучить правила написания кода титанов IT-индустрии, а кому-то — создать собственные, а потом пропустить их через экспертов и протестировать несколько раз.

Система новых стандартов требует времени на разработку, и пока её нет, всегда можно использовать старые добрые методы профилактики ошибок:

• Метод утёнка. Работник ставит, хотя бы мысленно, на стол игрушечного утёнка. Когда у сотрудника возникает вопрос, на который трудно ответить, то он задаёт его игрушке, словно она действительно может вступить в диалог. Считается, что правильная формулировка вопроса содержит половину ответа. Метод также используют при отладке. Если код не работает, программист пытается объяснить утёнку, что делает каждая строка, и в процессе этого находит несоответствия.
• Мозговой штурм. Нужно обозначить сложившуюся проблему и попросить всех причастных придумать возможное решение, принимая во внимание даже самые безумные идеи и предложения.
• Рецензирование. Систематическая проверка исходного кода, которая помогает обнаружить и исправить ошибки, незамеченные в начальной фазе разработки.
• Парное программирование. Код создают пары программистов: один кодит и занимается деталями, другой просматривает результат и держит в голове всю задачу. Иногда они меняются ролями.