Каков наиболее продуктивный способ обработки ошибок, связанных с развитием? [закрыто]

Мы все были там:

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

Мой вопрос заключается в том, как программисту наиболее эффективно обрабатывать сбои, связанные с разработкой, такие как эти?

Ваш проект провалился.

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

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

То, на что вы потратили дни написания кода, было отклонено вашей командой.

Сохраните свою работу (на потом). Есть две возможности: (а) это отстой, и тот факт, что несколько человек ответили одинаково, свидетельствует об этом; (б) это действительно гениальная работа, но далеко впереди того, что люди привыкли или могут понять. Людям вообще не нравится то, что они не понимают. Возможно, лучше показать это, когда придет время ИЛИ в другом месте с другой «Культурой»

Никто не слушает ваши идеи в вашей компании.

Это, вероятно, плохая идея, ИЛИ культура не соответствует вашему мышлению. Или переместитесь в место, которое поддерживает вашу культуру, или снова критически оцените вашу идею (объективно без вашего собственного предубеждения) -> действительно ли моя идея так хороша? <- Убей свое эго

Шаблон дизайна, который вы с силой применили в своей команде, создал беспорядок.

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

Они не неудачи - это опыт

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

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

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

• Сохраняйте спокойствие - не паникуйте, ничего лучше не будет
• Контроль ущерба - сохранить то, что еще можно сохранить
• Учитесь на своих ошибках - повторение неправильных действий, вероятно, не поможет
• Рассмотрите новый старт - начните свою следующую попытку без рюкзака разочарований и чувства вины
• Посмотрите на большие неудачи - по сравнению с первым полетом Ariane 5 , ваша ошибка незначительна
• Проконсультируйтесь с психотерапевтом, если вы не можете справиться с этим в одиночку

Вы что-то строите.

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

Это работает для меня в любом случае.

Ну, вы спросили :) Один за другим:

* Your project failed.

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

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

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

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

* What you have spent days coding was rejected by your team.

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

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

* Nobody listens to your ideas in your company.

Опять же, это требует контекста. Как давно ты здесь? Насколько ваши коллеги-хакеры доверяют вашим способностям? Считаете ли вы, что идеи, которые приводят к большему количеству работы для многих людей, могут привести к ЛЮБОЙ причине отклонить его? Однажды я что-то отклонил, потому что он не был готов к IPV6, но все же использовал простое доменное гнездо на устройстве обратной связи (исключительно). Человек, который затонул, просто не мог больше работать.

Кроме того, насколько хорошо ты формулируешь себя? Можете ли вы подружиться и влиять на людей?

* The design pattern you introduced with force in your team created a mess.

Следовательно, почему силы следует избегать. Умение говорить не является обязательным условием для умения слушать. Других комментариев нет.

О, парень, это много, если ты действительно имел в виду, что все случилось с тобой!

ВНИМАНИЕ : Во многих из приведенных ниже пунктов вы можете почувствовать, что я вас критикую, и что я хочу привлечь вас к ответственности за неудачи, а не учитывать внешние факторы. Я не. Просто вы не предоставляете много подробностей, а я просто предоставляю контрольные списки действий, которые нужно предпринять, чтобы убедиться, что все идет не так, как надо. Я знаю, что я сделал много ошибок сам (все делают), и мы только поправляемся, если мы учимся на них. И чтобы учиться у них, мы должны начать воспринимать их как ошибки в первую очередь и брать на себя ответственность за то, что пошло не так с нашей стороны. Черт возьми, возьми на себя ответственность за то, что пошло не так в чужих частях, ты также можешь извлечь из этого уроки.

Ваш проект провалился

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

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

Одна из книг с лучшим соотношением ((действительный совет) / страниц), которую я читал по этому вопросу, хотя, возможно, и не самая лучшая, это « Радикальное управление проектами» Роба Томсетта .

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

Если они не вовлечены, вы не можете знать, чего они хотят. Если вы не можете знать, чего они хотят, вы не сможете это сделать. Если вы не доставите его, они будут несчастны. Это провал. Кроме того, если вы не привлекаете своих заинтересованных лиц, они не связаны с реальностью разработки программного обеспечения, а это означает, что они не понимают ваших проблем. Если они часто общаются с вами, они лучше понимают, с чем вам приходится иметь дело. Они смогут лучше понять, когда вы скажете им, что «маленькая» функция [смеха] займет месяцы. Они могут доверять вашему планированию лучше, потому что они помогли построить его. Проект не может быть успешным только с «спецификациями в начале, разработкой, тестированием, доставкой в ​​конце». Просто никогда не бывает. Вы могли бы доставить то, что просили в спецификации,

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

То, что вы потратили дни на кодирование, было отклонено вашей командой

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

• Держите это в SCM на потом.
• Возможно, постарайтесь постепенно вводить мелкие фрагменты в основную базу кода вместо огромного рефакторинга.

Но есть и другие вещи, которые вы можете сделать, чтобы предотвратить такую ​​ситуацию:

• Почему это произошло? В чем причина отказа?
• Большую часть времени, когда я вижу, как это происходит (и это также относится ко мне), это означает, что разработчик пошел в одиночку или в режиме кодирования «мальчик-корова» и создал вещи, которые никогда не просили. Код, который не исходит из требований бизнеса, может быть причудливым и «лучше», но зачастую это пустая трата времени и денег. Плюс, это будет стоить еще больше, если вы интегрируете его, так как потребуется повторное тестирование. Подумайте, как люди, которые дают вам деньги: вы должны быть эффективны и на этом уровне.
• Было ли качество производимого программного обеспечения удовлетворительным? Соответствует ли оно стандартам и соглашениям, действующим в вашей компании?
• Вы периодически (и часто!) Сообщали об этом руководителям? Вы случайно обменивались с другими разработчиками команды? Если нет, то они ничего об этом не знают, им потребуется огромное время, чтобы оценить и проанализировать это сейчас. Это не относится к тому же времени в конце. Это все равно, что пытаться отложить уборку в квартире, а затем убирать ее только тогда, когда вы выезжаете: это дерьмовая работа, она утомительна, сложнее, чем если бы она делалась регулярно, и часто этого не происходит правильно.
• Вы производили тесты? Единицы испытаний? Интеграционные тесты?
• Ваш код регулярно проверялся в SCM? Это было в другой ветке? Нужна ли была другая ветка или это могло быть сделано в транке? Откладывание кода подтверждения обычно является плохим признаком. Очевидно, что иногда у вас возникает соблазн сделать это, но вы просто стреляете себе в ногу.

Никто не слушает ваши идеи в вашей компании

Ну, здесь есть 2 варианта, и мы рассмотрим оба:

• Твои идеи были плохими.
• Вы были хорошими идеями.

Давайте начнем предполагать, что они плохие (опять же, размышляя над этим, и принять вашу идею было просто плохо, я знаю, может быть трудно). Что вы делаете, чтобы изменить это?

• Почему вы пришли с идеей? Каково обоснование ? Есть ли реальная необходимость в том, что ваша идея пытается донести до стола?
• Как вы пришли к этой идее? Вы сделали это самостоятельно? Вы поделились? Мозговой штурм? Строить планы? Прототип? (делайте это в правильном порядке. Если по пути не получится, откажитесь от идеи, не продолжайте. Или, по крайней мере, не в своем графике работы.)

Идеи - это только идеи. Если вы просто предложите их как идеи, и они будут отвергнуты, я не понимаю, почему вы будете расстраиваться из-за этого. Однако, если вы действуете на них, не уведомляя никого, и ТОЛЬКО отправляете свои идеи, и они отклоняются, очевидно, я чувствую разочарование в то время, которое потрачено впустую. И ваши менеджеры делают, чтобы!

Предполагая, что ваши идеи были хорошими:

• Была ли ваша презентация хорошей?
• Был ли у вас хороший способ представить презентацию? (Я разработчик, я знаю, о чем говорю: мы сварливые, высокомерные , педантичные PITA, которые всегда правы и с которыми трудно работать из-за часто наших непропорциональных эго ).
• Есть ли у вас план по его реализации? Вы думали о стоимости и времени? Думали ли вы, как это приносит пользу пользователям / клиентам? Вы думали, как это влияет на продажи? Вы думаете, как работа над этой идеей может повлиять на другие проекты и приоритеты? Вы скажете мне: «Зачем мне все это делать, это работа моего менеджера и отдела маркетинга или продаж ?!» За исключением прямо сейчас, вы пытаетесь выполнить часть своей работы.

Шаблон дизайна, который вы с силой применили в своей команде, создал беспорядок

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

Кроме того, я немного удивлен самим подходом. Вы должны были действительно настаивать на представлении шаблона проектирования? Это кажется довольно странным. Шаблон уже существует, или вам необходимо провести рефакторинг части вашего решения в соответствии с шаблоном. Вы не продвигаете его так, как если бы вы приняли внедрение фреймворка или технологии (например, люди очень настаивали на том, чтобы повсеместно иметь XML, и теперь, как люди начинают настаивать на возможности писать HTML5 на обложке своего продукта большими яркими буквами).

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

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

Это совершенно не по теме, но это то, о чем я впервые подумал, когда прочитал название вопроса, так как думал, что оно касается сбоев программного обеспечения ... У меня было программное обеспечение, в котором реализован класс BlackHole для управления совершенно особым видом исключений в одном из компоненты. Это может показаться (и действительно является) явно странным и грязным хаком, но само наименование было настолько превосходным, что мы все оценили его как довольно крутой способ справиться с ошибкой! :)

Шаг 1: Можно разозлиться!

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

На самом деле, я думаю, что это может быть полезно и полезно - расстраиваться и выражать свое разочарование, если вы делаете это лично или с другом. У людей есть разные способы сделать это, но я думаю, что один из самых продуктивных способов - написать поддельное письмо (важно! Не отправляйте это письмо никому ). Объясните свои чувства, например, почему вы чувствуете, что все, что случилось, было неоправданным.

Шаг 2: Потратьте некоторое время, чтобы успокоиться.

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

Шаг 3: Просмотрите, что произошло на шаге 1

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

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

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

Шаг 4: определитесь с курсом действий

Можно ли что-то сделать, чтобы исправить ситуацию или хотя бы улучшить ее? Найдите минутку, чтобы подумать, реально ли можно что-то сделать, чтобы исправить или улучшить ситуацию. Часто нет, но иногда есть.

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

Затем подумайте, что вы можете сделать, чтобы улучшить будущее. Что вы можете сделать, чтобы предотвратить то же самое? Решите, чего вы хотите достичь, и используйте то, что вы узнали из шага 3, чтобы составить план для себя.

Если ничего не помогает, попробуйте перезагрузиться:

        try
        {
            // ...
        }
        catch (OhNoes111Exception)
        {
            // reboot fixes everything!
            System.Diagnostics.Process.Start("ShutDown", "/r");
        }