Как перестать совершать глупые ошибки на работе?

Три вещи помогут вам быть более точными:

• используйте контрольные списки и процедуры (напишите свои собственные) и следуйте им. Включите такие шаги, как “двойная проверка, на какой сервер вы нацелены”. Когда последствия ошибки высоки, на самом деле распечатайте список и проверяйте все ручкой по ходу дела.
• когда технология поможет вам, уделите время проверке. Скажите, что ваш почтовый клиент заполняет строку To после того, как вы напечатаете первое письмо. Не просто напечатайте письмо и нажмите кнопку Отправить. Остановитесь и посмотрите, что он заполнил.
• когда вы делаете ошибку, спросите себя, почему. Какой шаг вы пропустили? На что ты не посмотрел? Почему правильная вещь и неправильная вещь выглядели так похоже? Как может быть проще быть уверенным в том, что вы делаете все правильно? Обновите вашу процедуру тем, чему вы только что научились.

Со временем вы выработаете привычки и процессы, которые обеспечат вам правильное поведение. На самом деле, это и есть опыт.

Как перестать совершать глупые ошибки на работе?

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

Шаг 1: Поймите, что ошибки не “глупые” - они серьезные. Из-за них вы можете потерять работу. Я думаю, что большой индикатор вашей проблемы в том, что это кажется вещами, которые легко предотвратить, но вы все равно их делаете. Однако, не предотвращая их, у вас есть серьезная проблема.

Шаг 2: Притормозите. Слишком часто программистов и инженеров “рок-звезды” считают теми, кто движется быстро и яростно - ничто их не останавливает! Реальность такова, что они не такие. Бывают ситуации, когда это происходит, но бывает и так, что это неправда. Перестаньте чувствовать спешку, переведите дух и медленнее.

Шаг 3: Прежде чем “закончить” что-то, остановитесь и сделайте перерыв, затем вернитесь к нему и просмотрите. Получить кофе, читать электронную почту, или что-то не слишком отвлекает, чтобы отвлечься от поставленной задачи, так что вы будете иметь свежую перспективу, когда вы вернетесь к нему. Вы можете почувствовать, что это замедлит вашу работу или снизит ее производительность. Однако такой подход позволяет заметить ошибки на ранней стадии, что важно для продуктивности. Поэтому перед тем, как нажать кнопку “отправить” - прочитайте еще одно письмо или проверьте состояние сервера или еще что-нибудь. Речь идет не только о написании кода.

Шаг 4: Когда вы найдете ошибку, не просто исправьте ее. Уделите время, чтобы попытаться выяснить, почему произошла ошибка. Куда вы спешите? Ошибка копирования/вставки? Опираться на чужую работу или мнение? Это поможет вам быть более осведомленным о причине ошибок в то время, когда они происходят. Узнать позже не очень полезно, как вы знаете.

Шаг 5: Отследить ваш прогресс. Обратите внимание на полезность ваших новых привычек и практик. Держите электронную таблицу для подсчета ошибок или проблем, которые вы нашли после перерыва. Также обратите внимание, если открытие предотвратило что-то, что могло бы разозлить вашего босса или поставить в неловкое положение. Это развивает вашу способность лучше самооценивать приемлемость вашей собственной работы, а также пытаться узнать, какие привычки наиболее эффективны.

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

Попробуйте различные подходы к обнаружению ваших ошибок, прежде чем они станут проблемами. В то время как многие ответы здесь сосредоточены на разработке процессов/процедур/контрольных списков (особенно вокруг разработки кода), предпосылка “управления качеством” или “улучшения качества” связана с обнаружением ошибок в качестве средства обратной связи для разработки и/или улучшения процессов. Нельзя разработать “лучший” процесс, если вы не знаете причину ошибок. Работа над обнаружением причины ошибок Скорее всего, вы просто торопитесь, а не “перепроверяете” свою работу. Вот несколько советов, как сделать более медленный темп более продуктивным.

Хватит работать. Только так можно перестать совершать ошибки.

Нет, серьезно: Ты всегда будешь делать несколько ошибок. Это часть человеческого бытия (которое я чувствую себя в безопасности, если предположить, что это так). Любой профессиональный разработчик будет производить работу с некоторым количеством ошибок, и это нормально. Именно поэтому у нас есть такие отделы, как Test Driven Development, Unit Testing и Quality Department. Если ваш менеджер ожидает, что ПО без ошибок будет работать с первой минутой, то вы не имеете дело с разумными ожиданиями.

Тем не менее, мы живем в мире, где мы не можем перестать работать только потому, что ошибки случаются, поэтому мы принимаем меры, чтобы снизить риск ошибок. Я работаю в производственном цехе, поэтому лозунг “Poke-yoke” (буквально по-японски - “Защита от ошибок”) - это автоматизированный процесс, предназначенный для устранения человеческих ошибок. Это означает автоматизацию. Я определенно рекомендую перейти на автоматизированный процесс сборки для развертывания программного обеспечения на производстве. Это потребует участия более чем одного разработчика, но это стоит подтолкнуть насколько это возможно.

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

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

*В кратчайшие сроки: *Автоматизируйте там, где это возможно, не торопитесь и не бойтесь просить о помощи.

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

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

Выбор, что вы делаете. Понимаете ли вы, что вы делаете, почему и как? Можно ли сделать это более безопасно? Вы уверены, что лучше сделать это, чем не делать?

Пауза перед тем, как идти вперед с рискованными попытками. Не отправляйте электронные письма, не проверив получателей, тему, содержание и вложения. Один за другим. Не торопитесь. Отправка ценового предложения по клиенту А клиенту Б может привести к потере обоих клиентов. Лучше потратить минуту или около того, чтобы проверить его. Не поддавайтесь искушению поторопиться, даже в “чрезвычайной ситуации”.

Планируйте план восстановления. Заранее знай, что ты будешь делать, если что-то пойдет не так. Приготовьтесь к тому, что если вам все-таки потребуется исправить ошибку, вы сможете сделать это быстро - но без спешки. Как вы узнаете, если что-то пойдет не так? Есть ли способ узнать это раньше?

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

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

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

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

Learn. Каждая сделанная ошибка - это возможность пересмотреть процесс.

Берегите себя. Найдите время в течение дня, чтобы очистить свой разум и получить несколько минут тишины или расслабления. Перед работой, после работы, перерывы на обед и т.д. Хватит спать. Ешьте регулярно и здоровым образом.

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

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

2. Улучшенная процедура развертывания. Сначала разверните сервер на инсценировке, используя точные команды, которые вы бы использовали для prod, и проверьте там правильность развертывания, прежде чем отправляться в производство.

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

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

Я работаю инженером-программистом/архитектором более 10 лет, и могу с уверенностью сказать, что вы никогда не исправите все ошибки. Лучший совет, который я могу дать вам, это определить, какие задачи являются наиболее рискованными, и принять меры для уменьшения этого риска.

1. В большинстве случаев, отправка электронного письма не тому человеку не является большой проблемой. Я не могу сказать вам, сколько раз я получал электронное письмо, предназначенное для одного из других Дженнингсов, которые здесь работают. Но если вы отправляете электронное письмо, которое может содержать конфиденциальную информацию, всегда нужно время, чтобы дважды проверить получателей и содержимое.
2. Если вы пишете важный документ, напишите контрольный список/линию того, что в нем должно быть, и дважды проверьте содержимое перед отправкой.
3. Для развертывания сборок всегда используйте автоматизированный процесс и, если возможно, сначала разверните на вторичном сервере. Моя команда развертывает наши службы Ruby на вторичном сервере, тестирует, а затем переворачивает вторичный сервер на основной. Если на этом этапе возникнут проблемы, мы всегда можем просто перевернуть старый сервер. Если ни одна из этих вещей невозможна, это несет в себе гораздо больший риск, поэтому мой совет - потратить дополнительное время и внимание на выполнение задачи. Дважды и трижды проверяйте все для каждого шага, который несет в себе высокий уровень риска.
4. При возникновении ошибок в коде убедитесь, что вы пишете хорошие тесты на интеграцию/интеграцию, которые охватывают нормальные рабочие процессы и крайние случаи. Хорошей идеей будет убедиться, что проект в целом имеет как можно более высокое покрытие юнит-тестов, чтобы убедиться, что если вы измените что-то, что нарушает что-то другое, юнит-тест будет неудачным и вы поймаете ошибку рано. Это не будет ловить все ошибки, но это хорошее начало. Как только код будет готов к тестированию черного ящика, не просто тестируйте рабочий процесс, к которому прикасается ваш код, проанализируйте, на какие другие части проекта мог повлиять ваш код, а также протестируйте эти рабочие процессы. Тестирование черного ящика должно также охватывать как нормальные, так и крайние случаи.

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

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

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

• *

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

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

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

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