仕様変更の影響を軽視する管理スタッフ（会社の所有者）に対処する方法は？
私はしばらくの間、小さなWeb開発会社（3人のプログラマー）で働いています。昨年、会社は苦労し（プロジェクトが減り）、プロダクションマネージャーを含む数人の同僚が解雇されました。この人を私たちのチームから外すことは、私たちが会社の上司（所有者）とますます取引しなければならないことを意味します。クライアントに会い、今後のプロジェクト（カスタムWebアプリなど）について話し合うのは彼らです。
今週、上司と仕様の変更（いくつかの機能の追加）を希望する特定のプロジェクトについてミーティングを行いました。私は、実際の仕様では常にプロジェクト中に変更されることを理解しています（私はこのビジネスにほぼ10年間携わっていますが、すでにそれを理解しています）。私が苦労しているのは、上司が複雑さ、新しい仕様の影響を最小限に抑えるを試み続けるときです。なぜなら、彼の心の中では、これらの変更はそれほど難しくなく、それほど時間はかからないはずだからです（特に彼はすでに一定の金額の契約をクライアントと締結しているためです。 1人のプログラマーの同僚がそれについて冗談を言った、飛行機に作るのは車に2つの翼を追加することではなく、それは車両の設計全体に大きな影響を及ぼし、所要時間は同じではないので、ソフトウェアと同じです。
上司からのそのような態度をどのように扱うべきかについて何か考えはありますか？そのような状況で彼の考えを変えることは可能ですか？
これまでのフィードバックはすべて良いものですが、上司のアプローチを変更する方法を推奨しているので、これは無駄な努力であり、最終的にはますますイライラすることになります。
私や他の多くの人のように、あなたの上司は私たちの単なる開発者よりも会社の広い視野を持っています。彼らは、顧客の満足度、リピートビジネス、顧客が望んでいないものを提供することから得られる口コミや評判に関心を持っています。
数百万ドルの政府プロジェクトを引き受ける大規模な開発会社にとって、プロジェクトの全体的な成功を確実にするために、最初からすべての範囲と詳細を明確にすることが非常に重要であることを理解しました。あなたはそのような会社で働いているとは思いません。
あなたは最近、プロダクションマネージャー、バディを失ったと言いました...それはあなたがここでプレートに適応してステップアップする時です。あなたの会社は明らかに財政的負担にさらされており、少なくともあなたはまだここで仕事をしています。あなたの上司は毎日ズボンを脱いであなたを続けるためにできる限りのことをしていると確信しています（人々を解雇する最後の手段を取ることを含む）
つまり、別の方法で作業し、新しい状況に適応する必要があると思います。よりアジャイルな開発スタイルを採用し、顧客のニーズを最優先します。
ズボンの座席のそばを飛ぶのは楽しいことです。上司と直接話し、ここで言ったことを上司に伝えるだけです。何よりも、彼は人間であることを理解しているので、少し思いやりを持ち、あなたのPMの喪失により、かつてあったプロセスの一部が行き詰まってしまったと説明します。あなたは彼が受けているプレッシャーを理解していて、開発者がしばらくそれを翼にして間違いを犯さなければならないことを彼が受け入れることができれば、それはあなたが言う必要があるすべてです-彼は二度と戻って来てあなたが彼に警告しなかったと言うことはできません少なくとも。
thisプロジェクトでは、おそらく何もできませんnow。ただし、元の機能と変更の両方に対して個別に時間を追跡する機能がある場合は、追跡してください。プロジェクトが終了したら、回顧展を行います。
早く、予算を下回って来ましたか？もしそうなら、あなたの推定はオフであり、あなたの上司は正しいです。予算超過/遅れて入った場合は、超過の量が新しい変更に費やされた時間と等しいかどうかを確認してください。
すべてのプロジェクトでこれを開始すると、最終的には傾向がわかります。おそらく、最初の見積もりの後に追加される機能が多いほど、プロジェクトは遅くなります。
あなたが正しく、上司が間違っていることを証明するためにこれを行わないでください。目標は、誰かが間違っていることを証明することではなく、より適切な推定を行うためにどのように連携するかを学ぶことです。プロジェクトが遅れることが多く、最初の見積もりの後に変更が行われることが多い場合は、作業方法を変更するために必要な情報が得られます。
変更を行うために実行する必要があるタスクを正確に示した詳細な時間を彼に伝えます。時間を見積もるのは細かいことです。コミュニケーション（メールや会議）、単体テスト、QA、導入、文書化、研究と設計だけでなく、開発だけでなく（開発部分に多くのステップを踏むようにしてください）などを必ず含めてください。彼を教育する唯一の方法は、彼に詳細な影響を示すことです。弊社では、すべての仕様変更が見積もりの変更であり、それらすべてがクライアントに送信されるため、変更が期限に及ぼす影響と、それらにかかる費用がわかります。彼らは変更が自由ではないことを理解したので、私たちははるかに少ない変更を持っています。
将来に使用する時間見積もりテンプレートを作成することをお勧めします。
これが彼に影響を理解し始めさせないなら、彼は決して理解しません、そしてあなたが彼の非現実的な締め切りに間に合うためにあなたの個人的な時間をすべて費やす一連の死の行進に入る前に進む時が来ました。
これは私が働いているところでも起こります-クライアントは私たちがスケジュール/予算を超過する原因となる小さな変更を要求し続けます。 （私はこの現象を"要件クリープ"と呼びます。ソフトウェアのフィーチャークリープの原因/関連のように思われるからです）。
最近のプロジェクトで私たちが行った、要件のクリープとの戦いに役立つと思われることは、フェーズ1の終わりに機能のコアセットを提供し、フェーズ2。このようにすることで、予算内または予算内で最初の期限までに高品質のフェーズ1製品を提供できるようになることを願っています。
もちろん、第2フェーズには独自の期限と支払いがあります。これは、より多くのお金がかかるため、上司がおそらく望んでいることです。 （フェーズ3：利益！）
これは、フェーズ1のパートに最初の期限よりも時間がかかる場合、または上司が問題があることを認識していない場合は役に立たない可能性がありますが、これはあなたに提案する可能性があります。
私たちの仕事を理解していない上司と一緒に仕事をするのは難しいです。そんな経験があり、人生で最悪の時でした。
子供のように上司と話をし（彼の決定の賛否両論を示してください）、それがどのように機能するかを説明する必要があると思います。ユーモアのセンスがあれば、本を買うこともできます。
しかし、正直に言うと、多くのことは上司がクライアントと署名する合意に依存します。会社が契約を勝ち取りたいと思っているために複雑さが最小限に抑えられることがあることを私は知っています。その後、彼らは再びクライアントと話し合い、複雑さが増し、会社はより多くを稼ぎます。複雑さが最小化される2番目のケースは、クライアントが将来私たちにもっと多くのタスクを与えることを会社が知っているときです-それは餌を投げるようなものです。そして、その行動の最悪の説明は不適切な人です。