Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Ошибки сопровождают нас с рождения и являются нормальным следствием изучения мира и получения жизненного опыта. Этот опыт и становится причиной множества ошибок. Похоже на замкнутый круг, над которым бьются психологи и философы. Сегодня посмотрим на теорию, объясняющую механизм фейлов, и методы профилактики провалов.
Часто причины ошибки связаны с физиологическими факторами — недосып, головная боль — и организацией процесса: сжатые сроки и вынужденный кодинг по 36 часов подряд. По данным НАФИ, компании теряют миллиарды долларов в год из-за недосыпа сотрудников и тех ошибок, которые они совершают.
Но даже если организационных проблем нет, промахи всё-таки случаются. Иногда это приводят к длительной работе под исправлением ситуации. И никто не застрахован, даже если в проекте задействованы лучшие специалисты.
Утечки данных, упавшие сервисы — это случается с завидной регулярностью. Не все ошибки глобальны, но иногда постоянные мелкие недочёты сигнализируют о некомпетентности или излишней самоуверенности кого-то из команды. Существуют хрестоматийные случаи провалов в IT, которые привели к серьёзным проблемам:
Медицинский аппарат Therac из-за ошибки в коде выдал повышенную дозу облучения пациентам.
Электронный стояночный тормоз с дефектом привёл к тому, что Тойота отозвала с рынка 84 тысячи автомобилей.
Отключение электроэнергии в США, одной из причин которого стало отсутствие оповещения, обошлось в шесть миллиардов долларов.
Почему мы ошибаемся: прогнозирующее кодирование и шум
В непреднамеренных ошибках виновато наше мышление, а точнее — тот способ, которым мозг воспринимает информацию. Вопрос о работе мозга решают нейрофизиологи вместе с искусственным интеллектом — и все больше влияния приобретает теория прогнозирующего кодирования. Её суть такова: наш мозг генерирует восприятие, а информация, поступающая от органов чувств, лишь корректирует его. В противном случае мозгу пришлось бы обрабатывать слишком много данных, а это нерационально.
Проще говоря, эволюция нашла для мозга обходной путь. Мы постоянно строим прогностическую модель окружающего мира и одновременно сравниваем, совпадает ли поступающая сенсорная информация с прогнозом. Если да — отлично, модель мира хороша. Если же нет — придётся менять одно из трёх:
сам прогноз, то есть переделывать модель, что требует больших затрат энергии и потому редко случается;
информацию, то есть корректировать данные за счёт подключения других органов чувств;
свои представления.
Данные из внешнего мира поступают к нам через узкое окно восприятия и формирует убеждения. Но затем эти убеждения действуют подобно линзе: фокусируются на том, что нужно увидеть, а не на том, что есть в реальности.
В результате мы воспринимаем не действительность, а то, что «хочет» видеть наш мозг. Хорошим примером такой ошибки служат графические иллюзии, когда статичная картинка начинает двигаться.
В работе проявляется так: визуально практически невозможно найти ошибку в коде, потому что при чтении мозг «дописывает» строчку правильно. Именно из-за общего опыта и прогнозируемого кодирования целый отдел кибербезопасности может с лёгкостью прийти к единому неправильному решению.
Павел Комягин
Тимлид команды разработки внутренних продуктов Нетологии
Наверное, самая распространённая ошибка среди разработчиков, и та, от которой я регулярно сам страдаю — это слишком оптимистичная оценка времени, которое нужно для решения задачи.
В начале карьеры для тебя всё новое, ты никогда ещё не верстал вот такой блок, тебе ещё не приходилось писать эту логику. Поэтому ты думаешь, и что важно, говоришь руководителю, что справишься за день. Но в результате тратишь целую неделю. Со временем незнакомых задач становится меньше, но проблема до конца не уходит. Ты уже уверен в своих силах, но по-прежнему переоцениваешь себя.
Я пришёл к такой методике: сначала думаю о том, за сколько бы я сделал задачу интуитивно. Потом прибавляю к этой оценке процентов 50%, и вот это уже будет похоже на правду.
В нашей команде, как и во многих других, бывает так, что оценка не совпадает с затраченным временем. Мы стараемся относиться к этому философски, понимаем, что программирование — вещь порой непредсказуемая. Если работаешь не по чёткому ТЗ, то есть много неопределённостей, которые всплывают только при погружении в задачу и уже в процессе решения. Поэтому стараемся закладывать сверху оценки ещё немного времени на форс-мажоры. Менеджеры относятся с пониманием — предсказуемость часто важнее скорости.
Помимо опыта, мозгу помогают дописывать код внешние факторы. И иногда — неправильно. Даниэль Канеман в книге «Шум. Несовершенство человеческих суждений» рассматривает, как меняются мысли и убеждения из-за двух вещей: шума — noise — и предубеждения — bias, которые мешают выносить верные решения.
На появление ошибок влияют:
отличительные черты восприятия, памяти,;
общественная сторона оценки выбора и принятия решений;
стереотипные ситуации.
Плохая новость: если верить этим двум теориям, полностью избежать ошибок никому не удастся.
Хорошая новость: можно свести повторение ошибок к минимуму, а случившуюся — исправить.
Как не допускать ошибок: старые добрые методы и протокол непосредственных оценок
Если изучить расследование и проанализировать причины провалов, описанных выше, то окажется, что можно было снизить риски, привлекая сторонних экспертов для проверки продуктов и систем.
Таким образом, получаем первое и основное правило при написании кода или вообще создании продукта — привлекать экспертов для тестирования. Второй важный момент — системный подход к анализу и проверке на качество.
Чтобы использовать эти правила для принятия решений, обратимся к Канеману и его «Протоколу опосредованных оценок», описанном в книге о несовершенстве суждений:
Выявить самые важные составляющие для проверки кода: скорость написания, безопасность, быстродействие, надёжность. Различайте понятия «надёжность» и «качество». В сфере кибербезопасности, даже если ПО проработало несколько лет, это не говорит о его качестве. Всегда есть вариант новой угрозы.
Выбрать несколько составляющих, в которых вероятность ошибки наиболее высока. Разбейте задачу на блоки и каждой поставьте оценку по вероятности ошибки, пригласите экспертов также дать свой прогноз сбоев.
Выбрать составляющие, в которых ошибка может принести наибольший урон.
Убедиться, что эксперты, которых привлекли для оценки, действительно независимы и обладают нужной компетенцией.
Не будьте слишком уверены в программном обеспечении — если происходят инциденты, перепроверьте сами, протестируйте через другие системы, пригласите экспертов для анализа. При обнаружении масштабной катастрофы обращайтесь к коллегам, пережившим подобный опыт, чтобы узнать, в чём была проблема и как удалось её решить. После утечки данных «Яндекс Еды» произошла аналогичная ситуация в Delivery Club. Во втором случае компания приняла те же меры, что и руководители «Яндекс Еды»: сократили количество лиц, которым доступна персональная информация.
Используйте систему стандартов для себя лично и для компании. Можете задать её самостоятельно или воспользоваться тем, что уже есть. Изучайте правила написания кода титанов IT-индустрии и создайте свои. Их также «прогоните» через экспертов и протестируйте несколько раз.
Система новых стандартов требует времени на разработку, и пока её нет, всегда можно использовать старые добрые методы профилактики ошибок:
Метод утёнка. Работник ставит, даже мысленно, на стол игрушечного утёнка. Когда у сотрудника возникает вопрос, на который трудно ответить, то он задаёт его игрушке, словно она действительно может вступить в диалог. Считается, что правильная формулировка вопроса содержит половину ответа. Метод также используют при отладке. Если код не работает, программист пытается объяснить утёнку, что делает каждая строка, и в процессе этого находит несоответствия.
Мозговой штурм. Нужно обозначить сложившуюся проблему и попросить всех причастных придумать возможное решение, принимая во внимание даже самые безумные идеи и предложения.
Рецензирование. Систематическая проверка исходного кода, которая помогает обнаружить и исправить ошибки, незамеченные в начальной фазе разработки.
Парное программирование. Код создают пары программистов: один собственно кодит и занимается деталями, другой просматривает результат и держит в голове всю задачу, иногда они меняются ролями.
Поделитесь, какими способами вы снижаете количество ошибок на работе.
