ソフトウェアプロジェクトが失敗する20の理由
すべてのソフトウェアプロジェクトは大きな夢と壮大なビジョンから始まります。 代替宇宙のどこかで、すべての夢を実現するプロジェクトがありますが、私たちの宇宙のソフトウェアプロジェクトはあまりにも頻繁にフィニッシュラインに向かってつまずき、時にはそれを横断することがあります。
もちろん、定義上、ソフトウェアプロジェクトの失敗はバイナリのものではありません。 あなたはうまく動作するが、誰も使用しないコードで終わることができます。 または、コンパイルさえしないコードで終わることができます。 時には、あなたは燃える残骸から有用な何かを救うことができ、時にはそれが爆発する前に逃げるのが最善です。
くすぶっている混乱が冷えると、人々は何が間違っていたのか知りたいので、検死が始まります。 ここで最も一般的な犯人です。
チームメンバーが少なすぎる
プログラマーが少なすぎるとやりすぎてしまうのが一般的な問題です。 開発者は、燃え尽きる前に多くのコードを挽くことしかできません。 私は以前、マネージャーがアジャイルチームからより多くの作業を絞る正しい方法は、前のスプリントの直後に開始されるように各”スプリント”をスケジュー Sprint42は水曜日の午後1時59分に終了し、Sprint43は水曜日の午後2時に開始しました。 次のスプリントがすでに開始された後、回顧的分析会議が予定されていました。 いくつかの賢い男は、彼らが”マラソン”と改名され、すぐに別の仕事を見つけたことを提案しました。
もちろん、何人のプログラマが十分であるかを知るのは難しいです。 時には障害物や問題が邪魔になることがあります。 仕事の規模が2倍になるのはマネージャーのせいではないかもしれませんが、仕事に十分な人がいない場合、プロジェクトは運命づけられている可能性
チームメンバーが多すぎる
プログラマーが少なすぎると、ネットワーク効果がソフトウェアプロジェクトを破滅させる可能性があるため、多すぎると悪化する可能性があります。 より多くの人々はより多くの調整を意味し、それはコードを書くことから時間を取って、より多くの会議を意味します。 しかし、十分な会議を開催しないと、チームAのAPIがチームBのマイクロサービスとインターフェイスしないことがすぐにわかります。
プロジェクトを過剰に人員配置して問題にお金を投げることができればいいのですが、できません。
あまりにも多くのコミュニケーション
ソフ 人間は一緒に働くことができますが、限られた試合でのみ働くことができます。 多くの開発者は、深い没入型の論理的思考からよりオープンでソーシャルモードに精神的なギアをシフトする必要があるため、会議を嫌います。 これには時間がかかります。 何人かのチームリーダーは皆を合わせておくためにより多くの会合の開催によって失敗を戦うことを試みる。 それは高貴な努力ですが、歯車が研削するのを聞くことができます。 チームは同期を維持するのに十分な情報を共有する必要がありますが、それ以上は脳のサイクルを無駄にします。
基本的な機能の変更
理論的には、開発者は自分自身をアジャイルと考えるのが好きです。 それが彼らが言葉を受け入れる理由です。 しかし、時には敏捷性は、バランスをオフに皆を投げることができます。 それはすべて、シフトが基礎となるフレームワークに根本的な変更を必要とするかどうかに依存します。 ボタンを移動したり、色を変更したりするときに、アジャイルになるのは簡単です。 しかし、データベーススキーマを再加工したり、シャーディングとレプリケーションをいじったりする場合、優雅にピボットする簡単な方法はありません。
仕事のために間違った技術を選ぶ
慎重に計画し、正しい機能リストを作成しても、間違った技術を使用すると失敗することがあります。 たとえば、データベースは一般的で柔軟性があるように設計されていますが、アーキテクチャ上の制限があります。 彼らが行うように設計されていない何かを提供するためにそれらをプッシュし、スケールするように求められたとき、彼らは仮想停止に遅 あるいは、一貫性を保つためにACIDグレードのトランザクションが本当に必要であり、データベースがそれらを提供していないことを後で発見するためだけに、NoSQLデータベースから始めることもできます。 おっと
悪い優先順位
良いプランナーは、機能のリストを作成し、それらに優先順位を付けます。 しかし、時には優先順位がそれらを実装する現実と一致しないことがあります。 最悪の場合、最も重要な機能を作成するのが最も困難です。
あなたの開発者は何をすべきですか？ 彼らが最も重要な機能に集中すれば、進歩はなく、機能のどれも提供されなくなる可能性があります。 しかし、彼らは簡単なものをノックを開始した場合、彼らは無価値だ何かで終わる可能性があります。
良い計画にはチェックリスト以上のものが必要です。 建築ビジョンは、それらを提供するニーズとコストを考慮する必要があります。
マーケットウィンドウが閉じます
時にはプログラマのせいではありません。 私のプロジェクトの一つは、アプリにベストセラーの参考書を回すことでした。 この本は、インターネットの前の年にホットケーキのように販売されました。 計画は、その需要を活用し、人々がデータをソートして検索できるようにするインタラクティブなバージョンを作ることでした。 プログラミングチームは、本の中のすべてが含まれていますが、本自体よりも速く、きれいで、はるかに軽いソフトウェアを提供しました。 しかし、誰ももうそれを望んでいませんでした。 そこに十分な他のソースがあったし、誰もニュースサイトがどこでも行うように多くの同じことをした別のアプリを必要としませんでした。
時にはアイデアは素晴らしいようだが、市場は上に移動しています。
建築上の判断が悪い
あるプロジェクトで、データベース内の1行に1つの番号を変更する仕事を与えられました。 ユーザーが登録を完了したら、ユーザーのid番号を最新の注文に追加しました。 右、簡単に聞こえますか？ しかし、システムはマイクロサービスアーキテクチャ上に構築されており、データベースにその列を更新するように指示する1行のコードを書くことでこれを解決することはできませんでした。 いいえ。. アーキテクチャ計画は、既存のスタックに新しいmicroservice呼び出しを追加することでしたが、最初のmicroservice呼び出しが別のmicroservice呼び出しなどをトリガーする必要があ
最後に、このマイクロサービスのネットワークを作成した建築の達人は、それがすべて非常に簡単で、建築の五つの層を通る蛇行した道を概説したと私に言 私の仕事は、5つの異なるマイクロサービスに5つの新しいAPI呼び出しを追加することでした。 そして、各APIは長年にわたって異なるチームによって開発されたもので、私は五つの異なるスタイルのコーディングを理解してエミュレートする すべて一つの番号を変更します。
建築の決定は一生続くことができます—特にあなたの自我がそれらに徹底的に投資され、あなたがそれらを変更することができない場合。 プロジェクトマネージャーは、主な建築計画が機能していないときに気づく準備ができていなければならないので、大きな決定を下すことができます。
政治的対立
政治的要因を技術的な失敗のせいにすることは卑劣に見えるかもしれませんが、それはますます真実です。 プロジェクトが大きく成長し、複数の組織にまたがるように、それは派閥が表示され、グループが制御、リソース、最終的には力のためにジョッキーことは驚
政治的な派閥は、実際の技術的な違いとは異なります。 多くの場合、同じことをさまざまな方法で行う技術標準やコードベースがあります。 XMLとJSONを取ります。 今、私はそれを入力したことを、私はどちらかのファンが同じではない理由を説明するために急いで感じることができ、自分の好きな選択が正しい しかし、チームのある部分が一つの選択を愛し、別の部分が最高の点で競合する派閥を保持しているとき、まあ、摩擦はそれらを引き裂くつもりです。
アーキテクトがアプリケーションを複数の小さなサービスやApiに分割するにつれて、これはさらに一般的になりました。 異なるグループは、これらを制御することになりますし、彼らは常に一緒に取得しません。 グループAがJSONを好きで、グループBがXMLに固執する場合、チームは両方を実装するか、どちらかを変更する必要があります。 グループAとグループBの両方で作業しなければならないチームにとって、三つのすべてが苦痛です。
生産の準備ができていない技術に賭ける
プログラマーは最新のツールやフレームワークが大好きです。 彼らは新しいアプローチが前の生成の下で沼地すべてのcruftを掃除することを信じたいと思う。
しかし、多くの場合、次世代は生産用の準備ができていません。 新機能は完璧に見えるかもしれませんが、すぐには明らかではないギャップがしばしばあります。 場合によっては、コードが少数のファイルタイプのみをサポートしたり、少数のデータベースのみを持つインターフェイスをサポートしたりします。 他の人はすぐに来ている、彼らはあなたを保証しますが、あなたのプロジェクトは今月出荷する必要があり、”すぐに”あなたが必要な機能が完了する前に六ヶ月以上を意味する可能性があります。
すぐに時代遅れになる技術に賭ける
私の経験では、古いものは通常、より信頼性が高く、戦闘テストされていますが、それは古い技術が完璧である それがライブになると、ソフトウェアプロジェクトに不可欠な機能が欠落する可能性があります。 さらに悪いことに、古い技術に賭けると、ラインの変更に基づいて将来の機会を逃す可能性があります。 新しいアイデア、プロトコル、ファイル形式が表示され、実装されていないことがあります。 そして、競合するチームの誰かがあなたがいくつかの新しいプロトコルをサポートしていると主張するならば、古い技術は傷つくでしょう。
非現実的な締め切り
締め切りは難しいです。 多くのプロジェクトは特定の季節かでき事によって販売するためにそれを作る必要がある。 しかし、締め切りが最初に書き留められたとき、あなたの開発者は彼らの方法で障害物やハードルを発見し始めていません。 その後、プロジェクトがスリップし、ソフトウェアが起動されずにイベントが通過すると、コードがスムーズに実行されようとしていても、プロジェクト全体が失敗と見なされます。 締め切りは、誰もが集中し、一緒に引っ張るのに役立ちますが、彼らはまた、非現実的なことができます期待を作成します。
予期せぬ競争
良いプロダクトマネージャーは、ダイビングの前に競争を調査しますが、誰もどこからともなくどの競争が現れるかを予測することはできません。 新しい競合他社が複製する必要がある新機能を導入する場合は、上記の機能の変更と優先順位の不一致に関するセクションを参照してください。
プロセスを急ぐ
多くのソフトウェアプロジェクトは、何かを修正したい人やチームのビジョンとして始まります。 彼らは「Snapchat for Y」や「Uber for Y」のようなフレーズを思いついてから、製品チームがSnapchatやUberと同じくらい反応することを期待しています。 問題は、プロジェクトの範囲を把握し、データフローをスケッチし、UIを想像することは、多くの場合、コードを書くのと同じくらい十倍の作業であることです。 しかし、imagineersはすぐにideaからコードに行きたいと思っています。
ワイヤーフレーム、データベーススキーマ、ユーザーストーリーは単なる手を振っているだけでなく、仕事の不可欠な部分です。 しかし、ほとんどの人は、ソフトウェアプロジェクトはアイデアを実装するコードを書いているだけだと信じたいと思っています。
ソフトウェアの力に対する誤った信念
夢想家はしばしば、世界を変えるソフトウェアの力に対する非現実的な信念を持っている。 多くの人がソーシャルメディアが私たちを団結させると想像していましたが、どういうわけかそれは常に明白であっただけの露出した断層線です。 ソフトウェアプロジェクトは、多くの場合、世界の一部のコーナーに革命をもたらすことを約束するスライドデッキから始まります。 データベース内のビットを押し込んでも誰も変換されない場合、人々は怒ったり、退屈したり、混乱したり、悪化したりします。 彼らは、それが誰もが期待した魔法の変換を提供するために失敗したので、ソフトウェアが壊れていると言います。
多くのソフトウェアプロジェクトはコンパイル、QA、出荷、まともなレビューを得ることさえできますが、最終的にはスライドデッキ上の約束のいずれかを達成することはできません。
悪の下請け
私たちは、わずか数行のコードで魔法を作成することを可能にするライブラリやツールを生産するベンダーが大好きです。 時折、彼らは彼らの力の風を取得し、プロジェクトを破壊するためにそれを使用しています。 バージョン1.0の予算シートは非常に良かったので、経営陣はバージョン2.0を承認することを躊躇しませんでした。 それから売り手は価格を三倍にするか、または五倍にすることによって私達を絞ることにする。
この効果は、ベンダーが意図的にそれをしない場合でも感じることができます。 無料層は、プロジェクトを非常に安く見せることができます。 その後、需要が急増し、第二のバージョンは、需要を拡大すると、実際の価格がでキックします。
海の変化
パンデミックと抗議の一年で、時代精神よりも速く変化したものは何もありません。 このプロジェクトは、強力なプライバシー保護を中心とした機能にしましたか？ おっと パンデミックは、誰もが接触トレースに興味を持ってきました。 誰かが出張に集中したいと思ったか。 おっと ホテル業界は崩壊しました。 大変動のイベントによってupendedされて一年以上のリスクを取ることができ、より大きなソフトウェアプロジェクト。 初めに素晴らしいアイデアのように見えたものは、ライブに行く時が来たときに絶望的に失われ、切断されているように見えるかもしれません。
テクニカルシフト
それは世界全体の変化だけではありません。 技術コミュニティの潮汐の変化は同じ効果を持つことができます。 NoSQLはかつて、リレーショナルスキーマから私たちを解放する天才的なアイデアでした。 その後、誰かがすべてのレコードがローカルスキーマを運んだので、ファイルが肥大化することに気付きました。 優れたアジャイル開発チームは、技術的な海の変化がリーダーシップと顧客の態度を変えるときにシフトすることができます。 しかし、最も機敏なチームでさえ、建築計画からすべての空気を吸う大きな変化に対処することはできません。 このシステムは、Xが素晴らしいアイデアであり、突然Xが汚れていると仮定して構築されました。 時にはそれを爆破して再び主演するのが最善です。
あまりにも多くの追加
いくつかのソフトウェアプロジェクトはうまく起動し、正常に出荷されます。 次に、誰かが追加の機能または3つを追加し、新しいコードを既存のバージョンに移植して、コードがぐったりし続けるようにします。 英雄的な開発者は、最初の建築家がうまく計画している場合は特に、これを数回やってのけることができます。 しかし、ある時点で、財団は崩壊する。 たぶん、データベースは負荷を処理できません。 さまざまなクエリを満たすために必要な結合が多すぎる可能性があります。 良いソフトウェアは、時にはエッジの上にそれをプッシュ少し改善のおかげで、あまりにも脂肪を得ることができます。
ゴールポストの移動
最初の計画では、マーケティング計画を支援するために顧客の支出を追跡するデータベースが必要でした。 その後、いくつかの天才は、天気予報と支出を相関させるために人工知能を使用する機能を追加しました。 または他の誰かが自動的に検索エンジン広告の入札にソフトウェアを望んでいました。 宛先を変更すると、プロジェクトが終了する可能性があります。
変化が単独で物事を台無しにすることはまれです。 しかし、新たな目標は、弱点を明らかにし、故障モードをトリガすることができます。 たぶん、チームは今、プロジェクトを正常に完了するには小さすぎます。 たぶん、技術的な基盤は、新しいアプローチのために乱暴に非効率的です。 決定が目標を変更するために行われたときに誰もが気難しい組み合わせを予測することは困難です。