Forbes Technology Councilの
専門家パネルによる投稿
成功したCio、Cto&Forbes Technology Councilの幹部は、技術&ビジネスに関する直接の洞察を提供しています。
写真：
ゲッティ
技術チームは、多くの場合、高い期待を持って新しいソフトウェアプロジェクトに突入し、プロジェクトが脱線した場合、それはすべてのよ 技術指導者は、時間と予算のドルを無駄にすることを避けるために、事前に潜在的なプロジェクトの落とし穴を認識する必要があります。
フォーブス-テクノロジー-カウンシルの専門家は、プロの任期で多くのプロジェクトを監督してきました。 以下では、それらの14は、ソフトウェアプロジェクトのヒラメと技術チームが罠に陥るのを避けるために何ができるかの共通の理由を共有しています。
1. ビジネスのニーズを理解していない
ソフトウェアプロジェクトが失敗する理由の一つは、ビジネスのニーズを理解していないことです。 ビジネスは、要件を詳細に明確に明確にする必要があります。 機能と機能をビジネスのニーズに正確にマッピングする必要があります。 熟練したビジネスリーダーをプロジェクトチームに割り当てることは、成功のために不可欠です。 -ウェズリー-クルック、FPコンプリート
2。 優先順位に関するコンセンサスに達することができない
ソフトウェア開発プロジェクトが失敗する理由は様々ですが、大きな影響を与える共通のものは、プロジェクトのスポンサーとプロジェクトチームがプロジェクトの最優先順位に明確に整列していない場合です。 これらの優先順位を”必須”、”必須”、”可能性”に分解することで、特定の機能の反復と配信のための強固なフレームワークを提供することができます。 -Jahn Karsybaev,Prosource IT
3. 明快さと実行戦略の欠如
ソフトウェアプロジェクトの主な目標は、ビジネスの問題を解決することです。 これには、効果的で効率的なプロジェクト管理と利害関係者の期待管理だけでなく、ビジネスの問題の定義に関する利害関係者のグループ全体による明確なコンセンサスと、ビジネスの目的を解決するソフトウェアを提供するための堅牢な実行戦略が必要です。 上記のいずれかの側面に対処できないと、脱線したプロジェクトが発生します。 -カルティックアガルワル、テクノシップ株式会社
4. エンドカスタマー
から始まらないソフトウェアプロジェクトは、（時間通りまたは遅れて）実装され、開発者が解決した問題が実際には顧客が解決す 顧客、必要なもの、支払う意思のあるものを深く理解することは、プロジェクトのパフォーマンスの上限を設定し、物事が脱線したときにチームに再び焦点を -ガイ-ヤリフ
5 不明確な要件
ソフトウェアプロジェクトが失敗する最も一般的な理由の一つは、不明確な要件と詳細な説明の欠如です。 多くの場合、クライアント自身が何を見たいのか正確にわからず、その結果、プロジェクトは前進することができません。 あなたの顧客と伝達し合い、プロダクトの未来の彼らの詳しい視野を頼むことはプロジェクトが失敗しないことを保障することへキーである。 -ダリア-レシュチェンコ、サポートユーラップ株式会社。
6. “銀の弾丸”
を期待することは、あまりにも頻繁に、熱意は、ことわざの”銀の弾丸”が与えられた問題を解決するという誤った信念から生じる。 しかし、適切な解決策はめったにそう単純ではありません—彼らは方法論、戦略とチームサポートのブレンドではなく、単一のアクション、技術やアイデアの結 技術指導者は、オープンなコミュニケーションを奨励し、課題を解決するために参加型グループの意思決定を活用す -クリストファー-ヤン、企業旅行管理
7。 サイロでの作業
ソフトウェアプロジェクトが失敗する最大の理由は、チームがビジネスニーズではないか、適切な問題に対処していないものを構築す 両方の理由は、ビジネスと技術の間のずれの結果です。 これを回避するには、ビジネスが解決しようとしている問題を特定し、サイロではなくビジネスと一括して作業することが重要です。 -Tanvir Bhangoo,Freshii inc.
8. スコープを事前に定義できると考える
問題を理解し、ユースケースを事前に定義することは重要ですが、開発中のビジネス要件の変化に適応しなければ、 残念なことに、一部の技術チームはまだ元の目標を達成することを主張しているため、努力が無効になったり、失敗したりすることさえあります。 -ソン-バク-トー、タタ-コミュニケーションズ
9。 調整と詳細な計画の欠如
多くのソフトウェアプロジェクトは、適切な調整と詳細な計画の欠如のために遅れたり失敗したりしています。 チームは、成果物間の依存関係を特定し、エンジニア自身からの見積もりを含むボトムアップ計画プロセスを実装する必要があります。 リリース計画が設定された後、私は問題が浮上し、新しいリスクが特定され、管理されている毎日15分のスタンドアップミーティングを実行します。 -デイヴ-マリアーニ、AtScale
10。 未定義の役割による摩擦
未定義の役割は、多くの場合、プロジェクトチームに摩擦を作成します。 最初からDACIフレームワークを使用して、誰が何の権限を持っているかを明確に定義してみてください。 立ち往生したプロジェクトのために、ドライバ、承認者、貢献者であり、プロジェクト内で通知された人に再校正することは、新たなコラボレーションと自治 -レオレアヴィダル、Lob.com (株)
11. ソフトウェアの過剰カスタマイズを期待する
多くの場合、ソフトウェアはすべてのニーズに合わせたレベルにカスタマイズできると信じています。 それは誤解です。 現実的であることは重要である。 ソフトウェアの機能に関する要件を定義します。 あなたが行くように変更要求を行うには調整が必要ですが、それは不満を避けるために着用する必要があります帽子です。 -Bhavna Juneja,Infinity,A Stamford Technology Company
12. 規律の欠如
私たちが家を建てて青写真を変え続けると、プロジェクトの予算は制御不能になり、締め切り後の締め切りは見逃されるでしょう。 プロジェクトの成功がどのように見えるかのビジョンを作成します。 それをロックダウンして実行します。 他のすべての素晴らしいアイデアと迂回路は、プロジェクトの後の段階で考慮することができます。 -サム-ポラコフ、ネクステラス、株式会社
13. 開発ポットに手が多すぎる
は、社内で構築しているかどうかにかかわらず、初日から関与している人を確立（および制限）します。 これは、複雑なプロセスと通信チャネルを持つ大規模なハイテク企業にとって困難な場合があります。 しかし、アプリ開発の世界では、このような複雑さは、スコープのクリープと終わることのないプロジェクトのタイムラインに餌食になることなく、すべての人のユニークなビジョンに一致する完全に実現された製品を作ることに有害です。 -ジョシュア-デビッドソンChopDawg.com
14. ソフトスキルを十分に重視していない
変更プロセスの管理に明確で意味のある焦点が欠けているか不十分であることがよくあります。 彼らは技術的な仕事に超焦点を当てているが、トレーニング、コーチング、チームビルディング、ソフトスキルに向けて十分なエネルギーを適用していないので、私は様々なカテゴリで、組織の異なる種類やサイズの配列で多くのソフトウェアプロジェクトが課題に遭遇して見てきました。 -アミスナガラジャン、ラサ。イオ