免責事項：本日は、失敗したプロジェクトについてのみ説明するため、名前、パスワード、出席者の名前は付けません。
私と私の友人の経験から失敗したすべてのケースは、問題の原因に応じて3つのタイプに分けることができます。
1.利害関係者との協力
多くのプロジェクトの問題の理由は、私たちが顧客の話を聞いたり聞いたりしないためです。これは、「なぜプロジェクトが開始されるのか」という質問に対する答えを見逃すリスクがある最初の段階で特に重要です。
ケース1
社内で合意されていない契約に基づくすべての可能な金融取引をブロックするという単純な課題に直面しました。私たちは効果を計算し、私たちが思うように、すべてのリスクに取り組みました。しかし、議論の中で、メインユーザーはこれはうまくいかないと主張しました：「私たちは生産プロセスを持っています」。それは言い訳のように聞こえました、そして主要な顧客は私たちの仮説を確認し、それをすることを主張しました。
X-dayに、計画に従って機能を起動し、約1時間半後、メインの顧客があまり気分が良くない状態で、「機能しません！」と電話をかけてすべてをロールバックするように依頼しました。
どのように必要でしたか？組織の詳細を内部から知っているユーザーの懸念に耳を傾け、これらのリスクを解決します。誰にでも合うオプションを見つける機会は常にあります。
ケース2
私たちが考えたタスクとシステムを完全に理解したのは機能的な顧客でした。しかし、私たちはこのプロジェクトの実施におけるIT部門の関心を考慮に入れておらず、アーキテクチャの開発段階というかなり遅い時期に彼らのところに来ました。プロジェクトを修正し、納期を変更する必要がありました。機能的な顧客の影響力と能力を過大評価し、大企業の部門間の内部関係を過小評価することにより、時間、お金、評判を失いました。
どのように必要でしたか？顧客の保証にもかかわらず、最初からすべての利害関係者をプロジェクトの作業に関与させ、彼らの利益を考慮に入れること。
ケース3
そして、これはほとんど失敗したケースでした。CEOに代表される機能的な顧客は、コスト会計の方法を変更したいと考えていました。すべての計算によれば、変更の影響は重要であるはずでした。財務ブロックのチームは変更の準備ができており、タスクがITアナリストに届くまでに、決定はすでに行われていました。そしてここで私たちは正しいことをして尋ねました：なぜですか？それはどのように機能しますか？誰がプロセスをサポートしますか？その効果をどのように考えましたか？
その結果、ERPシステムの変更と、プロセスとツールの保守コストを考慮して、効果が再計算されました。その効果はお金の中で「消える」だけでなく、追加のリスクも発見されました。プロジェクトは終了し、社内自動化部門の従業員は、たとえCEOからのタスクであっても、最初に質問することがルールになりました。
結論
- 常に理由、目的、効果を探してください。あなたの立場を議論しなさい。私の友人の一人（クラスマネージャー）が言うように、「聞いて、売らないで...それからもう一度聞いて...そして売るだけだ」;）
- 製品の直接ユーザーと1日を過ごし、彼らのルーチンを詳細に知るようになります。これは、考えられるすべてのニュアンスを予測するのに役立ちます。
- あなた、機能的な顧客、および関心のある人にとって重要と思われるすべてのリスクに対処します。プロジェクトに対して最も否定的なクライアント/ユーザーに特に注意を払ってください。彼らは明らかに何かを知っています！;）
- プロセスの1人の参加者をお見逃しなく。プロセスに参加者を1人にすることはできず、IT部門を常に考慮する必要があります。
2.要件の説明
アナリストにとっての聖なるものは、要件の説明です。他の2つのケースでこの領域のエラーを考えてみましょう。
ケース1
開発チームの1つは、修正が必要なプロジェクトを受け取りました。システムにはドキュメントが付属しており、システムのロジックの説明はSQLクエリを使用して記述されています。作業が開始されるまでに、システムはすでに真剣に再設計されており、SQLクエリはもはや関連性がありませんでした。システムのロジックと機能を理解するために、リバースエンジニアリングに時間を費やす必要がありました。
どのように必要でしたか？プロジェクトの開発レベルとの関連性とコンプライアンスについて、ドキュメントを再確認してください。特にそれを他の開発者に渡すとき。
ケース2
組織内のすべてのプロセスを自動化することは興味深いプロジェクトでした。このプロジェクトには、さまざまなクラスの5つのシステムが含まれ、プロセスを中断することなく続行するには、これらを相互に統合する必要がありました。私がプロジェクトに接続したとき、チームは約2か月間ソリューションのアーキテクチャを設計していました。
顧客とのコミュニケーションの過程で、私は彼がそれをある方法で見ていて、開発者が別の方法でそれを見ていることに気づきました。これらは、プロジェクトを完全に変えた言葉での最小限の合意でした。私は最初から始めて、すべての要件を最初からやり直す必要がありました。なぜですか。何？どうやって？
どのように必要でしたか？プロセスとサブプロセスの実装の要件（どのように機能するか）だけでなく、最終結果がどのように見えるかを明確に説明します。
結論
多くの場合、チームは顧客のコメントを恐れて、「まあ、そのようなもの」と聞いたときに開発に走ります。お客様自身が自分の手で調整を始めた場合にのみ、お客様と共通の言語を見つけたと考えられます。テキストを読むのが便利だと思う人もいれば、図を持っている人もいれば、インターフェースのレイアウトを持っている人もいます。「ナプキンの絵」であっても、共通の言語が見つかるまですべてを試す価値があります。
3.アイデア、製品、またはソリューションの開発
これらは、アイデアが頭に浮かぶときの製品管理についての話であり、他のすべては重要ではありません。
ケース1
情報の入力から従業員からの質問への回答まで、組織内の日常的なタスクを自動化するための優れた製品がありました。そして、すべてが素晴らしかった：私たちは最初の顧客を見つけ、市場を理解しました-たくさんのお金があったように見えました-私たちはいくつかのプロジェクトを立ち上げ、それらを無事に完了しました。そしてその瞬間、私たちは目を開けました。誰もソリューションをサポートするコストを計算しませんでした。そして、それはお金をゼロにするためのすべての可能な試みを消し去りました。
どのように必要でしたか？開発からソリューションサポートまで、プロジェクトのすべての側面を慎重に計算します。
ケース2
もう一つの話は、私たちが市場をうまく動かさなかったときです。市場に競合他社はないが顧客はいる良い製品のアイデアが見つかりました。少なくとも1つ、そして彼は喜んで支払いと投資をしました。私たちはこのプロジェクトに参加し、そのような機能を開発するための理論的根拠の完全な欠如に直面しましたが、私たちはそれを管理しました。
そして、製品を持って市場に参入した後、彼らは競争相手がいないことは無駄ではないことに気づきました。多くの人々は、それが保証するすべての効果にもかかわらず、この機能を無視しています。
どのように必要でしたか？そのような収益性の高い市場セクターに競合他社が存在しない理由を考えて、真実の底に到達してください。
結論：
現在の市場の状況に応じて、1人の顧客ではなく、競争力の枠組みの中でプロジェクトの実行可能性を確認します。
失敗の文化
困難を克服し、再びそれらに陥らないようにするために、あなたは理由を見つける必要があります。多くの場合、それは組織で採用されている失敗の文化にあります。組織の失敗に対応するには、2つの悪い方法があります。
- 非難/罰
間違いを非難し、私たちは主導権を殺します。従業員は創造性を恐れ、安全な決定を下すだけです。これは会社の停滞につながります。
解決策：エラーの境界を定義します。イニシアチブの明示のためのリソースを割り当て、チェックポイントでそれらをチェックする必要があります。さて、事前に合意した厳格な基準に従って、プロジェクトの成功を追跡します。 - 沈黙
この戦術は、同じ過ちを何度も繰り返すことにつながります。そしてこれは、今度は、顧客、競合他社、および市場から見た会社の地位の喪失につながります。
解決策：従業員間の経験交換のシステムを構築します。失敗に対する可能な解決策の議論は、最終的にこれらの間違いを回避するのに役立つ方法論につながります。
合理的な反省は発展を助けますが、これは失敗だけで自分を取り巻く理由ではありません。成功したプロジェクトから学ぶことははるかに楽しいので、バランスを探してください