リソースが限られているプロジェクトを示すいくつかのマーカーを特定しようとしています。
私の経験では、誰かがクライアントにソリューションを売りたがっていたため、プロジェクトは「限られたリソース」のプロジェクトになります。その結果、予算は厳しくなり、機能は選別され、SDLC プロセスは最小限に抑えられます。これらの近道は、会社が利益を上げたり、損益分岐点に達したりする可能性があるように行われます。
これは、限られたリソースのプロジェクトと密接に関連しているのを私が見たもののリストです。
- QAに割り当てられる最小限の時間
- 仕様外の作業に対する厳格な官僚的プロセス
- 変更リクエストの予算が少ないか、存在しない可能性があります
- 開発に時間を費やすことを支持して、形式化されたプロセスは廃止されます
- コンテンツ チェックのような付加価値 QA に費やす時間はありません (たとえば、テキストの文法やスペルの誤り)。
- クライアントのコンテンツ管理またはデータ入力を行うことはできません
- 「十分な」コーディング ソリューションを使用する必要がある
- 廊下でのユーザビリティ テストのための時間の余裕はありません。
- ユーザー ドキュメントやマニュアルを作成するための予算がありません。
- 通常、コーディング前に技術研究を行う時間はありません
- リスク分析文書を作成する時間がない
- プロジェクト スケジュールの代わりに、生産チェックリストを使用することもできます。
- プログラマーがプロジェクト スケジュールの「実際の」時間と推定時間を埋める時間ではありません。
- クライアントに提供される進捗状況の更新は、あまり頻繁ではないか、非常に基本的なものである可能性があります
- クライアントのビジネス ドメインの理解に費やす時間が減る
- プログラマーは、無給の残業をしなければならない場合があります。
- プロジェクトの事後分析に割り当てられた時間はありません
リソースが限られているプロジェクトには、他にどのような確かな兆候がありますか?
===
編集
私は例でいくつかの混乱を解消しようとします. つまり、クライアントには、プロジェクトの費用が 20,000 ドルになるという提案/見積もりが渡されます。その後、クライアントが戻ってきて、「申し訳ありませんが、私の予算は最大 16,000 ドルです」と言います。上司は「提案を16,000ドルにしてください。この仕事が欲しい」と言います。
したがって、実際には、本来あるべき予算よりも少ない予算でプロジェクトを実行する必要があります。ばかげている境界があります。クライアントが「私の予算は 4,000 ドルです」と言った場合、それを実行することはできません。
はい、予算が限られていると、最初からプロジェクトを受け入れるのが悪いビジネス上の決定 (つまり、運命のプロジェクト) であるほどばかげたものになることがあります。
予算が無制限のプロジェクトなどないことは理解しています。多くの場合、ビジネスパーソンは、プロジェクトを実施するかどうかを決定します (ビジネスパーソンは、多くの場合、プロジェクトマネージャーではありません)。