失敗したプログラミングプロジェクトに対処する方法

プロジェクトが失敗することは珍しくありません。

プログラマーとして、失敗したプロジェクトにどのように対処しますか？

失敗のいくつかの定義：

• 締め切りがありません。
• コードと機能は本来のことをしていません。
• ソフトウェアはベーパーウェアまたは無限の数のフェーズになり、基本的には配信できません。

あるいは、あなた自身の失敗の定義があるかもしれません。

指差し始めますか？要件、技術、管理、クライアントなどを自分自身のせいにしますか？チームとしてレッスンを学びましたか？

失敗または成功したすべてのプロジェクトについて学んだ教訓を行う必要があります。良いプロジェクトから学ぶことはたくさんあります。

本当に失敗したプロジェクトは私にとって非常にまれです。何が起こったのかを理解することに加えて、私は根本的な原因に到達しようとするために「なぜ5回尋ねる」ことをします。何が起こっているのか気づかなかったので、それについて何かをするか、少なくとも外に出るかの問題もあります。

クライアント、技術、取り組まれるビジネス上の問題、方法論、チームメンバー、言語、プラットフォーム、朝のコーヒーの取り方など、誰もがすべてを非難することだと思います。レトロスペクティブの良いところは（たとえ自分の頭の中でしか起こらないとしても）これらの要因の一部またはすべてと調和し、それらが問題ではないことに気付く機会です。

過去30年以上の私の唯一の本当の失敗では、プロジェクトは私たちが到着したとき、文字通り何年もの間要件にありました。要件が解決しました。1人は管理職から、数百人はエンドユーザーから来ました。私たちはコードを作成しましたが、コードの多くは素晴らしいものでした。テストと受け入れテスト、変更と引数、変更要求、無給の仕事と有料の仕事、最後の瞬間のボルトオンとシュールなユーモアとVPへのエスカレーションがありました。結局、それはただつまずきました。失敗の理由は、単一の管理要件がエンドユーザーに受け入れられないことでした。そして、どれだけ多くのことを進めようとも、彼らはそれを乗り越えることができず、システムを決して受け入れません。しかし、経営者には他の方法はありません。それがそれで、私たちはたくさんのお金を手に入れましたが、最終的には、

私はまだそのテクノロジーで働いており、それらのプロセスを使用しており、同じ人と仕事をしています。そのクライアントのために別のプロジェクトを行うことさえあります。しかし、エンドユーザーが、自分の管理が要件に注入したものが気に入らないと言ったとき、機能する適切なコードを作成しても、失敗したプロジェクトから保護されないことを覚えています。そして、私はそれから1、2年後ではなく、それについて何かをします。

重要なことを避けながら、数日から1週間ほど退屈して、何が間違っていたのか、それが二度と起こらないようにする方法を見つけようとします。

死の行進と呼ばれる主題に関するすばらしい本があります：http : //www.amazon.com/Death-March-2nd-Edward-Yourdon/dp/013143635X

それを読むことを強くお勧めします。多くの説明でプロジェクトを認識できます。

政治を含む組織の多くの複雑なコンポーネントに大きく依存するため、単一の答えはありません...

私以外の人を非難しました。私がやることは、「Mea Culpa」ドキュメントを書くことです。「私がやった」ことすべてが間違っています。そのプロジェクトには役立たないかもしれませんが、同じ間違いを繰り返さないための良い方法です