厳しい締め切りのシナリオでプロジェクトの仕様の急速な変更に対処する方法は？ [閉まっている]

Question

本当に厳しい締め切りを課しているプロジェクトマネージャーに対処する方法ですが、締め切りが実装する新しい機能と仕様の変更をもたらす1日ほど前に、別の厳しい締め切りがあります。

これについて最悪なのは、以前に実装されていたビジネスルールが適用されなくなったり、「利得」がなくなったりするため、新しいもののほとんどが既存のコードの大幅な書き換えにつながることです。個別に処理する必要がある奇妙なコーナーケース。

システムをどれだけ拡張可能にしようとしても、最後の瞬間に文字通り出てきて、すぐに実装してサポートする必要があるものが常にあるようです。

このような状況に対処するにはどうすればよいですか？それは本当に士気を低下させており、ある同僚はすでにチームを辞めています。

Answer 1

あなたが何をしても、あなたは人間であり、間違いを犯したり物事を逃したりすることは事実です。ただし、要件の定期的な変更は、ほとんどの場合、要件が不十分であるか開発プロセスが不十分であるか、その両方の結果です。

前もって設計しているか

ビジネス分析は、開発者、プロジェクトマネージャーなどによって短い間隔で定期的に行われます。ほとんどの開発者は1日目にハッキングを開始したいだけで、ほとんどのPMはそれを許可しています：＆quot;そのばかげたビジネス分析に時間をかけることなく、1日で建設段階に移行します。それは完了ボーナスに最適です！＆quot;しかし、PMの主な仕事は、プロジェクトを（時間と予算内で）制御し続けることであることに注意してください。それは彼らが完全に無情だと言うことではありません。優れたPMは、スコープ制御を実施し、コミュニケーションを促進することで目標を達成します。どちらも有用です。

しかし、時間をかけて本当に必要なことを考え、考えられるシナリオをステップスルーすることで、対処している問題に重大な違いが生じる可能性があります。

• 完全なビジネス分析を実行しようとしても、最後の最後の変更に終わっている場合、おそらくあなたの問題はもう1つの古典的な課題です。あなたの主題の専門家は、これらのコーナーケースを処理し、識別する上であなたの最高の武器です。分析プロセスに関与していないユーザーがいる場合は、より優れた主題の専門家を取得します。
• また、ユーザーは通常の作業に忙しすぎているため、ユーザーが離脱する可能性もあります。その場合、それは管理上の問題であり、プロジェクトへの参加が仕事の一部であるという指示を彼らに与える必要があります。多くの場合、「昨日やり遂げる」ように言ったのと同じ管理者が、プロジェクトは、しゃっくりなしで、リソースなしで魔法のように起こることを期待しているナックルヘッドの同じグループです（彼らはカスタムソフトウェア開発の複雑さを理解せず、それが簡単であると仮定するという点で一般的です）。経営陣が無知で変化しない場合...まあ、あなたは残業してあなたが説明した問題に対処するか、新しい仕事を得る必要があります。

アジャイルヘルプはできますか

それらのコーナーケースについて、ユーザーが後でではなく、より早く説明してくれるといいでしょう。これは、トビー・ヘデが彼の投稿で議論したことに関連しています。おそらく、未研磨の状態であっても、できるだけ早くユーザーの前にソフトウェアを表示する方法論は、フィードバックをより早くトリガーできます。それは、すべてのアジャイルコンセプトのインスピレーションの1つでした。作成者は、あなたが説明する問題に対処することにうんざりしており、管理者とユーザーが変わらなければ、開発も可能性があることに気づきました。まだ開発中ですが、さまざまな技術を通じて早期のフィードバックを得ることに重点が置かれています（主題の専門家を開発チームと同じ場所に配置し、大まかなプロトタイプをより早くユーザーに提供し、ペアプログラミングで開発者の経験を活用します） 。これはすべて、私たちは人間だと理解されており、物事を見逃すからです。

最後に、急速な変化を支援するためにシステムを拡張可能にしようとしていると言いますが、どのようにですか？プレゼンテーションロジックをビジネスロジックから分離していますか？オブジェクトにビジネスロジックをカプセル化し、依存関係と結合を最小限に抑えるために適切にパーティション分割していますか？これらはすべて困難であり、計画と構築に時間がかかる場合があります。

ところで、あなたは一人ではありません。多くの（おそらくすべての）ショップにはこれらの課題があります。

Answer 2

最初に締め切りを課させないでください。

2つのオプションがあります

• PMが機能のリストを提供し、準備ができたらそれらを伝えます。
• PMは、機能のリストと期限を提供します。次に、指定された時間にどの機能を実装するかを伝えます。

PMがあなたの上司であるか、期限と機能の数を課す権限を持っている場合、私は新しい仕事を探しています。 careers.stackoverflow.com

PM

Answer 3

このようなものは対処するのが本当に難しいです。ここでの本当の問題は、実際にはプロセスがないことです。

答えは、あなたの組織の政治的状況と、変化を推進するためにどれだけのエネルギーが必要かによって異なります。

過去、私はいくつかの組織にプロセスの変更を導入しようとしましたが、それは常に闘争でした。ただし、可能です。

ソフトウェア開発を管理するためのいくつかの方法論を見ていきます。たとえば、スクラムを使用してお勧めします。

急速に変化する状況では、明確に説明可能な目標を持つ短い反復に取り組むことは本当に役立ちます。おそらくプロジェクトマネージャーを擁護して管理する必要がありますが、現在の「プロセス」のように聞こえます。明らかに機能していないため、新しいプロセスの販売が実際に容易になります。改善のための堅実なビジネスケースがあります。

確実なプロセスは、「プッシュバック」に役立ちます。要件の変更について。急速な反応の変化は、多くの場合、組織の方向性と戦略における広範な問題の兆候であり、組織内でこの問題を解決することはすべての人の利益になります。

Answer 4

これは、開発者として直面する主要な課題の1つです。

過去に使用した良いテクニックの1つは、質問することです。仕様を入手したら、最終ユーザーからの説明が必要なものを見つけてください。これは常に物事を遅くし、マネージャーのリスク意識を高める可能性を高めます。

プロジェクトの最新の変更の実装に伴うリスクをプロジェクトマネージャーが把握していることを確認してください。

Answer 5

あなたとあなたのチームは、これについてマネージャー自身と議論しようとしましたか？それが最初にするべきことです。

彼は開発プロセスにそれほど多くの経験がないため、一定の厳しい締め切りと非常に遅いメジャーの変更があります。私はそのようなケースを見てきました。開発できなかったがPMでもっと良い仕事ができると思っていた人々。
座って彼と話すことから、彼の性格/プロ意識に応じて2つのことが出てきます。彼はあなたのポイントを受け入れ、将来のために状況を変えようとします。そうしないと、彼は賢い少年になり、少しでも屈しません。その場合、状況をより高いレベルにエスカレートする価値があります。開発者を失うことを喜んで受け入れる会社はないと思います。

代わりに、彼のマネージャーが彼のあちこちにいる可能性があります。そしてそれは問題です。

すでに提案したように何もうまくいかない場合、仕事を変えることは公正なことです。