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