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

https://stackoverflow.com/questions/612892

03-07-2019
|

質問

私のスタッフには、納期や見積もりを慢性的に超過する開発者がいます。ここ 1 ～ 2 週間、毎日いくつかのプロジェクトで「今日中に終わらせるべきだ」という言葉を耳にします。この開発者は良い仕事をします。

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

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

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

アップデート:回答に基づいて;これが私が考え出したことです。

罰は悪い考えです。
従業員が介入なしに見積もりの問題を解決できないのは当然のことです。
それまでに完了しないと会社に不利益が生じる（契約が失われる）場合を除き、期限を設けないでください。
利用可能な方法 (アジャイル、ジョエルのチェックリスト) を利用して、開発者がより適切に見積もりを行えるようにします。

リンクと情報をありがとう。また、私の考え方をアップデートしていただきありがとうございます。

解決

問題は彼がこれらの期限に間に合わないことだとは思わない。

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

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

他のヒント

Joel Spolskyによる興味深い記事があります。エビデンスに基づくスケジューリング

1）ブレーク＆＃8216; er down

数日または数週間で測定されたスケジュールを見ると、それが機能しないことがわかります。スケジュールを数時間で測定できる非常に小さなタスクに分割する必要があります。 16時間を超えることはありません。

これにより、何をしようとしているかを実際に把握する必要があります。サブルーチンfooを作成します。このダイアログボックスを作成します。 Fizzbottファイルを解析します。サブルーチンを作成し、ダイアログを作成し、ファイルを解析したことがあるため、個々の開発タスクを簡単に見積もることができます。

あなたがずさんで、3週間の大きなタスク（例：＆＃8220; Implement Ajax photo editor＆＃8221;）を選んだ場合、あなたは何をしようと考えていません。詳細に。ステップバイステップ。そして、あなたが何をしようとしているのか考えていないときは、どれくらい時間がかかるかわかりません。

16時間の最大値を設定すると、いまいましい機能を設計する必要があります。＆＃8220; Ajaxフォトエディター＆＃8221;と呼ばれる3週間の手作業の機能がある場合詳細な設計なしで、私はあなたにそれを壊すものであることを残念に思うが、あなたは公式に運命づけられている。あなたはそれがとろうとしているステップについて考えたことがなく、あなたはそれらの多くを忘れてはいけないことを確認します。

要点は、彼（およびあなた）は彼の間違いから学び、次の推定でそれらを考慮に入れるべきであるということです。

また、あなたが開発者であれば、その日の開発プロセスについてのより良い洞察を得るために、一日の終わりに定期的なコードレビューを行います。

そして、もちろん、より小さな反復とタスクの細分性。最大タスク期間を1日に設定します。それが私たちが持っているルールです。

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

私は@OTislerに同意します。ペアプログラミングとおそらくあなた自身との定期的な一日の終わりのレビューは彼を助けることができます...ただし、期限/見積もりがあなたの問題のないところから始まるのは現実的ではない場合です。

いくつかの特定のタスクを綿密に監視することで、問題のある場所を強調する必要があります。

合格の罰の種類期限は有効ですか？

なし。あなたが彼を怒らせたら、彼は仕事をしないか、彼は別の仕事を見つけるでしょう。あなたは彼が彼の推定がオフになっている理由を理解するのを助けるべきです。推定の作成に関するスティーブマッコネルの本があります。私はそこから始めます。

これをどのように一貫させることができますか彼の行動を取り締まる従業員（時間推定値など）自分自身？

見積もりを行うための正しい方法を見つけるのを助けることで。

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

あまり言いたくないのですが、私の経験上、納期超過は、要件が不明瞭であったり、監督者の仕様が不十分であったりすることがよくあります。まず最初にすべきことは、問題があなたに起因していないか、あなたによって悪化しているのではないかを確認することです。

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

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

要件を作成するのはあなたですが、見積もりは常に開発者が行うので、削除する機能も指定しない限り、「これをもっと早くできないか」という考えに振り回されるべきではないことに注意してください。

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

このプロセスでは、適切な時間/タスクの追跡が欠如していることがわかり、最終的には改善への第一歩となる可能性があります。プロジェクト終了後、特定の項目にどれくらいの時間がかかったかがわからない場合は、おそらくそこに問題の原因があります。見積もりの定義が不十分であるか、プロジェクトの途中で発見されたものの見積もりがされていない「依存関係」タスクが欠落している可能性があります。。

どこに問題があったのか、あるいはそれに対して何ができるのかを知る前に、何にどれくらいの時間が費やされたのかを正確に知る必要があります。

次に、彼の見積もりがどこで失敗しているかを確認し、その理由を考えます。失敗したプロジェクトの見積もりを検討し、それをプロジェクト自体に落とし込み、解決すべき問題にします。

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

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

最後に、実際に懲罰や強制をしなければならない段階に達した場合は、その人を解雇して最初からやり直すときです。

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

ただし、この開発者が積極的に良い仕事をしようとしている場合、否定的な態度やフラストレーションを生み出して状況を悪化させるだけです。

問題が解決できず、問題があなたではなく彼にあると確信している場合は、彼を解雇して、期限を守ることができる開発者を雇う時期です。コストが膨らみ、利益が消えてしまっては、素晴らしい仕事をしてもあまり意味がありません。

さて、これはかなり一般的です-開発者は楽観的です。それに対処するのは経営陣の仕事です。誰かが罰せられるべきなら、それはマネージャーです（あなた？）

少なくともこのリストからいくつかの良い答えを得たようです。彼らが助けてくれることを望み、実際にいくつかの仕事を実装する方法を見つけてください。

私が若かったとき、私の最初の優秀なマネージャーはこのように対処しました：

まず、彼は項目ごとのリストを作成しました-タスクを数時間に分割し、非常にリベラルな見積もりで各リストを推定します-タスクがどれだけ小さいかに関係なく、期間は4時間未満であってはなりません。

それから彼はそれらを見て、私の見積もりをすべて倍にするように言った。（開発者、特に若い開発者は、運が良ければ、1日の約1/2だけ生産性があるという事実を考えないでください。その半分は、あなたがする必要のないものに費やしていますdo）。

その後、彼のスケジュールを作成する前に、彼は私の見積もりをすべて倍にしました（私に言わずに）。

上記のスケジュール要件に関係なく、彼はこの方法でそれらを変更しました。優れたマネージャーは、2日以内に完了する必要があると言っても、それを可能にしないことに気付くはずです。

見積もりが上手になったので、それに気づき、調整しました。

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

プロジェクトまたはスケジュールの失敗は、事実上、開発者の責任ではありません（実際には修正できない、または解雇する価値がなく、解雇する必要があるいくつかの慢性的な場合を除きます）。マネージャーは、開発者を雇う、信頼する、管理する、プロジェクトに人員を配置するなど、悪い決定を下しました。

実際、とにかく何が欠点なのでしょうか？マネージャーがプロジェクトを実現するのがあまり上手でなければ、誰かに指摘してもらう必要があります... HISマネージャーが良ければ、彼はなぜここまで来たのか、あなたがそれを修正するために何をしたのかを尋ねますなど。

マネージャーを雇うことは、問題を解決するために誰かを雇うことです。開発者を生産的にするため。生産性を上げることができない場合、彼は適切な人物ではありません。

ご質問へ：

締め切りに間に合わない人を罰することを選択した場合、良い結果は得られません。彼らはやる気を失い、軽視されます。締め切りに間に合わせるように人々を押し続けると、仕事の質が低下し、その後バグ修正に多くの時間を費やすことになります。
彼の時間の見積もりを改善するには、Joel Spolskyのエビデンスベースのスケジューリング結果の推定を改善するための素晴らしいフィードバックループがあります。

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

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

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

合格の罰の種類期限は有効ですか？

あなたは要点を述べ、それを逃しました。期限を過ぎた場合の明らかな罰は死です。期限を過ぎても開発者がまだ生きている場合、「期限」明らかに本当の締め切りではなかった。マーシャル言語を使用して開発者にプレッシャーをかけるのは面白いと思いますか？

文言を修正します。

動機

まず： Peopleware

をお読みください

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

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

また、マネージャーとして、意思決定の基礎となる正確な情報が必要です。これには安全な環境も必要です。正直で率直な態度で処罰されるリスクがある場合は、嘘や情報の欠如が保証されます。決定を下す非常に危険な拠点。

見積もり

指摘したように、推定値は推定値です。私たちのチームでは、個々の見積もりは一切行いません。チームとして見積もりを行います。（私たちはスクラムと呼ぶのを少し嫌がりますが、ほとんどはエミュレートしようとしていますが、これは本当に素晴らしい方法だと思います：各チームメンバーには、数字0で構成されるカードのデッキが与えられます）、1 / 2、1、3、5、8、13、20、40、60、100、およびタスクを見積もる場合、各開発者はカードを選びます（見積もりに影響を与えないように全員がカードを選ぶまでカードは隠されます）および平均選択したカードが推定値として採用されます。

数字の精度が徐々に低くなることに注意してください。大規模な見積もりは必然的に精度が低下するため、これは設計によるものです。

私たちのチームでは、「理想的な工数」ユニットを使用することを選択しました。推定のため。私たちの誰もが覚えている限りでは、理想的な日はまだ発生していませんが、カレンダーの日を「理想的な人の日」に変換する方法を知っているときは、それが良い基礎になります。

スクラムが規定するように、開発は2週間のスプリントで行われ、その後、新しいバージョンが運用環境に展開されます。各スプリントの後、完了したタスクの推定値の合計を取得し、それをスプリントの計画工数で割ります。この要素は、「理想的な人日数」を推定する基礎となります。チームは2週間で過ごすことができます。

個々の開発者が行った実際の作業項目には、見積もりは必要ありません。最初の近似は、完了するまで常に1/2-1日です。この見積もりが間違っていることが判明した場合は、仲間の開発者をつかみ、一緒にそれを実行してください。または、ワークアイテムをより小さなタスクに分割して、より適切に分散できるようにします。

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

私はあなたが彼を罰すべきだとは思わない。正確な見積もりを行う方法を理解してもらうだけです。

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

この演習を行い、すべてのタスクおよびサブタスクの見積もりを合計すると、開発者が当初の見積もりで考えるよりもはるかに長い時間がかかります。私は通常、彼らがより正確な推定を開始する前に、彼らとこの演習を数回行うだけです。

私が驚いたのは、このような人が 1 人しかいないということです。

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

これに対する解決策は、すべての人のために見積もりの方法を変えることです。開発者は絶対時間を推定するのは苦手かもしれませんが、相対時間についてはかなり得意です。したがって、月曜日には、「wheosiwhatsitを追加するのにどれくらい時間がかかるか」の代わりに、「1週間以内にwheosiwhatsitで何をすることができますか？」と尋ねます。それが今週の彼らの仕事になります。

次の月曜日に、それがどうなったかを見てみましょう。「まあ、私は2日間でフローグルをインストールしましたが、それはマクフィーに影響を与えたことが判明しました...だから今週、私はそれらの人を切り離す必要があります。 OK、その週に彼らの仕事があります。

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

期限が必要な場合は、他の開発者と同じように、誤った開発者に見積もりを水増しするよう強制する必要があります。コツを掴むのにそれほど時間はかからず、本来は 1 日かかるものを書くのにあっという間に「2 週間」かかるようになるでしょう。

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

開発者は良い仕事をしていますが、配信時間の見積もりが苦手ですか？あなたがまだあなたの手に罰の状況があるかどうかはわかりません。

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

これを自問してください：あなたの仕事には何が必要ですか？

開発者からの見積もり（盲目的に良い見積もりを提供できないことを知っている）を管理ラインに盲目的に渡しているだけで、その見積もりが達成可能かどうかを自分で判断していない場合、あなたは仕事をしていません。

「付加価値」の観点から考えてみてください。（私の古い雇用者の1人がこの用語を頻繁に使用しましたが、私はそれを嫌っていましたが、この状況ではおそらくあなたのために機能します）。どのような価値を追加していますか？経営陣と開発者の間で双方向に物を渡すだけの場合、最終的にはお金を稼ぐことはできません。削除される可能性がありますが、何も変わりません。

私が今までに持っていた最高のマネージャーは、他のチームから彼に与えられた一連の要件を調べ、ほぼ3分の1が雄牛であり、私が見た前にそれらを取り除いたと直接言ったリスト。私が今までで最悪のことは、私がこれまでに依頼したことのない他のマネージャーの誰も私にこれほどの余分な管理タイプのドキュメントをすべて書かせたものではありませんでしたプロジェクトの期日を教えてくれても、ほとんど仕事に出ませんでした。彼らは両方とも同じ会社にいましたが、奇妙なことに十分です。

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

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow