署名された契約で時間の見積もりを確定したいプロジェクトマネージャー
以前の雇用では、プロジェクトマネージャー（PM）は、私が参加していたプロジェクトのコードの納期に満足していませんでした。プロジェクトリーダーから、PMは、時間の見積もりを確定するための契約書にサインすることを検討していると考えていました私はタスクと納期をあげました。
プロジェクトの状況は、私たちが新しいテクノロジー、コードベース、コーディング標準、および非常に変更されやすい要件で作業していたことでした。私は新しいことを学び、変化し続ける要件にできる限りベストに適用していました。反復全体の要件は2〜3倍になり、完了までの見積もりは約5〜8倍になりました。変更されなかったのは、見積もりと納期のみでした。
はい、ほとんどの締め切りを逃してしまいました。そして私はいくつかの非常に新しい技術に取り組んでいましたが、開発チーム全体の誰もがそれに精通していないため、本当に助けることができないでしょう。少なくとも簡単ではありません。
そのとき、私には、PMは彼の数値を合計することを望んでいたようでした-したがって、常に時間どおりに動作するコードを提供することを「保証する」ための契約に署名することを望んでいました。署名された契約でPMは、時間どおりに配達できなかった場合、私に対してそれを使用できます。
次に起こったことは、他のプロジェクトマネージャーやプロジェクトリーダーが私を擁護し、これを起こさなかったことだと思います。
私の質問は次のとおりですこれはマネージャーについての注意を喚起する必要がありますか？マネージャーが署名された契約を持つソフトウェア開発者の推定時間を固定することは一般的な慣習ですか？または、この場合は、試してください。
私はフルタイムの従業員であり、独立したコンサルタントではありませんでした。
更新：毎週新しい見積もりを出したことを追加したいのですが、元の見積もりと納期はPMは修正されました。
私の質問は、これはマネージャーについての赤い旗を上げる必要がありますか？
はい。それはあなたがあなたの履歴書/ CVを最新にして、新しい仕事を探し始める時がきたということです。または、マネージャーがあなたと一緒にいくつかの 非常に厄介なゲーム をプレイしようとしていることを意味します。
署名された契約を持つソフトウェア開発者の推定時間を管理者が固定することは一般的な慣習ですか？
これが従業員に適用されることを聞いたことがありません。
時間と労力の見積もりは常に困難です。特に私たちの職業は過度の楽観に満ちているからです。将来の見積もりに役立つ可能性のある見積もりシステムがいくつかありますが、自分から履歴統計を収集する必要があります。 1つは [〜＃〜] psp [〜＃〜] です。もう1つは 関数ポイント です。多くの開発者はどちらも好きではありません、そしてあなたはそれらの両方に対して非常に強い意見を見つけるでしょう。
時間と労力を推定する上での主な困難は、推定ヒューリスティックスにフィードバックがないことです。重要なことの1つは、推定値とは何か、および推定に使用したパラメーターを書き留めることです。次に、実際に行ったことに基づいて、それをあなたがやろうと思ったことと比較します。そして、それを使用して推定パラメーターを変更します。エンジニアリングでは、これを「 フィードバック 」と呼びます。
はい、それは完全に警報ベルを鳴らす必要があります。
私がその地位にいたのであれば、個人的な娯楽のために、すべての要件を凍結する契約に署名するようにマネージャーに依頼したでしょう。私はマネージャーがおそらく保釈すると思います。それから私は去ります。
まあそれは簡単です。マネージャーが仕様をロックインするためにサインインするときに、推定時間をロックインするようにサインインすることをマネージャーに伝えてください。できないので、不明なことについては必ず見積もりを提供してください。開始する前の完全なプロジェクト仕様、変更なし-そして、時間内に完了することができます:)
Spec =>コントラクトへの1つの変更は無効です。おそらく、最初の日の10分後には無効になります。
はい、これは危険信号です。マネージャーがソフトウェアプロジェクトのリスクを管理する方法を理解していないということです。彼がしなければならないことは、そもそも遅延を正確に引き起こした原因を突き止め、ソフトウェアプロジェクトの実行中に避けられないスケジュールリスクを効果的に管理するためのプロセスを開始することです。
どのような状況でも、スケジュールを保証する上司と契約を結ぶことは決してありません。他の人たちは、彼に仕様のロックインに署名させることについて言及しました。これは私の意見では十分ではありません。これは、ツールやテクノロジーの予期しない困難、不完全または不十分な設計、他のチームメンバーのパフォーマンスなどを考慮に入れていません。
これは危険信号ではなく、武器グレードの愚かさです。
見積もりと期限が一貫して守られない場合は、原因を特定してプロセスを改善するのが合理的です。
どこに行くのかわからないために馬を責めたり蹴ったりした場合、馬があなたに噛み付いて逃げても驚かないでください！
マネージャーが彼の要求から外れていた間。彼は完全に責任があるわけではない。まったく知らない領域で働いていたなら、「わからない」と言っても問題はありません。 「わからない」は完全に受け入れられる答えだと気づくのにしばらく時間がかかったので、それらの言葉を発声するのにどれほどの刺激があったかはわかっています。しかし、本当にわからない場合は、それが答えです。そして、もし彼らがそれで気が狂ったなら、彼らにあなたにシアーズ（それをウィリスにする）タワーと同じくらいの高さでスタックを作るのにいくつのペニーの概算を与えるように頼みます。そして、彼らは彼らがオフにしたすべてのペニーをあなたに支払う契約に喜んで署名するでしょうか？
給与に値するプロジェクトマネージャーは、スプレッドシートにナイスできれいに収まらないものがあることを知っているはずです。時々、物事は終わったときに行われます。どれだけ上手く進んでいるのか、順調だと思います。数字の更新をやめるだけです。
別の演習では、大きなタスクをより推定可能な単位に分割します。この演習は、あなたが何をする必要があるかをよりよく理解するのに役立ちます。 Steve McConnellの Software Estimation とStephen Withallの Software Requirements Patterns をチェックして、タスクの分解と隠された要件の発見に関するヒントをそれぞれ確認してください。
概算で腰から撃たないでください。時間をかけて分解してください。多数の小さなタスクを見積もると、大きなタスクの全体的な見積もりが改善されます（平均の法則により、一部の見積もりは下回りますが、一部は超過し、お互いを比較検討する傾向があります）。
あなたの「プロジェクトマネージャー」に尋ねてください：私たちはソフトウェアを販売していますか、それとも期限ですか？
私はプロジェクトマネージャーであり、プログラマーでもあります:-)ほとんどのPMが業界外から来ており、生産ラインモデルにうまく適合しないものは処理できないということについて、長い怒りを言うことができますが、私はここではありません。その代わりに、実際に何をすべきかについての長い論争があります（Mr Mod、それが長すぎる場合は、それを使って何をするか）。私はここですでに行われたコメントに同意します。いくつかは他の人より先に行う必要がありますが、これが私が最初に行った方が良かったと思いますです。ああ、そしてあなたの質問に対する明白な答えはイエスですが、それは以下のカラフルで詳細な言語で詳しく説明されています。
始める前に、PMがあなたに悲しみを与えている可能性が高いことに注意してください。食物連鎖のさらに上の誰かが彼らに悲しみを与えているからです。彼ら（私たち）は単純な生き物です...方法はいくつかありますあなたが説明した状況を回避するために-マイクブラウンはそれをかなりカバーしています。それを開始する直前に3/4/5 ..時間のために何かをワークショップすることに問題はありません（これが実際にはすべての種類のアラームが鳴る必要がありますそして、未知の領域に行く場合は、プッシュバックして1週間をかけてエリアとテクノロジーを調査し、賢明な見積もりを作成できるようにします（新しいテクノロジーに習熟してもらいたいので、これを適切に行う必要があります） ＆で遊んでみませんか？）PMおよび現在の場所の管理者がこれを理解していない場合...履歴書を更新して、最寄りの出口を探してください。 PMは、フルタイムの従業員にそのような契約に署名してもらうことさえ考えるのは悪い悪いシグですn ...完全に無能ではないmightことがわかる唯一の方法は、プロジェクトのリーダーとあなたと本当にマインドゲームをプレイしていたということです。 （私が読んだことから、彼らはこれを直接あなたに伝えませんでした、そして最終的に脅威を通り抜けませんでした）。 結局のところ、PMingはあなたの標準的な企業精神病者にとって天国です。あなたが言ったことから他の人があなたのために打たれたのは良かったので、以下のアドバイスは結局のところ、あなたにとってポジティブだと思います。それが話以上であることが判明したならば、彼らは彼らの手に革命を持っていると思います。
実際の状況/説明した穴に対して、それは誰か、どこかで再び発生するためです（約5分前のように、また別の5ではscheduleRepeat（））。おそらく契約の愚かさはありませんが、基本的なストーリーは常に同じです。会議を開催します（！）、彼らは会議が好きです;-)何かが実際に行われたように、誰もが最後に背中を撫でることができます。 重要：技術的なプロジェクトリーダー/チームリーダー/アーキテクト/デザインマネージャーが会議の招待状に含まれていることを確認してください。階層の上位にある方が「サイド」の誰かのために行くことができるほど良いです。あなたのPMはそれを見て、デザインマネージャーを同等のものと試し、一致させます。そうでない場合、それらは馬鹿であり、あなたはすでに勝っています。それ自体は一般的にそれらを元に戻します、彼らはおそらくその場で解任することができる誰かに見えるので、彼らがあなたとゲームをしているなら、あなたは好意を返すことが許されています。
会議で、あなたが扱っていることの技術的な詳細と、なぜそれが時間がかかるのかを検討してください。彼らはこれを知りたい（そして彼らがあなたがそれをどのようにしてあなたがそれを成し遂げるのを助けることができる）か知りたいはずですが、悲しい事実は一般にこれが起こらないことです...あなたの目が彼らの頭に戻る前におそらくあなたは10分入るでしょう。さて、ここで私がしたいことはおそらく合法ではありません...ええ、私はチェックしました、それは実際には非常に違法であり、あなたはその間刑務所に行きたくないのです。重要なのは、あなたが積極的になるために最善の努力をしてきました、そしてあなたがいくつかのより高いレベルを持っているなら、あなたの痛みは今や彼らのものです... 「エスカレーション」が発生するため、物事がどのように展開される可能性があるかを判断する必要があります。あなたがいる場所でのリーダーシップがまともな場合、彼らは正しいことを行い、あなたも正しいことを行います。そうでなければ、あなたは事前にあなたの履歴書を市場に出していたでしょう...あなたはとにかく最初の機会に去ることになっていました（そしてあなたは最終的にあなたがしたように見えます）。リーダーシップは2つのグループに分類されます-彼らは技術的に精通していて、彼らは即座にあなたの視点を見るでしょう。または彼らはそうではなく、彼らはにやにや笑い以外にそれについて何をするつもりですか？彼らがあなたのすることができるなら、彼らはすでにそうしているでしょう。
最後に使用するトランプカードとして、変化する要件の問題を維持してください...それは誰にとってもアウトとして機能します。プロジェクト自体といまいましいクライアント/利害関係者は、彼らの名前を無駄にしてしまいます。最も痛みのない方法は、プロジェクトで一種のリセットが発生することです。おそらくPMは静かに別の領域に割り当てられます。奇跡は時々起こります。契約の問題が首相が会議で提起し、要件凍結契約の需要を反撃します-私が懸念している限り、彼らはすでにあなたと、そして開発チーム全体に、彼らがその種の心を果たし始めたときに彼らの橋を焼きましたゲーム。
サインオフする前に：スコープ/要件の変更-アジャイル手法を採用する最も良い理由の1つです。クライアント/利害関係者は、彼らが望むものについての考えを変えることに対して適切に責任を負います...
もう1つ、「わからない」という言葉については、プロジェクトチームの1人の技術者やメンバーの価値を評価する方法について、常に私の個人的なベンチマークがありました。私は、あなたの顔にまっすぐ向いていると言うことができる唯一の人がいると思います。主な理由は、自分の奥行きが足りないことを知っている人は決してそれを言わないからです。ハートビート。一方、前を向いてそれを言う人は、未知の問題に取り組む方法についての基本的な計画も持っています（たとえそれが通じていなかったとしても）。24時間以内にもっと役立つ答えが出ます。そして一週間でさらに良いものになります。アポロ13号が月の暗い側を飛び回っていたとき、たくさんの「知らない」が起こっていました。そのようなことに対処できない場合、あなたは間違ったゲームにいます。
はい、これは特にフルタイムの従業員である場合、危険信号を上げるはずです。契約の条件は？期限を逃した場合、実際に解雇されますか？それともボーナスを逃すだけですか？彼らは何をしますか？
これが提起する旗は、マネージャーが、新しい/なじみのないテクノロジーを処理するプロジェクトを管理する方法を知らず、見積もられた作業に直接影響する要件をシフトすることです。厳しい期限が発生することもありますが、状況を把握しているマネージャーは、従業員に契約書に署名して強制することを試みるべきではありません。深夜とクランチタイムは悪いでしょうが、それはおそらくコースに並ぶでしょう。そしてそれでも時々締め切りはずれます。それは起こり、他の誰かが投稿したように、スケジュールを守る唯一の方法は、要件を早期に凍結して、タイムラインを維持するための十分な余地があるようにすることです。
あなたが言ったことから、警報ベルは数ヶ月遅すぎます。時間に敏感なプロジェクトを、スタッフがまだ慣れていないテクノロジに基づいて行うことは、通常、危険です。要件の収集とスコープの管理を把握していない場合は、そうするのは簡単です。
そうは言っても、私は他の答えに同意します。また、履歴書をまだ更新していない場合は、更新することをお勧めします。
他のすべての回答者と同じように、これが赤信号を立てるべきであるということにこれ以上同意することができませんでした。
PMは開発プロセスに関与したくありません。
私の個人的な業務では、詳細な事前仕様、サインオフ、プロジェクト全体の見積もり、または固定入札価格（コンサルティングの観点から）を扱うことからずっと離れていました。
その理由は、アジャイルソフトウェアとリーンソフトウェアの専門家の多くが述べているように、ソフトウェアは固定された製造可能なエンティティではなく、ほとんどが発見のプロセスであるという認識です。
多くの人々はまだこの概念に問題を抱えており、あなたのPMもそうしたように思えます。それはトレードオフの単純な理解に帰着します。
変更のコストが高いシステムでは、厳密な事前仕様と固定見積もりが機能します。高層ビルを建てるように。エレベータシャフトを事前に仕様化するのを忘れた場合、建物が建てられた後で建物を改造することは非常に困難です。変更のコストが高いと、多くの事前の計画、未知のコンポーネントとテクノロジーの学習、および事前の実験が必要になります。この宿題をすべて終えたら、予算と費用を見積もることができます。
ソフトウェアの人々は、変更のコストが低いという考えに非常に慣れてきているので、リリースを見た後で物事を変更できることを利用して、アプリケーション、ビジネス、顧客に関する新しい理解を取り入れたいと考えています。継続的に。これらはすべて適切に活用された場合、良い機会であり大きなチャンスです。私が出会い、一緒に仕事をしたほとんどのソフトウェアの人々は、実際に多くの時間を計画や調査に費やすことを楽しんでいない。私たちのほとんど（午後を含む）は、進行中の牽引力を見たいと思っています。これは、機能の小規模で段階的なリリースによる反復的な開発の源です。変更のコストが低くとどまり、技術的負債が含まれることを保証するテスト駆動開発など、使用できる他のプラクティスがあります。
この作業を行うには、製品の所有者（PMまたは顧客またはQAチームに代わってアジャイルで話す）と開発者の間の「契約」が必要です。開発者は、優先されたものにのみ取り組むことに同意します与えられたイテレーションにとって最も重要であり、それを永遠に費やすのではなく、完全に統合された機能のチャンクを頻繁に（たとえば、毎週または毎月）リリースするよう努めます。逆に、製品所有者は、増分リリースを継続的に確認し、迅速なフィードバックを提供することに同意します。また、次の反復の優先順位を設定することに同意し、一度設定すると、反復の期間中は気が変わらないように設定します。
契約のこの後の部分は、あなたのPMはおそらく理解していません。多くの従来のPMは実際には理解していません。彼らの一部は、彼らが仕様を落としたときに彼らの仕事が行われたと思っています;彼らは問題、代替案、より良い方法などについて聞きたくありません。欠点は、これがソフトウェア開発の流れを妨げるだけでなく、多くの機会をテーブルに残すことによって組織を傷つけることです。
アジャイルマニフェストを見てください： http://agilemanifesto.org/ それはあなたに共鳴するかもしれません。読むのに適した本は、Mary Poppendieckの「リーンソフトウェア開発」でもあります。
幸運を。
上司に報告するとき、マネージャーが誰かを非難するように探しているようです。
「見積もり」が「固定期間」と同じであると考える不合理なマネージャーがいる場合は、非常に寛大な見積もり期間を考え、それを2倍にすることをお勧めします。
また、要件が完全に詳細かつ修正されていることを確認するようマネージャーに強制します。それ以降の変更は、新しい完了時刻のプロジェクトマネージャーとの「正式な再交渉」なしでは対処されません。
最終的に、プロジェクトマネージャーはアイデアを得て、それに応じて計画を立てます。
この種の私の個人的な経験は、プロジェクトマネージャーが終了をあなた自身のせいにしながら、あなたを処分するために紙の証跡を設定しようとしているということです。それは非常に赤い旗になるでしょう。もちろん、走行距離は多少異なります。
いい答えですが、2セント追加します。
あなたが確率を研究するならば、「ランダム変数」のようなものがあります。これは、値がわからない数値ですが、正規（ベルカーブ）分布などの分布で、知らないことを説明できます。
ポイントは、仕事にはある程度の時間がかかりますが、事前の見積もりはマイナスまたはプラスに少しまたは多く間違っているため、リスクがあり、誰かがリスクを取る必要があるということです。一般的に、人々がリスクを負うと、彼らはそれに対して報酬を受け取ります。保険はお金がかかります。
私がコンサルタントだったとき、私は通常、時間と材料の契約を結ぶか、固定価格の契約を結ぶかの選択肢がありました。時間と材料を使用して、クライアントはリスクを負います。固定価格で、私はリスクを負います。固定価格では、目標を達成できなければ誰も勝てないので、私は安全のマージンを構築します。
実際に何を危険にさらしているのかははっきりしていませんが、固定の納期を守るように要求することは、特に固定された要件がない場合、リスクをあなたに転送しようとするように聞こえます。いずれにせよ、1つの対応は、本当に寛大な安全域を確保することです。
追伸あなたは政府の契約でこれをいつも見ています。提案の最初のリクエストがあり、入札が行われ、低い入札が受け入れられ、その後、変更リクエストが届き始めるため、コストが膨らみ、請負業者が非難されます。クライアントと請負業者の間にチームワーク関係がある場合、敵対関係ではなく、物事がはるかにうまく機能します。
「水の上を歩くことと、仕様からソフトウェアを開発することは、両方とも凍結されていれば簡単です。」
-エドワードV.ベラード
要件が変化している場合、最初の見積もりが正確であることを期待するのは不合理です。はい、これは危険信号です。
はい、もちろん、これはあなたの前の上司の経験と能力についてのフラグを立てます。はい、ほとんどの人が示唆したように、これはあなたの履歴書を更新する良い機会です。
はい、他の回答が述べているように、ほとんどの場合、その契約に署名することは望ましくありません。ただし、署名を検討する状況がいくつかあることをお勧めします。
ほとんどの開発者とマネージャは、機能、期限、および予算の間の絶え間ない摩擦を認識しています。多くの人が品質を4番目の次元として指定します（「私は、あなたがそれが機能しないことを受け入れる用意がある限り、低予算で明日までにあなたが望む一連の要件を提供できます！」）
しかし、さらに別の側面があります。それはリスクです。 50％の時間で問題なく配信できれば、見積もりを大幅に下げることができます。それらは、はるかに高い配信率を処理するために埋め込まれます。
リスクにはさまざまな方法で対処できます（パディングの見積もりもその1つです）。マネージャーはリスクを受け入れる気がなく、リスクを肩にかけたいと考えています。通常、あなたはそのような動きを拒否するべきです...あなたが十分に補償されているのでない限り。
予想外の遅延に対処するために相互に受け入れ可能な量のパディングを使用して、期限を指定することができ、それを達成した場合に（非常に大きな）ボーナスを交渉することができ、ペナルティ（解雇など）ができない場合は、自分でそのリスクを受け入れて契約に署名することは価値のある「ギャンブル」である可能性があります-要件の変更を処理するための適切な条項を使用します。
私は彼/彼女の靴に身を置き、それを動機付けたものを理解しようとすると言います。マネージャー/会計士の見込み客からは、何が起こっているのか、物事がどうなっているのかを正当化するための数が必要です。
締め切りをずらすために役員室でばかげて、締め切りが多すぎるので、彼はそれらをロックする最も簡単な方法を試しました。番号を入力して、ここにサインしてください！あなたはもう一方の端にいるので、それがあなたに対して何かであることに気がついただけでした。どのように見積もりを行い、調整が必要であることに気づくと、彼は彼にとってより有用になります。リクエストの動機と彼が直面している本当の問題は何かを理解していれば、彼とあなた自身を助けることができるかもしれません。プログラマーとして問題を解決します。これも例外ではなく、彼の問題を理解して解決すると、彼はあなたの親友になります。やるべきことがたくさんあるので、個人的な復讐を計画する時間は誰にもありません！彼は彼の仕事の助けが必要です、最も簡単な解決策は誰かに紙に署名してもらうことでした！おそらく彼はダミーの管理の本からそれを手に入れました、「あなたの労働者に署名させてそして数の責任を負わせてください」。おかしいけど悲しい
これはまっすぐな愚かさです。最終的な目標が何であったかはわかりませんが、ソフトウェア製品を担当する中途半端なプロジェクトマネージャーは、見積もりが正確に呼ばれているものであることに注意してください。それらは約束ではなく、ソフトウェア開発者のすべてのエネルギーを使い果たすか、とにかく彼らに「約束」を破らざるを得ない限り、そのようにすることはできません。
そのような契約がいかにばかげているかを示したい場合は、次の2つの提案が考えられます。
a）契約なしで見積もる場合に比べて、プロジェクトに5〜10倍の時間がかかる点まで非常に過大評価します。プロジェクトマネージャが見積もりが非常に高い理由を尋ねた場合は、単に契約を履行できることを確認しているだけだと言ってください。
b）これはすでに提案されています。単一の要件が変更されないことを確認し、これにスペルミスの修正が含まれることを確認する契約を依頼してください。私の経験では、開発中のある時点で要件が変更されない単一のソフトウェアプロジェクトはありません。プロジェクトマネージャは、あなたよりも契約を解除する必要がある可能性が高くなります。
プロジェクトマネージャーがこれらの2つの提案のいずれかに同意する場合は、彼らが彼らの頭にないことを確実に知っています。
ちなみに、正社員との契約はどうですか？私は他の国の労働規制については知りませんが、会社の正社員として、締め切りに間に合うように拘束力のある契約に署名し、有効な訴訟を起こすことを強制できる人はいないと思います。確かに、締め切りに間に合わない場合、彼らはあなたに地獄を与えるかもしれませんが、そのための契約は必要ありません。誰もあなたを解雇したり、あなたにもっと少ないお金を与えることはできませんでした。彼らはあなたの同意したボーナスを最悪にカットするかもしれません。したがって、これが他の国で異なる場合を除いて、これは、真剣に取り組む必要があるものよりも空の脅威のように見えます。
ここで穀物に逆らうつもりです。
あなたが説明する状況は、エンジニアリングteamレベル、特に特に遅いプロジェクト/リリースでは、それほど珍しいことではありません。多くの状況で、経営陣と組織全体が実際に特定のリリース日にサインアップしていて、組織の他の部分が連動している場合がありますその日付まで。その日付に到達するために、管理チェーンに多大な圧力がかかる可能性があります。
これが一般的なエンジニアリングプロセスの出番です。おそらくウォーターフォールモデルについて聞いたことがあるでしょう。他のモデルもありますが、それらすべての最終目標は、いつが期待され、whatに同意しました。機能仕様、設計、タスクリストなどはすべて、これを予測可能なプロセスにすることを目指しています。コミュニケーション、リスク分析、および（おっしゃったように）スケジュールに関する期待を定期的に更新することで、驚きを減らし、情報をできるだけ早く利用できるようにすることで、計画を調整できます。そしてはい、機能が追加または削除されるたびに計画に調整が必要です。
私が協力してきたいくつかのチームでは、見積もりに署名済みのコミットメントとして扱うのをためらうことはありませんが、これはチームと経営陣の質を反映しており、特定の見積もりスキルを反映していません。 teamは、納期どおりに契約を結ぶことを望んでいるのは、うまく機能しているチームの指標であり、赤旗。