なぜ締め切りがいつもこんなに短いのですか？
私は小さな会社のジュニア開発者です（2人の開発者のチーム）。新しい機能を実装するように求められるたびに：
期限は、開発を行う時間があるように設定されています。エラーマージンはありません（何かが予想よりも少し時間がかかる場合、遅れます）。テストの時間はほとんどありません（バグがあると確信しています）。何かをリファクタリングする時間がない
機能が完全に指定される前に開発を開始するように求められるため、新しいことは表示されますが、期限はそのままです
その結果、私たちはバグのあるソフトウェアを提供し、技術的負債は増え続けています。 2006年頃に最新版とされてきた技術を採用しています。
よく覚えているリリースが1つありました。私たちが上司にデモンストレーションを行ったとき、彼は私たちに「何を！??それを作成するのに2週間かかった？！」と言った。答えられるのは「いいえ、実は3週間かかった」ということでした。私は彼と他のジュニア開発者（この会議のために会社を辞めました！）とのミーティングを行いました、そして彼は基本的に私たちがリリースしたものはがらくただったので彼は幸せではなかったと言いました。
技術的な負債とリファクタリングの必要性が非常に大きかったため、変更する必要がありました（ただし、時間がないためリファクタリングしないように言われました）。
- すでに悪いコードの上に悪いコードの層を追加する必要がありました。
- 私たちは完全に理解できないコードを試して理解するのに多くの時間を費やしました。
私はこの悪いリリースに責任があるとは感じていません。少なくともOOPの基本原則を理解するのは、優れた開発者を雇うのは上司の責任だと思います。しかし、ジュニアを雇うことははるかに安価です...
彼はすでに、私が現在取り組んでいる開発に遅れていると言っています。彼は、アプリケーションに既に存在するツールを「再設計」するために1年以上費やしましたが、今では2週間でそれを実装することを望んでいます。個人的には、正しくやりたいなら最低でも1ヶ月、あるいは6週間は必要だと思います。
上司は私たちがただ遅くて効果がないと思っていると思うので、私は何をすべきかわかりません。それは私が私が値すると思う昇給を得る方法ではありません。
なぜそうなのですか？これは、タスクを完了するのにx日必要な場合、「お願いします」と言って笑顔で尋ねても、x/2日でそれができないことを理解するのはそれほど難しくありません。それは非常に明白であるように、期限が守られない、および/または品質要件が満たされません。
ソフトウェア開発はアイコンをクリックするだけの長いプロセスであることを上司にどのように説明できるかを知る必要はありません。私は彼がすでにそれを知っていることを望んでいるからです。
本当に2つの選択肢：終了するか、バックボーンを成長させる。
辞めることについてあまり説明する必要がないと思います。それを取ることも、あえて変更することもできない場合は、それが先に進む唯一の方法です。
これを変更したい場合、これに立ち向かうのはあなたの責任です。これは「バックボーン」を必要とします。なぜなら、あなたは上司に反抗し、解雇される可能性があるからです。したがって、注意して踏んでください。
なぜあなたは押しのけられていると言っているのですか？もちろん、ジュニア開発者は経験が足りないので、シニア開発者よりもプッシュアラウンドが簡単ですが、ここで完全に見落としたように見える基本的な問題が1つあります（言うまでもありませんが）：期限は管理者ではなく開発者。
上司または一部のマネージャーが2週間かかると言い、それが短すぎると思われる場合は、専門家の行動により、この洞察について上司に通知する必要があります。結局のところ、あなたはその2週間を作業に費やす予定の開発者です。あなたよりもこの見積もりの正確さを判断する資格のある人はいません。あなたのマネージャーは以前の経験や他のチームのパフォーマンスに頼るかもしれませんが、あなたは本当の取引を知っています。特定のコードベース、その弱点、リスクなどを知っています。ユーザーの入力なしに意味のある期限を設定することはできません。
リファクタリング：これは常に興味深いトピックであり、それをスケジュールに組み込む方法について多くの優れた資料があります。ただし、これらの要点は、a）マネージャーからリファクタリングに専念する時間を決して得られないこと、およびb）それを要求するべきではないことです。取得しても、それだけでは不十分です。リファクタリングは、日常業務の一部になる必要があるものです。それはあなたの見積もりの一部でなければなりません、そしてそれはあなたがしていることの一部です。管理に向けて言及する必要すらありません。結局のところ、これが私たちがプロとして働く方法です。 1回または2回スキップして、次の期限にそれを考慮する必要があることを指摘することもできますが、それを補うことができない場合、専門家の方法は、最初から正しく完了することです。もちろん、バランスを保つ必要があり、コードベース全体を最初に半年間リファクタリングしないでください。とにかくあなたが取り組んでいることに固執し、それを増やすのではなく、可能であればそれを少しでも減らして、技術的負債を維持するようにしてください。
期限が近づいたとき-特に、承認なしに外部のソースから期限が与えられた場合-あなたが完了していないことを単に彼らに伝えるのは公正なゲームです。最初から2週間では不十分だと言った場合、2週間後に終了しないと誰もあなたを責めることはできません。ジュニアからシニアの開発者への道は、彼らの決定のためにそれが行われていないことをマネージャーに伝えるとき、まっすぐな顔を保つことができることを学ぶことを意味します。 4週間を見積もったが、2週間以内に納品する必要があった場合、遅延はnotが誤りであることに注意してください。
それにもかかわらず、マネージャーは遅延についてあなた/あなたのチームのせいにしようとします。この会社を使い続けたい場合は、さらに厳しい課題に直面します。マネージャーの心を変える必要があります！あなたは彼らに非難を割り当てることではなく、ビジネスに価値を提供することについて彼らに思い出させる必要があります。あなたはお互いに対してではなく、一緒に働くことになっていますが、あなたの言うことから、開発者と経営者の間には大きな信頼の問題があるようです。とんでもない締め切りに立ち向かうことは一つのことですが、それは今のところあなたを得るだけです。あなたが常にマネージャーと戦わなければならないなら、あなたは失敗するに違いありません（実際には両面です）。
要約すると、あなたが十分に強く、プレッシャーとストレスに追いつくことができると確信している場合は、1）最初から締め切り決定の一部であることを確認し、2）開発者とマネージャー間の信頼と信頼を向上させる必要があります。前者は比較的迅速かつ簡単ですが、後者は遅くてデリケートなプロセスであり、何年もかかる可能性があります。
締め切りが常に厳しい理由はたくさんあります。
ここでの主要な理論の1つはパーキンソンの法則です。
パーキンソン氏は次のように述べています。
それで、3か月かかるプロジェクトがあり、6か月の期限がある場合はどうでしょうか。どれくらいかかりますか？もちろん、6か月です。常に改善の余地があるからです。
より厳格な期限を設定することにより、経営陣は最高の人材を引き出そうとします。 厳しい締め切りの威力。
厳しい期限を設定する理由はたくさんありますが、良いものも悪いものもあります。また、経営理論を理解している、または理解していない善良なマネージャーもたくさんいます。
なぜ締め切りはいつもこんなに短いのですか？
なぜなら、マネージャーはあなたのストーリーの1つを気に入っているからです。見積もりプロセスを乗っ取り、独自の見方を開発者に課します。多くの場合、これは彼ら自身が以前の開発者であり、彼らの経験のおかげで彼らが良い見積もりを出すことができると思うからです。
理想的な世界では、マネージャーはプログラマーを信頼し、自尊心のある専門家と同じように、プログラマーに見積もりの作成を任せます。クライアントが定義した期限は、品質の低下ではなく、クライアントとの範囲の交渉によって満たされます。
「成長するボール」が言及されたが、それは主にマネージャーの問題であり、マネージャーは上からの圧力を持ち、彼が守れない約束に彼自身を語らせている。私の職場では、彼が約束した結果を得ることができなかったマネージャーのマネージャーが交代したときに、物事は大幅に改善されました。新しいマネージャーは達成すべき10のことのリストを与えられ、彼はそれらのうちの7つに「いいえ」とだけ言いました。そして、彼らが彼にどのように圧力をかけようとしても、7つの「いいえ」から少しもびくともしませんでした。そして、彼の下のチームは、ばかげた期限なしに、彼が受け入れた3つのタスクを達成しました。前のマネージャーがしなかったであろうもの。みんな（上下）は彼に本当に満足しています。
悪い設定が達成することは、無意味なストレス、生産性の低下、全員が失敗するために気分が悪くなる、急いで低品質の製品である可能性があります。
達成できることできる期限付きで達成する：一部タスクが完了するように優先順位を変更します。たとえば、ジョブAが90％終了したように見え、ジョブBが60％終了したように見える場合は、作業をBからAに移動して、いずれかが期限内に完了するようにします。または、ジョブのスコープを減らします。すべての計画された機能を備えたジョブAが期限内に達成できない場合は、機能を減らします。
見積もりについて：タスクにかかる時間を最もよく見積もり、あなたが本当に本当に本当に良い場合、タスクは見積もり時間にランダムな余計な時間をプラスまたはマイナスして計算します。それが「最良の見積もり」と呼ばれる理由です。見積もりを立てても、誰もそれを変えることはできません。推定値の変更を誰にも許可しないでください（最初に推定されるタスクを削減しない限り）。その後、マネージャーはターゲットを設定できます。これらの目標が見積もりに同意しない場合、それは彼の責任です。 「3か月かかる」と見積もり、「2週間でやる」と言った場合、2週間で完了しないのは彼の責任です。もし彼があなたにストレスを与え、あなたが推定3か月以内に終わらなければ、それは彼のせいです。
あなたのチームは明らかに 過度に楽観的なスケジュール に苦しんでいます：
3か月のアプリケーションを作成する人が直面する課題は、1年間のアプリケーションを作成する人が直面する課題とはかなり異なります。過度に楽観的なスケジュールを設定すると、プロジェクトの概要が明らかになり、効果的な計画が損なわれ、要件分析や設計などの重要な上流の開発活動が省略されるため、プロジェクトが失敗する可能性があります。また、開発者に過度の圧力をかけ、開発者の士気と生産性を低下させます。
あなたが本当に一生懸命働いているなら、それは管理の問題です。
いつもそうですか？締め切りはいつでも短いですか？
私の経験は：はい、通常そうです。しかし、計画が楽観的すぎると、失敗する運命にあります。
それについて私ができることはありますか？
本当に奇妙なスケジュール計画に関わっているとはどこにも言いませんでした。あなたはまだジュニア開発者なので、これはそうだと思います。それでも、彼らはあなたに尋ねるべきです。
唯一の合理的な答えは、適切に計画することです。設計、開発、リファクタリングにはどのくらい時間がかかりますか？最善の、最も可能性の高い、より悪い見積もりを与え、上司に提示します。重要なことは、見積もりからバックアップしないこと、および見積もりについての交渉を許可しないことです（ this を参照）。
人間年の見積もりを提出する場合、その数は、新しいツールや新しい問題などのリスクを推測することで、経験に基づいた直感で決定されます。通常、それはほぼ適切ですが、これを正当化することはできません。 。昔、マン年が木に成長したとき、元ソフトである私たちの上司が私たちを信頼してくれたので、私たちはそれらの時間を与えられ、出かけました。
それ以来、2つのことが起こりました。予算が削減され、管理コースがエンジニアリングの安価な代替品として発明されました。
競争がコストを削減したので、今私たちはコストを削減するために途方もない圧力の下にあるボスを持っています、そしてこれらのまさにその人々はほとんどまたはまったく技術的背景を持っていません。したがって、5人年と言った場合、彼は言うでしょう。4をあげます。これは、配管工が入ってきたときに効果があるためです。安くて急いでいる配管は、将来的に漏れが発生することを知っています。しかし、それまでに彼は家を引っ越すか、マネージャーの場合には別の支部のより良い給与の仕事に出向いたでしょう。
しかし、それは必ずしもそれほど悪いことではありません。あなたには極端なケースがあり、その会社はいつか腹を立てることになるので、新しい仕事を見つけることを真剣に考えてください。
私が何度か見た1つの問題は、PHBが製品の最初の有効なバージョンが完成していないことをまったく理解していないということです。
今日私は彼らに「それで、あなたが提案を書くとき、あなたはそれを完成させてクライアントに送るか、それとも起草プロセスを経ますか？」と尋ねます。
リファクタリングは私たちの起草プロセスです。
見積もりが不正確であるため、締め切りは常に短すぎます。
期限に関して考慮すべき重要な点が2つあります。
- 見積もりは、予想されるすべての努力に基づいている必要があります（理解、実装、新しい/以前の動作のテスト、展開などを含む）。
- 時々見積もりが間違っている
ポイント1は、見積もりが必要な作業を反映し、作業を行う人の速度でを反映している必要があることを示しています。
ただし、ポイント2は、推定値が時間とともに改善する可能性があること、および一般的な Scotty Principle を適用する必要があることを認めていますが、常に推定値が明らかに間違っている可能性があります。
締め切りが短すぎると見積りに問題があることを示すのは、チーム全体（マネージャーを含む全員）の責任です。
あなたのケースは、問題が、必要な労力のレベルを適切に調査せずに締め切りがあなたに与えられていることである可能性があることを示しています（つまり、作業にかかる時間を尋ねます）。
時々、締め切りは不動です。日付Xより前にリリースすると、すべてが支払われます。ここでは誰もが、できる限り完全に作業を完了する時間がないことを受け入れなければなりません。
最後に、過大評価されている作業によってマネージャーが過去にやけどを負ったという信頼の問題が発生する可能性があります。早期に配信してマネージャーに報告すると、信頼が築かれ、チームの態度が向上します。
これにどのくらいの労力をかけるかを決定します。それでも機能しない場合は、別のチーム/会社に移動することを決定します。
このシナリオは、この特定の会社のこの特定のマネージャーに限定されるものではなく、これを処理するyour方法を早く決定すればするほど、うまくいくことに注意してください。
締め切りが厳しすぎる主な理由は、深刻な誤解によるものだと思います。
何かを作成するときに、調整するいくつかの変数があります。
- 努力：生産に費やす必要な期間
- 経過：開始から終了までの期間
effortは交渉不可能です。タスクを完了するのに10時間かかる場合、それについてあなたができることは何もありません。しかし、別の人がそれをより速くまたは遅くすることができるかもしれません。アジャイルプラクティスでは、開発者間の速度の違いを説明するために、ポイントでの労力を測定することをお勧めします。
elapsedは、ただし、大幅に異なります。並行して作業する人数、1日あたり何時間作業するかなどによって異なります。結局、経過時間はon planning：誰がタスクに影響するか、いつ、...
多くの場合、締め切りは交渉されます。経過時間は計画（および優先順位のシフト）に大きく依存するため、確かに多少の余裕があり、したがって交渉することができますある程度。しかし、悪いマネージャーは非現実的な締め切りを課す傾向があります。なぜなら、彼らはその程度を超えてプッシュし続けているためです。
これがあなたに起こり、彼らがあなたにプレッシャーをかけ続けるとき、あなたはアジャイル運動に興味を持つかもしれません。 3番目の変数であるスコープを導入することで、アジャイルは「だまされました」。
全体のサイズを変更するのではなく、少しずつサイズを変更します（そして、ピース間の依存関係を明示的にします）。マネージャーが経過時間を短縮したい場合は、一部を削除する場合があります。