多くの人は期限が役立つと考えていますが、ソフトウェアを書くときに期限を設けるとマイナスの影響があると考えることがよくあります。 それにもかかわらず、それらは注意して使用する必要があるようです（他の幸福の丸薬のように）。 タイミングがどのようにプロジェクトに悪影響を与えるか、タイミングが将来の結果をどのように改善するかを分析しようとしました。
記事全体を読むのが面倒な人のために：締め切りが必要だと思いますが、マネージャーとプログラマーは、時には締め切りが失敗し、これには大きな悲劇がないことを理解すべきです。 状況は、特定の人々ではなく、失敗した時間のせいにすることがあります。
あなたがすることの締め切りがあることは良いことです。 しかし、プログラミングの場合、いくつかのニュアンスがあります。
ソフトウェアの記述に用語がどのように役立つか期限のおかげで、将来の計画を立てることができます。 機能Xの作業を2か月で完了する予定であれば、3か月でソフトウェアの新しいバージョンをリリースできることがわかります。
タイミングは合理化/最適化に役立ちます：Petyaが2か月で機能Xの作業を終了し、Vasyaが2日間でタスクの作業を終了することがわかっている場合は、誰がどれだけの作業をしているのかを簡単に整理できます。 明日、重要度が中程度のバグがある場合、合理的に状況を比較検討し、Vasyaがこのバグを修正することを決定できます。このバグは2日で無料になります。
タイミングは、ジョブを指定する追加の方法としても機能します。 プログラマーはタイムラインの影響下で操作することができます-どこかで彼はもっと熱心できれいになりますが、どこかではそうしません。 それは良いことです このような操作により、最終的にはソフトウェア開発の速度が向上します。
期限が良いソフトウェアの作成を妨げる理由残念ながら、プログラミングは複雑なものであり、優秀な専門家でさえ期限を正確に計算することはできません。 さらに、ほとんどのプログラマーは、タイミングが過度に楽観的であると見積もっています。 したがって、多くの場合、期限は延滞しています。 プログラマーは、合意された時間内に何らかのタスクを完了するために、多くの感情と努力を投資する必要があることがわかりました。 プログラマーは、マネージャーからの圧力の下で、不当に楽観的な用語を呼び出す場合があります。 さらに悪いことに、マネージャー自身がプログラマーに期限を要求する場合。
多くのプログラマーの目から見たタイミングは、マネージャーにとって懲罰的で非難的なツールです。 そのようなプログラマーにとって、タイミングは感情的な不快感を引き起こします。 プログラマーが感情レベルで気分が悪いとき、彼の有効性は低下する可能性があります。
プログラマーは、適切なタイミングでタスクを閉じる時間がないことに気付いたとき、熱意と集中力を高めて作業します。 私はこれから2つの結果を見ます：
- プログラマの操作上の敏ility性が低下します。 彼が仕事に遅れていることを知っている場合、彼は仕事の集団の一般的な生活の中でより受動的な位置を占めます-彼は新人を助けるのをやめ、将来のアーキテクチャを議論する必要があるときに頭に浮かぶ最初の決定を却下します。 複数の人が「期限切れの」タスクに取り組んでいる場合、それぞれの人が責任を一方から他方に移し始める可能性が非常に高くなります。 彼らは自分の手でイニシアチブを取り、全体的な相互作用を調整する時間がないでしょう。
- プログラマーは、他の人と同じように疲れます。 平均して50 kgの美しいコードを書いた場合、締め切りのプレッシャーの下で、彼は75 kgの美しいコードを書き始めます。 しかし、これは永遠に続くものではなく、75 kgのいコードの記述を開始するか、遅かれ早かれ50 kgの美しいコードの標準的な生産性に「ロールバック」します。 そして、この期限切れのタスクの完了後すぐに、彼はすぐに負の方向にロールバックします-少なくとも最初の数日間は、彼は30〜40 kgの美しいコードしか書きません。
最終的に、プログラマーは、「
私は何を責めるべきですか？ 今、私の仕事に余分な努力を注ぐ必要がありますか？ 期限を間違えたからといって？ 「。 そのような考えがあると、どんな人でもすぐに働く意欲を失います。
誰のせいですか？ そして、状況を保存する方法は？いつものように、真実はマネージャーとプログラマーの間のどこかにあります。 マネージャー側では、次のことを行います。
- プログラマーが自分の日付に名前を付けることができるようになりました（これがまだ行われていない場合）。 プログラマーが私からプレッシャーを感じていて、あまりにも速い期限に名前を付けようとしていることがわかったら、このプレッシャーを取り除こうとします。間違った期限を呼び出すプログラマーが必要なのはなぜですか？
- 私は用語の有効性を見ました（ありがとうncix ）。 プログラマーのタイミングに関する私の質問が拒否された場合、「ああ、1か月で完了します。」 それからプログラマに、1か月のうちにどのようにこれを行うか、どのサブステージで作業を中断するかを示すように依頼します。 各サブステップを完了するのにどれほど早く期待するか。
- プログラマーとの感情的な理解を確立しました。
- プログラマーは、「スタック」タスクがある場合、圧迫されることはありません。 彼はただマネージャーのところに行き、「ステパニッチ、とにかく、私には時間がありません...私たちは何をしているのですか？ タスクに余分なリソースを与えますか、それとも時間を遅らせますか？」
- プログラマーは、期限に間に合わなかったという罪悪感を感じなくなり、マネージャーとより率直になります。 タイミングは、もはやプログラマーの目にはマネージャーの懲罰的なツールではありません。
- チームの誠実さと正義に従うべきです。 なぜなら 私はプログラマーに関して高いレベルの信頼と自由を提供しますが、そのようなプログラマーが迂回してこれから利益を得ようとするかもしれません。 そのようなプログラマは、チームから除外する必要があります。なぜなら、 彼らは道徳を損なう。
私がプログラマーなら、次のことをします。
- 彼はまた、マネージャーと感情的な理解を確立しました。 明日、マネージャーのところに来て「ステパニーチ、時間がない...」と言いたくはありません。ステパニーチが私を困惑させることを恐れます。
- 私は弱点を与えません。締め切りについて尋ねられ、彼らの顔が明日それを必要とすることを示すとき、私は感情的なプレッシャーに屈しないようにし、仕事の量をひたすら評価します。
道徳と賞品の分配非難と権利はこのような状況ではありません。 社内の期限ポリシーのためにソフトウェア開発の品質または速度が低下した場合、両方の責任があります。 タイムラインが必要で便利です。 しかし、締め切りは柔らかくなければならないように思えます。労働者は、松葉杖を書くか、そうでなければ感情的に疲れてしまうなら、締め切りを「落とす」方がよいことを理解する必要があります。 私たちはまだ千里眼ではなく、締め切りは常に不正確であるため、締め切りを調整できるという事実についてオープンにする必要があります。