署名済みの契約で時間の見積もりをロックしたいプロジェクトマネージャー

以前の雇用では、プロジェクトマネージャー（PM）は、私のプロジェクトのコードの納期に満足していませんでした。プロジェクトリーダーから、PMはタスクと納期に与えた時間の見積もりをロックインする契約に署名することを検討していると言われました。

プロジェクトの状況は、新しいテクノロジー、コードベース、コーディング標準、および非常に変更しやすい要件を扱っていたということでした。私は新しいことを学び、変化し続ける要件にできる限りそれらを適用していました。反復全体の要件は2〜3倍に増加し、完了までの見積もりは約5〜8倍に増加しました。変更されなかったのは、見積もりと納期のみでした。

はい、私はほとんどの締め切りを逃してしまいました。そして、私は開発チーム全体の誰もそれを知らないので、本当に助けてくれないいくつかの非常に新しい技術に取り組んでいました。少なくとも簡単ではありません。

そのとき、私は、PMが彼の数字を加算することを望んでいたように思えたので、私は常に作業コードを時間通りに配信することを「保証」する契約に署名することを望みました。期限内に納品できなかった場合、PMは署名済みの契約でそれを使用できると思います。

次に起こったことは、他のプロジェクトマネージャーやプロジェクトリーダーが私を弁護し、それを起こさせなかったことだと思います。

私の質問は、これはマネージャーについて赤旗を上げるべきですか？マネージャが契約書に署名してソフトウェア開発者の時間の見積もりを確定するのは一般的な慣行ですか？またはこの場合、試してみてください。

私はフルタイムの従業員であり、独立したコンサルタントではないことに注意してください。

更新：毎週新しい見積もりを行ったことを付け加えたいと思いますが、元の見積もりと納期はPMが修正したものだったようです。

私の質問は、これはマネージャーについて赤旗を上げるべきですか？

はい。つまり、履歴書/履歴書を最新の状態にして、新しい仕事を探し始める時期です。または、上司があなたと非常に厄介なゲームをプレイしようとしていることを意味します。

マネージャが契約書に署名してソフトウェア開発者の時間の見積もりを確定するのは一般的な慣行ですか？

これが従業員に適用されると聞いたことはありません。

時間と労力の見積もりは常に困難です。特に私たちの職業は過度の楽観主義に満ちているためです。将来の推定に役立つ推定システムがいくつかありますが、それらはあなた自身から履歴統計を収集する必要があります。1つはPSPです。もう1つはFunction Pointsです。多くの開発者はどちらも好きではなく、あなたはそれらの両方に対して非常に強い意見を見つけるでしょう。

時間と労力を見積もる際の主な困難は、見積ヒューリスティックにフィードバックがないことです。キーの1つは、推定値とは何か、推定に使用したパラメーターを書き留めることです。次に、実際に達成したことに基づいて、それをあなたがしたいと思ったものと比較します。そして、それを使用して、推定パラメーターを変更します。エンジニアリングでは、これを「フィードバック」と呼びます。

はい、それは絶対に警鐘を鳴らします。

私が個人的な娯楽のためにその立場にいたならば、マネージャーにすべての要件を凍結する契約書に署名するように頼んだでしょう。マネージャーが保釈する可能性が高いと思います。それから私は去ります。

まあそれは簡単です。仕様書にロックインするためにサインインする時間の見積もりをロックインするためにサインインすることをマネージャーに伝えてください。できないので、不明なものの推定値を必ず提供してください。開始する前の完全なプロジェクト仕様、変更なし-そして、時間内に完了できます:)

spec => contractへの1つの変更は無効です。おそらくあなたの最初の日の10分後には事は無効になります:)

はい、これは赤旗です。あなたが言うことは、マネージャーはソフトウェアプロジェクトのリスクを管理する方法を理解していないということです。彼がすべきことは、そもそも遅延の原因を正確に把握し、ソフトウェアプロジェクト中に避けられないスケジュールリスクを効果的に管理するプロセスを開始することです。

いかなる状況においても、スケジュールを保証するマネージャーと契約を結ぶことは決してありません。他の人は、彼が仕様のロックインに署名することについて言及した。私の意見ではこれでは十分ではありません。これは、ツールまたはテクノロジーの予期しない問題、不完全または不十分な設計、他のチームメンバーのパフォーマンスなどを考慮していません。

これは赤旗ではなく、武器級の愚かさです。

見積もりと期限が一貫して延期されている場合、行うべき合理的なことは、原因を特定してプロセスを改善することです。

あなたがどこに行くのかわからないために馬を責めて蹴ったとしても、馬があなたを噛んで逃げても驚かないでください！

マネージャーが彼の要求と一致していなかった間。彼は完全に責任があるわけではありません。あなたが完全になじみのない領域で働いていたなら、「わからない」と言っても何も悪いことはありません。「わからない」が完全に受け入れられる答えであることに気付くのに私はしばらく時間がかかりました。しかし、あなたが本当に知らないなら、それは答えです。そして、もし彼らがそれを拒否した場合、シアーズ（ウィリスにする）タワーと同じ高さのスタックを作るのにどれくらいのペニーがかかるかをあなたに尋ねてください。そして、彼らは彼らがオフになったすべてのペニーを支払う契約書に喜んで署名しますか？

給料に見合うプロジェクトマネージャーは、スプレッドシートにうまく収まらないものがあることを知っている必要があります。時々、物事が完了したら完了します。私はあなたがどれだけやったかについて進歩を与えることでうまくやっていると思う。番号の更新を停止するだけです。

別の演習では、大規模なタスクをより推定可能な小さな単位に分割します。この演習は、あなたが何をする必要があるかをよりよく理解するのに役立ちます。タスクを分類し、隠れた要件を発見するためのヒントについては、それぞれSteve McConnellのSoftware EvaluationとStephen WithallのSoftware Requirements Patternsをご覧ください。

推定で腰から撃ってはいけません。時間をかけて分解してください。多数の小さなタスクを推定すると、大きなタスクの全体的な推定値が向上します（平均の法則により、推定値の一部は不足しますが、一部は超過し、互いに重くなる傾向があります）。

「プロジェクトマネージャー」に尋ねてください。ソフトウェアを販売していますか、それとも期限はありますか？

私はプロジェクトマネージャーであり、プログラマーです:-)ほとんどのPMが業界外から来ており、生産ラインモデルにうまく収まらないものは処理できないということについて、長い間暴言を吐くことができました...ここではありません。代わりに、実際に何をすべきかについて長い論争があります（Mr Mod、長すぎる場合はそれでやります）。ここですでに行ったコメントには同意します。他の人よりも先に行うべきものもありますが、ここにあなたの最初の動きがベストだと思います。ああ、あなたの質問に対する明白な答えはイエスですが、それは以下のカラフルで詳細な言語で詳しく説明されています。

私が始める前に、PMがあなたに悲しみを与えている可能性が高いことに注意してください。食物連鎖のさらに上の誰かが彼らに悲しみを与えているからです。彼ら（私たち）は単純な生き物です...あなたが説明した状況を避ける方法があります-マイク・ブラウンはそれをかなりうまくカバーしています。また、3/4/5 ..開始する直前に何かをワークショップすることにも何の問題もありません（実際に発生しない場合は、あらゆる種類のアラームをオフにする必要があります）。未知の領域に行く場合は、1週間前に戻って領域とテクノロジーを調査し、適切な見積もりを行えるようにします（新しいテクノロジーをドンで学び、プレイしたいので、これを適切に行う必要があります）じゃない？）。PMとあなたがいる場所の管理者がこれを理解していない場合...履歴書を更新し、最も近い出口を探します。彼らをとても豊かに値する運命に任せます。PMがフルタイムの従業員にそのような契約に署名してもらうことを考えることは悪い悪い兆候です...彼らがそれを見ることができる唯一の方法完全に無能ではないかもしれませんが、彼らは本当にあなたのプロジェクトリーダーとあなたとマインドゲームをプレイしていただけです（私が読んだことから、彼らはこれをあなたに直接伝えず、最終的には脅威をフォローしませんでした）。 結局、PMingは標準的な企業のサイコパスにとって天国です。 あなたが言ったことから他の人があなたの代わりにコウトになったのは良かったので、以下のアドバイスはおそらく最終的にはあなたにとってポジティブだったでしょう。話以上のものであることが判明した場合、彼らは彼らの手に革命をもたらしたであろうと思います。

だからあなたが説明した実際の状況/穴に、それは誰か、どこかで再び起こるだろうから（約5分前、そしてまた別の5で、scheduleRepeat（））。おそらく契約の愚かさはありませんが、基本的なストーリーは常に同じです。ミーティングを組織します（！）、彼らはミーティングが好きです;-)誰もが実際に何かが行われたかのように、最後に自分自身を後ろからでることができます。 重要：技術的なプロジェクトリーダー/チームリーダー/アーキテクト/デザインマネージャーを会議の招待状に含めて、必ず問題を解決してから参加してください。階層の上位に行くほど、あなたの「側」にいる誰かのために行くことができます。PMがそれを見て、デザインマネージャーと同等のものを試してみてください。そうでない場合、彼らは愚かであり、あなたはすでに勝ちました。それ自体は、通常、彼らをその場で略奪することができる誰かに見えるようになったので、一般に彼らを線に引き戻します。彼らがあなたとゲームをしている場合、あなたは好意を返すことができます。

会議では、何を扱っているのか、なぜ時間がかかるのかについての技術的な詳細を調べます。彼らはこれを知りたい（と彼らがあなたがそれを成し遂げるのを助けることができる方法）が、悲しい事実は一般にこれが起こらないということです...あなたはおそらく彼らの目が彼らの頭に戻る前に10分を得るでしょう。ここで私がしたいことはおそらく合法ではありません...ええ、私はチェックしました、それは実際には非常に違法であり、あなたはその長い間刑務所に行きたくありません。重要なのは、積極的に行動するために最善を尽くしたことです。もし上位の人がいれば、痛みは今や彼らの痛みになります。「エスカレーション」が起こるので、物事がどのように展開される可能性が高いかについて、あなたの判断を使用する必要があります。あなたがいる場所のリーダーシップが半分まともであれば、彼らは正しいことをするでしょう、あなたも正しいことをしてください。そうでない場合は、事前に履歴書を市場に出していたはずです...とにかく最初の機会に出発するつもりでした（そして最終的にあなたがしたように見えます）。リーダーシップは2つのグループに分類されます-技術的に精通しており、即座にあなたの視点を見ます。または、彼らはそうではなく、彼らはそれを笑って耐える以外に何をするつもりですか？彼らがあなたのすることができるなら、彼らはすでにそうしているでしょう。tそして彼らはそれを笑って耐える以外に何をするつもりですか？彼らがあなたのすることができるなら、彼らはすでにそうしているでしょう。tそして彼らはそれを笑って耐える以外に何をするつもりですか？彼らがあなたのすることができるなら、彼らはすでにそうしているでしょう。

変化する要件の問題を最後に使用する切り札として保管してください。それは、すべての人にとってアウトとして役立ちます。プロジェクト自体といまいましいクライアント/利害関係者は、彼らの名前を無駄にします。最も簡単な方法は、プロジェクトで一種のリセットを行うことであり、おそらくPMが静かに別の領域に再割り当てされるでしょう。奇跡は時折起こります。ミーティングでPMが契約の問題を提起した場合は、要件に応じてカウンター契約の需要を凍結します。これらの種類のマインドゲームをプレイします。

サインオフする前に：範囲/要件を変更する-アジャイル手法を採用する最大の理由の1つであるため、クライアント/利害関係者は、自分が望むものについて考えを変えることに適切に責任を負います...

ああ、もう1つ。「わからない」という声明では、常に、プロジェクトチームの1人の技術者やメンバーの価値を測る方法についての個人的なベンチマークでした。私はあなたの顔に真っ直ぐだと言うことができる唯一の人がいることを見つけます、主に彼らが彼らの深さから外れていることを知っている誰かが決してそれを言わないのでハートビート。一方、前もってそれを言う人は、未知のものに取り組む方法についての基本計画を立てます（たとえそれが考え抜かれていなくても）。そうすれば、24時間でより有用な答えが得られます。そして一週間のうちにさらに良いものになります。アポロ13号が月の暗い側を飛んでいたとき、「私は知らない」というたくさんの出来事が起こっていました。

はい、これは特にあなたがフルタイムの従業員である場合、赤旗を上げるはずです。契約の条件は何でしたか？締め切りに間に合わなかった場合、実際に解雇されますか？または、ボーナスを逃しますか？彼らは何をしますか？

このフラグは、マネージャーが、新しい/なじみのない技術を扱い、推定労力に直接影響する要件を変更するプロジェクトを管理する方法を知らないということです。厳しい締め切りが発生することもありますが、状況を知っているマネージャーは、従業員に契約を強制させて契約を締結させようとしてはなりません。深夜とクランチタイムは悪いでしょうが、それはおそらくコースに匹敵します。そして、まだ期限がずれることもあります。それが起こり、他の誰かが投稿したように、スケジュールに固執する唯一の方法は、要件を早期に凍結して、タイムラインを維持するための十分なスペースがあるようにすることです。

あなたが言ったことから、警報ベルは数ヶ月遅すぎます。通常、時間に敏感なプロジェクトを、スタッフがまだよく知らない技術に基づいて行うことは危険です。要件の収集とスコープ管理を把握していない場合、これを行うのは無理がありません。

そうは言っても、私は他の答えに同意します。また、まだ更新していない場合は、履歴書を更新することもできます。

他のすべての回答者と同様に、これが赤旗を上げることに同意することはできませんでした。

PMは開発プロセスに関与したくないようです。

私の個人的なプラクティスでは、詳細な先行仕様、サインオフ、プロジェクト全体の見積もり、または固定入札価格（コンサルティングの観点から）を扱うことから遠ざかりました。

この理由は、アジャイルとリーンのソフトウェアの達人の多くが言っている認識であり、そのソフトウェアは固定された製造可能なエンティティではなく、ほとんどが発見のプロセスです。

多くの人々はまだこの概念に問題を抱えており、あなたの首相もそうだったようです。トレードオフの単純な理解に帰着します。

変更のコストが高いシステムでは、厳格な先行仕様と固定見積もりが機能します。高層ビルを建てるような。エレベータシャフトを前もって特定するのを忘れた場合は、建物が建てられた後に改修するのは非常に困難です。高い変更コストには、多くの事前の計画、コンポーネントとテクノロジーの未知数の学習、および事前の実験が必要です。宿題をすべて終えたら、予算と費用を見積もることができます。

ソフトウェアでは、人々は変更のコストが低いという考えに非常に慣れており、リリースを見た後に物事を変更できることを活用し、アプリケーション、ビジネス、顧客の新しい理解を取り入れることを好む継続的に。これらのすべては、適切に活用された場合に有効であり、大きなチャンスです。実際に私が会って仕事をしたほとんどのソフトウェア関係者は、計画や調査に多くの時間を費やすことを楽しんでいません。私たちのほとんど（PMを含む）は、継続的な牽引力を見たいと思っています。これが、機能の小規模で漸進的なリリースによって反復開発が行われた場所です。変更のコストがあることを保証するために、このようなテスト駆動開発などに使用することができ、他の慣行があるまま低いと技術的負債が含まれているが。

この作業を行うには、製品所有者（PMまたは顧客またはQAチームをアジャイルに話す）と開発者の両方の「契約」が必要です。開発者は、与えられたイテレーションで最も重要なものとして優先順位付けされたものにのみ取り組み、それを永遠に続けないことに同意します。逆に、製品所有者は、増分リリースを継続的にレビューし、迅速なフィードバックを提供することに同意します。また、次の反復の優先順位を設定することに同意し、一度反復の期間中は心を変えないように設定します。

契約のこの後半部分は、PMが理解していない可能性が高いものです。多くの伝統的なPMは実際にはそうではありません。彼らの何人かは、仕様を落とすと作業が完了したと考えています。欠点は、ソフトウェア開発の流れに対抗するだけでなく、テーブルに多くの機会を残すことで組織を傷つけることです。

アジャイルマニフェストをご覧ください：http : //agilemanifesto.org/それはあなたに共鳴するかもしれません。読むのに適した本は、Mary Poppendieckの「Lean Software Development」でもあります

幸運を。

マネージャーが上司に報告するときに責任者を探しているようです。

「見積り」は「固定期間」と同じだと考える不合理なマネージャーがいるなら、非常に寛大な見積期間を考え、それを倍にすることをお勧めします！

また、要件が完全に詳細で修正されていることをマネージャーに強制します。それ以降の変更は、新しい完了時間のプロジェクトマネージャーとの「正式な再交渉」なしでは対処されません。

最終的に、プロジェクトマネージャーはアイデアを得て、それに応じて計画します。

この種のことに関する私の個人的な経験では、プロジェクトマネージャーは、あなた自身の責任で解雇する一方で、あなたを処分するためのペーパートレイルを設定しようとしています。それは非常に赤い旗になるでしょう。もちろん、走行距離は多少異なります。

良い答えはどこにでもありますが、2セントを加算します。

確率を研究する場合、「ランダム変数」などがあります。それは値がわからない数値ですが、正規分布（釣鐘曲線）などの分布でわからないことを説明できます。

要は、仕事にはある程度の時間がかかりますが、以前の見積もりは、マイナス側またはプラス側で少しずつまたは間違って行われるため、リスクがあり、誰かがリスクを取る必要があります。一般的に、人々がリスクを負う場合、彼らはそれに対して支払いを受けます。保険にはお金がかかります。

私がコンサルタントだったとき、私は通常、固定価格契約ではなく、時間と材料の契約に署名する選択肢がありました。時間と材料で、クライアントはリスクを負います。固定価格で、私はリスクを負います。固定価格の場合、目標を達成できなかった場合は誰も勝てないため、安全性を確保しています。

特に固定された要件なしに、固定された納期にコミットするように依頼することは、実際にリスクを負うものが明確ではない場合でも、リスクをあなたに移そうとしているように聞こえます。いずれにせよ、1つの対応は、単に非常に寛大な安全性を確保することです。

PS政府との契約でこれをよく見ます。プロポーザルの最初の要求があり、入札が行われ、低い入札が受け入れられ、次に変更要求が入り始めるので、コストが膨らみ、請負業者が非難されます。敵対的な関係よりも、クライアントと請負業者の間にチームワークの関係がある場合、物事ははるかにうまく機能します。

はい、もちろん、これはあなたの上司の経験と能力に関するフラグを立てます。はい、ほとんどの人が示唆しているように、これはあなたの履歴書を更新する良い機会です。

はい、他の回答が述べているように、ほとんどの場合、その契約書に署名したくないでしょう。ただし、署名を検討する状況がいくつかあることをお勧めします。

ほとんどの開発者と管理者は、機能、期限、予算の間の絶え間ない摩擦に気付いています。また、多くの人が4番目の次元として品質を指定します（「機能しないことを受け入れてくれる限り、明日までに低予算で好きな要件を提供できます！」）

しかし、さらに別の側面があります。リスクです。時間の50％だけを正常に配信する必要がある場合、見積もりを大幅に下げることができます。はるかに高い配信率を処理するためにパッドが埋め込まれています。

さまざまな方法でリスクに対処できます（パディングの見積もりもその1つです）。マネージャーはリスクを受け入れようとはせず、リスクを肩にかけたいと考えています。通常、あなたはそのような動きを断るべきです...あなたが十分に償われない限り。

予想外の遅延に対処するために相互に許容可能な量のパディングで締め切りを指名することができ、それをヒットした場合に（非常に大きな）ボーナスを交渉でき、その資金を処理できる財政状態にある場合罰則（解雇など）ができない場合は、そのリスクを受け入れて契約に署名することは価値のある「ギャンブル」であることがわかります-要件の変更を処理する適切な条項があります。

これは正真正銘の愚かさです。究極の目標が何であるかはわかりませんが、ソフトウェア製品を担当する中途半端なプロジェクトマネージャーはみな、見積りがまさに見積りと呼ばれるものであることを認識している必要があります。それらは約束ではなく、ソフトウェア開発者のすべてのエネルギーを浪費するか、とにかく「約束」を破らせることなく、そのようにすることはできません。

そのような契約がどれほどばかげているかを示したい場合、2つの提案があります。

a）プロジェクトが契約なしで見積もる場合の5〜10倍の時間がかかるほど、過大評価します。プロジェクトマネージャーが見積もりが非常に高い理由を尋ねた場合、単に契約を履行できることを確認しているだけだと言います。

b）これはすでに提案されています：単一の要件が変更されないことを確認する契約を求め、これにスペルミスの修正が含まれることを確認します。私の経験では、開発中のある時点で要件が変わらない単一のソフトウェアプロジェクトはありません。プロジェクトマネージャーは、あなたよりも契約を破らなければならない可能性が高くなります。

プロジェクトマネージャーがこれらの2つの提案のいずれかに同意する場合は、それらが頭の外にあることを確信しています。

ところで、正社員の契約はどのように機能しますか？他の国の労働規制については知りませんが、会社のフルタイムの従業員として、締め切りに間に合うように拘束力のある契約に署名して有効な訴訟を起こすことを強制できるとは思いません。もちろん、あなたが期限に間に合わなければ、彼らはあなたに地獄を与えることができますが、そのための契約は必要ありません。誰もあなたをクビにすることも、お金を減らすこともできません。最悪の場合、彼らはあなたの同意したボーナスを削減できます。したがって、他の国でこれが異なる場合を除き、これは真剣に取るべきものよりも空の脅威のようです。

ここで穀物に反するつもりです。

あなたが説明する状況は、エンジニアリングチームレベルでは特に珍しくはありません。特に、特にプロジェクト/リリースが遅れている場合はそうです。多くの場合、管理者と組織全体が特定のリリース日にサインアップしている可能性があり、組織の他の部分はその日付に合わせて調整されます。その日を打つために、管理チェーンに多大な圧力がかかる可能性があります。

ここで、一般的なエンジニアリングプロセスが開始されます。おそらく、ウォーターフォールモデルについて聞いたことがあるでしょう。他のモデルもありますが、それらすべての最終目標は、期待されるときに一貫して何かを提供し、合意されたものを含めることです。機能仕様、設計、タスクリストなどはすべて、これを予測可能なプロセスにするためのものです。コミュニケーション、リスク分析、および（あなたが言ったように）スケジュールに関する期待を定期的に更新することで、サプライズを減らし、できるだけ早く情報を利用できるようにして、計画を調整できるようにします。そして、はい、機能が追加または削除されるたびに計画を調整する必要があります。

私が協力したいくつかのチームでは、署名されたコミットメントとして見積もりを扱うことをheしませんが、それはチームと経営陣の質を反映しており、見積もりの​​特定のスキルではありません。チームに喜んでいる契約書に署名した時間に配信するためには、よく働いてチームの指標ではなく、赤い旗です。

私は自分の靴に身を置き、それが何を動機付けたのかを理解しようとすると言います。マネージャー/会計士の見込みから、彼らは何が起こっているのか、物事がどのように進んでいるのかを正当化するために数字が必要です。

締め切りを変更したり、締め切りが多すぎたりするために役員室で笑されているのかもしれません。反対側にいるあなたは、それがあなたに反するものであるとしか知覚できなかったでしょう。見積もりをどのように行い、調整する必要があることに気付くにつれて、彼にとってより有益なものになります。リクエストの動機と彼が直面している本当の問題が何かを理解すれば、彼とあなた自身を助けることができるかもしれません。プログラマーとして問題を解決します。これは彼の問題を理解し解決するのと同じです。彼はあなたの親友になります。多くの作業が行われているため、個人的な復endを計画する時間はありません！彼は彼の仕事の助けが必要です。最も簡単な解決策は誰かに論文に署名してもらうことでした！おそらく、彼はダミーの経営者の本から、「あなたの労働者に署名して番号の説明責任を果たすように」と言ったでしょう。面白いけど悲しい

「水の上を歩き、仕様からソフトウェアを開発することは、両方が凍結されていれば簡単です。」

-エドワードV.ベラード

要件が変化している場合、最初の見積もりが正確であることを期待するのは不合理です。はい、これは赤旗です。

契約は期限を守らないことに対するペナルティを指定していますか？そうでない場合、それはまったく問題ではありません-あなたは単にその時点でのあなたの知識に基づいて推定値にサインオフしています。