ソフトウェア業界に比較的慣れていないので、期限の強制についての質問に出くわしました。
アカデミアの牧歌的な時代に戻ると、締め切りは学期の終わりであり、ペナルティは明確に定義された「F」（または地域の同等物）でした。現実の世界では、現在および将来のピアが使用できるコードを作成する必要があります。締め切りが来て、締め切りが過ぎても、プロジェクトがまだ完了していないという状況に直面しています。
それで？極端な場合は、関係者全員を解雇することができ、他方では、関係者全員に豊富な報酬を与えることができます。
期限を過ぎた場合の「ペナルティ」としてどのようなアクションが適用されたと思いますか。また、これらのうちどれが最終的にはより良いコードになりましたか。
プロジェクト管理の対応により、プロジェクトが完全に失敗したのはどのようなものでしたか。
どのような応答が正常に機能し、後で維持できるコードをもたらしましたか？
どのような応答がより悪いコードをもたらしましたか？
締め切りは、ソフトウェア開発を行う方法についての根本的に間違った考えの一部です。ソフトウェア開発業界に不慣れな、またはその外の人々は、これを理解していません。
ソフトウェアは、それが行われたときに、すぐに、そして後で行われることはありません。
開発者にタスクとそれを行うための1週間があり、1週間以上かかると思われる場合、それを変更するために何もすることはできません。開発者がどれだけ一生懸命働いても、タスクに何人の人が追加されても、それはそれがかかるのと同じくらい長くかかります（実際、人を追加すると通常は時間がかかります）。
代わりに、アジャイル開発プロセスを読んでください。ソフトウェアは繰り返し開発する必要があり、各反復は、課せられた外部要件ではなく、前の反復の結果に基づいている必要があります。
以下の広範なコメントに基づいて編集します。
私は、開発者が何らかの配信の期待にとらわれることができないとは決して主張しません。私のポイントは、ビジネスにおけるソフトウェア開発の性質は、学業やその他の種類の仕事に何らかの形で類似しているという、質問者が提起した特定の仮説に対応するものです。私はそれが絶対にそうではないと主張します。「締め切り」とは、単なる納期以上のものを意味します。これは、一定量の作業を完了する必要がある固定点です。ソフトウェアは単にそのようには機能しません。その理由を説明する段落をさらにいくつか書きましたが、正直なところ、まだ信じていないのであれば、私が言うことは何もあなたを納得させることはできません。
ソフトウェアプロジェクトに取り組んでいて、期限に間に合わないことが明らかな場合、それを修正するために何ができますか？答えは今ではよく知られています：事実上何もありません。これ以上人を追加することはできません。あなたは「より速く働く」ことはできません。時間通りに終わらないだけです。あなたは利害関係者に話し、誰もが調整し、働き続けます（またはしません）。では、元の日付はどういう意味でしたか？
ソフトウェア開発が橋の建設や宿題に類似している、または開発者がたわごとをまとめて自分の尻を片付ければ、差し迫った締め切りに間に合わせることができると主張する人は誰でも、自分の職業について深く混乱しています。
最初の反応は、締め切りに間に合わなかった場合にどうするかではなく、締め切りに間に合わなかった理由を分析することです。期限を逃したことへの対応は、理由の結果として、それから自然に続きます。
たとえば、関係者全員が仕事をしなかった場合は、解雇します。
しかし、彼らが仕事をした場合、そしてそれ以上のことをした場合、なぜそれがまだ逃されたのですか？同じ人が行う他の活動が多すぎますか？期限の範囲が大きすぎる（つまり、非現実的な期限）。または...など。
私の経験で期限を逃した最大の理由は、人々が手元のプロジェクトで100％作業することを許可されていないため、あなたが持っているかもしれない見積もりは、それ自体は正確ですが、まったく役に立ちません。それに加えて、非現実的な見積もりと期限。
開発者は、管理者の過ちに対して罰せられるべきではありません。
親が悪い日を過ごしたので、親が子供を罰するようなものです。
理由：
締め切りは現実です。人々は何かがどれくらいかかるか知りたがっています。私たちができる最善のことは、見積もり/推測です。この魔法の、決して正しい推測を理解しようとするのは経営者の役割です。期限を作成するときは、適切なツールを使用する必要があります（経験、開発者、弁護士、時間などに助けを求める）
でも....
期限を逃したことに対する罰則は、労働者に頼るべきではありません。締め切りに間に合わなかったのは経営者の責任です。彼らはノーと言うべきだった、プロジェクトを縮小すべきだった、あるいは労働者の意欲を高めるべきだった。
建設作業員では、労働者を怒らせると戦いが始まります。私の会社では、締め切りに間に合わないと経営陣が困ります。労働者ではありません。プロジェクトと何が行われるかを管理するのはマネージャーの仕事です。労働者はできることだけをしている。マネージャーは、役割とタスクの割り当てを担当します。
労働者の質が要因ではないと言っているわけではありませんが、経営者はそれを知っている必要があります！プロジェクトが十分に検討されていない、または適切に管理されていないことを知るのに天才は必要ありません。上司が何が起こっているのか考えているかどうか誰かに尋ねると、問題が見つかります。
マネージャーが期限を設定/同意するのは彼らのせいであることに気付いたとき、私たちは多くの期限を逃すことをやめました。
</rant>
Re：質問：
1.締め切りに間に合わなかった場合の「ペナルティ」としてどのような行動が適用されたと思いますか。また、実際に物事を「より良く」したのはどれですか。
2.どのようなプロジェクト管理の応答がプロジェクトを完全に失敗させ、どのような応答が正常に機能し、後で維持できるコードをもたらしましたか？
ペナルティではなく、現実的な見積もりと時間通りのリリースに報いるのはどうですか？
私の応答へのコメントに触発されました
たぶん、質問は「どうすれば現実的な見積もりを行うことができるか」ということになるはずです。私の場合、FogBugzの 見積もり履歴と完了日のプロットを使用します。これらは、タスクにかかる時間を見積もった時間と実際にかかった時間のデータポイントを提供します。これは、長期的に現実的なリリース日を与えるのに役立ちました（一夜にしては起こりませんでした）。タイムラインの見積もりは対話型のプロセスであると思います。
死。清潔でシンプル。
開発者が各変更要求に期限を設定するかどうか、または管理者が期限を設定するかどうかによって異なります。
後者の場合、すべての開発者が1日中座ってHalo 3をプレイしていない限り、締め切りに間に合わなかった場合は、管理者またはチームリーダーの側に間違いがあることを示していることがよくあります。したがって、全員を解雇しても問題は解決しません。ソフトウェアプロセスにより良い指標を導入することは理にかなっているかもしれません。そうすれば、締め切りが来るずっと前に締め切りに間に合わないことがわかります。
開発者が時間の見積もりを出す場合、締め切りに間に合わなかったり、締め切りに間に合わなかったりした場合に、開発者に報酬を与えたり、ペナルティを科したりすることに非常に注意します。これを行った結果、時間の見積もりで「ファッジファクター」を調整する可能性があります。彼らは（報酬を獲得するために）あまりにも多くの余分な時間を与えるでしょう、それは彼らが見積もりが得意であるならば物事を台無しにします。あなたの目標は、彼らがこれらの見積もりを満たすために働く方法を変えるのではなく、彼らに良いそして信頼できる見積もりを与えるようにすることであるべきです。
そもそも締め切りが可能かどうかにもよるが、計画と見積もりに問題があったのかもしれない。罰を決定する前に、期限を逃した理由を知っていることを確認してください
ちょっと、あなた...
まず、外部の期限と内部の期限があり、それらは異なる必要があります。
内部期限で発生するのは、期限が近づくにつれてアクティビティの頻度が増加し、期限にピークに達し、期限が近づくにつれて低下することです。したがって、外部の期限は、少なくとも数週間は内部の期限に従うように計画してください。
次に、期限が現実的であることを確認します。部分的には、開発者を設定に関与させ、何を達成するかを決定することによってそれを行います。
最後に、私は主に開発者でしたが、一度経営陣を突き刺したときは、最新かつ最高のバージョンを会議やプレゼンテーションに持ち込みたくありませんでした。少なくとも数週間前のバージョンを使用したいと思います。問題がどこにあるかを知っていて、不快な驚きが含まれていないことを確信できました。
プロジェクト管理に関する彼の素晴らしい本「締め切り」の中で、トム・デマルコは、西側世界のプロジェクトマネージャーが架空のポストコミュニストの東ヨーロッパの野生の国でプロジェクトを管理しているという話をしています（野生は本当に良い用語です。市民は少し..文明化されていません）。
ある日、PMは何かがうまくいかなかったことを発見し、彼のプロジェクトの一部が非現実的なスケジュールを劇的に逃しました。前の首相は、責任者を肉屋のフックにぶら下げるだけで期限を逃したことに対するペナルティを設定しましたが、スケジュールが非現実的だったため、1人の男性がすでに期限を逃しました。
それで、物語は、西洋式の首相が責任者と一緒に提示され、彼が肉屋のフックに絞首刑にされるために彼を送るべきである日について私たちに伝えます。PMは、ほとんどの人がそうであるように、プロジェクトを時間内に完了できなかったという理由だけで、誰かに残酷な死を宣告するというビジョンを恐れています。そして、どうしても、この貧しい男をぶら下げることはプロジェクトを前進させません。これは拷問ではなくプロジェクト管理に関するフィクション小説であるため、私たちのヒーローはペナルティをキャンセルします。
しかし、誰かを絞首刑にすることについて、この話の背後にはいくつかの大きな問題があります。締め切りを設定し、この締め切りに間に合わなかった場合に何らかのペナルティを設定すると、その日が来るでしょう。おそらく実際に誰かを罰する必要があります。そして、あなたはそれをしますか？罰が何であろうと：ぶら下げ、ボーナスの損失、解雇、取引の破綻、またはいくらかの料金–誰かを罰しなければならないかもしれません。このペナルティはあなたのプロジェクトにいくらか役立つでしょうか？あなたは自分でそれに答えなければなりません。
したがって、期限を過ぎてもペナルティを設定しないでください。実行したくないでしょう…</ p>
他の人が述べているように、ペナルティについて話す前に、「これらの期限が現実的であるかどうかをどのように判断するか」から始めますか？
または、私の上司がかつて言ったように、「あなたが私たちにうまくいく計画を与えたら、私たちは喜んで計画を立てます」。
私はまだそれがTシャツにあるべきだと思います。
私のキャリアのこれまでのところ、締め切りを逃したことによる実際のペナルティは見られませんでした（そして私はたくさん逃しました）。ソフトウェアやゲームを作っている会社が、公に約束した店で売るのは違うと思います。
しかし、カスタムソフトウェア開発の領域では、プロジェクトにかかる時間を正確に見積もることは非常に困難です。そして、多くの場合、この事実はどこの企業にもしぶしぶ受け入れられています。
締め切りに間に合わなくなったら、（A）その自然な結果は何か、（B）タスクを完了し、ビジネスに向けたある種の動きを維持するにはどうすればよいかを自問する必要があります。目的（あなたがビジネスを運営していない場合でも）。
期限を過ぎたことで明示的にペナルティを科すことが、期限を過ぎたと信じない限り、役に立たない可能性があります。期限が非現実的だった場合、主要な障害点であるチームの要素があった場合、要件に重大な問題があった場合、または関係するチームの大多数が上記の要因が正しいと信じている場合、これは起こりません。
あるケースでは、私は小さな成果物の締め切りを3か月以上遅らせたチームに所属していました。当初の成果物の期日は、開始から3か月でした。要件を誤解し、お客様と十分に話し合わず、時間を過小評価していました。経営陣は非難を割り当てることにまったく興味がありませんでした。これは、成果物の完成に逆効果があったこと、「問題のある従業員」がいないこと、経営陣が問題を解決して顧客を満足させる意欲があることを経営陣が知っていたことによるものです。それで、私たちはそれを成し遂げ、顧客は期待できるほど満足し、私たちは私たちの生活を続け、将来の状況を回避する方法についていくつかの貴重なレッスンを行いました。
私は懲戒処分や解雇を見たことがありませんが、多くの「強制的な」残業や同僚からの長時間労働への圧力を見てきました。
私は、週末に来て遅くまで働かないようにと私に報告したチームに言ったために、マネージャーとして解雇されそうになりました。私はそれらがプロジェクトと士気に有害であることを知っています。
一般的に「罰」は、人々に罪悪感や不安を感じさせる形ですが、もっと「公式な」ことをする場所もあると思います。
世界は馬鹿でいっぱいです。管理も例外ではありません。
ペナルティなし。「締め切り」と見積もりは、ソフトウェア開発の最も困難で最も困難な部分の1つであり続けています。
この問題について開発者にペナルティを課すことはばかげています。
それ自体の質問は、管理とプロジェクト管理の役割についての誤解を示していると思います。
残念ながら、多くの人の心には、マネージャーという言葉がタイトルに含まれているという一般的な認識があります。管理とは、怠惰な労働者の尻を癒す/蹴ることを意味します。パーキンソンの法則を信じる人にも合います。
そうではありません。それは、作品が仕事をすることを可能にすることです-それは彼らと組織の他の部分との間のコミュニケーションチャネルであろうと、彼らにリソースを取得することであろうと、干渉を実行すること（家具を邪魔にならないようにすること）であろうと。
つまり、PMは、プロジェクト/タスクが期限を過ぎてしまうことをすでに知っているはずです。彼らは質問をし、何が起こっているのかを知っているべきです。彼らには、タスクを削減するか、リソースを増やしてバランスを取り直して仕事を成し遂げる力があります（または、リソースを与えないと、時間どおりに成し遂げられない場合は、スポンサーに言います）。そのため、ペナルティは、それが何もない、舌をたたく、降格、または終了であるかどうかにかかわらず、PMに適用されます。
場合によっては、遅延が避けられません。これが、私たちが不測の事態に備えている理由です。時々、それは既知のリスクです。そして、バックアップ計画がある限り、あなたは大丈夫です。
回答に関しては、スコープ、時間、お金、品質の4つのパラメーターがあります。
これらのことを（必要な場合に）十分に積極的に行わないと、間違いなく失敗につながります。
それは確かに簡単な答えではありません。これが私が計量するいくつかのことと、物事が時間通りに行われることを確実にするために私がする/奨励することです。
1.）優先順位を適切に設定します。プロジェクトは常にさまざまな程度で完了します。これは、バイナリの「完了」/「未完了」の切り替えではありません。最優先事項を最初に行うと、飲み込みやすくなります。理想的には、すぐに機能するようになるはずですが、必要なすべてのことを実行できるわけではなく、見栄えもよくありません。そこに到達したら、どうしても必要な場合はリリースできます。
2.）それを処理する最良の方法は、リリースをできるだけ小さくすることであることがわかりました。これにより、見積もりがより正確になります。上司または「市場」が見積もりを受け入れられないと判断した場合は、可能であれば、このタスクにより多くの開発者を割り当てることを検討してください。タスクを簡単に分割できない場合や、コードに精通している人が1人だけの場合があります。優先度が高くない場合は、時間がかかることをパワーに伝えてください。合理的な目標を設定し、期待を管理することが重要です。
3.）動機、報酬、罰については...これらの主題について本全体を書いた医師はたくさんいます。私の経験では、プログラマーにやりがいのあるものを提供し、プログラマーに自由にそれを実行させることは良いスタートです。聞くことは、マネージャーが成功するためにうまくやらなければならないことです。開発者が熟練している場合は、問題を説明し、開発者に解決策を考えさせることができるはずです。彼らの解決策があなたが考えていたものほど良くない場合、あなたはそれを提案してそこから行くことができます。新しいプログラマーであっても、何かを行う方法を指示するだけでは、ほとんど効果がありません。開発者に物事について考えさせることは、開発者が自分で問題を解決できるようにするのに役立ちます。これは委任に関連しています。これは、開発者が自分で作業を実行できる場合にのみ機能するためです。
4.）うまくいっている場合は、人々によく支払うことで売上高を減らします。通常、良い人を見つけるのにはるかに多くの費用がかかります。大規模なコードベースに慣れるには時間がかかります。また、採用プロセスは、マスタードを切ることができない人々に時間を費やすことを避けるのにも役立ちます。
5.）開発者が週末に遅くまで仕事をすることができるかどうかを尋ねます（要求しないでください）。これは、非常に重要な場合にのみ実行してください（たとえば、ユーザーがアクセスできないはずのデータにユーザーがアクセスできるようにするセキュリティ上の欠陥、準拠しなければならない新しい法律/規制の通過など）。彼らがノーと言った場合、彼らに対してそれを保持しないでください。物事が成し遂げられなかったのは彼らのせいではないでしょう。たとえそうだとしても、彼らが仕事をすることが期待されていない時間の計画を立てたのは合理的です。彼らが喜んで入ってきたら、彼らがあなたの心からの感謝を知っていることを確認してください。彼らが義務付けられていないときに助けるために彼らをうまく補償します、昼食を買うことはそれほど費用がかからず、それは非常に素晴らしいジェスチャーです。それがない限り、人々が遅く/週末に働くことを期待する習慣をつけないでください」
6.）物事が予定より遅れている理由を理解します。あなたは不可能なことを約束しましたか（利用可能な人々、期待される品質、割り当てられた時間を考えると）？他のプロジェクトが立ち上がってリソースを消費し、期限が調整されませんでしたか？コードは予想よりも実行が難しかったですか？時間の見積もりを出すのは難しいです。すべてを計画し、経験を積み、各開発者がタスクにかかる時間を知る必要があります。発生する可能性のある予期しない問題を補償し、プログラマーに上司やクライアントよりも早い期限を与えます。早くやっても大丈夫です。そして、ほとんどの場合、早い段階または時間どおりに完了している場合、ある種の説明があれば、締め切りに間に合わなかったことがより理解しやすくなります。
7.）覚えておいてください、それは通常、時間、品質、そしてお金に要約されます。通常は2つを選択できますが、3つ目は方程式のバランスを取る必要があります。したがって、それを迅速かつわずかな予算で行う必要がある場合は、品質が低下することが予想されます。あなたがそれを迅速にそして高品質で行う必要があるならば、多額のお金を払うことを期待してください、等々。
8.）私にとって最も効果的なのは聞くことだと思います。あなたの忙しすぎる吠え声の注文なら、あなたは会社の問題についてさえ知らないかもしれません。開発者が「コードがひどいので、デザインがひどいので、タイムリーに何かをやりたいのなら、すべてを書き直す必要がある」と言ったからといって、それが実現するわけではありません。しかし、そのようなコメントを聞いて、これを行う余裕がない、または市場で殺されるだろうと説明した場合、それは非常に高価になります。そして、物事がそれほど悪化しないようにするために何ができるかを尋ねます。時間の経過とともにクリーンアップできる方法があるかどうかを尋ねます。1つのクラスを（再）作成し、それに基づいて新しいものを構築することはできますか？一度に1つの機能/セグメント/モジュールを新しい設計にゆっくりと移行できますか？あなたはそれらがどこから来ているのかを理解しており、逆もまた同様です。おそらく少なくともいくつかの問題を解決することができます。妥協は両方の方法で機能することを覚えておいてください。
9.）負の強化は、より高い離職率をもたらすようであり、これはコストがかかります。あなたのコードに精通していない人がたくさんいることも、締め切りに役立ちません。お金は一つの動機ですが、私は以前より幸せな場所に行くために高給の仕事を辞めました、そして私はそこに一人ではないことを知っています。チームが良い仕事をしているときの無料の食事は、それほど高価ではありません。グループ活動は、従業員の時間を減らしたり、仕事の時間を奪ったりしているので、あまり熱心ではありません。それは時々機能しますが、従業員の個人的な時間を短縮して、友人と一緒にいる代わりに同僚と一緒に過ごすことができるようにすることは、それほど大きな報酬ではありません。全員に仕事をやめさせるのも費用がかかるので、会社の規模や文化などによって異なります。
うまくいけば、それはあなたの質問に答えるのに役立ちます。このスレッドの他の回答も良い提案です...デザインはコードがどれだけ速く書かれるかに大きな役割を果たします。
締め切りに間に合わない場合は、見積もりを修正してください。
企業開発の観点から...
作業を行っている人以外の人が締め切りになっている場合は、状況を確認してオーバーランの原因を特定してください。これらの場合、それはしばしば不完全な要件、スコープクリープ、不十分な管理などに関連しています。そもそも人が決して提供しなかった期限を逃したことに対する罰は与えられるべきではありません。
作業を行う個人が期限を定めたり合意したりした場合、その人は遅延の原因となった要因を説明する必要があります。さらに、この人は、締め切りに間に合わない可能性があることに気づいたらすぐに、上司、プロジェクトマネージャー、またはその他の責任者に通知するように通知する必要があります。この情報は、期限が過ぎた後は明らかにならないはずです。これが繰り返し発生する場合は、会社の懲戒手続きに従う必要があります。これには、書き込み、一時停止、または終了が含まれる場合があります。
締め切りを設定するのは、締め切りを実際に所有する傾向があります。締め切りが入力なしで設定されると、締め切りは作業を行う人にとって無意味になる傾向があります。
プロジェクトが遅れると、「管理」（良い、悪い、意味のある、または悪意のある）でできることはあまりなく、プロジェクトがさらに遅くなることはありません。
...唯一の例外は、外部の気を散らすものの除去/回避である可能性があります。
あなたの質問は本質的に欠陥があります：それは罰が人々を管理するための最良の方法であると仮定しています。一般的に、人々は罰や罰の脅威にうまく反応しません。それは最悪の行動を引き出し、動機を外部にし、内部の動機から気をそらします。報酬と賄賂（報酬の脅威）は同じコインの反対側であり、それ以上のことはありません。
これらの部隊は職務著作物として機能するように組み込まれているため、プログラマーから最高のクリエイティブな仕事を引き出すことはできませんが、締め切りに間に合わなかった場合に罰することで悪化させる必要はありません。
代わりに、創造的なプロセス、創造的な仕事をしている複数の人々の混沌、そして混沌を管理するのに効果的なツールについて瞑想してください。
混沌としたシステムを管理するには、多くの測定を行い、コースをすばやく変更する準備をします。プログラミングの場合：
可能な限り最小の手順を実行します。「タスクを小さなステップに分割」しないでください。計画どおりに機能しないステップを計画するのに多くの時間を浪費することになります。カオス、覚えてる？
最大の価値をもたらす最小のステップを選択してください。
短期間で、学んだことに基づいて計画を再評価します
実際の実際の顧客にできるだけ早く実用的なソフトウェアを提供して、彼らがあなたが実際に何をすべきかを教えてくれるようにします。
これはスクラムの背後にある考え方として認識されるかもしれません。
おそらくより良い質問は、不正確な見積もりに直面して期限が意味があるかどうかです。企業はソフトウェアを見積もるというお粗末な仕事をします-それは事実です。管理者と開発者の両方がこれに関与しており、どちらもこの問題での責任を自覚することをいとわないようです。
しかし、あなたの特定の質問に答えるために：
1.締め切りに間に合わなかった場合の「ペナルティ」としてどのようなアクションが適用されたと思いますか。また、これらのうちどれが最終的にはより良いコードになりましたか。
マネージャーや開発者の締め切りに間に合わなかった場合に見た「ペナルティ」は、何もないものから昇進、単純な異動までさまざまです。私が個人的に目撃した最も厳しい罰則は、マネージャーがそれほど重要ではないプロジェクトに「異動」し、ビジネスユニットが金銭的ボーナスを失うことでした。
期限を過ぎて誰かが解雇されたのを見たのは、従業員がすでに解雇される予定だったときだけでした。期限は、ビジネスに従業員を解雇する法的理由を与えました。
2.プロジェクトが完全に失敗した原因となったプロジェクト管理の対応は何ですか？
これはそれ自体でまったく別の議論です...しかし、この質問にはいくつかの固有のバイアスがあります-プロジェクト管理に責任があります。
私が個人的にPMがプロジェクトを妨害するのを見てきた上位3つのことは、（重大度の順に）次のとおりです。
3.どのような応答が正常に機能し、後で維持できるコードをもたらしましたか？
機能的なソフトウェア開発組織はまだ見たことがありません。したがって、修正は通常、社内の政治から身を守る方法を知っている（つまり、BSをスタッフからそらす）非常に有能なPMと協力している2人の英雄的な開発者からの大量の血、汗、涙です。
4.どのような応答がより悪いコードをもたらしましたか？
いくつかの締め切りに間に合わなかった直後に、幹部が会社を辞めるのを見ました。これはすべてを変えましたが、必ずしも物事を良くしたり悪くしたりするわけではありませんでした。私は、クローバックのようないくつかの契約上の義務を、彼らがどれほどうまく機能しているかわからない期限を逃したことで誰かにペナルティを科す方法として見ました。
プロジェクトに割り当てられた時間の途中でプロジェクトが行うことになっていることを完全に変更すると、最初の軌道が無効になり、予算内の最初の期限に間に合わない可能性があるため、プロジェクトは失敗します。プロジェクトをせいぜい数か月の短い増分に再計画することは、多くのプロジェクトが締め切り、人数、または時間は働いた。
2つの可能性があります：
ペナルティの観点から考えるのではなく、事後分析を行って何が悪かったのかを判断し、次の期限の見積もりを改善する方法を見つけることをお勧めします。
あなたは「ペナルティはどうあるべきか...」と尋ねます。「社内」の観点からお伺いしているようです。
実生活では、罰則はしばしば迅速かつ厳しいものです-ビジネスの喪失、訴訟、業界での評判の悪さ。これらは、特定の日付までに履行されなかった何かを約束されたクライアントによって課される実際のペナルティです。
内部的には、多くの場合、好きなことを行うことができます。しかし、有料のクライアントを巻き込み始めると、それらのクライアントの管理は全体的な仕事の重要な部分になります。
私が説明したようなペナルティは、クライアントとの「トップ」コミュニケーションによって回避（または軽減）できることがよくあります。クライアントが何かを追加したい場合（いわゆるフィーチャークリープ）、これらの変更がプロジェクトに与える影響（コストが高く、後で提供されるなど）ですぐに回答する必要があります。クライアントは、そのようなすべての要求を期限と予想されるコストに照らしてトリアージするように奨励されるべきです（つまり、クライアントに機能のクリープを管理させます。あなたではありません）。
他の事柄が配達時間を変更する場合、滑りがあることがわかったらすぐにクライアントに通知する必要があります。早期に行われた場合、クライアントは非常に喜んであなたと協力します。しかし、手遅れになるまで何も言わないと、彼らは許す可能性が低くなります...特に、あなたがかなり前に知っていて、彼らに言わなかったことを彼らが発見した場合はなおさらです。
乾杯、
-リチャード
開発者とそのリードのすべてのアドバイスに対して非現実的に短い開発期間を設定した場合のペナルティは何ですか？
偶然にも、これは開発チームが出荷日を逃したのとほぼ同じくらい頻繁に起こるようです。
これは実際にはプログラミングの質問ではなく、管理の質問です。
締め切りに間に合わなかったことが開発者のせいになることはめったにありません。開発者として、あなたはできる限り良い仕事をするために最善を尽くすべきです、しかし結局、誰もがそれだけの能力しかありません。開発者が正直に努力し、それにもかかわらず締め切りに間に合わなかった場合、それは締め切りがそもそも非現実的だったことを意味します。
締め切りに対処することはマネージャーの責任です。さまざまなアプローチがありますが、それらのいずれにも、開発者が仕事をすることに対して「ペナルティを課す」ことは含まれていません。ここで理解しておくべき重要なことは、いわゆるプロジェクト管理の三角形です。つまり、ソフトウェアプロジェクトは、優れている（つまり、要件を満たしている、品質が高い）、高速（期限を守る）、安価（人員、ツール）である可能性があります。問題は、これら3つのプロパティのうち2つしか選択できないことです。
したがって、経営陣が何か良いものと速いものを求めているのなら、それは安くはないでしょう。
経営陣が何か良いものと安いものを望んでいるなら、それは速くはありません。
そして最後に、経営陣が安くて速いことを望んでいるなら-何を推測するか、それは何の役にも立たないでしょう。
したがって、期限を過ぎた場合の正しい対応は、選択したシナリオによって異なります。優れた高速性には、いくつかの追加のヘルプ、より優れたツール、平均以上の開発者への投資などを追加する必要があります。
定義上、良いものと安いものは、締め切りに間に合わないことを前提としています（Blizzard、World Of Warcraftのメーカーはこのアプローチの良い例です）
そして最後に、安くて速いということは、通常、機能を切り取ってバグをリリースすることを意味します。
プロジェクト管理の主な目標は、アプリケーションが時間内にどのように構築されるかを計画することです。プロジェクトが続く毎日何をするかを示すスケジュールがない場合は、プロジェクト開発を開始しないでください。
このようにして、プロジェクトの進展を定期的に（毎日ではないにしても毎週）追跡している限り、遅れることを検出できます。そして、あなたがそれを早く知っているほど、あなたはそれに応じてより早く行動することができます。
通常、2つのオプションがあります。
2番目のオプションについては、ペナルティが発生しないという意味ではありません。しかし、私の個人的な経験から、顧客が事前に通知され、解決策を提供されている限り（できれば、3つ：追加の労働者にもっとお金を与える/時間を節約するために機能を削除する/プロジェクトが遅れることを受け入れる）、彼らは交渉にオープンになります。これは常に競合よりも優れています:)
締め切りに間に合わなかったために解雇されました。98％が製品、外力、締め切りを終えました。これらの会社はソフトウェアを適切に開発することを許可していません。私でさえ、その状況下でいくつかの貧弱なコードを書いたことを認めることができますが、私はいくつかの優れた保守可能なコードも書きました。機能のクリープについては考慮されていません。実際、技術仕様は事前に詳細に説明されておらず、ソフトウェアの限定されたバグのあるバージョンが管理者のレビューに利用できるようになったため、機能の適応が必要でした。私はもっとうまくコミュニケーションをとることができたかもしれませんが、私がコミュニケーションをとったとき、締め切りは交渉不可能であることが強調されました。
私はこれを支持していませんし、これらのいずれも実装していません。それらは私が聞いた興味深い/奇妙なものです
リリースサイクル（通常はFOSS）でビデオを読んだり見たりしているだけで、一般的なことは次のように思われます。
それはあなたのためのオープンソースソフトウェアだと思いますが！
締め切りに間に合わなかった場合、2つの明らかな質問が思い浮かびます。
明らかに、誰かがあなたに意味のない期限を提示した場合、期限を逃したことに対するペナルティはありません。また、陪審員として召集されたために締め切りに間に合わなかった場合も、陪審員としての義務を負わないようにする必要があります。
これらの質問が当てはまらない場合、次に行うことは、何が悪かったのかを理解することです。何かにかかる時間、つまり期限の見積もりを、開発者がコードを書くのにかかる時間の見積もりに基づいている場合、おそらく彼らは彼らの応答において楽観的すぎました。
「誰がいつまでに何をするか」は、各プロジェクトチームメンバーがあらゆる職業で専門的なコミットメント/応答を提供しなければならない質問です。期限を過ぎた場合は、その証拠を使用して見積もりプロセスを改善し、個人に新しいコミットメントを行うように依頼します。これは、彼らが実際に前の締め切りに対してなされたコミットメントであったことを前提としています。「いつまでに誰が何をするか」に関するすばらしいシリーズがmanager-toolsで入手できます。
また、見積もり、目標、コミットメントを区別することをお勧めします。そして、「ギャップ」または見積もり<---ギャップ--->コミットメント間のリスクを管理します。 ソフトウェアの見積もりを見てください：ブラックアートの謎を解き明かしてください。
締め切りとコード品質について、どちらか一方が存在するゼロサムゲームの一部であるかのように話します。一歩後退するために、プロジェクトの全体的な成功は、会社/コミュニティに提供される全体的なメリットに基づいています。メリットは、プロジェクトの開始時に明確に決定する必要があり、品質コード、市場投入までの時間、機能、または全体的な品質または任意の組み合わせ。コスト/労力は、目的、環境、関係者に基づいて見積もられます。コストやタイムラインを正確に決定する方法はありませんが（将来を予測することはできません）、ナビゲートに役立つガイドラインとして設定します。そして、最終的なメリットが努力によって上回らないようにします。あなたの特定の質問に：
1. –どのようなペナルティアクションが使用されているのを見ましたか？発砲からペナルティなしまで–ほとんどの場合、プロジェクトの失敗の最大の原因であるアクションが実行されていないことを確認しました（回答＃2）
2 –プロジェクトの失敗の原因となったプロジェクト管理の対応–最初のタイムラインが満たされない理由を修正または対処せずに、アクションを実行したり、将来の任意のタイムラインを設定することに集中したりすることはありません。
3 –どのような応答で正常に機能しましたか？根本的な原因/リスク分析、プロジェクトの迷いの基本的な問題が何であるかを把握します。タイムラインとコストは、プロジェクトに問題がある可能性があることを示す単なる指標です。全体的な品質、チームのモラル、コミュニケーションなど、プロジェクトが強要されていることを示す、より意味のあるものが他にもあります。
4 –どのような応答がより悪いコードをもたらしましたか？応答がないか、意図したメリットを提供するのではなく、期限を守ることに重点を置いています。
見積もりが出された後、仕様や要件は変更されましたか？
プロジェクトマネージャーは、期限を逃したことではなく、期限を誤って計算したことに対してペナルティを課す必要があります...
ペナルティは、そもそも期限を与える（または求める）目的のみに基づく必要があります。
彼らは最大で2回締め切りを逃し、その後は好きなだけ締め切りを逃すことができます...