Xiao Zouは最近開発プロジェクトを引き継ぎ、プロジェクトのユーザーは他の補助情報なしで期待を高め、結果を達成しただけで、2か月以内に完了することを要求しました。
ユーザーが提示した要件と実際の状況を組み合わせて、要件ドキュメントが整理され、合意されました。バージョンは半月後に提出され、正式な環境で数日間継続的にテストされました。テストプロセスの間、ユーザーの上級リーダーは新しいアイデアや新機能を思い付き続けました。ユーザーと実際に協力するために、Xiao Zouは対策も用意しました。
上級指導者は全体に注意を払い、開発の詳細を気にしないため、しばしば進歩を要求します。Xiao Zouは、開発とテストの過程で、関連するバグを常に発見し、開発と設計の最初に詳細を考慮しませんでした。進歩を追求するためのリーダーシップの絶え間ない要求は、開発ロジックとビジネスロジックのカップリングがフォローアップのソフトウェアエンジニアリング要件に従っていないため、製品品質の問題が発生していました。その後の変更と修復は続行されます。
このプロジェクトについて、プロジェクトマネージャーとしてどのように対応しますか？
ITスタッフ、特にプロジェクト管理を行うスタッフにとって、質問をすることは避けられません：なぜ顧客は常にニーズを繰り返し変更するのですか？自身のソフトウェアプロジェクト管理のキャリアの中で、ユーザーのニーズの変化にほぼ毎日直面していました。これらの変化に効果的に対処できなければ、プロジェクト計画が何度も調整され、ソフトウェアの配信日が何度も遅れると感じていました。スタッフの士気はどんどん低くなり、ついに全員が結果を待っています。プロジェクトはすぐに終了するのが最善です。
要件の変更は、具体的には積極的に管理する必要があります。
1.プロジェクト契約で、変更管理委員会（CCB）を設置し、厳密な変更管理プロセスを規定します。一般的に言って、契約段階では、お客様はこの標準化された管理方法を喜んで受け入れます。
2.契約段階で主導権を取得した後、実施段階での厳密な実施も重要です。変更プロセスを厳密に実装することで、顧客との関係に影響を与えることはできません。この点は、プロジェクトマネージャーとテクニカルマネージャーの管理とコミュニケーションの技術に依存します。私たちの目標は、ユーザーが変更を提案できないようにすることではなく、ユーザーが自由に変更を提案することを困難にすることです。
3.ユーザーが提案する変更については、実際の状況に対処し、顧客の立場から顧客を検討することができます。また、一部のニーズは、顧客に後のプロジェクトで実現するように導くことができ、会社にとっても良いプロジェクト機会をもたらすことができます。
継続的な学習と実践では、ソフトウェア開発段階でこの問題を解決できる2つのより効果的な方法をまとめました。
1.プロトタイプを通じてユーザーのニーズを定義するための需要分析段階
ソフトウェアプロジェクトの需要分析の段階では、収集、スクリーニング、処理が必要な大量の需要情報があり、これが需要管理の始まりです。顧客と研究開発担当者のニーズの理解は、「一般にコンセンサスがあり、詳細に違いがある」という特徴があります。コミュニケーションを繰り返しても、最終的には「ユーザー要件の仕様」がタイムテーブルの制限内で作成される可能性がありますが、実際の経験では、ユーザー要件の説明は常に「十分に明確ではない」「十分に明確ではない」ものです。これは主に、この段階でいわゆる製品がすべての人の頭の中で考え出されているためです。この段階では、プロトタイプ開発は実際にすべての人の心に存在する仮想現実を表現する、より優れた補助的な方法です。インターフェース、いくつかのコントロール、外観フォームが固定され、機能の説明が明確であり、これが研究開発部門によるユーザーのニーズの理解です。このとき、再度ユーザーとやり取りして、基本的には「これが欲しい」、「いや、これは欲しいものじゃない、欲しいものは……」と言います。通常の状況では、プロトタイプ後の要件の伝達がはるかに実用的であり、両者の理解はすぐに妥協ソリューションに近づき、開発プロセスを導くことができる要件仕様が正式に生まれました。
2.厳格な需要変更管理プロセスを採用する
要件分析フェーズが終了すると、ユーザーが新しい要件を提供されたソフトウェアシステムに追加するように要求した場合、要件変更管理プロセスを実行する必要があります。このプロセスは、ソフトウェアプロジェクトの確立の最初にユーザーと合意する必要があります。一般的なソフトウェア会社には、変化するニーズに対する管理プロセスがあります。この問題についてユーザーと合意に達するまで、ユーザーにこの管理の必要性を説明できます。ユーザーがそれを受け入れないことを心配する必要はありません。ソフトウェアプロジェクトエクスペリエンスの開発を成功させるための多くの要求がありました。需要変更管理プロセスには、疑う余地のない合理性があります。これはまさにソフトウェア会社の経験と価値です。ユーザーは最終的に理解し、同意します。
胸の写真を撮ってはいけないということを皆さんにお伝えしたいと思います。その前に、「胸の写真を撮ったら、時間どおりに仕上げられません。すべての責任を負うことはできますか？」このようなトラブルを軽減するためのより良い方法があります。つまり、要件分析段階の後で、ユーザーと密接に連絡を取り合うのではなく、ソフトウェアプロジェクトサイクルまたは2者間の初期合意に従ってソフトウェア開発の進捗状況を定期的に報告します。ソフトウェアの研究開発に反復開発が使用されている場合、これは製品の各フェーズがリリース用に提供されたときに行うことができ、相談されたユーザー要件は将来のフェーズでソフトウェアバージョンに組み込まれます。
PMP準備資料を必要とする学生はメッセージを残すことができます！
