私は5人以上の開発者を持つチームリーダーです。私には開発者がいます（彼をAと呼びましょう）。彼は優れたプログラマーで、きれいでわかりやすいコードを書いています。しかし、彼は管理するのがいくぶん困難であり、時々彼は本当に成績が悪いのかどうか疑問に思います。

1. 弊社では、開発者が使用するバグトラッカーで作業の進捗状況を示すことを要求しています。プログラマを監視するためだけでなく、関係者に進捗状況を知らせておくためです。問題は、Aはタスクの進行状況が完了したとき（最初に作業を行ってから3週間後）にのみ更新するため、開発週の途中で何が起こっているのか不思議に思う人を残します。彼は繰り返し調査しても習慣を変えませんでした。（大丈夫、開発者は事務処理が嫌いです、私もそうです）
2. 最近2〜3か月、彼はさまざまなイベントのために非常に頻繁に休暇を取ります。病気であるか、多くの個人的なイベントに出席する必要があります。
3. 各月のスプリントまたはロードマップを定義します。また、スプリントの最初に、各開発者がスプリントで行う必要のある作業量について説明し、開発者は各タスクに必要な時間を設定することができます。彼は通常、それらすべてを完了することはできません。（大丈夫です。開発者は自分のせいではなく、定期的に締め切りを逃しています）。
4. 私はシンガポールに拠点を置いています。それが重要かどうかわかりません。ええ、アジア人はtic黙であることが知られていますが、それは重要ですか？

上記のイベントの1つまたは2つだけが発生した場合、Aのパフォーマンスが低下しているとは感じませんが、それらはすべて一緒に発生します。だから私は、Aのパフォーマンスが低いと感じています。

これは、プログラマーとしての私の長年の経験に基づいた感覚です。しかし、私は間違っている可能性があります。

プログラマの仕事を測定することは、2つのタスクがすべて同じというわけではなく、プログラマの会社へのコミットメントを測定する標準的な目的がないため、測定が難しいことで有名です。プログラマーが自分の仕事をしているのか、怠けているのかを見分けるのは、まったく不可能です。あなたができることは、それらを信頼することだけです。ええ、信頼性と自律性を与えることは、プログラマーが仕事をするための最善の方法です。多くの場合-しかし、彼らがあなたの信頼を濫用している場合、あなたは知っていますか？

結果：

彼のパフォーマンスに対する私の認識について、私は彼とまっすぐ話しました。彼が自分の最高のレベルで演技していないと感じたことを示唆したとき、彼はinした。彼はこれが完全に不公平な気持ちだと感じました。それから私はこれが私の気持ちだと答え、私の気持ちが正しいかどうかわからなかった。彼はこれのどれも持たず、すぐに議論を終了しました。

彼が去る前に、彼は非常に冷たい口調で「会社にもっと多くを与えようとするだろう」と言った。私は彼の反応に驚いた。何らかの形で彼を怒らせたと確信しています。しかし、それが彼にとってとても率直であるために私がするべき正しいことであったかどうかはあまりわかりません。

私の質問は次のとおりです。プログラマーのパフォーマンスが低いかどうかはどうすればわかりますか？これについて、私よりもよく知っている経験豊富なチームリーダーがいますか？ 

追加のメモ：

1. 私はマイクロ管理が嫌いです。したがって、ソフトウェアプロセスに必要なものはすべてスプリント（タスクに優先順位が付けられて割り当てられ、月末に行われた作業量のレビュー）です。開発者は、日々の作業に合わせてタスクを更新する必要があります。
2. スタンドアップミーティングなどはありません。主に私たちには自宅で仕事をする自由があり、誰もがこの自由を大事にしているからです。
3. 締め切りを設定するのは私ですが、開発者が各タスクの見積もりを提供し、見積もりに基づいて、特定のスプリントに入るタスクを決定します。スプリントの終わりにタスクを完了できない場合は、次のタスクにプッシュします。したがって、理論的には、スプリント全体で1つまたは2つのタスクしか実行できず、残りの99タスクを次のスプリントにプッシュできますが、これを正当化する限り、彼は毎日の作業進捗の更新の形で問題ありません

これは驚くほど簡単に解決できる問題です。

彼と2回目の会議を行います。おそらくあなたの現実の認識が間違っていることを受け入れると彼に言ってください。そして、それを「しかし、もしそうなら、私たちの認識を改善するために協力する必要があります。」でそれを修飾します。最後に、その問題を解決するように彼に挑戦してください。そうすれば、彼は微妙に管理されているとは感じません。

このことはずっと前に私に起こりました。私にとっての問題は、私が単に自分の仕事をするために余分な信用を求めていると誰かが考える可能性を嫌うことでした。そして、それは十分に公平でしたが、スタッフのメンバーとラインマネージャーの間に定期的なフィードバックループが必要です。

ない場合は、これらの問題が発生します。

定期的で計画的な1：1は素晴らしいアイデアです。そして、人々が指摘しているように、スタンドアップは在宅勤務と直交する必要はありません。しかし、それらには3つの質問が含まれている必要があります。昨日は何をしましたか？今日は何をする予定ですか？そして、ほとんどの人が忘れているものは...（もしあれば）何があなたを支えていますか？

それは言った、あなたがすべきチームメンバーが一緒に働くことはありません状況を阻止しようとします。私は以前にそのような状況で働いたことがあり、それがチーム内外の不信の種となりました。全員がオフィスに来る定期的な日を設けてください。定期的な会議を開き、プロセスの改善などについて意見を述べることができます。

行報告イベントにしないでください。ただ話をする機会にしてください。あなたが学んだことに驚くでしょう。可能であれば、それを社交的なイベントに変えて、絆のエクササイズとして勤務時間に数杯飲みましょう。

ここにはたくさんの素晴らしいアドバイスがありますが、私はそれを取り上げたくないので、これを別の回答として投稿しています。

最初に、問題の根本原因を発見していないことは、私（および明らかに他の人）に明らかです。あなたは症状を見つめ、それを治そうとしています。自分とこの開発者との間に大きな摩擦を引き起こしているものを見つける必要があります。おそらくあなたは権威が強すぎます（私の製品所有者は最近、プロジェクトに対して「Infinite Power」を持っていると説明しました。おそらく彼は深刻な家族の問題を抱えている（仕事が終わってからずっと説明するだろう）。ここには根本的な問題があり、それが見つかるまで修正されません。

グッドキャッチ！

彼のパフォーマンスがもっと良くなるなら、それはあなたがそれを決定したという素晴らしいことです。ただし、彼の悪いパフォーマンスが比較してまだ良いパフォーマンスである場合は、優れた開発者を失うことを避けるために慎重に踏む必要があることに注意してください。優秀な開発者を見つけるのは難しく、優秀な開発者には非常に具体的な一連のことが必要です。おそらく見てみましょうジョエルテスト彼のニーズが満たされているかどうかを確認します。

問題の原因を見つける

彼がしている仕事に関連する何かに不満がある場合は、問題の原因を特定することによってのみ修正できます。プログラマーが良いコードを書いたと言っていました。つまり、彼はプログラミングが大好きだということです。（会議の説明から）彼が仕事に不満を抱いていることは明らかであり、おそらく彼のパフォーマンスが本来あるべきレベルを下回っていることは間違いありませんが、を仮定しないでください。多くのプログラマーは単にソーシャルスキルを持っていないことに注意してください。

あなたも完璧ではない

時々、特に内向的な人格との衝突が起こることを忘れないでください。これが性格の対立であることが判明した場合、パフォーマンスを向上させるためにどこまで進んでいくかを検討してください（1を参照）

そのすべて

プログラマーの管理に関するブログ記事を書きました。あなたはそれを読むべきだと思います。

http://deltreey.blogspot.com/2012/07/managing-programmers.html

その投稿の最後の部分を十分に強調することはできません。

開発者がまったく得意であれば、開発者はコーディングを望んでいます。

あなたのプログラマーは、たとえ彼が怠けていても、怠けたくありません。この問題の根源を見つける必要があり、それは単に修正できないものであることが判明し、彼を手放す必要がありますが、それが何であれ、それを決定せずに情報に基づいた決定を下すことはできません。

あなたが説明するように誰かが「やや管理が難しい」と感じた場合、どのように実行するか、開発チームのメンバーの生産性に影響する問題（客観的または主観的）があるかどうかをよりよく理解するために、あなたと定期的に1：1の慣行を確立することを検討してください優れた記事「アップデート、ベント、災害」で紹介されているチームメンバー：

... 1：1のすべてが深く隠れた緊急災害を発見するための曲がりくねった事件であることを示唆しているわけではありませんが、不満が静かに現れるかもしれない週ごとの場所を作りたいと思います。1：1は、チームの健全性を理解しながら、毎週予防保守を行うチャンスです。

... 1：1の成功したレジメンを囲む音は沈黙です。1：1で行われるリスニング、質問、およびディスカッションはすべて、管理上の予防保守です。プロジェクトへの関心が衰え始め、それが仕事の不満になる前に行動を起こし始めるのがわかります。2人の従業員間の緊張について聞き、会議で大声で試合をする前に議論を調整します。健康な1：1の文化に対するあなたの報酬はドラマの明らかな不足です。

_{言及された記事の非常に強い点は、利点を説明するだけでなく、基本的に他のソースを掘ることなく定期的な1：1の練習を開始できる実用的な推奨事項のセットを提供するという意味で、自己完結型であることです追加情報が傷つくことはありません）。}

明らかに、ここには大きなコミュニケーションの問題があります。彼は素晴らしい仕事をしているのかもしれませんが、彼が今何をしているのかわからないという気持ちがあれば、それ自体が問題です。そして、あなたが彼が何をしているのかわからなければ、彼の同僚もおそらく知らないでしょう。これは、彼が2週間前のコードをチェックインするときに問題を引き起こす可能性があります。特に、同様の分野で作業している人がいた場合。

この種の競合を最小限に抑えるために、より頻繁に更新をチェックイン/提供することをいつでも提案できます。これにより、「何をしているのかわからない」というよりも、チームを支援するという点でリクエストを処理できます。

私はスタンドアップが多くの憎しみを得るのを知っていますが、実際に同じ部屋で開催される必要はありません。1日1回のクイックコールまたはグループSkypeの更新は非常に迅速であり、全員が同じページにアクセスできます。

私は現在、アイルランドのチームでインドから仕事をしていますが、毎日それぞれと連絡を取り合っていないと想像することはできません。

無意味

毎日のステータスの更新は無意味です。「今日、私は2.5％完了しています」、「今日は3.74％完了しています」と報告するのはばかげています。

それは利害関係者に価値を提供せず、仕事をしている人々を悩ます。

邪魔されることなく、仕事に任せてください。

ベースレス

開発者Aが「業績不振」だと思う理由は何ですか？彼/彼女の仕事が時間通りに行われている場合、それは十分に良いはずです。

あなたはマイクロ管理が嫌いだと言いますが、あなたが説明したのはまさにそれです。

弊社では、開発者が使用するバグトラッカーで作業の進捗状況を示すことを求めています。プログラマを監視するためだけでなく、関係者に進捗状況を知らせておく必要があります。...開発者は、日々の作業に合わせてタスクを更新する必要があります。

これは無意味です（上記参照）ナンセンスです。あなたのチームはハンバーガーをひっくり返すのではなく、技術的なソリューションを作り上げています。進捗状況は直線的ではなく、簡単に測定したり、推定することもできません。たとえそうであったとしても、そのような毎日の測定値や推定値には価値がありません。

危険な

開発者Aが「パフォーマンスが低い」という「気持ち」の根拠を再検討します。あなたは彼/彼女がより良くできると思いますが、どんな証拠に基づいていますか？

不幸な！=パフォーマンス不足

説明されているように続行し、ある時点で、開発者Aは自分が過小評価されていると判断し、会社に十分に与えて、別の会社を見つける可能性があります。従業員の努力の最後の0.01％を絞ることは、それらを長期にわたって保持することよりもはるかに重要ではありません。

開発者は、自分が行っていることを文書化してステータスを更新する努力を嫌うかもしれませんが、それはプロの開発者であることの一部です。問題ログの更新が遅れているために、彼の仕事に対する不必要な否定的な認識が生じていることを指摘してみることをお勧めします。彼がコミュニケーションの失敗がパフォーマンスの問題であることに気付かない場合、あなたは彼のチームリーダーです。彼に言うことがあること。

推定について-それは古典的な問題です。Steve McConnellによる「ソフトウェア評価-黒い芸術の謎解き」を読むことをお勧めします。この例では、ほとんどの開発者が過小評価しているという印象を与えます。奇妙なことに、これは正常であり、めったに対処されません。この個人ではなく、推定プロセス自体に問題があることをお勧めします。

見積もり-測定-レビューの「ループを閉じて」改善してください。その後、開発者がより定期的に予定通りに来て、この個人がそうでない場合は、彼についてどうするかを検討できます。

最後に、スタンドアップミーティングがあります。インスタントメッセージによるものであっても。あなたが望むのは、誰もが「私がしたこと、今日していること、問題点」を知っていることだけです。また、問題がある場合は、後で議論するためにオフラインにします。それは私が前にやったことであり、そのチームのために成功しました。

まず、なぜスプリントがそんなに長いのですか？スプリントは2週間を超えないようにしてください。あなたの問題の大部分はそこにあると思います。トライアルベースでスプリント時間を短縮してから、質問を再度分析することをお勧めします。

コードチェックインはどうですか？彼は常に自分のコードをチェックインしていますか？個人的には、プログラマーは本当に管理人ではなく、管理しようとすればするほどイライラするだろうと思います。実際、これらの更新タスクを実行するのは嫌いです。おそらく、PMとリードがそこにいるのはそのためです。しかし、同時に、私はスクラムミーティング中または会うたびにステータスを提供します。今、あなたがタスクを割り当てるとき、彼らはタイムラインにコミットしますか、それとも彼らにタイムラインを割り当てるのですか？

したがって、誰かが実行中かどうかを確認できる唯一の方法は、コミットされたタイムラインを作業の％にマップすることです。もちろん、2つの数値を加算するメソッドを作成するのに2日かかると誰かが言った場合、問題があることを知っているので、タイムラインは現実的なものであり、両当事者が合意する必要があります。

このように考えてみてください-1時間でコードを記述できる場合は、1時間+バッファを与えてください。彼がその時間内にあなたにそれを届けているなら、私はあなたたちが元気にやっていると思う。もし彼が質問しないなら、後で彼が合理的な説明を提供するかどうかを決めるのはあなた次第です。

できることの1つは、XPlannerなどをバージョン管理ツールと統合することです。

怠けている人を特定することになると、プログラミングの職業が他の職業と本質的に異なるとは思いません。あなたの腸で行かなければならないかもしれません。

個人的には、Aが一度に何週間も更新を提供することを拒否するのは奇妙だと思います。私は自宅で仕事をしているプログラマーであり、私の進捗状況を毎日更新する必要があるという暗黙の契約があります。これらは「公式」アップデートではなく、作成するために支払われているソフトウェアで何が起こっているかを彼に知らせる短いメールまたはIMです。更新には1〜2分もかからずに書き込みが行われ、私たちの両方に閉鎖が提供されます。バグ修正については、1日の終わりまでにバグトラッカーでチケットを解決済みとしてマークします。これらは私にとって難しい手順ではありませんが、私は非常に少ない事務処理でリラックスした作業環境を楽しんでいます。

カジュアルな更新でさえ彼から来ていただければ幸いです。あなたの投稿は非常に寛大に聞こえます。あなたが彼が長い間怠けていると疑っていたなら、あなたは彼とそれに対処するために別の言い訳を必要としません。

スカイプ上またはチャットルーム内であっても毎日のスタンドアップはこれを回避する方法ですが、利害関係者の更新として扱う場合はそうではありません。1日1回、チーム全体がチェックインして、作業内容、実行中の課題、次に行う予定を発言すると、いくつかの勝利が得られます。

• 良い理由でも悪い理由でも時間を浪費している場合でも、時間がかかりすぎていることはより透明になり、開発者が必要なときに助けを求めるよう促し、おそらく発生する必要のない研究に行き過ぎないようにしますまたは、チームの他のメンバーからの意見が彼らがそれをはるかに速くノックアウトするのを助けるとき、それの挑戦のために問題を解決します。

• あなたは、マネージャーが人々が最も頻繁にロードブロッキングに遭遇している場所を見ることができるので、時間/お金を浪費している根本的な問題をよりよく推定し、おそらく解決するのに役立ちます。

• IMO、これは、チームが比較的簡単なことをするのに誰もが通常どれくらいの時間を要するかを見ることができれば、チームが見積りを過小評価することを学ぶのに本当に役立ちます。

• 多くの場合、チームメンバーが次に何をする予定かを伝えると、優先順位を再設定するという点で伝達する必要があることを思い出します。

したがって、「％of complete」を忘れてください。他のすべての人と同様に自分自身に正直になり、より多くの経験を積むにつれてより良い/より信頼性の高い見積もりを行い、それが心に変わることなく報告するための少しの動機を人々に与えるプロセスを作るだけです-あなたが本当にできないものに番号を付けるという麻痺する運動。

経営陣は、納期が常に遅れるとは限らないことを理解しているようです。毎日スタンドアップを行うと、その前線で弾薬がより多く与えられます。なぜなら、彼らが攻撃を受けない理由について、より具体的なアイデアが得られるからです。

そして、それらを最初にやらないでください。常に間違いIMO。すべての問題であるIMOをより確実に報告できるようになるには、人々が問題に歯を戻す時間を必要とします。

説明責任よりもコミュニケーションに関するものであり、単に目標を設定するだけの素早いスタンドアップは、私の意見ではアジャイルを機能させるものです。残りの部分、特にスクラムは、経営者/関係者のヘビ油と見なされるようになりました。

業績不振？

強度は、人のキャリアの中で衰退して流れます。もし彼が彼の費用以上の価値があるなら、彼と話をして、彼の仕事を楽にするようにしてください。または、代替品を探し始めます。

コミュニケーション

毎週の会議に頼らないでください。ほとんどの人は完全なブレインダンプを行うつもりはありません。さらに1：1をスケジュールします。物事がどのように進んでいるのか、あなたがより良くできること、そしてあなたが彼らがより良くできると思うことを彼らに尋ねてください。時々、何も話すことはありませんが、それは大丈夫です。1：1を増やすことで、何かに言及することを忘れないようにできます。

より永続的なコミュニケーション手段を持っている

余分な雑用のように感じない限り、人々からより多くの情報を得ることができます。すべてがリモートの場合は、HipchatやIRCなどのログ機能を備えたチャットプログラムを使用するように依頼します。より持続的なコミュニケーション手段があると、人々はより多くのことを話すようになります。他の人が同じことをするように促すために、例を挙げて率直に話し合います。少なくとも1日に1回、プロジェクトのどこにいるのかを人々に言ってもらいます。チャットを見るだけで、状況がどのように進行しているかを感じることができます。

ソース管理

全員に毎日コードをチェックインしてもらいます。gitを使用している場合は、会社のレポの独自のブランチにプッシュしてもらいます。コミットを見ることで、コミットの様子を知ることができます。

手段を両端から分離する

利害関係者は更新したいですか？自分で利害関係者に対処する。マネージャーとしてのあなたの仕事の一部は、たわごとの傘になることなので、コーダーは自分の仕事に集中できます。チャットログとコミットを確認し、状況の概要を書きます。

これらは私の提案です：

1. イノベーション：想像力と創造性は、コストを削減し、現在の状況を改善するために使用されていました。

2. Corporation：他者が目的を達成できるように支援する意欲

3. イニシアチブ：非定型のジョブとタスクの試行。

4. 出席：欠席または遅刻、基準以下。

5. 注意力：新しい情報と状況をすばやく理解する能力

6. 精度と品質：コードのレビュー、期限内の配信、発行率）。