podcast - 慢性的な時間の問題にどう対処するか?

Question

私のスタッフには、締め切りや見積もりを慢性的にオーバーシュートする開発者がいます。いくつかのプロジェクトで、この 1 週間か 2 週間毎日、「一日の終わりまでに終わらせるべきだ」と耳にします。この開発者は良い仕事をしています。

私はすでに彼の問題について彼に話しました。彼は本当にイライラしているようで、それらを修正するために何をすべきかについて腹を立てています。

私の質問は次のとおりです。

期限を過ぎた場合の罰則にはどのようなものがありますか?
この従業員に自分の行動 (時間の見積もりなど) を取り締まるように強制するには、どのような方法がありますか?

UPDATE : 応答に基づく。これが私が考え出したものです。

罰は悪い考えです。
従業員が介入なしでは見積もりの問題を解決できないのは当然です。
締め切りまでに完了しなかったことによる会社の結果 (契約の喪失) がない限り、期限を設けないでください。
利用可能な方法 (アジャイル、Joel のチェックリスト) を利用して、開発者がより適切に見積もりできるようにします。

リンクと情報をありがとう。また、私の考えを更新してくれてありがとう。

score 43 · Accepted Answer

問題は、彼がこれらの締め切りに間に合わないことではないと思います。

彼はタスクを完了するのにかかる時間を見積もるのに本当に問題があると思います.

タスクにかかると彼が言っていることと、タスクを完了するのに実際にかかった時間を日記につけ始めてもらいます。最終的に、このジャーナルは、彼がより良い見積もりを作成するための一種のガイドになります. 彼が見積もりが上手になると、急いだり急いだりする必要はありません。

score 29 · Accepted Answer

Joel Spolsky による興味深い記事があります: Evidence Based Scheduling

1) 分解する

数日、さらには数週間単位のスケジュールを見ると、うまくいかないことがわかります。スケジュールを時間単位で測定できる非常に小さなタスクに分割する必要があります。16時間以内です。

これにより、実際に何をしようとしているのかを理解する必要があります。サブルーチン foo を書きます。このダイアログボックスを作成します。Fizzbott ファイルを解析します。以前にサブルーチンを作成し、ダイアログを作成し、ファイルを解析したことがあるからです。

ずさんな人で、3 週間の大きなタスク (たとえば、「Ajax フォトエディターの実装」) を選んだ場合は、何をしようとしているのかを考えていません。詳細に。一歩一歩。そして、何をしようとしているのか考えていないときは、どれくらいの時間がかかるかわかりません。

16 時間の最大値を設定すると、いまいましい機能を設計する必要があります。「Ajax フォトエディター」と呼ばれる詳細なデザインのない 3 週間の機能を持っている場合は、それを壊して申し訳ありませんが、公式には運命づけられています。あなたはそれが取ろうとしているステップについて考えたことがなく、それらの多くを忘れているに違いありません.

重要な点は、彼 (そしてあなた) が彼の過ちから学び、次の見積もりでそれらを考慮に入れる必要があるということです。

また、あなたが開発者であれば、彼の開発プロセスをよりよく理解するために、1 日の終わりに定期的にコードレビューを行います。

そしてもちろん、反復回数を減らし、タスクの粒度を高めます。タスクの最大期間を 1 日に設定します。それが私たちのルールです。

score 20 · Accepted Answer

あなたの最初の質問が どのような種類の罰を考慮すべきかということであれば、あなたは真っ先に敗者だと思います. 彼が良い仕事をしていると感じたら、締め切り/見積もりを見て、そもそもそれらが現実的かどうかを確認する必要があるかもしれません. 問題の開発者が関与していない場合、それは問題の一部である可能性があります。

ペアプログラミングと、おそらくあなた自身との定期的な一日の終わりの進捗状況のレビューが彼を助けることができるという@OTislerに同意します... ただし、締め切り/見積もりが非現実的である場合、それはあなたの問題がある場所ではありません.

いくつかの特定のタスクを詳しく監視すると、問題がどこにあるかが明らかになります。

score 16 · Accepted Answer

期限を過ぎた場合の罰則にはどのようなものがありますか?

なし。あなたが彼を怒らせれば、彼はその仕事をしないか、別の仕事を見つけるでしょう。彼の見積もりが外れている理由を彼が理解するのを手伝うべきです。スティーブ・マコーネルによる見積もりの作成に関する本があります。私はそこから始めます。

この従業員が自分の行動 (時間の見積もりなど) を取り締まるようにするには、どうすれば一貫させることができますか?

彼が見積もりを行う正しい方法を見つけるのを助けることによって。

score 10 · Accepted Answer

まず、要件が明確であることを確認してください。

私はそれを言うのは嫌ですが、私の経験では、期限が過ぎていることは、監督者の側の不明確な要件または弱い仕様の問題であることがよくあります。最初にすべきことは、問題があなたに起因するものでも、あなたによって悪化するものでもないことを確認することです。

また、要件と彼の見積もりが現実的であることを確認してください。

非現実的な要件を満たすために、あなた自身の期待が彼に非現実的な見積もりをするように促していないことを確認してください。

要件を実行することを忘れないでください。ただし、開発者は常に見積もりを実行するため、削除する機能も指定しない限り、「これをもっと速く実行できますか」に左右されないようにする必要があります。

次に、彼が自分の時間/タスクを正確に追跡していることを確認します。これにより、プロジェクトで何が起こっているかをよく把握できます。

このプロセスは、適切な時間/タスクの追跡の欠如を示します。これは、改善への最初のステップになる可能性があります。プロジェクトの後で特定のアイテムにかかった時間がわからない場合は、それが問題の原因である可能性があります。見積もりに十分な定義がないか、プロジェクトの途中で発見されたが見積もりが行われなかった「依存関係」タスクが欠落しています。。

クリープがどこにあったか、またはクリープについて何ができるかを知る前に、正確に何をするのにどれだけの時間が費やされたかを知る必要があります。

次に、彼の見積もりが失敗している場所を確認し、その理由を理解します。吹き飛ばされたプロジェクトの見積もりを調べて、それをプロジェクト自体にします-解決すべき問題です。

彼の見積もりが実際に問題の原因であると判断したら、彼とおそらく別の開発者と一緒に行った見積もりを調べて、その理由を理解します。

これは、問題の原因を特定するのに役立ちます。問題をしっかりと理解することが実際の解決策になる可能性があります。

最後に、あなたが実際に罰や強制を試みなければならないポイントに達した場合、それは彼を解雇して最初からやり直す時です。

罰と強制は、特定の状況での故意の不正行為に対する適切な対応です。

ただし、この開発者が積極的に良い仕事をしようとしている場合は、否定的な態度と欲求不満を生み出すことによって状況を悪化させるだけです。

問題を解決できず、問題があなたではなく彼にあると確信している場合は、彼を解雇し、期限を守ることができる開発者を雇う時が来ました。あなたのコストが爆破されて利益が窓の外に出るとき、素晴らしい仕事はあまり意味がありません。

score 6 · Accepted Answer

開発者は楽観的です。それに対処するのが経営者の仕事です。誰かを罰するならマネージャー（あなた？）

少なくとも質問してよかったです。このリストからいくつかの良い答えが得られたようです。それらが役に立ち、実際に機能するものを実際に実装する方法を見つけてくれることを願っています.

私が若い頃、私の最初の優れたマネージャーは次のように対処しました。

まず第一に、彼は私に項目別のリストを作成させました - タスクを時間に分割し、それぞれを非常に自由な見積もりで見積もります - タスクがどれほど小さいかに関係なく、期間は4時間未満であってはなりません.

それから彼はそれらを見て、私の見積もりをすべて2倍にするように言いました. (開発者、特に若い開発者は、運が良ければ 1 日の約 1/2 しか生産的ではないという事実について考えていません。行う）。

それから、スケジュールを作成する前に、彼は私の見積もりをすべて倍増させました (私には言わずに)。

上からのスケジュール要件に関係なく、彼はそれらをこのように変えました。優れたマネージャーは、2 日以内に完了しなければならないと言っても、それが可能になるわけではないことを認識する必要があります。

見積もりが上手になるにつれて、私たちはそれに気づき、それに応じて調整しました。

マネージャーの仕事はプロジェクトを作るだけではなく、チームを作ることです。多くの場合、何らかのトレーニングが必要になります。これはまた、エンジニアではないエンジニアリングマネージャーが受け入れられない理由でもあります。

プロジェクトやスケジュールの失敗は、実質的に開発者のせいではありません (ただし、開発者が実際には修正できない、または価値がなく、解雇する必要があるいくつかの慢性的なケースを除きます)。マネージャーは、開発者を雇ったり、信頼したり、管理したり、プロジェクトに人員を配置したりする際に、間違った決定を下しました。

そして本当に、とにかく障害とは何ですか？マネージャーがプロジェクトを実現するのが苦手な場合は、指摘してくれる人が必要になると思います... HIS マネージャーが少しでも上手であれば、なぜここまで進んだのか、あなたがそれを修正するために何をしたのかを尋ねるでしょう。など

マネージャーを雇うことは、問題を解決するために誰かを雇うことです。開発者の生産性を高める。彼らを生産的にすることができないのなら、彼は適任者ではありません。

score 4 · Accepted Answer

あなたの質問に：

締め切りに間に合わなかったために人々を罰することを選択した場合、良い結果は得られません。彼らは意欲を失い、軽蔑されていると感じます。締め切りに間に合わせるように人々を押し続けると、作業の質が低下し、その後のバグ修正に多くの時間が費やされることになります。
彼の時間の見積もりを改善するために、結果の見積もりを改善するための素晴らしいフィードバックループを備えたJoelSpolskyの証拠ベースのスケジューリングを使用してみることができます。

しかし、私はあなたが考える必要があると思ういくつかの質問があります。

彼は他の誰よりも遅いですか？もしそうなら、なぜ-それは彼が過度に楽観的な見積もり者または遅い労働者であるためですか？楽観的すぎる見積もりは簡単に修正できます。上記の証拠に基づくスケジューリングに従って、彼のすべての数値に係数を掛けるだけです。彼が遅い労働者なら、なぜですか？彼は気が散りますか？彼は非常に低い欠陥コードを生成するように非常に注意していますか？彼はエンジニアリングソリューションを超えていますか？彼はコードを効果的に再利用していませんか？

期限は重要ですか、それとも管理階層の進捗状況を報告するための見積もりに基づく任意の日付ですか？後者の場合は、彼の見積もりを自分で調整することでこれを解決できます。

score 3 · Accepted Answer

動機

まず、ピープルウェアを読む

次。創造的であるべき人々を管理するのに罰が効果的な方法になるのはなぜだと思いますか? マネジメントとチームのアプローチ全体を再考する必要があると思います。

私が見ているように、マネージャーの最初の、そして最も重要な役割は、開発者が創造的で生産的であることを確認することです。それらが生産的であるというわけではありません。その小さな言葉に大きな違いがあります。創造性を発揮するには、安全な環境が必要です。締め切りと処罰の脅威の両方から常にプレッシャーにさらされることで、安全とは正反対のものを生み出します。

また、マネージャーとして、意思決定の基礎となる正確な情報が必要です。これには安全な環境も必要です。正直で率直であることに対する処罰のリスクがある場合、嘘をついたり、情報が不足したりすることが保証されています. 決定を下すには非常に危険な基地です。

見積り

指摘されているように、見積もりは見積もりです。私たちのチームでは、個別に見積もりを行うのではなく、チームとして見積もりを行います。(私たちが行っていることをスクラムと呼ぶのは少し気が進まないのですが、ほとんどの場合、それをエミュレートしようとします) これは見積もりを行うための非常に優れた方法だと思います: 各チームメンバーには、0 の数字で構成されるカードのデッキが与えられます。 ,1/2,1,3,5,8,13,20,40,60,100 であり、タスクを見積もるとき、各開発者はカードを選びます (見積もりに影響を与えないように、全員がカードを選ぶまでカードは非表示になります)。選択されたカードが見積もりとして使用されます。

数値の精度が次第に低下していく様子に注目してください。これは設計によるものです。これは、大きな推定値は必然的に精度が低くなるためです。

私たちのチームでは、見積もりに「理想工数」という単位を使用することを選択しました。私たちの誰もが覚えている限り、理想的な日はまだ発生していませんが、暦日を「理想的な人日」に変換する方法を知っている場合、それは良い基礎となります.

スクラムが規定しているように、開発は 2 週間のスプリントで行われ、その後新しいバージョンが本番環境にデプロイされます。各スプリントの後、完了したタスクの見積もりの合計を取り、それをスプリントの計画工数で割ります。この要素は、チームが 2 週間に費やすことができる「理想的な工数」を見積もる基礎となります。

個々の開発者が実際に行った作業項目については、見積もりは必要ありません。最初の概算は、完了するまで常に 1/2 - 1 日です。この見積もりが誤りであることが判明した場合は、仲間の開発者を集めて一緒にやり遂げてください。または、作業項目をより小さなタスクに分割して、より適切に分散できるようにします。

score 3 · Accepted Answer

期限を過ぎた場合の罰則にはどのようなものがありますか?

あなたは要点を述べて、それを逃しました。期限を過ぎた場合の明白な罰は死です。締め切りを過ぎても開発者がまだ生きている場合、「締め切り」は明らかに実際の締め切りではありません。敬語を使って開発者に圧力をかけるのはおかしいと思いますか?

言葉遣いを修正します。

score 2 · Accepted Answer

私を驚かせたのは、あなたがこれらの男を 1 人しか持っていないということです。

エンジニアは、何かにかかる時間を見積もるのが苦手です。他の開発者の見積もりを注意深く見ると、多くのパディングが見つかるはずです。パディングが必要ない場合もありますが、とにかくタスクが拡張されて利用可能な時間を埋めます。

これに対する解決策は、見積もりの方法を変更することです。開発者は絶対時間の見積もりは苦手かもしれませんが、相対時間の見積もりは得意です。そのため、月曜日に、「whoosiwhatsit を追加するのにどれくらいの時間がかかりますか?」ではなく、「whoosiwhatsit で 1 週間以内に何ができるでしょうか?」と尋ねます。それがその週の彼らの仕事になります。

次の月曜日、あなたはそれがどうなったかを見ます。「ええと、floogle を 2 日でインストールしましたが、それが mcphee に影響を与えていることが判明しました。今週は、whoosiwhatsit ファイルが上書きされないように、それらの人たちを分離する必要があります。」わかりました、今週の彼らの仕事があります。

whoosiwhatsit がいつ準備できるかはまだわからないので、役に立たないと思うかもしれません。それは本当だ。ここには 2 つの選択肢があります。

締め切りが必要な場合は、他の開発者と同じように、誤った開発者に見積もりを押し付ける必要があります。彼がコツをつかむのにそれほど時間はかからず、1日かかるはずだったものを書くのに、あっという間に「2週間」かかることになります。

もう 1 つの選択肢は、架空の見積もりと引き換えに可視性を高めることです。長期的には、このアプローチにより生産性が向上し、エンジニアの満足度が向上します。

score 2 · Accepted Answer

マイルストーンを設定し、@OTisler が提案したようにアジャイルを試してください。

score 2 · Accepted Answer

彼を罰するべきではないと思います。正確な見積もりを行う方法を彼に理解させてください。

チームリーダーとして、締め切りまでに X 機能を完成させるのは「問題ない」とチームメンバーに言われました。それから私は通常、彼らと一緒に座って、機能を完成させるために実行する必要があると思われるタスクとサブタスク、および開発者がそれぞれにかかると考えている時間を検討します。

この演習を行って、すべてのタスクとサブタスクの見積もりを合計すると、開発者が当初の見積もりで考えていたよりもはるかに長い時間がかかることは避けられません。彼らがより正確な見積もりを作成し始める前に、私は通常、彼らと一緒にこの演習を数回行うだけで済みます.

score 1 · Accepted Answer

自問自答してください: あなたの仕事は何を伴いますか?

開発者からの見積もり (良い見積もりができないことを知っている) をやみくもに管理ラインに渡し、その見積もりが達成可能かどうかを自分で判断しない場合は、仕事をしていません。

「付加価値」の観点から考えてみてください (私の以前の雇用主の 1 人はこの用語をよく使っていましたが、私はそれが嫌いでしたが、この状況ではおそらく役に立ちます)。どのような価値を付加していますか? 上層部と開発者の間で双方向に物事をやり取りしているだけでは、最終的にはお金を稼ぐことはできません。あなたは削除される可能性があり、何も変わりません。

私がこれまでに持っていた最高のマネージャーは、別のチームから与えられた一連の要件を調べて、リストを見る前に、それらのほぼ 3 分の 1 が雄牛であると率直に伝え、それらを削除した人でした。私が今までで最悪だったのは、私が今まで私が今までに頼んだことのない、この余分な管理タイプのドキュメントをすべて書くことでした (私は文字通り彼のために彼の仕事をしているという印象を受けました)。プロジェクトの期日を教えてくれても、ほとんど仕事に来ませんでした。奇妙なことに、彼らは両方とも同じ会社にいました。

score 1 · Accepted Answer

では、開発者は良い仕事をしていますが、納期を見積もることは苦手ですか? まだ処罰の対象になっているかどうかはわかりません。

たぶん、しばらくの間、配達ポイントを見積もるプロセスを彼に説明してもらいます. これは、ステップ X、Y、および Z に一定の時間がかかる理由を彼に尋ねる機会になる可能性があります。彼は、ほぼ確実に遅いペースでエクササイズを行うだけで、自分の見積もりを修正していることに気付くかもしれません。

score 0 · Accepted Answer

90時間は、一般的な短いプロジェクトの期限の1つです。簡単な方法は、「あなたの時間」を見積もる代わりに、別の時間を測定することです。コンピュータープログラマーは、自分の時間を計算すると他の人を観察するよりも大きな誤差が生じることを証拠が示しているため、プロジェクトの時間の見積もりを行うべきではありません。

podcast - 慢性的な時間の問題にどう対処するか?

15 に答える 15

1) 分解する

動機

見積り

Related

Reference