非常に厳しい締め切りを課しているが、締め切りの 1 日ほど前に新しい機能や仕様の変更を実装し、さらに厳しい締め切りを課すプロジェクト マネージャーに対処する方法。
これに関する最悪のことは、以前に実装されたビジネス ルールが適用できなくなったり、個別に処理する必要がある奇妙なコーナー ケースが「得られたり」するため、新しいもののほとんどが既存のコードの大幅な書き直しにつながることです。
システムを拡張可能にしようとしても、文字通り最後の瞬間に発生し、迅速に実装およびサポートする必要があることが常にあるようです。
このような状況にどのように対処できますか？本当に意気消沈しており、同僚の 1 人がすでにチームを辞めています。
確かに、あなたが何をしても、あなたは人間であり、間違いを犯したり、物事を見逃したりします。とはいえ、要件の定期的な変更は、ほとんどの場合、不十分な要件または不十分な開発プロセス、あるいはその両方の結果です。
事前に設計するものはありますか？
ビジネス分析は、開発者やプロジェクトマネージャーなどによって定期的に短期間で行われます。ほとんどの開発者は、1日目からハッキングを開始したいと考えており、ほとんどのPMは、次のように述べています。ばかげたビジネス分析に時間を費やすことなく、1日でフェーズを実行できます。これは、完了ボーナスとして最適です。」ただし、PMの主な仕事は、プロジェクトを（時間どおりに予算内で）管理することです...必ずしもユーザーを満足させるわけではなく、開発者を満足させるわけでもありません。それは彼らが完全に無情だと言っているのではありません。優れたPMは、スコープ制御を実施し、コミュニケーションを促進することで目標を達成します。どちらも役立ちます。
しかし、時間をかけて実際に何が必要かを考え、考えられるシナリオをステップスルーすることで、対処している問題に深刻な違いをもたらすことができます。
アジャイルは役に立ちますか？
ユーザーがこれらのコーナーケースについて後でではなく早く教えてくれるといいですね。これは、TobyHedeが彼の投稿で説明したことに関連しています。おそらく、ソフトウェアをできるだけ早くユーザーの前に表示する方法論は、研磨されていない状態であっても、フィードバックをより早くトリガーすることができます。これは、すべてのアジャイルコンセプトのインスピレーションの1つでした。作成者は、あなたが説明する問題に対処することにうんざりしていました。また、管理者とユーザーが変更されない場合は、開発が変更される可能性があることにも気づきました。それはまだ開発中ですが、さまざまな手法を通じて早期のフィードバックを得ることに重点が置かれています（対象分野の専門家を開発チームと同じ場所に配置し、大まかなプロトタイプをより早くユーザーの手に渡して、ペアプログラミングで開発者の経験を活用するなど） 。
最後に、急速な変化に対応するためにシステムを拡張可能にしようとしているとおっしゃいましたが、どうすればよいでしょうか。プレゼンテーションロジックをビジネスロジックから分離していますか？依存関係と結合を最小限に抑えるために適切にパーティション化された、ビジネスロジックをオブジェクトにカプセル化していますか？これらのことはすべて行うのが難しく、計画と構築に時間がかかる可能性があります。
ちなみに、あなたは一人ではありません。多くの（おそらくすべての）店がこれらの課題を抱えています。
そもそも彼らに期限を押し付けさせないでください。
2 つのオプションがあります
PM があなたのマネージャーであるか、期限と機能の数を課す権限を持っている場合は、新しい仕事を探します。 キャリア.stackoverflow.com
PM がマネージャーでない場合は、マネージャーに参加してもらい、PM に上記のリストからオプションを提供してもらう必要があります。
このようなものを扱うのは本当に難しいです。ここでの本当の問題は、実際にはプロセスがないことです。
答えは、組織の政治情勢と、変化を推進するためにどれだけのエネルギーが必要かによって異なります。
過去に、私はいくつかの組織にプロセスの変更を導入しようと試みましたが、常に苦労していました。ただし、可能です。
ソフトウェア開発を管理するためのいくつかの方法論を見てみます。たとえば、私はスクラムを使用し、推奨しています。
急速に変化する状況では、明確な説明責任のある目標を持つ短いイテレーションに取り組むことが非常に役立ちます。おそらく、プロジェクト マネージャーを擁護して管理する必要がありますが、現在の「プロセス」は明らかに機能していないように思われるため、新しいプロセスを販売することは実際には簡単になります。改善のための確かなビジネス ケースがあります。
堅実なプロセスは、要件の変更を「後押し」するのに役立ちます。急速な反動的変化は、組織の方向性と戦略におけるより広範な問題の兆候であることが多く、組織内でこの問題を解決することは、全員の利益になります。
これは、開発者が直面する主要な課題の 1 つです。
私が過去に使った良いテクニックの 1 つは、質問をすることです。仕様を入手したら、その中に最終ユーザーからの説明が必要なものを見つけます。これは常に物事を遅くし、マネージャーの心にリスクの可能性を高めます.
プロジェクト マネージャーは、プロジェクトの変更を後から実装することに伴うリスクを認識していることを確認してください。
あなたとあなたのチームは、これについてマネージャー自身と話し合ってみましたか？それがあなたが最初にすべきことです。
彼は開発プロセスについてそれほど多くの経験を持っていない可能性があり、したがって、一定の厳しい締め切りと非常に遅い大きな変更があります。私はそのようなケースを見てきました。成長することはできなかったが、PMでより良い仕事ができると思った人々です。
座って彼と話すことから、彼の性格/プロ意識に応じて、2つのことが出てくる可能性があります。彼はあなたのポイントを受け入れて、将来のために状況を変えようとします。さもないと、彼は賢くなり、少しは諦めません。その場合、状況をより高いレベルにエスカレートする価値があります。負けた開発者を喜んで受け入れる会社はないと思います。
あるいは、彼のマネージャーが彼のいたるところにいる可能性があります。そしてそれは問題です。
すでに示唆されているように、何もうまくいかない場合は、仕事を変えることは公正なことです。