project-management - 今日、多くのソフトウェアプロジェクトが失敗するのはなぜですか？

Question

ソフトウェアプロジェクトがある限り、世界はなぜそれらがそれほど頻繁に失敗するのか疑問に思っています。

今日失敗したソフトウェアプロジェクトの数を示すリストまたは同等のものがあるかどうかを知りたいです。過去20〜30年の比較があればいいのにと思います。

ソフトウェアプロジェクトが失敗する主な理由を追加することもできます。私のは「要件が不十分であるか、存在すらしていない」です。これには、「（実際の）顧客/ユーザーは関与していません」も含まれます。

編集：「失敗」という用語を明確に定義することはほぼ不可能です。失敗とは、プロジェクトが予算と時間を10％以上上回っていたことを意味するとしましょう。私の意見では、10％+/-はオファー/入札に適した範囲です。

編集：これまで（2月11日）、ほとんどのポスターは、プロジェクトの失敗は基本的にプロジェクト管理の失敗であることに同意しているようです（失敗が意味するものは何でも）。しかし、私見では、ほとんどの開発者はこの状況に満足していないことがわかりました。プロジェクトが成功しなかったときにマネージャーが罰せられるのではなく、怠惰で無能な開発者チームが罰せられるからかもしれません。

投稿を読むと、開発者側と管理者側の間に大きな「ギャップ」があることもわかります。期待（おそらく要件も）が非常に異なるため、プロジェクトは最終的に成功することができません（時間/予算、ユーザーは満足していません、すべてのファーストプリオ機能が実装されているわけではありません、開発者が強制されたためにバグが多すぎます）短すぎる時間枠で実装する...）

私は自分自身に問いかけています：どうすればそれを改善できますか？それとも私たちはそれを改善する可能性がありますか？誰もが今のやり方に不満を持っているようです。これら2つの世界の間のギャップを埋めることができますか？私たち（開発者）は、「高品質の要件」と「現実的/反復ベースの時間制限」のためにストライキを行い、戦うべきですか？

編集： RalphWestphalとStefanLieserは、Clean-Code-Developerと呼ばれる新しい「コミュニティ」を設立しました。このグループの目的は、ソフトウェアエンジニアリングにより多くの専門性をもたらすことです。独立して、開発者が学位または数トンの経験を持っている場合、あなたはこの運動に参加することができます。

クリーンコード開発者は、SOLIDのような原則を毎日実践しています。プロの開発者は、彼自身の作品の最大のレビューアです。そして、彼は彼が改善し、より良くなるのを助ける内部価値システムを持っています。

チェックアウト：クリーンコード開発者

編集：私たちの会社は現在、「アプリケーション開発とメンテナンスのベンチマーク」と呼ばれることを行っています。これは、ソフトウェアエンジニアリングプロセスの品質などについて外部の誰かからフィードバックを得るためにIBMが提供するサービスです。結果が得られたら、それについて詳しく説明します。

score 30 · Accepted Answer

悪い管理。

プロジェクトは、プロジェクトの基本的な機能に基づいて成功または失敗するのではなく、ユーザーのニーズを満たすかどうかによって決まります。(それらは完全に失敗する可能性があり、その場合、何が可能であったかについての重大な虚偽表示がありました。) ほとんどの場合、ソフトウェアプロジェクトが失敗したり、失敗したりする傾向があるのは、プロジェクトの実現可能性と費用対効果の比率を評価し、目標を設定する過程にあります。成功した。

事実や物事を扱う人 (プログラマーなど) と、それ以外の人 (セールスタイプやマネージャーなど) を扱う人との間には断絶があります。プログラマーにとって、事実は事実であり、対処する必要があります。営業担当者にとって、事実とは他の人が考えていることであり、変更可能です。

有形の事実と無形の事実の間にも違いがあります。労働者が本当にやる気があれば、1 か月で大きな橋を架けることができるとは誰も考えていません。彼らは、移動して所定の位置に固定する必要があるすべての鋼鉄とコンクリート、およびその他のものを見ることができます。ソフトウェアは具体性がはるかに低く、物理的な制限がありません。理論的には 1 か月以内に橋を架けることは不可能ですが、チームがしなければならない「すべて」として、1 か月以内に大規模なプロジェクトを作成できると考えられます。最初にすべてを正しくすることです。1 日に数千行のコードを入力することは物理的に可能です。ただ、そのまま使える可能性は限りなくゼロに近いので問題ありません。一流の開発者の実際の生産性は、実際には単語数ではあまり印象的ではありません。

したがって、柔軟な事実に慣れている人は、物理的な限界を感じず、物事は限界までしか進められず、プログラミングに実際に何が必要かを理解せず、実際にどれだけの生産性が実現可能かについて良い感覚を持ちません。さらに、彼らは平均的な開発者よりも交渉で自分のやり方を理解する方法を知っています。

一方、ソフトウェア開発は本質的にあいまいです。物理的な製品の作成は簡単だからです。ソフトウェアが開発されたら、そのコピーを迅速かつ安価に作成できます。ソフトウェア開発は設計作業であり、純粋で単純です。コンパイラやウィザード、コード生成など、製造に相当するものは容赦なく排除されます。開発者は、不可能を望んでいるマネージャを前にして、不可能が実際には不可能であるとは言い難いことに気づきます。柔軟性を感じるほど未知の事実が与えられた場合、強力な交渉スキルと決意を持つ人は通常、自分が望む答えを得ることができます。

この断絶を考えると、それを橋渡しするのは誰の責任なのかと尋ねる人がいるかもしれません。私の意見では、答えは明らかです。さまざまな人々の考え方を理解する責任は、他の人々への対応を専門とする人々にあります。さまざまなタイプの人々を調整する責任は、これらを調整する仕事をしている人々にあります。したがって、管理者。

ソフトウェア開発と開発者を理解しており、他のマネージャーとうまくやり取りできるマネージャーはうまくいき、彼らのプロジェクトは一般的に成功します。世界にはまだ他のタイプのものが多すぎます。

score 20 · Accepted Answer

直接的な答えではありませんが、仮想ケースファイルは、政府が支援する大規模な資金のあるプロジェクトが依然としてどのように機能するかについての魅力的なケーススタディであることがわかりました。

ソフトウェアプロジェクトが失敗する主な理由を追加することもできます。

別のIEEESpectrumOnlineの記事「ソフトウェアが失敗する理由」では、まさにこの問題について考察しています。主なポイントを以下にまとめます。

非現実的または明確でないプロジェクトの目標
必要なリソースの不正確な見積もり
正しく定義されていないシステム要件
プロジェクトのステータスの報告が不十分
管理されていないリスク
顧客、開発者、およびユーザー間のコミュニケーション不足
未熟な技術の使用
プロジェクトの複雑さを処理できない
ずさんな開発慣行
不十分なプロジェクト管理
利害関係者の政治
商業的圧力

score 11 · Accepted Answer

11

計画が悪い。

于 2009-02-09T14:20:18.680 に答える

score 11 · Accepted Answer

ホフスタッターの法則

ホフスタッターの法則を考慮に入れても、常に予想よりも時間がかかります。

score 10 · Accepted Answer

管理ミス。

SW プロジェクトは、認識された問題に対して開発者を投げることによって開始されます。プロジェクトが進行するにつれて、ビジネス要件が具体化します。締め切りが守られている間に新しい機能が追加されます。より多くの開発者が投入されます。元のプロジェクトメンバーは辞めるか、解雇されます。この時点で、プロジェクトには時間、お金、およびリソースが投資されすぎているため、キャンセルすることはできません。締め切りが過ぎると、完成品が明らかに不足しているにもかかわらず、プロジェクトは完了し、成功したと宣言されます。

そういえば、SW プロジェクトが失敗するのを見たくてたまらなかった...

score 10 · Accepted Answer

正直なところ、ほとんどのプログラマーは自分の仕事があまり得意ではないからだと思います (そして、単にコードを作成するという意味ではありません)。stackoverflow の人はおそらく例外です。残りの人については知りませんが、コンサルタント/契約プログラマーとして、私は多くの場所で、またはその周辺で働いてきました。平凡または貧弱なプログラマーと優れたプログラマーの比率は約 10 対 1 です。

私の強みの 1 つは、常に正確に見積もりを行い、予算内または予算内で納期どおりに納品することです。コストと納期を 10% 下回ることを常に目指しています。次に、クライアントに、予想よりも少ない $$ で物事を成し遂げたので、追加したい「追加機能」はどれですか? と伝えたいと思います。

完全に機能する製品であっても、遅れたり予算をオーバーしたりしても、多くのビジネスマネージャーは失敗とみなします。プログラマーは、コストや期限をほとんど考慮せずに、自分の作業の技術的な側面だけに集中することがよくあります。成功したプロジェクトと見なされるには、3 つすべてをうまく行う必要があります。私の周りには間違いなくサークルをコーディングできるプログラマーが他にもたくさんいますが、プロジェクトにお金を払っている人にとっては、それだけでは十分ではありません.

score 5 · Accepted Answer

それは、もう誰も読んでいないように見えるからです。プロジェクトが失敗するすべての理由は、何度も何度も分析されてきました。プロジェクトの 80% が失敗する理由を知るには、3 冊の本を読むだけで済みます。

The Deadline: A Novel About Project Management (Tom Demarco、1997 年発行) これは優れた入門書であり、非常に面白いものです。Peopleware : Productive Projects and Teams (Tom Demarco、1987 年発行) The Mythical Man-Month: Essays on Software Engineering (Fred Brooks、1975 年発行)

私たち専門家は、3 ～ 5 年ごとにすべてを忘れているように見えます (「集中型コンピューティングは非効率的です。クライアントに処理させる」とクラウドコンピューティングを参照してください)。

score 4 · Accepted Answer

(プログラマーの観点から言えば、私はプロジェクトマネージャーではありませんが、プロセスに関与することはよくあります)。

多くの人が、悪いプログラマーは風土病であると述べています。しかし、これは別の意味でも真実だと思います.複雑さを予測するのが難しいという点で、私たちは皆悪いプログラマーです.50年にわたる魔法の弾丸の見積もりと計画スキームが解決できなかった避けられない問題.

大規模なプロジェクトの副作用を予測することは、プロジェクトが大きくなるにつれて指数関数的に難しくなります。これは確かに退屈な自明の理ですが、私にとっては、見積もりプロセスに関与したプロジェクトで、設計上の決定の予期しない結果が発生する場合に遭遇したことを意味します。すべてがひどく停止するか、少なくとも数日間のバグ修正が発生します。これは、誰も予見できなかったものであり、不正や愚かさではありません。それは、十分に複雑なシステムの性質にすぎません。

組み込みの不確実性は別として、概要がわかっているものを過小評価する傾向もあります。

不確実なものは拡大され、明確なものは最小限に抑えられ、不確実だとは思わなかったものが本当に命取りになります。

score 4 · Accepted Answer

一番の理由は、プロジェクト管理の失敗です。

PM の存在理由はプロジェクトを成功させることであり、プロジェクトの失敗は彼らの失敗です。確かに、彼らが制御できない要因はありますが、そのリスクを管理することは、依然として PM の職務内容の範囲内であり、唯一の撤回条項は、意思決定を行うフードチェーンの上層部の誰かでなければなりません (これは PM に対して行うにはひどいことです)。または神の行為。

私の経験では、ほとんどの失敗は、PM の作業が迅速で緩い、または存在しないときに発生します。たとえば、営業担当者から意思決定が流れ始めたときや、クライアントが変更管理を命じ始めたときなどです。優れた PM は貴重です。

score 3 · Accepted Answer

失敗は判断です-実際には、より多くの告発です。

「プロジェクトは予算と時間の10％以上でした。」

どの予算？どのスケジュール？

6ヶ月前、6ヶ月かかるという計画を書きました。

3か月前、ユーザーはさらに多くのものを要求しました。あと9ヶ月かかるという計画を立てました。

先月、プロジェクトは予算を6か月超えていたため、「失敗」したと言われました。

ちょっと待って。ユーザーが望むものを提供しました。それは「元の」見積もりを超えていました。修正後の見積もりでした。ユーザーはもっと欲しい。ITはより少ないものを望んでいます。

score 3 · Accepted Answer

ここでは、他のほとんどの人とは異なる側面からアプローチします。

プロジェクトが一定期間にわたってゆっくりと失敗することに気付きました。確かに、その時も良くなりましたが、それでもまだ利益を上げていません。この市場では、収益性と黒字であることは成功を意味します。

なぜ失敗するのですか？シンプルだと思います。

ソフトウェアは銀行口座のようなものであり、原初のにじみではありません。そこにリソース (時間、お金、集中力、努力) を投入しなければ、失敗とコスト以外には何も得られません。そのため、プロジェクトに投資する必要があり、初期の作業が今後数年間の舞台を設定する場合があります。コンピューターに泥を投げつけて、2 年後に新しいマウスを購入し、1,000 万ドル後に 1,000 万ドルを期待することはできません。

今日の最大の問題の 1 つは、第三世界の国の「予算開発者」です。私は彼らが市場の一部であることを恨みませんが、十分な資金を持つシリコンバレーの新興企業が彼らを探し出し、予算基盤 (フレームワークやプロトタイプさえも) を手に入れることは、将来への不十分な投資をすることです. これとまったく同じ予算の枠組みが、今日、私の友人たちを非常に悩ませている原因です。今すぐ動作します。書かれた時点では機能していましたが、うまく書かれておらず、メンテナンスに時間をかけている人はほとんどいません。会社がソフトウェアを止めて、最初に書かれたはずの方法で書き直せば、このような問題は起こらなかったでしょう。彼らは時間に余裕がありますか？いいえ。彼らはそれを気にする前に、利益を上げる必要があります。

ことわざにあるように、「私はそれを作ることができます。安い、速い、または良い。今、それらのいずれか2つを選択してください。」私も含めて、誰もが3つすべてを望んでいます。しかし、最初からプロジェクトを成功させるために必要な時間、計画、および作業を投資しない場合は、後で誇れるものは何も期待できません。あなたとあなたのような他のすべてのエンジニアが、最初からそこにあるべきではなかった欠陥をあちこちに見ることができる、偽造されたモナリザのように感じるでしょう.

そう：

時間、お金、労力、集中力など、余裕のないことに取り組まないでください。
計画をスキップしないでください！
最も重要な時期に書き直すことを恐れないでください。(あとで、歯医者に行くよりも悪いことになると思います。)
官僚機構の力を過小評価しないでください。
そして、あなたが最も多くの時間を費やすべき場所で安っぽくならないでください. 後で費用がかかりますが、保証されています。 そして、あなたではない場合、他の誰かがあなたのために弾丸を取ります.

score 2 · Accepted Answer

予算と時間を超過することは、失敗の適切な定義ではありません (また、実際に予算と時間を超過しても、必ずしも成功とは限りません)。Expert Project Management - Project Success: Looking Beyond Traditional Project MetricsでPMP の Hugh Woodward が提供する次の例を見てみましょう。

シドニーオペラハウス: 優雅な帆がシドニーハーバーを支配するシドニーオペラハウスは、間違いなく世界で最も有名な建物の 1 つです。しかし、プロジェクト管理の観点からは、これは見事な失敗でした。1959 年に建設が開始されたとき、700 万ドルの費用がかかり、建設には 4 年かかると見積もられていました。最終的に 1973 年に 1 億ドル以上をかけて完成しました。

[...]

Project Orion : Kodak の新しい Advantix 写真システムを開発するためのこの大規模な取り組みは、プロジェクト管理の観点から非常にうまく管理されたと言われています。PMI はそれを 1997 年の国際プロジェクトオブザイヤーとして認め、ビジネスウィークはこのシステムを 1996 年の最高の新製品の 1 つに選びました (Adams, 1998)。しかし、Kodak の株価は、Advantix システムの導入以降、67% 下落しました。デジタル写真への切り替えの加速を予測できなかったことも一因です。

企業イントラネット: Finch は、グローバル化とコミュニケーションの改善を目的とした企業イントラネットの実装を含むプロジェクトについて説明しています。従来のプロジェクトの観点からは、成功基準を満たせませんでしたが、それほど大きくはありませんでした。それは 1 か月遅れており、わずかな予算超過で達成されたと考えられています。しかし、プロジェクトマネージャーと上級管理職の両方が、プロジェクトが成功したと見なしていました。ハードウェアとソフトウェアは最小限の中断で正常にインストールされ、すべてのスタッフメンバーが企業のイントラネットにアクセスできるようになりました。しかし、実装後、従業員はイントラネット機能を限定的にしか使用しませんでした。したがって、プロジェクトの主な目的は達成されませんでした。この場合、プロジェクトマネージャーと上級管理職の両方が、あまりにも狭い目標に焦点を合わせていました。

[...]

製造工場の最適化: 北米に 5 つの工場を持つ製紙会社は、ボトルネック解消プログラムに着手して製造能力を増強することを決定しました。必要な機器を設置するためにプロジェクトチームが編成され、2,600 万ドルの費用をかけて 18 か月で作業を完了するように請求されました。しかし、ほとんどすぐに、プロジェクトチームは、無関係なキャッシュフローの問題が解決されるまで、主要な支出を延期するよう求められました。チームは作業を完全に停止するのではなく、ボトルネック解消プログラムの基礎となるテクノロジーのプロトタイプを作成する戦略を採用し、実際に安価で効果的なソリューションをいくつか開発しました。プロジェクトの進行が承認された後も、チームは同じアプローチを続けました。このプロジェクトは最終的に 5 年間に及びましたが、結果として容量が増加し、当初のコミットメントの 3 倍になりました。

[...]

これらの例の中で、本当に成功したのはどれですか? 2002 年冬季オリンピックやバトゥヒジャウ銅コンセントレーターのような例は、これらが真の成功を収めていることを示唆しています。なぜなら、それらは伝統的なプロジェクトマネージャーの成功の定義を満たしただけでなく、プロジェクトスポンサーの成功の認識も満たしていたからです。

Project Orion、企業イントラネット、ラップトップのアップグレードなどの例を見始めると、従来の指標が失敗し始めていることに気付きます。これらのプロジェクトは、プロジェクトマネージャーの成功の定義では成功と見なされますが、スポンサーの成功基準を満たしていません。プロジェクト Orion の例は、このプロジェクトが 1997 年に PMI (Project Management International) によって International project of the year として認められたため、非常に驚くべきものです。それでもコダックの収益は増加しませんでした。なぜなら、彼らはデジタルカメラの普及を予測していなかったからです。

最も興味深いのは、製造工場の最適化とシドニーオペラハウスの例です。どちらも、従来のプロジェクトマネージャーの成功基準を満たしていませんでしたが、実際には成功と見なされていました。これは、シドニーオペラハウスが「1300% のコストオーバーラン」と「250% のスケジュールオーバーラン」を持っていたことを見ると、特に衝撃的です。

プロジェクトが従来の成功基準を満たしていなくても、利害関係者にとっては成功している可能性があることに気付くと、プロジェクトマネージャーは困惑します。成功を実際にどのように定義しますか? スポンサーのニーズを満たしていたはずの「挑戦的」プロジェクトがキャンセルされる可能性はありますか? また、現在予定通り、予算通りで、定義されたニーズを満たしているキャンセルすべきプロジェクトを特定することは可能ですか?

その結論についてどう思いますか。成功を実際にどのように定義しますか?

score 2 · Accepted Answer

よくある間違いの 1 つは、営業担当者と技術担当者が十分にコミュニケーションをとっていないことです。そのため、営業担当者は、技術的に予算内で実現不可能なものを販売します。（そして、彼らはボーナスで走ります:)）

score 2 · Accepted Answer

私の答えは、これ以外のものとはかなり異なりますが、ここでは非常に一般的です。キラーバグです。ソースコードを掘り下げるまで知らなかったソースの1つのスイッチが原因で、プロジェクトをさらに2週間（50％余分な時間）進めました（ヘルプやWebには何も文書化されていませんでした）。

score 1 · Accepted Answer

上記の Construx リンクは本当に良いです!

多くのプロジェクトはバラ色の現実に基づいて管理されています。マネージャーは、開発者に楽観的な見積もりを与える傾向があります。しかし、たとえば 20 週間のプロジェクトが 10 週間に「減額」されるとします。要件フェーズは 2 週間ではなく 1 週間になりました。1 週間後、要件は完了していませんが、プロジェクトは続行されます。今、あなたは不安定な状況で働いています--そして、伸びたスケジュールで!

これは面白いかもしれません。かつて私の向かいの部屋にこの老人がいました。彼の役職はシステム管理者でした。しかし、彼が管理するはずだったシステムはそこにありませんでした。経営陣は完成したと思っていましたが、完成したことはありませんでした。その男は、飽きて別の場所に移るまで、約 1 年間ゲームをプレイしました。

一番面白い部分は？彼が去った後、経営陣は新しい求人を出しました！

score 1 · Accepted Answer

人々/企業は自分たちの失敗について誇らしげに叫ばないので、多くのケースが聞かれることはありません.

score 1 · Accepted Answer

プラクティスとソフトウェア開発方法の不適切な使用。私の経験では、プロジェクトが失敗した大きな理由の 1 つは、開発チームがソフトウェア開発プロセスに向き合うために間違った方法を使用したことです。どのように機能し、何が必要かをよく理解せずに方法論を選択すると、計画が不十分であるなど、プロジェクトに時間がかかる問題が発生する可能性があります。

また、よくある問題は、テクノロジーを事前に評価せずにテクノロジーを使用して、それをどのように適用できるか、またそれがプロジェクトに何らかの価値をもたらすかどうかを理解することです。

score 1 · Accepted Answer

IT Project Failuresは、プロジェクトの失敗に関するブログです。それについて読みたい場合は、ここにいくつかの回答があるかもしれません。

私自身、これの大部分は、実際には答えがはるかに自由な場合に、$y で x か月に予想されることを正確に述べることができるかという問題にかかっていると思います。たとえば、企業がERPまたはCRMシステムを交換する場合、すべての要件を正確に満たすことはできない可能性が高く、そのため、そのようなものを引き受けることでいくつかの変更、バグ修正、および追加機能が発生します。大規模なプロジェクト。例えとして、高校や大学に入学する何人の学生が、授業を受けずに 4 年間すべての正確なスケジュールを述べ、実際にそれを最後まで守ることができるかを考えてみてください。専攻やコースを変更する人もいるので、そうする人はほとんどいないと思います。

score 1 · Accepted Answer

これについては、いくつかの優れた研究が行われています。Construx Web サイト (Steve McConnells company) からのこのリンクをお勧めします。

score 0 · Accepted Answer

前に述べたように、ソフトウェア開発に携わる大多数の人々は実際にどのように理解していないか

問題について学ぶために適切な質問をする
ユーザーの目標を評価し、期待を判断する
利用可能な技術と関連するエコ構造を理解する
直接的/間接的に関与するチームのほとんどは、スキルが不十分です。
彼らが間違っていることを認めたり知らなかったりして、彼らは行動を起こすことができますか。

完璧な要件と関連する定義があっても、多くの開発者は自分たちが何をしているのかを知りません。

ここで尋ねられる質問の種類を見てください。同じ同等の質問をした医者に行きませんか。怖いのは、彼らがどのように学び、推論するかを尋ね、知らないということです。

score 0 · Accepted Answer

私が聞いた最後の統計は、プロジェクトの90％が時間の経過または予算の超過であるというものでした。したがって、それが失敗したと考える場合は、少しやめてください。

それが失敗する理由は主にプロセスにあります。私たちソフトウェアエンジニアは、要件を収集し、顧客を管理するという良い仕事をしていません。ソフトウェアの構築はIT以外の人々にとって「怪しいお仕事」であるため、土壇場での変更が難しい理由を理解することは困難です。家を建てて、レンガでできた家の裏側に別のドアをすばやく追加できない理由を明確に示すのとは異なります。

score 0 · Accepted Answer

プロジェクトが本当に成功しているかどうかを正確に判断するには、当初の見積もりや予算はおそらく不十分な尺度です。ほとんどのエンジニアは、政治的圧力のためにどれくらいの時間がかかるかを過小評価する傾向があり、いずれにせよ見積もりの方法を知りません。多くのマネージャーは、上司を喜ばせるために非現実的な締め切りを望んでおり、何が関係しているのかを理解していないことが多く、さらに、実際に問題を解決するのではなく、見て理解して会議の棒として使用できるものであるため、計画を立てるのが苦手です。実際には、企業が予算編成の目的で大まかな費用を見積もるのに役立ちます。少なくとも、ある程度の目安にはなります。

プロジェクトの成功をより適切に測定するには、ユーザーは満足していますか? それはビジネスがお金を稼ぐのに役立ちますか？獲得した資金は、システムのコストをどれだけ早く回収するのに役立ちますか? ただし、これらは単純な計画よりも測定が困難です。

最終的には、たとえ残業をすることになったとしても、締め切りに間に合わせたほうがよいことがわかりました。くどいですが、それが現実です。

score 0 · Accepted Answer

ソフトウェアプロジェクトが予算を超過したり、完了までに予定以上の時間がかかったりするだけではありません。新聞を開いて、橋のような公共プロジェクトを見てください。

しかし、ソフトウェアプロジェクトの場合、すべてをキャンセルする方がはるかに簡単です。橋や建物が半分完成したら、後戻りはできません。インフラストラクチャの半分が整っています。目立ちますし、撤去するにはお金がかかります。

ソフトウェアプロジェクトの場合は、Shift-Delete キーを押しても誰も気付かないでしょう。

正確なコスト分析を行うのは非常に難しい仕事です。

score 0 · Accepted Answer

このスレッドは、有能で不幸なソフトウェア開発者、エンジニア、プロジェクトマネージャーなどの最大のグループを 1 か所に集めることができたと思います。

私は、ここに立ち往生しているほとんどの投稿と同じ見解を持っています。仕事 (プログラミング) と成功が私たちの生活の最も重要な部分であるときに、同僚が良い仕事をしていないのを見ることで、多くの苦しみから生まれていると思います.

http://www.clean-code-developer.de/ 彼らには信じられないほどの理由があります! そして彼らの哲学を先取りすれば、開発者や IT プロフェッショナルの主流が最近非常に ROT であるため、ヒーローの新しいレイヤーを作成することができます.

ここブラジルでも似たようなことに取り組んでいます。なぜなら、PM とソフトウェア開発者 (.NET) の両方として、ソフトウェアを生き生きとさせるという私たちの職業が大好きだからです。ほとんど手間をかけずに大金。

...確かに、コンピューターの優しさの前で一夜を過ごすことは考えていません。しかし、重要な少数の人々は、それを複数回行っています。

score 0 · Accepted Answer

さまざまな議題

経営陣は、開発者が何をしているか、どのようにコードを作成しているか、遭遇した困難を本当に理解していません。彼らが気にかけているのは、時間通りに納品される最終製品だけです。しかし、開発者にとって、彼らは技術的な側面に関心があり、私たちが誇りに思っているソリューションで適切に作成されたコードです。

締め切り

開発者が、より良いコードを作成できたらいいのにと言うのをよく耳にします。締め切りによって、良いコードではなく、単に機能するものを作成するように迫られることがよくあります。これらの期限が非現実的である場合、問題は悪化します。

score 0 · Accepted Answer

FBI の仮想ケースファイルシステムを使用すると、プログラム管理が不十分になります。このプログラムには、9.11 以前の要件と 9.11 以降の期待がありました。政府の管理者が仕事をしていたら、契約変更があったでしょう。

http://government.zdnet.com/?p=2518

「セーフガードがほとんどない無制限の契約のため、ソフトウェアが適切に機能しなかったにもかかわらず、SAIC はプロジェクトがより大きく、より複雑になるにつれて、1 億ドル以上を手に入れました。プロジェクトに関与したか、後に政府のためにレビューした人々によると、プロジェクトに対するFBIのアプローチには大きな欠陥がありました。」

700,000 行のコードで $105,000,000 がコード 1 行あたり $150 になります。悪くない。

project-management - 今日、多くのソフトウェアプロジェクトが失敗するのはなぜですか？

26 に答える 26

Related

Reference