私たちは皆そこにいました：
- プロジェクトが失敗したか、キャンセルされました。
- 作業に費やしたコードは、チームによって拒否されました。
- チームに紹介した設計パターンは混乱を生み出しました。
- 誰もがあなたのアイデアを無視します。
私の質問は、プログラマがこれらのような開発関連の障害を処理する最も生産的な方法は何ですか？
進行中の構造化タグクリーンアップイニシアチブの一環として、この質問はメタディスカッションサイトで議論されています。
私たちは皆そこにいました：
私の質問は、プログラマがこれらのような開発関連の障害を処理する最も生産的な方法は何ですか？
回答:
プロジェクトは失敗しました。
ソフトウェア開発は、プロジェクトの失敗を非常に起こしやすく、深刻度によっては、管理者が対処するのが最適です。
多くのプロジェクトが失敗し、さらに多くのプロジェクトが失敗するので、注意してください！プロジェクトが失敗した理由を学び、次回も同じ間違いをしないようにします。成功よりも失敗から多くを学びます。
コーディングに費やした時間は、チームによって拒否されました。
作業を保存します（後で）。次の2つの可能性があります。（a）ひどく、複数の人が同じように反応したという事実は、このことを示しています。人々は一般に、自分が理解していないことを好まない。おそらく、時間が正しいときに表示するか、異なる「文化」を持つ別の場所で表示する方が良いでしょう
会社であなたのアイデアを聞く人はいません。
それはおそらく悪い考えです、または文化はあなたの思考と一致していません。あなたの文化を支える場所に移動するか、あなたのアイデアを批判的に評価します（客観的にあなた自身のバイアスなしで）->私のアイデアは本当に良いですか？<- 自我を殺す
チームに力を入れて導入した設計パターンが混乱を生み出しました。
正直に言って、あなたはベストを尽くしましたが、それはあなたがそれを計画した方法を明らかにしませんでした。もう一度やり直すか、チームとして設計の誤りから学び、前進する方が良いかもしれません。
さて、あなたは尋ねました:) 1つずつ：
* Your project failed.
それはほとんど新しいものではありません。私たちはすべて個人的に失敗しました、そして、私たちはすべて仲間の完全な視野で失敗しました。初等および中等教育を受けた人は誰でもこれを経験しています。
間違いを犯せず、安定した雇用が期待できる場合は、人事を将来の検討から禁止することを知らせるメモをHRに送信することを検討してください。
連続したいくつかの失敗は、あなたが不合理な要求と仕様を持っているか、自分の間違いから学ばないことを意味します。いずれのシナリオでも、すぐに行動を起こしてください。
多くの人が単に雇用を得るために何かにサインし、それから要件を実現する何らかの方法を考え出すことが考えられます。
* What you have spent days coding was rejected by your team.
発生します。他の人が述べたように、保存してください。再びそれを行う。これが私たちがそれを仕事と呼ぶ理由です。この場合、あなたはおそらくあなたがやっていることにチームをあまり関与させなかったと思います。
要件が昨日または1時間前に変更された可能性もあります。ただし、これは例外であり、標準ではありません。査読は有用ですが、残酷です。コードが常に「不適切」（またはそのようなもの）として却下されている場合は、頭脳を選んで他の人を巻き込むのにより多くの時間を費やす必要があります。「チーム」が自己説明以外のものでない限り、この質問はほとんどのチーム設定で誤りであると信じています。
* Nobody listens to your ideas in your company.
繰り返しますが、これにはコンテキストが必要です。どのくらいそこに居ましたか？あなたの仲間のハッカーはあなたの能力をどれだけ信頼していますか？多くの人々にとってより多くの仕事をもたらすアイデアは、それを却下する何らかの理由を招くかもしれないと考えましたか？IPV6の準備ができていなかったため、何かを却下しましたが、ループバックデバイスで単純なドメインソケットを使用していました（排他的に）。それを沈めた人は、もうこれ以上仕事をすることができませんでした。
また、あなたはどのくらい自分自身を明確にしますか？友達を作り、人々に影響を与えることはできますか？
* The design pattern you introduced with force in your team created a mess.
したがって、なぜ力を避けるべきだったのか。話すことができることは、聞くことができるための前提条件ではありません。他のコメントはありません。
ああ、あなたは本当にあなたにすべてが起こったことを意味する場合、それはたくさんです！
警告：以下の多くの点で、あなたは私があなたを批判しているように感じるかもしれません。しません。それはあなたが多くの詳細を与えないということだけです、そして、私は物事が間違って行かないことを確実にするために引き受けるべき行動のチェックリストを提供するだけです。私は多くの間違いを自分でしたことを知っています（誰もがそうします）。そして、彼らから学ぶためには、そもそもそれらを間違いと見なし始め、私たちの側で何がうまくいかなかったのかについての責任を受け入れる必要があります。地獄、他の人の部分で何がうまくいかなかったかについての責任を受け入れてください、あなたもそれから学ぶことができます。
今それを軽減するためにできることはあまりありません。
ただし、将来それを再現するために多くのことを行うことができます。プロジェクトと時間管理のスキルを向上させることをお勧めします。
最高の比率（（有効なアドバイス）/頁）私は件名に読んだと本の一つ、しばらくそうでないかもしれない最高の、それロブThomsettのラジカルプロジェクト管理。
プロジェクトが失敗したものを実際に指定するわけではありませんが、通常のコスト/時間/品質の三角形に不均衡をもたらすものの組み合わせを想定しています。私の目で最も重要な要素は、プロジェクトと開発をリードしながら、常に技術的なアクター（開発者とテスター）だけでなく、利害関係者とも連絡を取り合うことです。スポンサーや利害関係者の声に耳を傾けず、プロセスに関与するように彼らを押し付けないため、非常に多くのプロジェクトが失敗します。
彼らが関与していない場合、あなたは彼らが何を望んでいるかを知ることができません。彼らが何を望んでいるかわからないなら、それを届けることはできません。あなたがそれを届けなければ、彼らは不幸になります。それは失敗です。さらに、利害関係者を巻き込まなければ、ソフトウェアエンジニアリングの現実から切り離されます。つまり、彼らはあなたの問題を理解しません。彼らが頻繁にあなたと接触している場合、彼らはあなたが対処しなければならないものをよりよく把握します。「小さな」（笑い）機能には数か月かかることを伝えると、彼らはより理解できるようになります。彼らはそれを構築するのを助けたので、彼らはあなたの計画をより良く信頼することができます。プロジェクトは、「最初の仕様、開発、テスト、最後の配信」だけでは成功できません。それは決してしません。仕様で要求されたものを提供するかもしれませんが、
同様に最も重要なのは、回顧を行い、自我が少なく、非難ではないことを確認することです。問題を特定するだけです。
私はそのような状況にありました。繰り返しますが、以下を除いて、それを緩和するためにできることはあまりありません。
ただし、このような状況を防ぐためにできることはもう1つあります。
さて、ここには2つのオプションがあり、両方を見ていきます。
それらが悪いと仮定して始めましょう（繰り返しますが、それについて自己反省し、あなたのアイデアを受け入れることは単純に悪いことであるかもしれません、私は知っています）。それを変えるにはどうしますか？
アイデアは単なるアイデアです。それらをアイデアとして提案しただけで拒否された場合、なぜあなたがそれについて気分が悪いのかわかりません。しかし、だれにも通知せずに行動し、アイデアを提出するだけで拒否された場合、明らかにその時点でのフラストレーションが無駄に感じられます。そして、あなたのマネージャーはそうします！
あなたのアイデアが良かったと仮定します：
また、アプローチ自体にも少し驚いています。あなたが実際にしなければならなかった押し導入されるようにデザインパターンのために？それはかなり奇妙に思えます。パターンが既に存在するか、パターンに従ってソリューションの一部をリファクタリングする必要があります。フレームワークやテクノロジーの採用のようにプッシュすることはありません（人々がXMLをどこにでも持っていくように非常に強くプッシュし、今では人々が大きな明るい文字で製品のカバーにHTML5を書くことができるようにプッシュし始めているように）。
なぜプッシュする必要がありましたか？なぜ抵抗があったのですか？多分それは正当化された。
この特定のパターンが大幅な方法でコードベースを改善するのに役立つ例を提供できましたか（たとえば、パターンをリファクタリングする例と一致させることによって）。
完全にオフトピックのメモですが、それがソフトウェア障害に言及していると思ったときに質問のタイトルを読んだときに最初に考えたものです...私はBlackHoleクラスを実装して、コンポーネント。明らかに奇妙で汚いハックのように思えるかもしれませんが、ネーミング自体は非常に素晴らしかったので、障害を処理するためのかなりクールな方法として皆に感謝しました！:)
まず、障害に遭遇したときに動揺したり怒ったりすることは理解できます。そのような状況で誰かに助言を与える場合、彼らは「ちょうどそれを乗り越えて先に進む」または「ちょうどそれを学習の機会と考えてください」を聞きたくないでしょう。
実際、個人的にまたは友人と一緒にやれば、イライラしてイライラするのは健康的で生産的だと思います。人々はさまざまなやり方を持っていますが、最も生産的な方法の1つは怒っている偽の手紙を書くことだと思います（重要！この手紙を誰にも送らないでください）。何が起こったのか不当だと感じる理由など、あなたの気持ちを説明してください。
自分が感じていることをすべて表現していることを確認してください。怒りを発散した後は、落ち着くまで少し時間がかかります。たぶん、あなたはほんの数分、あるいはおそらく数時間しか必要としません。
この時点で、状況についてより客観的に考えることができます。手紙を書いたら、それを自分自身に読んでください。あなたが誰かに打ち明けたなら、あなたが言ったことを思い出してみてください。誰かに叫ぶことを想像しただけなら、それを精神的に見直してください。
怒っているときによく手紙を書きます。落ち着いた後は、手紙を読んで誰かが自分のことを理解してくれると納得するまで、元々言っていたことをより明確に伝えるように努力します当時の感じ。
ポイントは、あなたのポイントが何であるかを客観的に選択しようとすることです。彼らは理にかなっていますか？おそらく、明確化や詳細が必要です。彼らは根拠がありませんか？あなたが客観的に他人の靴に身を置くとしたら、あなたが作ったポイントを理解しますか？これらの点に同意しますか？この機会を利用して、自分自身を評価できます。あなたは何をうまくやりましたか？もっと良くできたと思うことは何ですか？
状況を改善する、または少なくとも改善するためにできることはありますか？状況を修正または改善するためにできることは現実的に存在するかどうかを考慮してください。しばしばありませんが、時々あります。
あなたが何かに過失がある場合、それは誰かへの正式な謝罪と同じくらい簡単かもしれません。未来。
次に、将来を改善するために何ができるかを検討してください。同じことが再び起こらないようにするにはどうすればよいですか？達成したいことを決定し、ステップ3で学んだことを使用して、自分の計画を作成します。
他のすべてが失敗した場合は、再起動してください：
try
{
// ...
}
catch (OhNoes111Exception)
{
// reboot fixes everything!
System.Diagnostics.Process.Start("ShutDown", "/r");
}